recursive-spec

recursive-spec

このスキルを使用して、新しい再帰モードの実行に向けた、リポジトリの状況を踏まえた 00-requirements.md を共同で作成します。

このスキルは、実装開始前に要件や仕様を作成するためのものです。/.recursive/RECURSIVE.md の代わりにはならず、Phase 2 の計画や Phase 3 の実装に先回りするものでもありません。

主なユースケース

ユーザーが実行を開始する前に作業内容をまとめたい場合、特に次のような依頼があったときに recursive-spec を使用します。

• 計画を作成して
• 計画を立てるのを手伝って
• 仕様を作成して
• 要件を書いて
• 仕様としてまとめて
• スコープを決めて

重要な判断材料は、既存の実行の実装ではなく、新しい実行に向けた計画や仕様についての表現です。

会話の進め方

トリガーを検出したら、次の手順に従います。

1. まず、再帰モードの実行に向けた仕様の作成を手伝ってほしいか、ユーザーに確認します。
2. ユーザーが希望すると答えた場合は、次のように尋ねます。何をしたいですか？
3. その後、背景情報を集め、リポジトリを読み、要件を共同で作成します。

ユーザーが仕様作成を希望すると確認する前に、00-requirements.md の作成に取りかかってはいけません。

承認前のドラフトの扱い

ユーザーが仕様を明示的に承認するまでは、次のルールを守ります。

• ドラフトはリポジトリのワークツリー外に保管します。
• 一時的なセッション成果物やスクラッチファイルを優先します。
• /.recursive/run/<run-id>/ を作成してはいけません。
• 00-requirements.md を書き込んではいけません。

ユーザーがドラフトを却下した場合は、ドラフトを修正するか、一時的なドラフト成果物を破棄します。承認が不完全な実行フォルダーを残してはいけません。

必須の読み取り動作

要件のドラフトを作成する前に、次の項目を読みます。

1. /.recursive/STATE.md
2. /.recursive/DECISIONS.md
3. /.recursive/memory/MEMORY.md
4. 実際に関連する場合に限り、関連するメモリの分割ファイル
5. 依頼された領域に最も関連するコードとテスト

このスキルでは、質問を機械的に並べるのではなく、リポジトリの状況を踏まえて対応します。制御プレーンのドキュメントから現状の正確な情報を把握し、コードベースから実際の対象領域、関連モジュール、既存のテスト、想定される境界を理解します。

作成の進め方

ガイド付きのインタビュー形式で進めます。リポジトリのドキュメントやコードから答えがすでに確認できない場合は、焦点を絞った質問を一度に一つずつ尋ねます。

推奨する順序は次のとおりです。

1. 目標とユーザーが得る成果
2. タスクの種類：機能追加、バグ修正、リファクタリング、移行、調査
3. 影響を受けるサブシステムまたはファイル
4. スコープ内の要件（R#）
5. 各要件で確認可能な受け入れ基準
6. エッジケース、失敗経路、除外事項
7. 制約、確定済みの決定、境界
8. Phase 0 を確定する前に解決が必要な未確定事項

ユーザーに文書全体を一から作成してもらうのではなく、ドラフトの文言を提案して確認や修正を依頼する方法を優先します。

品質ルール

契約ファーストのワークフローにおける優れた仕様作成の考え方を取り入れつつ、出力は再帰モード本来の形式に沿わせます。

• ユーザーの意図と望ましい成果から始める
• 確定済みの決定と未解決の質問を分ける
• 決定的で確認可能な受け入れ基準を定義する
• 正常系だけでなく、例外や失敗経路も検討する
• 後の AS-IS 分析と計画の指針となるよう、境界を具体的にする
• スコープ外の項目を明示する

独自の .spec DSL や、別形式のワークフローを新たに導入してはいけません。

出力の契約

完成した出力は、次のファイルにする必要があります。

• /.recursive/run/<run-id>/00-requirements.md

リポジトリ本来の Phase 0 の要件構成を使用します。

• recursive-init のスキャフォールド済みヘッダーを維持します。Workflow version: recursive-mode-audit-v2 も含めてください。
• 必須の ## TODO セクションを維持し、見出しは削除せず、プレースホルダーのチェックリスト項目を置き換えます。
• ## Requirements
• ## Out of Scope
• ## Constraints

## Requirements では、各 R# に次の内容を含めます。

• 簡潔なタイトル
• 明確な説明
• 確認可能な受け入れ基準の箇条書き

実行作成ルール

実行フォルダーをすぐに作成しないでください。

1. まずユーザーと要件の草案を作成し、推敲します。
2. 承認されるまでは、リポジトリ外の一時的な成果物に草案を保存します。
3. ユーザーが仕様を承認し、作業を進めるのに十分な内容になっていることを確認します。
4. .recursive/scripts/recursive-init.py または .recursive/scripts/recursive-init.ps1 で実行を作成します。
5. ひな形として生成された 00-requirements.md を、承認済みの要件内容に置き換えます。

これにより、実行成果物が未完成のメモではなく、ユーザーが承認した要件に基づくようになります。

ルーティングに関する注意

仕様の作成に、委任による批評、委任によるレビュー、その他の外部モデルによる草案作成支援を利用する場合、その CLI／モデルを選ぶ直前に、次のファイルを再度読み込んでください。

• /.recursive/config/recursive-router.json
• /.recursive/config/recursive-router-discovered.json

そのうえで、場当たり的にモデルを選ぶのではなく、recursive-router を経由してルーティングします。

境界

• 新しい実行の 00-requirements.md の作成に専念してください。
• 知らないうちにこれをフェーズ 2 の計画へ切り替えないでください。
• 要件が明確になったからといって、実装を始めないでください。
• リポジトリの構造がスコープや制約に関わる場合、コードの確認を省略しないでください。
• ユーザーが承認した仕様を作成する準備が整うまで、実行を作成しないでください。
• 承認されていない草案から、リポジトリ内の要件成果物を作成しないでください。

参照

• /.recursive/RECURSIVE.md
• /.recursive/STATE.md
• /.recursive/DECISIONS.md
• /.recursive/memory/MEMORY.md
• ../recursive-mode/references/artifact-template.md
• ./references/patterns.md