implement

name	implement
description	コード変更を伴うタスク（機能追加・バグ修正・リファクタリング）の実装時に使用。実装からコミット作成まで自律的に行う（計画が要る変更は /start-issue へ）。
disable-model-invocation	true
argument-hint	[機能の説明]
allowed-tools	["Bash(cargo *)","Bash(npm *)","Bash(git *)","Read","Edit","Write","Grep","Glob","Agent","Skill"]

自律的にフルサイクル開発を行う。実装判断はコードとドキュメントから自律的に行い、要求判断が必要な場合のみ確認する。

タスク: $ARGUMENTS

Step 1 — 入口判定

このスキルは計画を所有しない。動くのは「レビュー済みの計画がある」か「計画が要らない」かのどちらかのときだけである。

1a. workspace/plan.md の由来を確かめる

workspace/plan.md があれば、それが今から着手するタスクのもので、かつレビューを経ているかを確かめる。/start-issue は中断（セッション断・放棄）しても workspace/ を残すため、別タスクの残骸や、レビュー前で止まった計画が残っていることがある。

この 2 つは別の性質である——同一性（今のタスクのものか）と、レビュー到達（/plan-review を通ったか）。/start-issue「5b. セルフレビュー（plan-review 固有の補完）」の後に /start-issue「Step 6 — workspace をコミット & プッシュ」が来る順序なので、コミット済みであることが立てるのは「レビュー到達」である。「同一性」は与えられたタスクとの噛み合いで別に確かめる——/implement は単独起動が日常的な経路であり、このブランチの issue が今のタスクとは限らないためである。

plan.md の状態	読み取れること
このブランチ上でコミット済み（git log --oneline main..HEAD -- workspace/）で、plan.md とコミットメッセージの issue 番号・目的が与えられたタスクと噛み合う	同一性・レビュー到達がともに立つ（レビュー到達は Step 6 到達から、同一性は左列の噛み合いから）
未コミットで残っている	git の証跡が無い。同一性は内容の一致（変更ファイル一覧・目的・issue 番号がブランチ名や与えられたタスクと噛み合うか）で、レビュー到達は plan.md 末尾の「セルフレビュー」節の有無で、別々に確かめる
main から到達できる／別ブランチのもの／このブランチ上でも与えられたタスクと噛み合わないもの	別タスクの残骸である

既定は fail-closed である——確かめられなければ、あるものとして扱わない。倒す向きに非対称があるためで、古い計画や未レビューの計画を有効と誤れば違うものを実装し、検証を全部通ってコミットまで気づけない。逆に有効な計画を無効と誤っても、止まって聞き直すだけで回復できる。

1b. 分岐（行き先を決めるのはこの表だけである）

状況	動き
同一性・レビュー到達がともに立つ plan.md がある	それを実装の指示として読み Step 2 へ。この場合に限り計画はレビュー済みである（/start-issue「出力」の引き渡し契約）。調査はやり直さない
同一性は立つが、レビュー到達が立たない	計画は在るがレビューを経ていない。止める（1c-B）
別タスクの残骸と分かった	消さずに何の残骸かを報告し、削除か退避かをユーザーに確認したうえで、「計画が無い」ものとして下の「計画が無く…」の 2 行のどちらかへ進む
由来の判断がつかない	止める（1c-C）
計画が無く、計画を書かずに直せる	下の調査を行ってから Step 2 へ
計画が無く、計画が要ると判明した	止める（1c-A）

計画なしの経路でだけ行う調査:

• SPEC.md と関連する CLAUDE.md を読み、意図とアーキテクチャを理解する
• $ARGUMENTS からエントリポイントと関連モジュールを特定する
• 要求された機能と重複する既存コードを検索する
• 3層モデルの制約（意図は SPEC.md、実装はコード）に留意する
• 要求の曖昧さを判定する — 「何を作るか」がコードとドキュメントから一意に決まらない場合（UI の見た目、対象範囲、既存動作を変えるか追加するか等）、最も影響の大きい 1〜2 点に絞って質問し、回答を得てから進む

計画が要るサイン（網羅ではなく徴候である）:

• 複数ファイルにまたがり、変更の順序に依存する
• 新しい状態・プロセス・ウィンドウ・永続形式を導入する
• SPEC.md に書かれた挙動を変える
• どう直すかが一つに決まらず、代替案の比較が要る

サインは実装の途中で立つこともある。 その場合もその時点で止める。

1c. 止まったときの引き渡し

実装を始めない。 停止は 3 種で、それぞれ渡し方が違う:

• 1c-A（計画が無く、要ると判明した）: 何が計画を要求したかを報告し、issue 本文の草案を出して起票を打診する。承認されたら gh issue create を実行し、/start-issue <N> へ渡す
• 1c-B（計画はあるがレビューを経ていない）: 新規 issue は起票しない。 計画が未レビューである旨を報告し、/plan-review を回し、その結果を plan.md 末尾の「セルフレビュー」節へ記録してから /implement を再実行するよう促す（/start-issue「Step 2 — main 最新化 & ブランチ作成」でブランチを作る構成のため、途中からの再開口を持たない）
• 1c-C（由来の判断がつかない）: 何を確かめられなかったかを示して問う。答えを得るまで進まない

Step 2 — 実装

• 純粋核（crate を問わず egui/Win32 非依存でテスト可能なロジック）の追加・変更: 先に失敗する #[cfg(test)] テストを書き（Red）、次に実装して通す（Green）。snotra-core に限らず src-tauri 等の純粋モジュール（lifecycle.rs・search_state.rs 等）も対象（view/Win32 依存はテスト前提にしない）
• 計画がある場合は、計画に沿って変更を行う
• 新しい純ロジックには、それが属する crate に #[cfg(test)] ユニットテストを追加する
• ソースファイル（.rs/.ts/.tsx）を新規追加・削除したら、同じ変更で該当 CLAUDE.md のモジュール構成節の索引（ファイル名）を更新する（責務散文は各ファイルの //!/TSDoc が正本・#562。索引漏れは governance:check が捕捉するが PR まで漏らさない）
• SPEC.md に記載された挙動に影響する変更の場合、SPEC.md も更新する（AGENTS.md「3層分担」に従う）

Step 3 — 検証（最大5サイクル）

docs/build-commands.md の「変更後の検証チェックリスト」を SSOT として、変更したファイルの種類に該当するカテゴリ A〜E をすべて実行する。失敗した場合、修正して失敗したステップから再実行する。

• カテゴリ A（Rust 変更）の clippy・snotra-core のテストも SSOT 上「必須」（最初の失敗で停止するチェーン実行を推奨）
• ソースファイルを追加/削除した場合、カテゴリ F（npm run governance:check）も実行する（モジュール索引・参照・スキル表の整合。#629/#630 で索引更新漏れが CI まで再発した）
• 状態でゲートされた挙動（分岐表示・エラー経路・cold path）は build/test が通っても検証済みとは限らない——その状態を実際に発生させて確認する（docs/development-principles.md デバッグ節）
• 具体的なコマンド文字列は docs/build-commands.md を参照（二重メンテを避けるためこの SKILL に書かない）

5サイクル後もエラーが残る場合、中止して診断サマリーを書く:

• 試みた内容
• 残存するエラー
• 根本原因の推定

Step 4 — レビュー

4a. check スキルの実行

変更の種類に応じた check スキル（/symmetric-check・/dry-check・/race-check・/cache-check・/persistence-check・/state-check）を、AGENTS.md「条件別チェック（トリガー → 参照先）」表に従って実行する（トリガー→検査の写像の SSOT はその表。二重管理を避けるためここに再掲しない）。/symmetric-check はコードパス変更・バグ修正でほぼ常に該当。発見事項があれば修正してから 4b に進む。同じ check が /start-issue の計画段階で走っていても、ここで実行する——対象が計画と実装で別だからである（計画に無い変更は実装中に必ず生じる）。

4b. code-reviewer エージェント

code-reviewer エージェントを変更に対して実行する。Critical または High の発見事項は修正してから次に進む。

Step 5 — コミット

• git branch --show-current で現在のブランチを確認し、main 上にいる場合は feature ブランチ（feat/ / fix/ / chore/ 等）を作成してからコミットする（main 直コミットは禁止・.githooks/pre-commit に弾かれる。/start-issue を経ていない単体起動時に該当しやすい）
• このタスクで変更したファイルのみをステージする
• workspace/ を削除する前に、否定の知識を ADR へ回収する（#593）: plan.md・本サイクルの検討に「代替案 B を検討して却下した」判断があれば、削除で失う前に docs/adr/NNNN-<title>.md を起こす（形式は docs/adr/0001-*.md に倣う）。トリガーは否定の知識が生じたときだけ — 自明な実装・一本道の選択では作らない。無ければ何もしない
• workspace/ ディレクトリが存在する場合、削除してステージに含める（/start-issue の引き継ぎバッファは実装完了で役目を終える。git 履歴から復元可能）
• conventional commit を作成する（例: feat:, fix:, refactor:）
• 何を実装し、なぜ実装したかの簡潔な説明を含める

出力

Step 1 で止まった場合（1c-A / 1c-B / 1c-C）は Step 2 以降に到達しないため、入口判定の結果と、1c が定める渡し方に沿った報告だけを行う。下の 2〜4 は該当経路では生成物が存在しない。

Step 2 以降まで進んだ場合、以下を報告:

1. 入口判定の結果（計画あり／なし。plan.md があった場合は同一性とレビュー到達を確認した根拠）
2. 最終検証結果 — check, clippy, test の出力（Step 3）
3. コミットハッシュとメッセージ（Step 5）
4. 全変更の diff