القائمة
コード変更を伴うタスク（機能追加・バグ修正・リファクタリング）の実装時に使用。実装からコミット作成まで自律的に行う（計画が要る変更は /start-issue へ）。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
workspace/plan.md の完成後、実装着手前に使用。計画の影響範囲・不変条件・スコープの漏れを検証する。
GitHub issue から作業を開始するときに使用。実装の前段階（ブランチ作成・調査・計画・計画レビュー）までを行う。
大きなサイクル完了後や定期メンテナンス時に使用。governance:check（決定的検査）を実行し、機械化できない意味的整合（コマンド直書き grep・npm ラッパー等価・メモリ整合）を検証して報告する（修正はしない）。
開発サイクル完了時（実装・レビュー・追加修正まで済んだ後）に使用。教訓の抽出・残タスクの振り分け・RETROSPECTIVE.md 更新を行う。
UI モード・状態遷移・ガード条件の追加・変更時、または計画レビュー時に使用。既存モードとの直交性・リセット経路・入力分岐・SPEC §8.6 整合を検証する。
worker スレッド・channel・フレーム drain・Tauri listener・スレッド/窓をまたぐ共有状態・フレーム内 live-read を追加/変更したとき、または async 関数を追加/変更したとき、あるいは計画レビュー時に使用。送信から適用までの窓での状態競合リスクを検証する。
| 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 があった場合は同一性とレビュー到達を確認した根拠）