# Porting Another Repository

Plan how to port a feature, configuration, or implementation from this repository into...

- Repository: https://github.com/dyoshikawa/rulesync (1577 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add dyoshikawa/rulesync --skill porting-another-repository -g -a claude-code -y`
Codex: `npx skills add dyoshikawa/rulesync --skill porting-another-repository -g -a codex -y`
Cursor: `npx skills add dyoshikawa/rulesync --skill porting-another-repository -g -a cursor -y`
Gemini CLI: `npx skills add dyoshikawa/rulesync --skill porting-another-repository -g -a gemini-cli -y`

## Description

Plan how to port a feature, configuration, or implementation from this repository into another repository. Analyzes the source feature here and the target repo's conventions, then writes a multi-file porting plan (overview, source analysis, target analysis, plan, diff) to tmp/porting-another-repository-{YYYYMMDD-HHmm}/*.md for the user to review and apply manually.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

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:

```bash
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:

The rest: https://github.com/dyoshikawa/rulesync/blob/HEAD/.rulesync/skills/porting-another-repository/SKILL.md