Menu
コード変更を伴うタスク（機能追加・バグ修正・リファクタリング）の実装時に使用。実装からコミット作成まで自律的に行う（計画が要る変更は /start-issue へ）。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| 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
このスキルは計画を所有しない。動くのは「レビュー済みの計画がある」か「計画が要らない」かのどちらかのときだけである。
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 である——確かめられなければ、あるものとして扱わない。倒す向きに非対称があるためで、古い計画や未レビューの計画を有効と誤れば違うものを実装し、検証を全部通ってコミットまで気づけない。逆に有効な計画を無効と誤っても、止まって聞き直すだけで回復できる。
| 状況 | 動き |
|---|---|
同一性・レビュー到達がともに立つ plan.md がある | それを実装の指示として読み Step 2 へ。この場合に限り計画はレビュー済みである（/start-issue「出力」の引き渡し契約）。調査はやり直さない |
| 同一性は立つが、レビュー到達が立たない | 計画は在るがレビューを経ていない。止める（1c-B） |
| 別タスクの残骸と分かった | 消さずに何の残骸かを報告し、削除か退避かをユーザーに確認したうえで、「計画が無い」ものとして下の「計画が無く…」の 2 行のどちらかへ進む |
| 由来の判断がつかない | 止める（1c-C） |
| 計画が無く、計画を書かずに直せる | 下の調査を行ってから Step 2 へ |
| 計画が無く、計画が要ると判明した | 止める（1c-A） |
計画なしの経路でだけ行う調査:
SPEC.md と関連する CLAUDE.md を読み、意図とアーキテクチャを理解する$ARGUMENTS からエントリポイントと関連モジュールを特定するSPEC.md、実装はコード）に留意する計画が要るサイン（網羅ではなく徴候である）:
SPEC.md に書かれた挙動を変えるサインは実装の途中で立つこともある。 その場合もその時点で止める。
実装を始めない。 停止は 3 種で、それぞれ渡し方が違う:
gh issue create を実行し、/start-issue <N> へ渡す/plan-review を回し、その結果を plan.md 末尾の「セルフレビュー」節へ記録してから /implement を再実行するよう促す（/start-issue「Step 2 — main 最新化 & ブランチ作成」でブランチを作る構成のため、途中からの再開口を持たない）#[cfg(test)] テストを書き（Red）、次に実装して通す（Green）。snotra-core に限らず src-tauri 等の純粋モジュール（lifecycle.rs・search_state.rs 等）も対象（view/Win32 依存はテスト前提にしない）#[cfg(test)] ユニットテストを追加する.rs/.ts/.tsx）を新規追加・削除したら、同じ変更で該当 CLAUDE.md のモジュール構成節の索引（ファイル名）を更新する（責務散文は各ファイルの //!/TSDoc が正本・#562。索引漏れは governance:check が捕捉するが PR まで漏らさない）SPEC.md に記載された挙動に影響する変更の場合、SPEC.md も更新する（AGENTS.md「3層分担」に従う）docs/build-commands.md の「変更後の検証チェックリスト」を SSOT として、変更したファイルの種類に該当するカテゴリ A〜E をすべて実行する。失敗した場合、修正して失敗したステップから再実行する。
snotra-core のテストも SSOT 上「必須」（最初の失敗で停止するチェーン実行を推奨）npm run governance:check）も実行する（モジュール索引・参照・スキル表の整合。#629/#630 で索引更新漏れが CI まで再発した）docs/development-principles.md デバッグ節）docs/build-commands.md を参照（二重メンテを避けるためこの SKILL に書かない）5サイクル後もエラーが残る場合、中止して診断サマリーを書く:
変更の種類に応じた check スキル（/symmetric-check・/dry-check・/race-check・/cache-check・/persistence-check・/state-check）を、AGENTS.md「条件別チェック（トリガー → 参照先）」表に従って実行する（トリガー→検査の写像の SSOT はその表。二重管理を避けるためここに再掲しない）。/symmetric-check はコードパス変更・バグ修正でほぼ常に該当。発見事項があれば修正してから 4b に進む。同じ check が /start-issue の計画段階で走っていても、ここで実行する——対象が計画と実装で別だからである（計画に無い変更は実装中に必ず生じる）。
code-reviewer エージェントを変更に対して実行する。Critical または High の発見事項は修正してから次に進む。
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 履歴から復元可能）feat:, fix:, refactor:）Step 1 で止まった場合（1c-A / 1c-B / 1c-C）は Step 2 以降に到達しないため、入口判定の結果と、1c が定める渡し方に沿った報告だけを行う。下の 2〜4 は該当経路では生成物が存在しない。
Step 2 以降まで進んだ場合、以下を報告:
plan.md があった場合は同一性とレビュー到達を確認した根拠）workspace/plan.md の完成後、実装着手前に使用。計画の影響範囲・不変条件・スコープの漏れを検証する。
GitHub issue から作業を開始するときに使用。実装の前段階（ブランチ作成・調査・計画・計画レビュー）までを行う。
大きなサイクル完了後や定期メンテナンス時に使用。governance:check（決定的検査）を実行し、機械化できない意味的整合（コマンド直書き grep・npm ラッパー等価・メモリ整合）を検証して報告する（修正はしない）。
開発サイクル完了時（実装・レビュー・追加修正まで済んだ後）に使用。教訓の抽出・残タスクの振り分け・RETROSPECTIVE.md 更新を行う。
UI モード・状態遷移・ガード条件の追加・変更時、または計画レビュー時に使用。既存モードとの直交性・リセット経路・入力分岐・SPEC §8.6 整合を検証する。
worker スレッド・channel・フレーム drain・Tauri listener・スレッド/窓をまたぐ共有状態・フレーム内 live-read を追加/変更したとき、または async 関数を追加/変更したとき、あるいは計画レビュー時に使用。送信から適用までの窓での状態競合リスクを検証する。