port-feature

機能の移植

REFERENCE 実装ですでに動作している機能を、TARGET のスタックに移植し、TARGET 独自の作法に合わせます。移植への確信につながる情報、つまり機能の動作、TARGET が備えているもの、不足しているもの、再利用できるものを、discover → plan の開始時点で1つのギャップマップとしてファイルにまとめ、その後は引き継ぎます。1回限りの処理であり、ループでもパイプラインでもありません。

入力

まず、リクエストと容易に確認できるリポジトリの証拠（Project Matrix、cwd、GLOSSARY.md、ADR 名）から推測します。本当に不足している情報だけを、/feature-prompt 形式で質問します。

• 移植する機能 — 引き継ぐ動作やワークフロー。
• REFERENCE PROJECT-CODE — 動作の正とするソース。
• TARGET PROJECT-CODE — 機能の移植先。

3つすべてが判明するまで調査を始めないでください。ユーザーが不在で、いずれかを推測できない場合は、不足している項目を正確に明記した Needs-user メモを残して中止してください。決して推測してはいけません。

正とする情報の扱い

すべてのギャップマップのセクションで、次の方針を維持します。

• 動作についてはREFERENCEを正とします — ワークフロー、ナビゲーション（メニューの配置、入口、ルート）、権限、データへの影響、状態が該当します。TARGETの現在の動作がREFERENCEと異なる場合は、REFERENCEを優先します（ユーザーが動作の変更を明示的に決定した場合を除きます。その場合は、このスキルではなく/grill-with-fieldで決定します）。
• UIについてはTARGETのデザインシステムを正とします。 REFERENCEのUIがTARGETのデザインシステムと競合する場合はデザインシステムに従い、その差異（REFERENCEではXを使用していたが、TARGETのDSではYを使用するため、DSを選択した）をUI／デザインのギャップセクションに記録します。
• スタックのルールを決めつけないでください。 TARGETのルールは、適用されるコンテキスト（GLOSSARY.md、specs/adr/、AGENTS.md）とUIコーディングスキルから読み取ります。移植に関わるルール（スタックのバージョン、DSの規約、コンポーネントの扱い、ADRの場所）がそこに記録されていない場合は、作り出さず、推測する代わりにOpen questions / Needs-userに記載してください。

ルール

• 帰属表示は一切禁止です。 どの出力にも、共同作成者、AI、ツールの帰属表示を追加したり残したりしてはいけません。このルールをギャップマップにも含めてください。
• 提案にとどめ、自動で次へ進めないでください。 ギャップマップをもとに/grill-with-fieldを提案して終了します。計画やイシューの作成は、別途依頼があるまで行いません。
• ここでは実装しないでください。 プロダクトコード、設定、マイグレーションは編集しません。書き込み可能なのはギャップマップファイルのみです。
• Project Matrixに記載されたPROJECT-CODEの正式名称を、どこでも使用してください。異なるプロジェクトの規約、トークン、コンポーネントを混在させてはいけません。
• 対象を絞って検索します。 根拠に基づく対象限定の検索（正確なルート／パス／シンボル／状態に対するrg／git grep）を使い、REFERENCEをたどり、TARGETを調査します。手法は/feature-discoveryに準じます。「すべて見つける」ためにリポジトリ全体やspecs/ツリーを一括して読み込むことは、決してしないでください。
• 判断の前にコンテキストを読みます。 GLOSSARY.mdと関連するADRには記録済みの決定が、現在のコードとテストには実装済みの動作が示されています。現在のユーザーによる明示的な決定に従い、古いコンテキストとの矛盾を記録し、ネイティブCLIのメモは検証が必要な手がかりとして扱ってください。
• 決定は成果物として残します。 成果物は永続的なギャップマップファイルであり、チャットの要約ではありません。チャットでは、書き込んだ内容とフェーズの更新のみを報告します。
• サブエージェント：独立した作業にはローカルレーンを自動的に割り当てます。クラウドエージェントは使用しません。割り当て時にレーン数を伝え、各レーンの完了時に報告します。

プロセス

1. TARGETの適用コンテキストを読む

スタック／DSのルールについて、GLOSSARY.md（旧CONTEXT.md）、AGENTS.md、UIコーディングスキルを読みます。トピックまたは関連する決定を手がかりに関連するADRを特定し、該当するものだけを読みます。specs/adr/ツリー全体は読みません。適用ルールを把握するか、不足している項目をそれぞれOpen questionsに記載した時点で完了とします。

2. リファレンスを調査する

実際の動作、ワークフロー、ナビゲーション、権限、状態、データへの影響を、/feature-discovery スタイルでたどります。フィールドの検証とデフォルト値、フィールド間の依存関係、行単位および一括操作、インポート／エクスポート、自動更新、ロールによって制限されるコントロールも含めます。モック、フィクスチャ、スタブデータに基づく経路は動作の真実として扱わず、推測と明記して「未解決の質問」に記載します。すべての主張に具体的な参照（file:symbol、ルート、マイグレーション、テスト）が付いていれば完了です。

3. ターゲットの現在の状態を調査する

現在あるもの、リファレンスと比べて一部しか実装されていない点や誤っている点、再利用できるデザインシステムのコンポーネントと既存のパターンを確認します。機能に UI がある場合は、認可されたローカル環境でターゲットのコンポーネントプレビューを見つけて調査します。プレビューが存在しない、または利用できない場合は、コンポーネントのソースを一覧にして、その制約を記録します。プレビューのルートをでっち上げてはいけません。

4. 範囲を限定したレーンに分担する（任意）

重複しない調査（例：リファレンスの追跡を一つのレーン、ターゲットの調査を別のレーン）に分けます。同じ対象を複数のレーンで調査してはいけません。統合、不確実性に関する判断、成果物の作成はメインエージェントが担当します。

ギャップマップ成果物

移植する機能ごとに、ギャップマップを一つ作成します。

<artifacts-root>/specs/port/<feature-slug>-gapmap.md

<artifacts-root> は次のように解決します。*.code-workspace ディレクトリが存在する場合はそのディレクトリ、なければコンテキストごとのルート（リポジトリルートの GLOSSARY-MAP.md、旧形式の場合は CONTEXT-MAP.md）、それもなければリポジトリルートを使います。<feature-slug> は機能名をケバブケースにした ASCII 文字列で、最大約4語です。ギャップマップは必要に応じて作成するスラッグファイルであり、NNNN プロンプト／ADR の連番には含めません。

更新前に既存のギャップマップを読みます。ユーザーの編集内容と記録済みの決定を保持します。新たな調査結果がそれらと矛盾する場合は、該当箇所を示し、置き換える前に指示を待ちます。ユーザーが不在の場合は既存の内容を維持し、矛盾を「未解決の質問」に追記します。

既存のマップに同じ REFERENCE/TARGET の組み合わせが記載されていることを確認します。組み合わせが異なる場合はそのマップを保持し、<feature-slug>-<REFERENCE-CODE>-<TARGET-CODE>-gapmap.md を使用します。出力と完了確認には、この解決済みのパスを使います。

9つのセクションを指定順に並べ、各セクションは最大3項目とします。根拠をリンクまたは引用（file:line、ルート、マイグレーション、テスト）で示し、根拠そのものを貼り付けてはいけません。

# Port Gap Map — <feature> (<REFERENCE-CODE> → <TARGET-CODE>)

Zero attribution: never add or leave co-author, AI, or tool attribution in any output.

## 1. Reference behaviour / workflow
- <behaviour/permission/state/data-effect> — evidence: `file:symbol`, route, migration, test.
- Navigation: where the feature lives in the reference and any moves the port implies.

## 2. Target current state
- <what exists today for this feature in the target> — evidence refs.
- <target piece that already matches the reference> — do not touch; evidence ref.

## 3. Missing / wrong in target
- <gap or divergence from the reference> — absent, partial, or behaving differently.

## 4. Reusable target code & DS components
- <existing target seam/service/component to extend> — path + why it fits.
- <design-system component from the target preview> — where it applies.

## 5. Tests needed
- Success paths, validation, permission checks, empty/error/success states, data effects, regressions to guard.

## 6. UI / design gaps vs reference (and forced DS deviations)
- <reference UI element> → <target DS equivalent>.
- Forced deviation: reference did X; target DS does Y; chose DS because <rule/source>.

## 7. Risks
- <behaviour, data, permission, or migration risk> and where it bites.
- Coexistence: while reference and target both run on shared data, which one writes.

## 8. First slice
- One thin vertical slice that cuts through all layers and is testable on its own — not a layer, not a big-bang.

## 9. Open questions
- <evidence-derived question for /grill-with-field>. List them; do not block on them.

セクションのルール（記入例は references/gapmap-example.md を参照）：

• セクション1〜4のすべての主張に具体的な根拠を付けます。証明されていない主張は事実ではなく推測として明記します。
• セクション5は、後の受け入れ基準の基礎となります。テンプレートの箇条書きで挙げられているすべてのカテゴリを扱います。
• セクション5では、セクション1の動作のうちリファレンステストがないものをすべて示します。特性化テストを追加してから移植するか、「未解決の質問」に記載します。

出力

フェーズが切り替わるたびに Stage / Found / Next / Needs user を出力します。各フィールドは1行に1つずつ記載します。最終更新：

Stage: port-feature — wrote specs/port/<feature-slug>-gapmap.md (<REFERENCE-CODE> → <TARGET-CODE>).
Found: <N> reference behaviours traced; target is <absent/partial/diverging>; <M> reusable target/DS pieces; <K> forced DS deviations; <R> risks.
Next: run /grill-with-field on the gap map to challenge it and produce the ADR (next number in specs/adr/).
Needs user: <open questions to steer, or ambiguous reference/target mapping, or "none">.

Suggested next skills (optional):
- /grill-with-field: challenge the gap map and record the porting decisions as an ADR.
- /prototype: if a UI/interaction open question needs to be seen or felt before planning.

完了条件

• 解決済みのパスにギャップマップが存在し、別の組み合わせのファイルとの混同を避けるために必要な PROJECT-CODE が含まれ、9つすべてのセクション見出しがあり、各セクションに内容が記載されている
• git status に、ギャップマップ以外で今回作成または変更したファイルが表示されない（実装は行わない）
• 最終の Stage / Found / Next / Needs user 更新が出力され、最後にアドバイザリー提案のフッターが付いている