development-workflowlisted

# 開発ワークフローの振り分け 変更内容を 4 つのモードへ分類し、必要な工程だけを起動する。**全変更にフル工程を課さない。** **判定基準を持つのはこの Skill だけである。** 他の Skill とエージェント定義は判定結果を 受け取る側に徹する。同じ基準を複数箇所へ書くと、モードを追加・変更したときに片方だけが 古くなる。 ## 判定の手順 ### 1. 変更対象を確認する ```bash git status --short git diff --stat # 変更済みなら ``` 依頼文だけで判定しない。**実際に触るファイルと、触る理由**で決める。 ### 2. 上から順に条件を判定する 最初に該当したモードを採る。複数に当てはまる場合は**上のモードが勝つ**。 | 順 | モード | 該当条件（いずれか 1 つで該当） | | --- | --- | --- | | 1 | `architecture` | 公開インタフェース（API・イベント・コマンド）の追加・変更・削除 / 既存データの移行を伴うスキーマ変更（列の削除・改名・型変更など） / 認証・認可の変更 / 複数モジュールにまたがる変更 / 重要なドメイ���ルールの追加・変更 | | 2 | `legacy-refactor` | 本番の振る舞いを変えず本番コードの構造を変える変更で、対象にテストがない・少ない | | 3 | `standard` | 本番の振る舞いの追加・変更、バグ修正 / 本番の振る舞いを変えない構造変更で、対象にテストが十分にある | | 4 | `light` | **本番の振る舞いも本番コードの構造も変えない局所変更**（文言・書式・コメント・ドキュメント・静的な設定値、テストの追加、ログ出力の追加など） | `light` の括弧内は**例示であり限定列挙ではない**。判定の基準は「本番の振る舞いも本番コードの 構造も変えない」ことであり、例示に無い変更もこの条件を満たせば `light` として扱う。 スキーマ変更のうち、既存データの移行が不要な追加（インデックスの追加、既定値付き NULL 許容列の追加）は `standard` として扱う。判定に迷う場合と境界事例は [references/workflow-modes.md](references/workflow-modes.md) を参照する。 ### 3. 判定結果を出力する 呼び出し側（エージェント・他の Skill・利用者）が**判定結果だけを受け取れる形式**で返す。 ```text mode: standard 根拠: 注文確定の振る舞いを変更する。公開 API とスキーマは変えない 必須工程: requirements-design → implementation-plan → tdd-cycle → refactoring → pr-review → quality-gates → plan-to-spec（仕様が変わった場合） ``` 判定基準の本文を出力へ貼らない。呼び出し側が基準を写し取ると、この Skill が唯一の 置き場所である前提が崩れる。 ## モードと必須工程 | モード | 対象 | 必須工程 | | --- | --- | --- | | `light` | 文言、ドキュメント、設定、テストの追加など、本番の振る舞いも本番コードの構造も変えない局所変更 | 成功条件の確認