Workflow

---
name: workflow
description: "Complete automated flow with Preflight Plan and stop/resume"
---

# Command: /workflow

## Purpose

Execute the complete development workflow with Preflight Planning, state persistence, and stop/resume capability. Orchestrates all 6 specialized agents (0→5) with approval gates at critical points.

## When to Use

Use this command:
- **At the start of any development task** to execute structured workflow
- **When you want automated orchestration** of all workflow steps
- **For tasks requiring planning and approval** before implementation
- **When you need stop/resume capability** for complex changes
- **As the primary workflow command** for development

## Behavior

This command executes in **two phases**:

---

## PHASE 1: Preflight Plan (Planning Phase)

### 1.1 Generate Preflight Plan

Analyzes the requested task and generates a 10-15 line checklist covering:

**Plan Structure:**
```markdown
## Preflight Plan - [Task Description]

**1. Objective:**
   [What will be accomplished]

**2. Suggested Branch:**
   [Recommended branch name: feature/*, fix/*, hotfix/*]

**3. Scope:**
   [frontend | backend | database | fullstack]

**4. Modules/Files Affected:**
   - [List of modules and key files that will be modified]

**5. API Contracts Affected:**
   [Yes/No + list of endpoints if yes]

**6. DB Schema Changes:**
   [Yes/No + tables affected if yes]

**7. Estimated Risk:**
   [LOW | MEDIUM | HIGH + brief reasoning]

**8. Minimum Required Tests:**
   - [Test type 1]
   - [Test type 2]

**9. Acceptance Criteria:**
   - [Criterion 1]
   - [Criterion 2]
   - [Criterion 3]

**10. Prohibited Changes:**
   [e.g., "Do not touch {{STABLE_MODULES}}"]

**11. Available Tools:**
   **MCPs:**
   - [List configured MCPs with status]

   **Skills:**
   - [List: workflow, implement-backend/frontend/database, etc.]

**12. Blocking Questions:**
   [Any ambiguities that must be resolved before starting]

1.2 User Approval Gate (MANDATORY)

Question: "Do you approve this implementation plan? (yes/no)"

If User Says NO:

• Iterate on plan based on feedback
• Regenerate improved plan
• Ask for approval again
• Repeat until approved or user cancels

If User Says YES:

• Save approved plan to .claude/state/workflow.json
• Initialize workflow state with status: "running"
• Proceed to Phase 2 (Execution)

---

PHASE 2: Execution (Sequential Steps 0→5)

Executes agents in mandatory sequence, updating state after each step.

Step 0: Workspace Validation

Agent: git-workspace-validator Command: /validate-workspace

Actions:

• Verify branch ≠ {{BRANCH_MAIN}}
• Check workspace cleanliness
• Verify remote synchronization

Outcome Handling:

• OK: Proceed to step 1
• WARNING: Log warnings, proceed
• BLOCKED: STOP → Pause workflow, save reason

STOP Trigger: If verdict is "BLOCKED"

• Set paused: true, pauseReason: "workspace-unsafe"
• Save state with currentStep: 0
• Display: "🛑 Workflow paused: [reason]. Resolve the issue and run /workflow to resume."
• Exit workflow

State Update:

{
  "currentStep": 0,
  "steps": {
    "step0_validation": {
      "status": "completed",
      "verdict": "OK|WARNING|BLOCKED",
      "summary": "...",
      "timestamp": "ISO-8601"
    }
  }
}

---

Step 1: Implementation

Agent: change-architect Command: /implement-controlled

Actions:

• Implement code changes within approved scope
• Respect architectural guardrails
• Follow project-specific workflow for database changes
• Apply naming conventions and API contracts

STOP Triggers:

• Stable module modification without approval:

  • If modifying {{STABLE_MODULES}}
  • AND not explicitly in Preflight Plan
  • STOP → Ask: "Confirm modification to STABLE module (in production)? (yes/no)"
  • If NO: pause workflow
  • If YES: continue but mark as HIGH risk

• Architecture violation detected:

  • If attempt to violate project guardrails
  • STOP → Provide correct workflow guidance, pause

State Update:

{
  "currentStep": 1,
  "steps": {
    "step1_implementation": {
      "status": "completed",
      "filesModified": ["file1", "file2"],
      "summary": "...",
      "timestamp": "ISO-8601"
    }
  }
}

---

Step 2: Impact Analysis

Agent: impact-analyzer Command: /impact-check

Actions:

• Inventory changes by layer (DB/Backend/Frontend)
• Classify risk: LOW/MEDIUM/HIGH
• Detect cross-module impacts
• Generate recommendations

STOP Trigger: If risk is HIGH

• Set steps.step2_impact.stopRequired: true
• STOP → Ask: "Continue with HIGH risk change? (yes/no)"
  • Display risk summary with specific triggers
  • Show potential impacts
• If NO: paused: true, pauseReason: "high-risk", save state, exit
• If YES: continue, log approval in state

Automatic HIGH Triggers:

• Destructive SQL (DROP TABLE, DROP COLUMN, ALTER TYPE)
• Stable module modification
• Breaking API changes
• Security-sensitive changes

State Update:

{
  "currentStep": 2,
  "steps": {
    "step2_impact": {
      "status": "completed",
      "riskLevel": "LOW|MEDIUM|HIGH",
      "summary": "...",
      "stopRequired": true,
      "timestamp": "ISO-8601"
    }
  }
}

---

Step 3: Documentation

Agent: docs-updater Command: /docs-update

Actions:

• Detect modules modified
• Update existing documentation
• Create new docs if needed
• Verify markdown validity

No STOP triggers in this step (documentation is low-risk)

State Update:

{
  "currentStep": 3,
  "steps": {
    "step3_documentation": {
      "status": "completed",
      "docsTouched": ["doc1.md", "doc2.md"],
      "summary": "...",
      "timestamp": "ISO-8601"
    }
  }
}

---

Step 4: Commit and Push

Agent: git-commit-pusher Command: /commit-push

Actions:

• Group changes into logical commits
• Generate conventional commit messages
• Create