CDD Discussion Session

Mode Detection

If argument $1 is provided: Discussion mode for existing decision If no argument: New decision creation mode

Mode 1: Existing Decision Discussion (when $1 is provided)

You are starting a discussion session for decision $1.

Your Task

1. Load the decision context:

   • Read CDD/**/*$1*.cdd.md to find the decision file
   • If not found, search all CDD files using Grep tool

2. Progressive Disclosure - Gather related context:

   • Read documents referenced in the Context section
   • Search for related cdd.md files (use tags, keywords)
   • Read docs/README.md → docs/architecture/overview.md and relevant docs/research/ files
   • Build a complete picture before starting the discussion

3. Verify current status:

   • Check decisionStatus field
   • If already DECIDED, warn the user before proceeding

4. Facilitate the discussion:

   • Read the Goal, Context, and current Selection
   • Ask clarifying questions about unclear aspects
   • Propose alternatives or improvements
   • Help refine the Selection section

5. Update the decision:

   • When consensus is reached, update the cdd.md file
   • Change decisionStatus to appropriate value (DRAFT/REVIEW/DECIDED)
   • Update Selection section with discussion outcomes
   • Add discussion notes if needed

Mode 2: New Decision Creation (when no argument)

You are starting a new decision creation session.

Your Task

1. Understand the requirement:

   • Ask the user what they want to achieve
   • Ask clarifying questions to understand:
     • What problem they're solving
     • What constraints exist
     • What options they're considering

2. Progressive Disclosure - Gather context automatically:

   • Based on the user's description, search for related information:
     • Related cdd.md files (use Grep to search by keywords, tags, etc.)
     • Architecture documents (docs/README.md → docs/architecture/overview.md)
     • Technical research (docs/research/*.md)
   • Read the relevant documents
   • Add references to the Context section of the new cdd.md:

     ## Context
     
     ### Related Decisions
     - PHASE4-001: CDD/tasks/xxx.cdd.md
     
     ### Technical Background
     - Architecture: docs/architecture/overview.md
     - Research: docs/research/investigation.md
     

   • Use this context to inform your discussion without asking redundant questions

3. Determine the appropriate template:

   • Based on the discussion, identify the best template type:
     • feature: New functionality
     • bug: Bug fix
     • refactor: Code refactoring
     • decision: Architectural or process decision
     • research: Investigation or analysis
   • Propose the template to the user and confirm

4. Create the cdd.md file:

   • Use the Bash tool to run: cdd new --template <type>
   • The command will prompt for:
     • Decision ID
     • Title
     • Assignee
   • Help the user fill in these fields based on your discussion

5. Continue the discussion:

   • Once the file is created, read it
   • Help the user fill in the sections:
     • Goal: What they want to achieve
     • Context: Background and constraints
     • Selection: Initial thoughts (if any)
   • Update the file using the Edit tool

6. Test Specificationの議論（必要に応じて）:

   • 実装を伴う決断の場合、Test Specificationセクションを議論する
   • Given-When-Then（Gherkin風）形式でテストシナリオを記録
   • DECIDEDにする前にTest Specificationを含めて確認
   • テスト不要なケース（ドキュメント変更等）ではスキップ可

7. Set appropriate status:

   • Start with decisionStatus: DRAFT
   • Only change to REVIEW or DECIDED when the user confirms

Important Rules

• DO NOT implement code unless decisionStatus: DECIDED
• Focus on decision quality, not speed
• Challenge assumptions constructively
• Document rejected alternatives in Rejections section

File Editing Principles

When updating the cdd.md file (especially the Selection section):

1. Read the entire target section before editing

   • Understand all existing content in Goal, Context, Selection, etc.

2. Preserve existing content when adding new information

   • Example: Selection has items A, B, C
   • Adding item D → Result: A, B, C, D (NOT A, B, D)
   • "Add new decision points" means APPEND, not REPLACE

3. Only delete when explicitly required

   • User explicitly asks to remove something
   • Content is objectively incorrect and outdated
   • When uncertain, preserve existing content

4. Distinguish "add" from "replace"

   • Adding discussion outcomes ≠ Removing previous content
   • Refinement = Enhancement of existing content, not deletion

DECIDED後の自動フロー進行

decisionStatus: DECIDED に変更した後、以下のフローを 自動的に 進行する。 ユーザーが手動で /cdd-implement などを呼ぶ必要はない。

フロー

1. DECIDED確定
2. AskUserQuestion: implementationStatusをIN_PROGRESSに変更しますか？
3. IN_PROGRESSに変更
4. Skill tool で /cdd-implement <id> を呼び出し（fork subagentで実装）
5. fork完了 → メインに戻る
6. AskUserQuestion: implementationStatusをIN_REVIEWに変更しますか？
7. IN_REVIEWに変更
8. 並列で以下を呼び出し:
   - Skill tool で /cdd-review-implementation <id>（fork: 決断整合性レビュー）
   - Skill tool で /cdd-review-quality <id>（fork: 品質レビュー）
9. 両方のfork完了 → メインに戻る → 結果を集約して報告
10. AskUserQuestion: implementationStatusをDONEに変更しますか？
11. 両方APPROVEDの場合のみDONEに変更、完了報告

重要な責務分離

• fork subagent: 実装・レビューなどの作業のみ。ステータス変更しない
• メインエージェント（このスキル）: ステータス変更 + AskUserQuestion による確認

fork subagent は AskUserQuestion が使えないため、ステータス変更は必ずメインエージェントが行う。