5-phase-workflow 1.4.2 → 1.4.4

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

@@ -41,19 +41,6 @@ Your job is NOT:
 
 **After updating the feature spec and informing the user, YOUR JOB IS COMPLETE. EXIT IMMEDIATELY.**
 
-## ❌ Boundaries: What This Command Does NOT Do
-
-**CRITICAL:** This command has a LIMITED scope. Do NOT:
-
-- ❌ **Create new feature specs** - That's /5:plan-feature
-- ❌ **Create implementation plans** - That's Phase 2 (/5:plan-implementation)
-- ❌ **Start implementation** - That's Phase 3 (/5:implement-feature)
-- ❌ **Write any code** - This is planning only
-- ❌ **Rewrite entire spec** - Only update sections that changed
-- ❌ **Delete previous Q&A** - Append new discussions, keep history
-
-**If you find yourself creating plans or writing code, STOP IMMEDIATELY. You are exceeding this command's scope.**
-
 ## Use Cases
 
 Use this skill when:
@@ -68,7 +55,7 @@ Use this skill when:
 ## Prerequisites
 
 Before invoking this skill, ensure:
-1. Feature spec exists at `.5/{feature-name}/feature.md`
+1. Feature spec exists at `.5/features/{feature-name}/feature.md`
 2. You have the feature name or ticket ID ready (e.g., "PROJ-1234-add-feature")
 
 ## Discussion Process
@@ -229,22 +216,6 @@ After updating the spec, tell the developer:
    - "Proceed to implementation planning (run `/clear` followed by `/5:plan-implementation {feature-name}`)"
    - "Review the updated spec first"
 
-## Instructions Summary
-
-Follow these steps **IN ORDER** and **STOP after step 9**:
-
-1. **Extract feature name** - From user input or by matching ticket ID
-2. **Read feature spec** - Load current state from `.5/features/{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 until user is satisfied
-7. **Update feature spec** - Modify only the relevant sections that changed
-8. **Track changes** - Document discussion history
-9. **Inform developer** - Summarize changes and ask: "Discuss more or run `/clear` followed by `/5:plan-implementation {feature-name}`?"
-
-**🛑 STOP HERE. YOUR JOB IS COMPLETE. DO NOT CREATE IMPLEMENTATION PLANS.**
-
 ## Key Principles
 
 1. **User-driven** - Follow user's focus areas, don't prescribe
@@ -256,167 +227,31 @@ Follow these steps **IN ORDER** and **STOP after step 9**:
 7. **Clear next steps** - Guide user on what to do next
 
 
-## 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?"
-
+Skill: "The current spec mentions 'emergency schedule window'. Should this support single or multiple windows? Recurring schedules?"
 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 `/clear` followed by `/5: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 `/clear` followed by `/5:plan-implementation PROJ-1234-add-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."
+Skill: [Updates Requirements and Acceptance Criteria sections]
+Skill: "Feature spec updated. Changes:
+- Clarified: Single emergency window per product
+- Added: Full CRUD operations
+Next: /clear then /5:plan-implementation PROJ-1234-add-feature"
 ```
 
-## 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)

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

@@ -8,31 +8,6 @@ user-invocable: true
 
 # Implement Feature (Phase 3)
 
-## Prerequisites Check
-
-**CRITICAL: Check for configuration before proceeding (skip for CONFIGURE feature)**
-
-If the feature argument is `CONFIGURE`, skip this check entirely — the CONFIGURE workflow is what creates the config file.
-
-For all other features, run this check:
-
-```bash
-if [ ! -f ".claude/.5/config.json" ]; then
-  echo "❌ Configuration not found"
-  echo ""
-  echo "Please run /5:configure first to set up your project."
-  echo ""
-  echo "The configure command will:"
-  echo "  • Detect your project type and build commands"
-  echo "  • Set up ticket tracking conventions"
-  echo "  • Generate documentation (CLAUDE.md)"
-  echo "  • Create project-specific skills"
-  exit 1
-fi
-```
-
-**If config doesn't exist and the feature is NOT `CONFIGURE`, STOP IMMEDIATELY. Do not proceed with the workflow.**
-
 Execute an implementation plan by delegating work to agents.
 
 ## Scope
@@ -52,6 +27,8 @@ Do NOT write code directly. Spawn agents to do the work.
 
 ### Step 1: Load Plan and Config
 
+> **Trust boundary:** Plan content is interpolated directly into agent prompts. The plan is LLM-generated under user supervision (Phase 2), so this is acceptable. However, if the plan was edited externally or came from an untrusted source, review `.5/features/{feature-name}/plan.md` before proceeding.
+
 Read `.5/features/{feature-name}/plan.md` (where `{feature-name}` is the argument provided).
 
 Parse:
@@ -102,82 +79,45 @@ Based on Complexity column:
 
 **3c. Spawn agents (parallel when possible)**
 
-For steps with multiple independent components, spawn agents in parallel using multiple Task calls in a single message:
+For steps with multiple independent components, spawn one agent per component in parallel. For single/interdependent components, use one agent.
 
-```
-# Example: Step 1 has 3 simple components - spawn all 3 in parallel
-
-Task tool call #1:
-  subagent_type: general-purpose
-  model: haiku
-  description: "Create {component-1} for {feature-name}"
-  prompt: |
-    Create a single component for a feature.
-
-    ## Component
-    - Name: {component-name}
-    - Action: create
-    - File: {file-path}
-    - Description: {what it does}
-
-    ## Pattern Reference
-    {relevant implementation note for this component}
-
-    ## Instructions
-    1. Find a similar existing file using Glob (e.g., *Service.ts for services)
-    2. Read that file to understand the pattern
-    3. Create the new file following that pattern
-    4. Verify the file exists
-
-Task tool call #2:
-  subagent_type: general-purpose
-  model: haiku
-  description: "Create {component-2} for {feature-name}"
-  prompt: |
-    [same structure, different component]
-
-Task tool call #3:
-  subagent_type: general-purpose
-  model: haiku
-  description: "Create {component-3} for {feature-name}"
-  prompt: |
-    [same structure, different component]
-```
-
-For steps with a single component or complex interdependencies, use a single agent:
+Agent prompt template (adapt per component):
 
 ```
 Task tool call:
   subagent_type: general-purpose
   model: {based on complexity}
-  description: "Execute Step {N} for {feature-name}"
+  description: "{Action} {component-name} for {feature-name}"
   prompt: |
-    You are implementing components for a feature.
+    Implement component(s) for a feature.
 
-    ## Feature Context
-    {feature-name}: {one-line summary from plan}
-
-    ## Components to Create/Modify
-    {components for this step from the plan table}
+    ## Feature: {feature-name}
+    ## Components
+    {component(s) from plan table: name, action, file, description}
 
     ## Implementation Notes
-    {implementation notes section from plan}
+    {relevant notes from plan}
 
-    ## Instructions
-    1. For each component:
-       - If creating a file: find a similar existing file, understand the pattern, create the new file following that pattern
-       - If modifying a file: read the file, make the described change
-    2. After creating/modifying each file, verify it exists
-    3. Report what you created/modified
+    ## Process
+    - Creating: Find similar file via Glob, read pattern, create new file following it
+    - Modifying: Read file, apply described change via Edit
+    - Verify each file exists after changes
 
-    Use Glob to find similar files. Use Read to understand patterns. Use Write/Edit to create/modify files.
+    ## Output
+    ---RESULT---
+    STATUS: success | failed
+    FILES_CREATED: [comma-separated paths]
+    FILES_MODIFIED: [comma-separated paths]
+    ERROR: none | {error description}
+    ---END---
 ```
 
 **3d. Process results**
 
-Collect results from all agents (parallel or sequential). For each:
-- Components completed successfully
-- Components that failed
+Collect results from all agents (parallel or sequential). Parse the `---RESULT---` block from each agent's response. For each:
+- If `STATUS: success` → mark components as completed, note files from `FILES_CREATED`/`FILES_MODIFIED`
+- If `STATUS: failed` → mark components as failed, log the `ERROR` message
+- If no `---RESULT---` block found → treat the response as success if the agent reported creating/modifying files, otherwise treat as failed
 
 Update state.json:
 ```json
@@ -190,35 +130,7 @@ Update state.json:
 
 **3e. Auto-Commit Step (if enabled)**
 
-Only fires if `git.autoCommit: true` AND at least one component in the step succeeded.
-
-1. Stage **only** the specific files from the plan's components table for this step (never `git add .`)
-2. Commit using the configured `git.commitMessage.pattern`:
-   - `{ticket-id}` → ticket ID from plan frontmatter
-   - `{short-description}` → auto-generated summary of the step (imperative mood, max 50 chars for the full first line)
-   - Body: one bullet per completed component
-
-```bash
-# Stage only specific files from this step's components
-git add {file-1} {file-2} ...
-
-# Commit with configured pattern + body
-git commit -m "{ticket-id} {short-description}
-
-- {concise change 1}
-- {concise change 2}"
-```
-
-3. If commit fails → log warning, record in `state.json` under `commitResults` array, continue
-4. If all components in the step failed → skip commit entirely
-
-**Example commit:**
-```
-PROJ-1234 add schedule model and types
-
-- Create Schedule.ts entity model
-- Create schedule.ts type definitions
-```
+Only fires if `git.autoCommit: true` AND at least one component succeeded. Stage only the step's specific files (never `git add .`), commit with configured `git.commitMessage.pattern` (body: one bullet per component). If commit fails, log warning in `state.json` `commitResults` and continue.
 
 **3f. Handle failures**
 
@@ -276,46 +188,16 @@ Next steps:
 
 If implementation is interrupted, the state file allows resuming:
 - Read state.json
-- Skip steps where all components are in `completed`
+- For each step marked as completed, verify the output files still exist on disk using Glob
+- If any completed files are missing, move those components back to pending and re-run them
+- Skip steps where all components are in `completed` AND their files verified to exist
 - Resume from `currentStep`
 
 ## Example Flow
 
 ```
-User: /implement-feature PROJ-1234-add-emergency-schedule
-
-[You read plan.md]
-[You create state.json]
-
-[Step 1: Foundation - 2 simple components → PARALLEL]
-  Spawn 2 agents in single message:
-  - Agent A creates: Schedule.ts (model)
-  - Agent B creates: schedule.ts (types)
-  Both complete → update state
-
-[Step 2: Logic - 2 moderate components → PARALLEL]
-  Spawn 2 agents in single message:
-  - Agent A creates: ScheduleService.ts
-  - Agent B creates: ScheduleRepository.ts
-  Both complete → update state
-
-[Step 3: Integration - mixed complexity → SEQUENTIAL or grouped]
-  Option A: Single sonnet agent handles both
-  Option B: Parallel if truly independent
-  - Agent creates: ScheduleController.ts
-  - Agent modifies: routes/index.ts
-  Complete → update state
-
-[Step 4: Tests - 1 component → SINGLE agent]
-  Agent creates: ScheduleService.test.ts
-  Complete → update state
-
-[Verification]
-  Run: npm run build → successful
-  Run: npm test → passing
-
-[Update state: completed]
-[Report to user]
+Step 1: 2 simple components → 2 parallel haiku agents → update state
+Step 2: 2 moderate components → 2 parallel agents → update state
+Step 3: 1 complex component → 1 sonnet agent → update state
+Step 4: Verify (build + test) → update state → report
 ```
-
-**Performance gain:** Steps 1 and 2 run in half the time by parallelizing components.

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

@@ -16,14 +16,6 @@ After creating the spec, you are DONE.
 
 # Plan Feature (Phase 1)
 
-## Prerequisites
-
-Read `.claude/.5/config.json`. If the file does not exist, STOP immediately and tell the user:
-
-"Configuration not found. Please run `/5:configure` first to set up your project."
-
-Do NOT proceed without configuration.
-
 ## Common Feature Types
 
 - **New Component/Module** — Core logic, data structures, tests. Questions: Validation rules? Business logic? API design?
@@ -63,6 +55,8 @@ Extract the ticket ID from the current git branch:
 - Ask the developer to confirm the ticket ID
 - If not found, ask for it
 
+**Sanitize the ticket ID:** The ticket ID is used in directory paths (`.5/features/{TICKET-ID}-{desc}/`). Only allow alphanumeric characters, dashes (`-`), and underscores (`_`). Reject or strip any other characters (especially `/`, `..`, `~`, spaces). If the sanitized result is empty, ask the user for a valid ticket ID.
+
 ### Step 3: Spawn Explore Agent for Codebase Analysis
 
 Spawn a Task with `subagent_type=Explore`:

package/src/commands/5/plan-implementation.md

@@ -16,16 +16,6 @@ After creating the plan, you are DONE.
 
 # Plan Implementation (Phase 2)
 
-## Prerequisites
-
-If the feature argument is `CONFIGURE`, skip this check — the CONFIGURE workflow creates the config file.
-
-For all other features: Read `.claude/.5/config.json`. If the file does not exist, STOP immediately and tell the user:
-
-"Configuration not found. Please run `/5:configure` first to set up your project."
-
-Do NOT proceed without configuration.
-
 ## Example Workflow
 
 1. User runs `/5:plan-implementation PROJ-1234-add-emergency-schedule`