Develop User Story
適用先のストーリー台帳から、利用者成果、実装、検証の契約を組み立てる。依頼された操作と、その完了に必要なGateまで進める。
正本と対象を解決する
repository root、適用されるAGENTS.md、既存差分を確認する。台帳は利用者が指定したpathを優先し、指定がなければ対象PLANと同階層、その祖先、repository rootのdocs/USER_STORIES.mdの順に探す。複数候補が残る場合だけ確認する。
解決した台帳の対象US、全体ルール、状態、受け入れ条件を読み、今回の判断に必要な同scopeのPLAN、EVIDENCE、実装、テストを確認する。コードから判明する事実は調べ、利用者成果やscopeを変える未確定事項だけを質問する。
台帳は製品契約、PLANは実装順と進捗、コードとテストは実装証拠、EVIDENCEは必要な実検証証拠の正本である。下位の都合で上位契約を弱めず、既存の他者差分を上書きしない。
追加・実装・検証で対象USが未指定なら、依頼と台帳の優先度から一件へ絞る。複数USを同じ実装scopeへ含めるのは、利用者成果として分離できない場合だけとする。残るscope全体の計画化では複数USを入力にしてよいが、USを結合せず条件IDで追跡する。
操作に応じて読む
| 操作 | 詳細と終了位置 |
|---|---|
| Storyの追加・意味変更 | Story作成。ストーリー独立レビューGateまで |
| PLANの作成・実行責務の意味変更 | PLAN作成。PLAN独立レビューGateまで。再利用・複数PLANの資料は該当時だけ読む |
| PLANの実装・再開 | 実装。担当する検証・Journey・handoff、または指定停止Gateまで |
| Story/PLAN/実装のレビュー | 対象資料の独立レビューGateとreview-gate。判定・指定先への送信まで |
| Journey・実サービス・release確認 | Journey検証。固定条件の判定と結果記録まで |
| 状態・証拠の記録だけ | 結果記録。既存結果を反映しvalidatorで確認 |
資料の後工程を読むだけで開始しない。意味変更には必要なGateを通すが、追加だけ・計画だけ・レビューだけの依頼から実装へ進まない。指定された送信やhandoffが停止Gateなら、成功を確認して終了し、待機し続けない。
レビューへ渡す契約
観点選定、正本照合、全観点の探索、候補分類、GO/NO-GO、増分再確認はreview-gateを正本とする。本skillはGate固有の質問、一次情報、役割分離、条件IDと開発状態を担当する。
Review Briefより先に、依頼・台帳・PLAN・Gate質問からReview Inputを固定する。condition_idsは次で決め、Briefや実装から逆算しない。
- 依頼から対象Story/Gate/plan setを決め、解決した台帳から対象条件IDを直接抽出する。
- PLAN対象では担当IDも別に抽出し、台帳へ照合する。candidateは担当ID、Story完了を所有する統合PLANは台帳の対象ID全件を使う。
- Story Gateは台帳の対象ID、PLAN/実装Gateは照合済みの担当IDを過不足なく渡す。
現在契約、変更surface、全体不変条件、既存handoffも同じ一次情報から固定する。handoffはid、gate、owner、contractを持つ。review-gateが返すlater-gateを、次の意味で開発へ引き継ぐ。
| 振り分け | 必要な前提 |
|---|---|
plan-input |
Storyが成立し、その成果の実装・検証方法をPLANで決める |
implementation-risk |
固定PLANと名前付き実装Gate、owner、handoff契約がある |
journey-risk |
実装契約が成立し、実画面・実サービス・目視品質・費用を伴う確認だけが残る |
現在適用される既存契約同士が衝突し、どちらを正とするか決めないとGateへ答えられない場合だけ契約判断待ちとする。名前付きhandoffを示せない将来用途や一般的な改善は非適用とし、曖昧な後続作業へ送らない。
Gateの再開と状態
Storyのタイトル、きっかけ、活動、目的、scope、導線、受け入れ条件を意味的に変えたらストーリー独立レビューGate、PLANの実装・検証契約を変えたらPLAN独立レビューGateを再開する。実装成果・外部状態の意味変更も影響する実装Gateを再開する。コードだけでなく、テスト、設定、schema、依存、コンテンツ、prompt、静的・生成アセット、デプロイ済み設定を含む。
review-gateで再確認する観点を決め、影響したStory、PLAN、実装Gateを依存順に通す。その後、関係するJourneyだけを再実施する。影響しない観点・別Story・後続Gateを全面的にやり直さない。
状態、チェック欄、検証結果、証拠link、PLAN進捗、誤字・書式だけの更新はGateを失効させない。未確認を完了にする更新や、記録に見せかけた契約変更はこの例外に含めない。
| 状態 | 意味 |
|---|---|
todo |
着手前 |
doing |
実行中。未実装の条件が残る場合も維持する |
implemented |
コードと必要な自動検証が成立し、実装後独立レビューGateを通過した |
verified |
全受け入れ条件を必要な検証水準で確認した |
blocked |
外部条件により進められない。理由と未確認条件を示す |
影響Gateと必要なJourneyを通さず、implemented/verifiedへ進めない。結果の記入形式はJourney資料で管理する。
永続文書の書き方
日本語で、目的・判断・操作・例外・完了条件を分けて書く。一文へ詰め込まず、必要な列挙や対応は表・箇条書きにする。固有名詞、コード識別子、command、path、schema field、運用ラベル以外の不要な英単語を避け、同じ概念は同じ言葉で表す。
条件ID、Gate、責務、検証基準、停止条件、template/validatorの書式は保つ。Review Input、Brief、manifest、review履歴、case台帳、一時path、branch、commit SHA、worktree、session等の実行識別子を台帳・PLAN・EVIDENCEへ保存しない。