Porting Another Repository

arguments = the user's request

Parse arguments as:

• target_repo: the repository to port INTO, in owner/repo form, a URL, or a local path
• scope: what to port from THIS repository (a feature name, directory, file, or rough description)

If target_repo is not provided, ask the user which repository to port into. If scope is not provided, ask the user what part of this repository they want to port.

The direction is fixed: the source is this repository, the target is target_repo. This skill never modifies the target repository directly, it only produces a porting plan on disk for the user to apply manually.

Step 0: Prepare the Output Directory

Compute a single timestamp once and reuse it for every file:

ts="$(date +%Y%m%d-%H%M)"
out="tmp/porting-another-repository-${ts}"
mkdir -p "${out}"

All artifacts in this run go under ${out}/. Do not recompute the timestamp per file, every file must share the same directory.

Step 1: Analyze the Source (This Repository)

Understand exactly what is being ported. Prefer targeted symbol and search tools over reading whole files.

Identify, for the requested scope:

• The entry points and the files that implement it.
• Its dependencies within this repo (shared utilities, base classes, types, config) that would also need to come along.
• Any build/test/tooling wiring it relies on (scripts, configs, fixtures, CI steps).
• External package dependencies it pulls in.

Write the result to ${out}/01-source-analysis.md.

Step 2: Analyze the Target Repository

Understand the target's conventions so the port fits in naturally.

• If target_repo is a local path, inspect it directly (grep/read).
• If it is owner/repo or a URL, use gh repo view, gh api repos/<owner/repo>/contents/<path>, and the deepwiki MCP (mcp__deepwiki__ask_question, mcp__deepwiki__read_wiki_contents) to learn its structure.

Capture: