@curdx/flow 1.1.11 → 2.0.0-beta.2

package/commands/plan-ceo.md

@@ -1,117 +0,0 @@
----
-name: plan-ceo
-description: CEO-level planning review — strategic / scope / ROI / opportunity cost. A business-layer review of design.md.
-argument-hint: "[spec-name]"
-allowed-tools: [Read, Write, Bash, Task]
----
-
-# Flow Plan CEO — Strategic-Layer Review
-
-@${CLAUDE_PLUGIN_ROOT}/knowledge/planning-reviews.md
-
-Review design.md from the **CEO perspective**: is this worth doing? Is the scope right?
-
-## Step 1: Preflight
-
-```bash
-SPEC_NAME="${ARGUMENTS:-$(cat .flow/.active-spec 2>/dev/null)}"
-[ -z "$SPEC_NAME" ] && { echo "✗ No active spec"; exit 1; }
-
-DIR=".flow/specs/$SPEC_NAME"
-[ ! -f "$DIR/design.md" ] && { echo "✗ Missing design.md. Run /curdx-flow:design first"; exit 1; }
-```
-
-## Step 2: Dispatch CEO-perspective review
-
-Reuse the `flow-architect` agent but switch the perspective:
-
-```
-Task:
-  subagent_type: general-purpose
-  description: "CEO Review: $SPEC_NAME"
-  prompt: |
-    **CEO Review Mode**
-    
-    You are not an architect, not a developer. You are a reviewer from the CEO / PM perspective.
-    
-    Full methodology: ${CLAUDE_PLUGIN_ROOT}/knowledge/planning-reviews.md (Review 1)
-    
-    Review targets:
-    - .flow/specs/$SPEC_NAME/requirements.md (business goals)
-    - .flow/specs/$SPEC_NAME/design.md (technical solution)
-    - .flow/PROJECT.md (project vision)
-    - .flow/ROADMAP.md (roadmap)
-    
-    Review checklist (answer each):
-    
-    1. Scope appropriateness
-       - Solution scope vs. business value vs. timeline
-       - Over-engineered? (doing more than currently necessary)
-       - Insufficient? (users still unsatisfied after completion)
-    
-    2. Timeline reasonableness
-       - Refer to the priorities in ROADMAP.md
-       - Is the urgency reasonable relative to other work in progress / pending?
-    
-    3. Quantifiable ROI
-       - User value: N users benefit / N scenarios unlocked
-       - Business value: revenue / retention / brand
-       - Engineering cost: estimated person-days
-    
-    4. Opportunity cost
-       - What does doing this mean we won't do?
-       - Is what's being deferred more important?
-    
-    5. Strategic alignment
-       - Does it support company OKRs / quarterly goals
-       - Does it lock in future choices (is this risky)
-    
-    6. Stakeholders
-       - Who benefits? How many?
-       - Who is affected (possibly negatively)?
-    
-    Use sequential-thinking ≥ 5 rounds for derivation.
-    
-    Output:
-    .flow/specs/$SPEC_NAME/plan-review-ceo.md
-    
-    Format:
-    # CEO Plan Review: $SPEC_NAME
-    
-    ## Verdict
-    - APPROVED / APPROVED_WITH_CONCERNS / NEEDS_REVISION / REJECTED
-    
-    ## Findings
-    
-    ### [Scope] Scope analysis
-    ...
-    
-    ### [Timeline] Timeline analysis
-    ...
-    
-    ### [ROI] Business value
-    ...
-    
-    ## Recommendations
-    - Concrete change recommendations (not abstract "increase value")
-    
-    Return a briefing to me.
-```
-
-## Step 3: Output
-
-```
-✓ CEO Review complete
-
-Verdict: <APPROVED / APPROVED_WITH_CONCERNS / NEEDS_REVISION>
-
-Key concerns:
-  - <concern 1>
-  - <concern 2>
-
-Report: .flow/specs/$SPEC_NAME/plan-review-ceo.md
-
-Next steps:
-- If NEEDS_REVISION → /curdx-flow:design to fix + rerun
-- If APPROVED → /curdx-flow:plan-eng (engineering layer) or /curdx-flow:tasks
-```

package/commands/plan-design.md

@@ -1,107 +0,0 @@
----
-name: plan-design
-description: Design planning review — UI/UX, design system, accessibility review. Dispatches flow-ux-designer (Emma).
-argument-hint: "[spec-name]"
-allowed-tools: [Read, Write, Bash, Task]
----
-
-# Flow Plan Design — Design-Layer Review
-
-@${CLAUDE_PLUGIN_ROOT}/knowledge/planning-reviews.md
-
-Review design.md and existing sketches (if any) from the **UX perspective**: can users use it? Is the visuals consistent?
-
-## Step 1: Preflight
-
-```bash
-SPEC_NAME="${ARGUMENTS:-$(cat .flow/.active-spec 2>/dev/null)}"
-[ -z "$SPEC_NAME" ] && { echo "✗ No active spec"; exit 1; }
-
-# If no UI-related content (pure backend spec) → skip
-DIR=".flow/specs/$SPEC_NAME"
-if ! grep -qE "(UI|UX|interface|user interface|frontend)" "$DIR"/*.md 2>/dev/null; then
-    echo "ℹ This spec does not involve UI; skipping Design Review"
-    exit 0
-fi
-```
-
-## Step 2: Dispatch Emma (Design Review mode)
-
-```
-Task:
-  subagent_type: general-purpose
-  description: "Design Review: $SPEC_NAME"
-  prompt: |
-    **Design Review Mode** (you are Emma, flow-ux-designer)
-    
-    Your full definition: ${CLAUDE_PLUGIN_ROOT}/agents/flow-ux-designer.md
-    Review methodology: ${CLAUDE_PLUGIN_ROOT}/knowledge/planning-reviews.md (Review 3)
-    
-    Review targets:
-    - .flow/specs/$SPEC_NAME/design.md (UI-related sections)
-    - .flow/specs/$SPEC_NAME/ui-sketch/ (if /curdx-flow:sketch has been run)
-    - .flow/CONTEXT.md (user preferences)
-    - Existing UI patterns in the project (.flow/codebase-index.md, if present)
-    
-    Review checklist:
-    
-    1. User flow
-       - Main scenario ≤ 3 steps?
-       - Multiple entry points?
-       - Keyboard flow?
-    
-    2. Error states
-       - Are failure messages user-friendly?
-       - Does the user know how to recover?
-    
-    3. Loading states
-       - Visual feedback for long-running operations?
-       - Skeleton / spinner?
-    
-    4. Empty states
-       - Guidance when no data (CTA / illustration)?
-       - Not a blank page
-    
-    5. Accessibility
-       - Color contrast WCAG AA+?
-       - Fully keyboard operable?
-       - Semantic HTML + ARIA?
-       - Screen-reader friendly?
-    
-    6. Design system consistency
-       - Using project tokens (colors / fonts / spacing)?
-       - Using existing components, not reinventing?
-       - New components within the theme?
-    
-    7. Mobile adaptation
-       - Usable at narrowest viewport (375px)?
-       - Touch targets ≥ 44pt?
-       - Both portrait and landscape unbroken?
-    
-    8. Internationalization
-       - Copy replaceable?
-       - RTL compatible?
-       - Space adapts to different lengths (e.g., German is ~30% longer than English)?
-    
-    Output: .flow/specs/$SPEC_NAME/plan-review-design.md
-    
-    Return a briefing.
-```
-
-## Step 3: Output
-
-```
-🎨 Design Review complete
-
-Verdict: <APPROVED / NEEDS_REVISION>
-
-Key findings:
-  - <top 3>
-
-Report: .flow/specs/$SPEC_NAME/plan-review-design.md
-
-Next steps:
-- UI/UX issues → /curdx-flow:sketch to iterate again
-- Or /curdx-flow:design to update UI-related sections
-- Pass → /curdx-flow:plan-dx or /curdx-flow:tasks
-```

package/commands/plan-dx.md

@@ -1,104 +0,0 @@
----
-name: plan-dx
-description: DevEx planning review — next maintainer's perspective, 8-dimension evaluation (naming/comments/structure/errors/setup/types/tests/dev loop)
-argument-hint: "[spec-name]"
-allowed-tools: [Read, Write, Bash, Task]
----
-
-# Flow Plan DX — Developer Experience Review
-
-@${CLAUDE_PLUGIN_ROOT}/knowledge/planning-reviews.md
-@${CLAUDE_PLUGIN_ROOT}/gates/devex-gate.md
-
-Review from the **next maintainer's** perspective: in 6 months, can I or a colleague quickly pick this up?
-
-## Step 1: Preflight
-
-```bash
-SPEC_NAME="${ARGUMENTS:-$(cat .flow/.active-spec 2>/dev/null)}"
-[ -z "$SPEC_NAME" ] && { echo "✗ No active spec"; exit 1; }
-[ ! -f ".flow/specs/$SPEC_NAME/design.md" ] && { echo "✗ Missing design.md"; exit 1; }
-```
-
-## Step 2: Dispatch DX Review
-
-```
-Task:
-  subagent_type: general-purpose
-  description: "DX Review: $SPEC_NAME"
-  prompt: |
-    **DevEx Review Mode**
-    
-    You review design.md on DevEx dimensions. Reuse the flow-reviewer agent:
-    ${CLAUDE_PLUGIN_ROOT}/agents/flow-reviewer.md
-    
-    Gate definition:
-    ${CLAUDE_PLUGIN_ROOT}/gates/devex-gate.md
-    
-    Methodology:
-    ${CLAUDE_PLUGIN_ROOT}/knowledge/planning-reviews.md (Review 4)
-    
-    Review targets:
-    - .flow/specs/$SPEC_NAME/design.md
-    - Related source code (if design references existing code)
-    - .flow/codebase-index.md (if present)
-    
-    8-dimension scoring (0-10 per dimension):
-    
-    DX-01 Naming clarity
-    DX-02 Intent comments
-    DX-03 File structure
-    DX-04 Error messages
-    DX-05 Easy setup
-    DX-06 Clear types
-    DX-07 Tests as docs
-    DX-08 Fast dev loop
-    
-    For each dimension:
-    - Observe relevant decisions in the design
-    - If the design specifically mentions a dimension (e.g., "we use strict TypeScript") → basis for scoring
-    - If the design does not mention it (e.g., no word about error-message design) → mark as "missing", score 5
-    
-    Use sequential-thinking ≥ 4 rounds.
-    
-    Output: .flow/specs/$SPEC_NAME/plan-review-dx.md
-    
-    Format:
-    # DX Plan Review: $SPEC_NAME
-    
-    ## Scores
-    DX-01 Naming: 7/10
-    DX-02 Comments: 5/10 (not mentioned)
-    DX-03 Structure: 8/10
-    ...
-    
-    Total: N/80
-    
-    ## Findings
-    
-    ### DX-02 Intent comments
-    Observation: the design does not explicitly state a comment strategy
-    Risk: the implementer may under-comment
-    Recommendation: add a paragraph in the design "key decision points should have why comments"
-    
-    ...
-```
-
-## Step 3: Output
-
-```
-📐 DX Review complete
-
-Total: N/80 ($([ $N -ge 40 ] && echo "pass" || echo "needs improvement"))
-
-Weakest dimensions:
-  - <dimension 1> N/10
-  - <dimension 2> N/10
-
-Report: .flow/specs/$SPEC_NAME/plan-review-dx.md
-
-Next steps:
-- Add strategies in design.md for low-scoring dimensions
-- Or add "DX checkpoint" tasks in tasks.md
-- Pass → /curdx-flow:tasks (execution breakdown)
-```

package/commands/plan-eng.md

@@ -1,108 +0,0 @@
----
-name: plan-eng
-description: Engineering planning review — architecture lock-in, risk identification, technical debt assessment. Dispatches flow-architect in review mode.
-argument-hint: "[spec-name]"
-allowed-tools: [Read, Write, Bash, Task]
----
-
-# Flow Plan Engineering — Engineering-Layer Review
-
-@${CLAUDE_PLUGIN_ROOT}/knowledge/planning-reviews.md
-
-Review design.md once more from the **engineer's perspective**: will the architecture work? Is it maintainable long-term?
-
-## Step 1: Preflight
-
-```bash
-SPEC_NAME="${ARGUMENTS:-$(cat .flow/.active-spec 2>/dev/null)}"
-[ -z "$SPEC_NAME" ] && { echo "✗ No active spec"; exit 1; }
-[ ! -f ".flow/specs/$SPEC_NAME/design.md" ] && { echo "✗ Missing design.md"; exit 1; }
-```
-
-## Step 2: Dispatch Eng Review
-
-```
-Task:
-  subagent_type: general-purpose
-  description: "Eng Review: $SPEC_NAME"
-  prompt: |
-    **Engineering Review Mode**
-    
-    You are an independent engineering reviewer. You read design.md to find risks, holes, and unclarities.
-    
-    Full methodology: ${CLAUDE_PLUGIN_ROOT}/knowledge/planning-reviews.md (Review 2)
-    
-    Review targets:
-    - .flow/specs/$SPEC_NAME/design.md (main body)
-    - .flow/specs/$SPEC_NAME/requirements.md (NFR requirements)
-    - .flow/STATE.md (existing decisions)
-    
-    Review checklist:
-    
-    1. Architecture lock-in
-       - Does each AD-NN have a tradeoff explanation?
-       - Does the rationale reference sequential-thinking rounds?
-       - Is there an explicit cost ("we accepted X")?
-    
-    2. Scalability
-       - What happens at 10x users / 10x data?
-       - Are bottlenecks identified?
-    
-    3. Reasonable dependencies
-       - Is the library / service choice justified?
-       - Risk of deprecation?
-       - Known CVEs / issues?
-    
-    4. Clear data flow
-       - Does the mermaid diagram reflect the real flow?
-       - Are all component boundaries explicit?
-    
-    5. Error paths
-       - Handling of upstream failures?
-       - Handling of downstream failures?
-       - User input anomalies?
-       - Concurrency / retries?
-    
-    6. Test strategy
-       - Reasonable unit / integration / E2E ratio?
-       - Core scenarios covered?
-    
-    7. Deployment feasibility
-       - CI/CD pipeline?
-       - Monitoring / alerting?
-       - Rollback strategy?
-    
-    Use sequential-thinking ≥ 6 rounds (adversarial-style review; "looks fine" is not accepted).
-    Must find ≥ 3 findings.
-    
-    Output: .flow/specs/$SPEC_NAME/plan-review-eng.md
-    
-    Format for each finding:
-    ### [Category] Issue
-    Location: design.md section N / AD-NN
-    Observation: what was specifically seen
-    Risk: high / medium / low + consequences
-    Recommendation: concrete change (command or code snippet)
-```
-
-## Step 3: Output
-
-```
-⚙ Engineering Review complete
-
-Findings:
-  High: $HIGH
-  Medium: $MED
-  Low: $LOW
-
-Verdict: <APPROVED / NEEDS_REVISION>
-
-Key risks:
-  - <top 3>
-
-Report: .flow/specs/$SPEC_NAME/plan-review-eng.md
-
-Next steps:
-- Fix high/medium → /curdx-flow:design to update (bump version)
-- After pass → /curdx-flow:plan-design or /curdx-flow:tasks
-```

package/commands/qa.md

@@ -1,118 +0,0 @@
----
-name: qa
-description: Real-browser QA — run user flows with chrome-devtools MCP, capturing bugs / performance / accessibility. Dispatches flow-qa-engineer (Oliver).
-argument-hint: "[spec-name] [--url=<dev-url>]"
-allowed-tools: [Read, Write, Bash, Task, WebFetch]
----
-
-# Flow QA — Real-Browser Testing
-
-Dispatches `flow-qa-engineer` (Oliver) to run user flows in real Chrome using **chrome-devtools MCP**.
-
-## Step 1: Preflight check
-
-```bash
-[ ! -d ".flow" ] && { echo "✗ Not a CurDX-Flow project"; exit 1; }
-
-ARGS="$ARGUMENTS"
-URL=""
-case "$ARGS" in
-    *--url=*)
-        URL=$(echo "$ARGS" | grep -oE -- '--url=[^[:space:]]+' | cut -d= -f2)
-        ;;
-esac
-SPEC_NAME=$(echo "$ARGS" | sed 's/--url=[^ ]*//g' | xargs)
-[ -z "$SPEC_NAME" ] && SPEC_NAME=$(cat .flow/.active-spec 2>/dev/null)
-[ -z "$SPEC_NAME" ] && { echo "✗ No active spec"; exit 1; }
-```
-
-## Step 2: Detect chrome-devtools MCP
-
-```bash
-# If MCP is not up, flow-qa-engineer will fall back to static QA
-# Do not block here; the agent will handle it
-```
-
-## Step 3: Confirm dev server URL
-
-If `--url` is not given, ask:
-```
-AskUserQuestion:
-  question: "What is your dev server URL?"
-  options:
-    - http://localhost:3000 (common)
-    - http://localhost:5173 (Vite)
-    - Other (custom)
-```
-
-## Step 4: Dispatch Oliver
-
-```
-Task:
-  subagent_type: general-purpose
-  description: "QA: $SPEC_NAME"
-  prompt: |
-    You are the flow-qa-engineer agent (Oliver). Full definition:
-    ${CLAUDE_PLUGIN_ROOT}/agents/flow-qa-engineer.md
-    
-    Target:
-    spec_name: $SPEC_NAME
-    URL: $URL
-    
-    Prerequisites:
-    - .flow/specs/$SPEC_NAME/requirements.md (AC list)
-    - .flow/specs/$SPEC_NAME/design.md (error paths + NFR)
-    
-    Workflow:
-    1. Detect chrome-devtools MCP (mcp__chrome-devtools__*)
-       - Available → real-browser QA
-       - Unavailable → static QA, clearly inform the user
-    2. Run the happy path (once per AC)
-    3. Run edge cases (at least 4 of the 7 categories in edge-case-gate)
-    4. Performance trace (LCP / INP / CLS)
-    5. Accessibility scan
-    6. Save screenshots to .flow/specs/$SPEC_NAME/qa-screenshots/
-    7. Generate .flow/specs/$SPEC_NAME/qa-report.md
-    
-    Return to me:
-    - Bug count (categorized by severity)
-    - Performance data (measured, not estimated)
-    - Accessibility warnings
-    - Recommended next steps
-```
-
-## Step 5: Read + report
-
-```bash
-REPORT=".flow/specs/$SPEC_NAME/qa-report.md"
-[ ! -f "$REPORT" ] && { echo "⚠ QA report was not generated"; exit 1; }
-
-HIGH_BUGS=$(grep -c "\[high\]" "$REPORT" || echo 0)
-MED_BUGS=$(grep -c "\[medium\]" "$REPORT" || echo 0)
-LOW_BUGS=$(grep -c "\[low\]" "$REPORT" || echo 0)
-```
-
-## Step 6: Output to user
-
-```
-🔬 QA complete: $SPEC_NAME
-
-Findings:
-  [high]: $HIGH_BUGS
-  [medium]: $MED_BUGS
-  [low]: $LOW_BUGS
-
-Report: .flow/specs/$SPEC_NAME/qa-report.md
-Screenshots: .flow/specs/$SPEC_NAME/qa-screenshots/
-
-Next steps:
-- Fix high-severity bugs → /curdx-flow:implement --task=QA-fix
-- Or add tasks to Phase 3.X in tasks.md
-- Retest: /curdx-flow:qa
-```
-
-## Error recovery
-
-- chrome-devtools MCP not installed → recommend `/curdx-flow:install-deps` or `claude mcp add chrome-devtools`
-- Dev server not running → prompt the user to start it and rerun
-- URL not accessible → prompt to check (`curl -I $URL`)

package/commands/requirements.md

@@ -1,146 +0,0 @@
----
-name: requirements
-description: Run the requirements stage — dispatch the flow-product-designer agent to generate user stories + FR/NFR, producing requirements.md
-argument-hint: "[spec-name]"
-allowed-tools: [Read, Write, Bash, Task, AskUserQuestion]
----
-
-# Requirements Stage
-
-Dispatch the `flow-product-designer` agent to translate research directions into user stories.
-
-## Step 1: Resolve spec + preflight checks
-
-```bash
-SPEC_NAME="${ARGUMENTS:-$(cat .flow/.active-spec 2>/dev/null)}"
-
-[ -z "$SPEC_NAME" ] && { echo "❌ Run /curdx-flow:start first"; exit 1; }
-[ ! -f ".flow/specs/$SPEC_NAME/research.md" ] && {
-    echo "❌ research.md missing. Run /curdx-flow:research first"
-    exit 1
-}
-```
-
-Verify the status of research:
-
-```bash
-python3 -c "
-import re
-fm = open('.flow/specs/$SPEC_NAME/research.md').read()[:500]
-m = re.search(r'status:\s*(\w+)', fm)
-status = m.group(1) if m else 'unknown'
-if status not in ('completed', 'approved'):
-    print(f'⚠ research status: {status}')
-    print('Recommend completing the research stage before continuing')
-"
-```
-
-## Step 2: Open question check
-
-If research.md lists open questions but no user answers are visible, prompt:
-
-```
-⚠ research.md has unanswered open questions:
-  Q1: ...
-  Q2: ...
-
-You can:
-  1. Answer the questions first (write them to STATE.md or state them), then run /curdx-flow:requirements
-  2. Let the agent continue based on reasonable assumptions (assumptions will be listed explicitly in requirements.md)
-
-Continue? (continue / answer / skip)
-```
-
-Use AskUserQuestion.
-
-## Step 3: Update state + dispatch agent
-
-```python
-# Mark in_progress
-import json
-s = json.load(open(f'.flow/specs/{SPEC_NAME}/.state.json'))
-s.setdefault('phase_status',{})['requirements']='in_progress'
-s['phase']='requirements'
-json.dump(s, open(f'.flow/specs/{SPEC_NAME}/.state.json','w'), indent=2, ensure_ascii=False)
-```
-
-Task dispatch:
-
-```
-Task:
-  subagent_type: general-purpose
-  description: "Requirements design $SPEC_NAME"
-  prompt: |
-    You are the flow-product-designer agent. Full definition at:
-    ${CLAUDE_PLUGIN_ROOT}/agents/flow-product-designer.md
-    
-    Prerequisite files:
-    - .flow/specs/$SPEC_NAME/research.md (must read)
-    - .flow/PROJECT.md
-    - .flow/CONTEXT.md
-    
-    Template:
-    ${CLAUDE_PLUGIN_ROOT}/templates/requirements.md.tmpl
-    
-    Output:
-    .flow/specs/$SPEC_NAME/requirements.md
-    
-    Workflow:
-    1. Read research.md to understand recommended directions
-    2. Generate user stories (US-NN) — at least 2
-    3. At least 3 acceptance criteria per US (AC-X.Y), must cover happy path + edges + errors
-    4. Extract FR (functional requirements) + NFR (at least performance and security)
-    5. Explicit Out of Scope (at least 3 items)
-    6. List open questions (if user decisions are needed)
-    7. Update .state.json and .progress.md
-    
-    If multiple reasonable interpretations exist, you MUST AskUserQuestion — do not silently pick a direction.
-    
-    Success criteria:
-    - At least 2 US, all from the user's perspective (non-technical language)
-    - Each AC testable (can be written as curl / assert)
-    - At least 3 FR, NFR covers at least P and S
-    - Out of Scope lists at least 3 items
-    
-    Return a brief when finished.
-```
-
-## Step 4: Output verification
-
-```bash
-REQ_FILE=".flow/specs/$SPEC_NAME/requirements.md"
-
-# Count US / FR / AC
-US_COUNT=$(grep -c "^### US-" "$REQ_FILE" || echo 0)
-FR_COUNT=$(grep -c "^- \*\*FR-" "$REQ_FILE" || echo 0)
-AC_COUNT=$(grep -c "^- AC-" "$REQ_FILE" || echo 0)
-
-echo "  US: $US_COUNT, FR: $FR_COUNT, AC: $AC_COUNT"
-
-# Minimum requirements
-[ "$US_COUNT" -lt 2 ] && echo "⚠ Fewer than 2 user stories"
-[ "$FR_COUNT" -lt 3 ] && echo "⚠ Fewer than 3 functional requirements"
-[ "$AC_COUNT" -lt 6 ] && echo "⚠ Fewer than 6 acceptance criteria (average < 3 per US)"
-```
-
-## Step 5: Output
-
-```
-✓ requirements stage complete
-
-File:                .flow/specs/$SPEC_NAME/requirements.md
-User stories:        N
-Functional reqs:     M
-Acceptance criteria: K
-
-Next steps:
-  - Review requirements.md
-  - If the agent listed open questions, answer them before entering design
-  - /curdx-flow:design  — enter design stage
-```
-
-## Error recovery
-
-- research.md missing → prompt to run /curdx-flow:research first
-- Agent times out → requirements may be too complex, consider splitting into an Epic (/curdx-flow:triage, see Phase 4)
-- Agent made a major interpretation without asking the user → the user can annotate requirements.md and request a correction