5-phase-workflow 1.0.0

package/src/commands/5/configure.md

@@ -0,0 +1,309 @@
+---
+name: 5:configure
+description: Phase 1 of project configuration. Analyzes project, gathers preferences, and creates a configuration feature spec. Follow up with /5:plan-implementation CONFIGURE.
+allowed-tools: Read, Write, Bash, Glob, Grep, AskUserQuestion
+context: inherit
+user-invocable: true
+---
+
+# Configure (Phase 1 - Plan Feature for Project Configuration)
+
+## Overview
+
+This command is **Phase 1** of the 5-phase workflow applied to project configuration itself. It analyzes the project, asks the user questions, and outputs a feature spec at `.5/CONFIGURE/feature.md`.
+
+After running this command, proceed through the standard phases:
+1. **`/5:configure`** (this command) - Plan the configuration feature
+2. `/5:plan-implementation CONFIGURE` - Create implementation plan
+3. `/5:implement-feature CONFIGURE` - Execute configuration (uses `configure-project` skill)
+4. `/5:verify-implementation` - Verify configuration
+5. `/5:review-code` - Review generated files
+
+## Configuration Process
+
+### Step 1: Analyze Project (auto-detect, no user interaction)
+
+Perform all detection silently, collecting results for Step 2.
+
+**1a. Check for existing config:**
+```bash
+if [ -f ".claude/.5/config.json" ]; then
+  # Config exists - will ask user in Step 2
+fi
+```
+
+**1b. Detect project type** by examining files:
+
+```javascript
+// Node.js/JavaScript/TypeScript
+if (exists('package.json')) {
+  const pkg = readJSON('package.json');
+
+  if (pkg.dependencies?.['next'] || pkg.devDependencies?.['next'])
+    return 'nextjs';
+  if (pkg.dependencies?.['@nestjs/core'])
+    return 'nestjs';
+  if (pkg.dependencies?.['express'])
+    return 'express';
+  if (pkg.dependencies?.['react'])
+    return 'react';
+  if (pkg.dependencies?.['vue'])
+    return 'vue';
+
+  return 'javascript';
+}
+
+// Java
+if (exists('build.gradle') || exists('build.gradle.kts'))
+  return 'gradle-java';
+if (exists('pom.xml'))
+  return 'maven-java';
+
+// Python
+if (exists('requirements.txt') || exists('pyproject.toml')) {
+  if (exists('manage.py')) return 'django';
+  if (exists('app.py') || exists('wsgi.py')) return 'flask';
+  return 'python';
+}
+
+// Rust
+if (exists('Cargo.toml'))
+  return 'rust';
+
+// Go
+if (exists('go.mod'))
+  return 'go';
+
+// Ruby
+if (exists('Gemfile')) {
+  if (exists('config/routes.rb')) return 'rails';
+  return 'ruby';
+}
+
+return 'unknown';
+```
+
+**1c. Detect build/test commands** based on project type:
+
+| Type | Build Command | Test Command |
+|------|--------------|--------------|
+| javascript | `npm run build` | `npm test` |
+| nextjs | `npm run build` | `npm test` |
+| nestjs | `npm run build` | `npm test` |
+| express | `npm run build \|\| tsc` | `npm test` |
+| gradle-java | `./gradlew build -x test -x javadoc --offline` | `./gradlew test --offline` |
+| maven-java | `mvn package -DskipTests` | `mvn test` |
+| python | `python -m py_compile **/*.py` | `pytest` |
+| django | `python manage.py check` | `python manage.py test` |
+| rust | `cargo build` | `cargo test` |
+| go | `go build ./...` | `go test ./...` |
+
+**1d. Detect available tools:**
+
+```bash
+# CodeRabbit CLI
+if command -v coderabbit &> /dev/null; then
+  coderabbit_available=true
+  if coderabbit auth status | grep -q "authenticated"; then
+    coderabbit_authenticated=true
+  fi
+fi
+
+# IDE MCP (JetBrains) - check if MCP tools are available
+```
+
+**1e. Check CLAUDE.md:**
+- If `CLAUDE.md` exists, read its content
+
+**1f. Scan existing skills:**
+- Check `.claude/skills/` for existing project-specific skills
+
+### Step 2: Gather User Preferences (interactive via AskUserQuestion)
+
+**2a. If config exists:**
+- "Configuration already exists. What would you like to do?"
+  - Options: "Update existing", "Start fresh", "Cancel"
+  - If Cancel: stop here
+
+**2b. Confirm project type:**
+- "Detected project type: {detected-type}. Is this correct?"
+  - Options: "Yes (recommended)", "No, choose manually"
+- If manual, present list: JavaScript/TypeScript, Next.js, NestJS, Express, React, Vue, Java (Gradle), Java (Maven), Python, Django, Flask, Rust, Go, Ruby on Rails, Other
+
+**2c. Ticket ID pattern:**
+- "How do you track work items in this project?"
+  - Options:
+    1. "JIRA-style (e.g., PROJ-1234)" - Pattern: `[A-Z]+-\\d+`
+    2. "GitHub Issues (e.g., #123)" - Pattern: `#\\d+`
+    3. "Linear (e.g., ENG-1234)" - Pattern: `[A-Z]{3}-\\d+`
+    4. "No tracking / skip" - Pattern: null
+- Follow-up: "Extract ticket ID from branch name?" - Options: "Yes (recommended)", "No"
+
+**2d. Branch naming convention:**
+- "What branch naming convention do you use?"
+  - Options:
+    1. "ticket-id/description (e.g., PROJ-1234/add-feature)"
+    2. "feature/description (e.g., feature/add-login)"
+    3. "Custom pattern"
+    4. "No convention"
+
+**2e. Confirm build/test commands:**
+- "Suggested build command: `{command}`. Use this?"
+  - Options: "Yes (recommended)", "Customize", "None (no build step)"
+- "Suggested test command: `{command}`. Use this?"
+  - Options: "Yes (recommended)", "Customize", "None (no test step)"
+
+**2f. Confirm CLAUDE.md generation:**
+- "Generate/update CLAUDE.md? This will analyze your codebase to document structure and conventions."
+  - Options: "Yes (recommended)", "Skip"
+
+**2g. Confirm project-specific skills:**
+- Present proposed skills based on detected project type (see skill table in configure-project/SKILL.md)
+- "These project-specific skills were detected for your {project-type} project: {skill-list}. Confirm or customize?"
+  - Options: "Use these (recommended)", "Customize", "Skip skill generation"
+
+### Step 3: Create Feature Spec
+
+Write `.5/CONFIGURE/feature.md` containing all gathered data:
+
+```markdown
+# Feature: Project Configuration
+
+## Summary
+Configure the 5-phase workflow for this {project-type} project. Creates config.json, generates CLAUDE.md with codebase analysis, and creates project-specific skills.
+
+## Requirements
+
+### Requirement 1: Create config.json
+Create `.claude/.5/config.json` with the following values:
+- Project type: {project-type}
+- Ticket pattern: {pattern}
+- Extract from branch: {yes/no}
+- Branch convention: {convention}
+- Build command: {build-command}
+- Test command: {test-command}
+- Build timeout: 120000ms
+- Test timeout: 300000ms
+- CodeRabbit: {available/not-available}, authenticated: {yes/no}
+- IDE integration: {available/not-available}, type: {type}
+- Review tool: {coderabbit/none}
+
+### Requirement 2: Generate Documentation Files
+Analyze the codebase and generate modular documentation:
+
+**Create separate documentation files in `.5/` folder:**
+- `.5/ARCHITECTURE.md` - Architectural patterns and layers
+- `.5/STACK.md` - Technology stack and dependencies
+- `.5/STRUCTURE.md` - Directory layout and organization
+- `.5/CONVENTIONS.md` - Coding standards and patterns
+- `.5/TESTING.md` - Test framework and patterns
+- `.5/INTEGRATIONS.md` - External services and APIs
+- `.5/CONCERNS.md` - Tech debt, bugs, and risks
+
+**Create CLAUDE.md as navigation hub:**
+- Quick reference section with links to all `.5/*.md` files
+- Project overview and build commands
+- "Getting Started" guide with references to appropriate files
+- Mandatory coding guidelines:
+  1. Types should be clear and types should be available when possible
+  2. Use doc (jsdoc, javadoc, pydoc, etc) concisely. No doc is better than meaningless doc
+  3. Keep files short and structured
+  4. Extract methods, classes
+  5. Respect SRP and DRY
+  6. Make code maintainable and modular
+
+**Preserve existing content:**
+- If CLAUDE.md already exists, preserve user-written custom sections
+
+### Requirement 3: Generate Project-Specific Skills
+Generate the following skills in `.claude/skills/`:
+{List of confirmed skills, e.g.:}
+- create-component: Creates a React component following project conventions
+- create-hook: Creates a custom React hook following project conventions
+- create-context: Creates a React context provider following project conventions
+
+Each skill should:
+- Follow standard SKILL.md frontmatter pattern
+- Derive patterns from existing code in the project
+- Include file naming and location conventions
+- Include template/pattern based on existing examples
+
+## Acceptance Criteria
+- [ ] `.claude/.5/config.json` exists with correct values (no `steps` array)
+- [ ] `.5/` directory created
+- [ ] All 7 documentation files exist and are populated:
+  - [ ] `.5/ARCHITECTURE.md`
+  - [ ] `.5/STACK.md`
+  - [ ] `.5/STRUCTURE.md`
+  - [ ] `.5/CONVENTIONS.md`
+  - [ ] `.5/TESTING.md`
+  - [ ] `.5/INTEGRATIONS.md`
+  - [ ] `.5/CONCERNS.md`
+- [ ] `CLAUDE.md` exists with references to `.5/` files
+- [ ] CLAUDE.md contains 6 coding guidelines
+- [ ] No placeholder text like `{YYYY-MM-DD}` remains unfilled
+- [ ] All specified project-specific skills are generated in `.claude/skills/`
+- [ ] Generated skills reference actual project conventions
+- [ ] If CLAUDE.md existed before, user-written sections are preserved
+```
+
+**Important:** Use `mkdir -p .5/CONFIGURE` before writing the feature spec.
+
+### Step 4: Guide User to Next Phase
+
+Tell the user:
+
+1. "Configuration feature planned at `.5/CONFIGURE/feature.md`"
+2. "Next: Run `/5:plan-implementation CONFIGURE`"
+3. "Then: `/5:implement-feature CONFIGURE` -> `/5:verify-implementation` -> `/5:review-code`"
+
+## DO NOT
+
+- DO NOT write config.json directly (that's Phase 3's job via the configure-project skill)
+- DO NOT create CLAUDE.md directly (that's Phase 3's job)
+- DO NOT generate skills directly (that's Phase 3's job)
+- DO NOT skip user interaction - always confirm detected values
+- DO NOT assume project structure - always detect or ask
+
+## Example Usage
+
+```
+User: /5:configure
+
+[Step 1: Auto-detection runs silently]
+
+Claude: "Detected project type: Next.js. Is this correct?"
+User: "Yes"
+
+Claude: "How do you track work items?"
+User: "GitHub Issues"
+
+Claude: "Extract ticket ID from branch name?"
+User: "Yes"
+
+Claude: "Branch naming convention?"
+User: "feature/description"
+
+Claude: "Build command: `npm run build`. Use this?"
+User: "Yes"
+
+Claude: "Test command: `npm test`. Use this?"
+User: "Yes"
+
+Claude: "Generate CLAUDE.md with codebase analysis?"
+User: "Yes"
+
+Claude: "Proposed skills for Next.js: create-page, create-api-route, create-component. Confirm?"
+User: "Use these"
+
+Claude: [Writes .5/CONFIGURE/feature.md]
+Claude: "Configuration feature planned at `.5/CONFIGURE/feature.md`"
+Claude: "Next: Run `/5:plan-implementation CONFIGURE`"
+```
+
+## Related Documentation
+
+- [5-Phase Workflow Guide](../../docs/workflow-guide.md)
+- [configure-project skill](../../skills/configure-project/SKILL.md)
+- [/5:plan-feature command](./plan-feature.md)
+- [/5:plan-implementation command](./plan-implementation.md)

package/src/commands/5/discuss-feature.md

@@ -0,0 +1,393 @@
+---
+name: 5:discuss-feature
+description: Discusses and refines an existing feature specification through iterative Q&A. Use after /plan-feature when requirements need clarification or changes. Updates the feature spec based on discussion.
+allowed-tools: Read, Write, Glob, Grep, Task, AskUserQuestion
+context: inherit
+user-invocable: true
+---
+
+# Discuss Feature Specification (Phase 1 - Optional Iteration)
+
+## Overview
+
+This skill is part of **Phase 1** (Feature Planning) of the 5-phase workflow:
+1. **Feature Planning** - Initial requirements gathering (`/plan-feature`), then optional iteration (`/discuss-feature`)
+2. **Implementation Planning** - Map to technical components
+3. **Orchestrated Implementation** - Execute with state tracking
+4. **Verify Implementation** - Check completeness and correctness
+5. **Code Review** - Apply automated quality improvements
+
+This skill enables **optional iterative refinement** of feature specs after initial planning through discussion, clarification, and requirement changes. Use it when the initial spec needs adjustments before proceeding to implementation planning.
+
+## Use Cases
+
+Use this skill when:
+- Requirements need clarification after initial planning
+- User wants to add/modify/remove requirements
+- Scope needs adjustment
+- Technical constraints discovered during exploration
+- Alternative approaches need evaluation
+- Feature complexity needs reduction
+- Acceptance criteria need refinement
+
+## Prerequisites
+
+Before invoking this skill, ensure:
+1. Feature spec exists at `.5/{feature-name}/feature.md`
+2. You have the feature name or ticket ID ready (e.g., "PROJ-1234-add-feature")
+
+## Discussion Process
+
+### Step 1: Extract Feature Name
+
+If user provides only ticket ID (e.g., "PROJ-1234"), find the feature file:
+- Use Glob: `.5/{TICKET-ID}-*-*/feature.md` (pattern from config)
+- Match the ticket ID
+- If multiple matches, ask user to specify
+- If no match found, inform user and suggest running `/plan-feature` first
+
+If user provides full feature name (e.g., "PROJ-1234-add-feature"), use directly.
+
+### Step 2: Read Feature Specification
+
+Read the feature spec from `.5/{feature-name}/feature.md`.
+
+Extract current state:
+- Ticket ID
+- Summary
+- Requirements (functional and non-functional)
+- Constraints
+- Affected domains
+- Entity definitions
+- Business rules
+- Acceptance criteria
+- Alternatives considered
+- Questions & Answers
+
+### Step 3: Initial Discussion Prompt
+
+**FIRST ACTION:** Ask the user what they want to discuss using AskUserQuestion.
+
+Prompt to use:
+
+"What would you like to discuss or change about this feature?"
+
+Provide context options for common scenarios:
+- "Clarify existing requirements"
+- "Add new requirements"
+- "Remove or simplify requirements"
+- "Change scope or approach"
+- "Discuss technical constraints"
+- "Review acceptance criteria"
+- "Other (specify)"
+
+Use `multiSelect: false` to get single focus area initially.
+
+### Step 4: Contextual Exploration (Optional)
+
+Based on the user's focus area, explore the codebase if needed:
+
+**For technical constraint discussions:**
+- Search for similar implementations
+- Check existing patterns
+- Identify integration points
+
+**For scope changes:**
+- Verify affected modules
+- Check dependencies
+- Identify ripple effects
+
+Use Task tool with subagent_type=Explore for complex exploration.
+
+### Step 5: Interactive Q&A
+
+Based on the discussion topic, ask targeted follow-up questions using AskUserQuestion.
+
+**Question types by topic:**
+
+**Clarify Requirements:**
+- "The current requirement says X. Should it also handle Y scenario?"
+- "How should the system behave when Z happens?"
+- "Are there edge cases we haven't considered?"
+
+**Add Requirements:**
+- "What is the expected behavior for this new requirement?"
+- "How does this interact with existing requirement X?"
+- "Should this be in scope or future work?"
+
+**Simplify/Remove:**
+- "If we remove X, what's the minimum viable version?"
+- "Can we defer Y to a future iteration?"
+- "Would simpler approach Z meet the core need?"
+
+**Change Approach:**
+- "What are the pros/cons of approach A vs B?"
+- "Have you considered alternative C?"
+- "What's the trade-off we're trying to optimize?"
+
+**Technical Constraints:**
+- "Is performance constraint X realistic?"
+- "Should we use existing component Y instead?"
+- "How will this integrate with system Z?"
+
+**Acceptance Criteria:**
+- "How will we verify requirement X is met?"
+- "What does success look like for this feature?"
+- "Are there specific test scenarios?"
+
+### Step 6: Iterative Refinement
+
+After each round of Q&A:
+1. Summarize what you've learned
+2. Ask: "Would you like to discuss anything else about this feature?"
+3. Provide options:
+   - "Yes, discuss another aspect"
+   - "Yes, continue this topic"
+   - "No, update the spec"
+
+Allow multiple rounds of discussion until user is satisfied.
+
+### Step 7: Update Feature Specification
+
+When user indicates they're done discussing, update `.5/{feature-name}/feature.md`:
+
+**Update these sections based on discussion:**
+
+1. **Summary** - If core understanding changed
+2. **Problem Statement** - If motivation clarified
+3. **Requirements** - Add/modify/remove based on discussion
+4. **Constraints** - Add new constraints discovered
+5. **Affected Domains** - If scope changed
+6. **Entity/Component Definitions** - If data model changed
+7. **Business Rules** - If logic clarified
+8. **Acceptance Criteria** - Add/refine verification criteria
+9. **Alternatives Considered** - Document discussed alternatives
+10. **Questions & Answers** - Append new Q&A from this session
+
+**Preserve existing content** - Only update sections that changed during discussion.
+
+**Track changes** - Add a "Discussion History" section if it doesn't exist:
+
+```markdown
+## Discussion History
+
+### Session 1: {Date} - {Topic}
+**Changes made:**
+- Added requirement: {X}
+- Clarified: {Y}
+- Removed: {Z}
+
+**Rationale:** {Why these changes}
+```
+
+### Step 8: Inform Developer
+
+After updating the spec, tell the developer:
+
+1. "Feature specification updated at `.5/{feature-name}/feature.md`"
+2. Summarize key changes:
+   - "Added: {X}"
+   - "Modified: {Y}"
+   - "Removed: {Z}"
+3. Ask: "Would you like to:"
+   - "Discuss more (run /discuss-feature again)"
+   - "Proceed to implementation planning (run /plan-implementation {feature-name})"
+   - "Review the updated spec first"
+
+## Instructions Summary
+
+1. **Extract feature name** - From user input or by matching ticket ID
+2. **Read feature spec** - Load current state from `.5/{feature-name}/feature.md`
+3. **Ask initial question** - What do they want to discuss?
+4. **Explore if needed** - Understand codebase context
+5. **Interactive Q&A** - Multiple rounds of clarifying questions
+6. **Iterate** - Allow continued discussion
+7. **Update feature spec** - Modify relevant sections
+8. **Track changes** - Document discussion history
+9. **Inform developer** - Summarize changes and next steps
+
+## Key Principles
+
+1. **User-driven** - Follow user's focus areas, don't prescribe
+2. **Iterative** - Allow multiple discussion rounds
+3. **Contextual** - Explore codebase when relevant
+4. **Challenge constructively** - Question complexity, suggest alternatives
+5. **Document evolution** - Track how requirements changed
+6. **Preserve history** - Keep previous Q&A, add new discussions
+7. **Clear next steps** - Guide user on what to do next
+
+## DO NOT in This Skill
+
+- DO NOT rewrite the entire feature spec (only update changed sections)
+- DO NOT skip asking what the user wants to discuss
+- DO NOT create new feature specs (use /plan-feature for that)
+- DO NOT proceed to technical planning (that's Phase 2's job)
+- DO NOT start implementation
+- DO NOT delete previous Q&A sections (append to them)
+
+## Discussion Patterns
+
+### Pattern 1: Scope Reduction
+User: "This is too complex, can we simplify?"
+Skill:
+1. Ask: "What's the minimum viable version?"
+2. Ask: "Which requirements are must-have vs nice-to-have?"
+3. Present options for phased approach
+4. Update spec with reduced scope
+
+### Pattern 2: Requirement Addition
+User: "We need to also handle X scenario"
+Skill:
+1. Ask: "How should X scenario work?"
+2. Ask: "How does X interact with existing requirement Y?"
+3. Ask: "Should X be in this feature or separate?"
+4. Update requirements section
+
+### Pattern 3: Technical Feasibility
+User: "Can we reuse existing component Z?"
+Skill:
+1. Explore: Find component Z implementation
+2. Ask: "Does Z fully meet the need or need extension?"
+3. Present trade-offs: reuse vs custom
+4. Update affected domains and approach
+
+### Pattern 4: Acceptance Criteria
+User: "How do we verify this works?"
+Skill:
+1. Ask: "What's the happy path test?"
+2. Ask: "What edge cases should we test?"
+3. Ask: "What does failure look like?"
+4. Update acceptance criteria section
+
+### Pattern 5: Alternative Evaluation
+User: "Should we use approach A or B?"
+Skill:
+1. Ask: "What's the goal: simplicity, performance, flexibility?"
+2. Present pros/cons of each approach
+3. Ask: "What constraints matter most?"
+4. Update alternatives considered section
+
+## Example Workflow
+
+### Example 1: Scope Clarification
+
+```
+User: /discuss-feature PROJ-1234-add-feature
+
+Skill: [Reads feature spec]
+Skill: "What would you like to discuss or change about this feature?"
+
+User: "Clarify existing requirements"
+
+Skill: "The current spec mentions 'emergency schedule window'. Should this support:
+- Single time window per product?
+- Multiple overlapping windows?
+- Recurring schedules?
+What level of complexity do you need?"
+
+User: "Just single window per product for now"
+
+Skill: "Should we support updating/deleting the window after it's set?"
+
+User: "Yes, full CRUD"
+
+Skill: "Would you like to discuss anything else about this feature?"
+
+User: "No, update the spec"
+
+Skill: [Updates Requirements and Acceptance Criteria sections]
+Skill: "Feature specification updated. Changes:
+- Clarified: Single emergency window per product (not multiple)
+- Added: Full CRUD operations for emergency windows
+Would you like to proceed to implementation planning? Run: /plan-implementation PROJ-1234-add-feature"
+```
+
+### Example 2: Adding Requirements
+
+```
+User: /discuss-feature PROJ-1234
+
+Skill: [Finds PROJ-1234-add-feature.md]
+Skill: "What would you like to discuss or change about this feature?"
+
+User: "Add new requirements"
+
+Skill: "What new requirement would you like to add?"
+
+User: "We need to notify customers when emergency schedule is activated"
+
+Skill: "How should notifications be delivered?
+- Email only
+- SMS only
+- Both email and SMS
+- Configurable per customer"
+
+User: "Email only for now"
+
+Skill: "Should notification be:
+- Immediate when emergency schedule is created?
+- When emergency window starts?
+- Both?"
+
+User: "When emergency window starts"
+
+Skill: "Would you like to discuss anything else?"
+
+User: "No, update the spec"
+
+Skill: [Updates Requirements, adds email notification requirement]
+Skill: [Updates Affected Domains, adds email service integration]
+Skill: [Updates Acceptance Criteria, adds notification verification]
+Skill: "Feature specification updated. Changes:
+- Added: Email notification when emergency window starts
+- Added: Integration with email service
+Review the changes and run: /plan-implementation 12345-implement-your-new-feature when ready"
+```
+
+### Example 3: Simplification
+
+```
+User: /discuss-feature PROJ-1234-add-feature
+
+Skill: "What would you like to discuss or change about this feature?"
+
+User: "Remove or simplify requirements"
+
+Skill: "Current requirements include:
+1. Emergency schedule CRUD
+2. Email notifications
+3. Audit logging
+4. Analytics tracking
+Which are critical for MVP?"
+
+User: "Just #1 and #3. We can add notifications and analytics later"
+
+Skill: "So we'll keep emergency schedule CRUD and audit logging, defer notifications and analytics to future work?"
+
+User: "Correct"
+
+Skill: [Updates Requirements, moves #2 and #4 to "Future Enhancements" section]
+Skill: [Updates Affected Domains, removes email and analytics integrations]
+Skill: "Feature specification updated. Changes:
+- Removed: Email notifications (moved to future enhancements)
+- Removed: Analytics tracking (moved to future enhancements)
+- Kept: Core CRUD and audit logging
+The simplified scope should reduce implementation complexity significantly."
+```
+
+## Tips for Effective Discussion
+
+1. **Read the spec first** - Understand current state before asking questions
+2. **Focus on one topic** - Don't try to discuss everything at once
+3. **Ask open questions** - Let user explain their thinking
+4. **Present options** - Give user choices with pros/cons
+5. **Challenge gently** - "Have you considered..." not "You should..."
+6. **Summarize often** - Confirm understanding before moving on
+7. **Track rationale** - Document WHY decisions were made
+8. **Be patient** - Allow multiple rounds until clarity emerges
+
+## Related Documentation
+
+- [5-Phase Workflow Guide](../docs/workflow-guide.md)
+- [plan-feature command](./plan-feature.md)
+- [plan-implementation command](./plan-implementation.md)