@curdx/flow 1.1.11 → 2.0.0-beta.10

package/commands/party.md

@@ -1,241 +0,0 @@
----
-name: party
-description: Party Mode — multiple persona agents independently think about one question at the same time. BMAD-style true multi-agent collaboration.
-argument-hint: "<persona-1> <persona-2> ... \"<question>\""
-allowed-tools: [Read, Task, AskUserQuestion]
----
-
-# Flow Party — Multi-Agent Independent Thinking
-
-Have multiple **persona agents** (Mary/John/Winston, etc.) independently think about the same question at the same time. This is BMAD's true innovation: **not one LLM playing multiple roles, but multiple Task subprocesses each thinking on their own, avoiding opinion convergence**.
-
-## When to use
-
-- Hard decisions needing multiple perspectives (e.g., architecture selection)
-- Spec review (separately reviewed from product / arch / qa)
-- Brainstorming / divergent thinking
-- Finding blind spots (one perspective may see what others cannot)
-
-## When not to use
-
-- Simple questions (overhead is high)
-- Questions with a clear answer (agents will only echo)
-- Execution tasks (use a dedicated executor)
-
-## Step 1: Parse arguments
-
-```bash
-ARGS="$ARGUMENTS"
-
-# Recognize personas (known list)
-PERSONAS=()
-QUESTION=""
-
-# Simple parsing: persona names + a question wrapped in quotes at the end
-# Example: /curdx-flow:party mary john winston "JWT or session?"
-
-# Parsing logic: iterate words, add known persona names to PERSONAS, rest is the question
-KNOWN_PERSONAS="mary john winston amelia rachel oliver serena david emma"
-
-REMAINING=""
-for word in $ARGS; do
-    if echo "$KNOWN_PERSONAS" | grep -qw "$word"; then
-        PERSONAS+=("$word")
-    else
-        REMAINING="$REMAINING $word"
-    fi
-done
-
-# REMAINING is the question (possibly with quotes)
-QUESTION=$(echo "$REMAINING" | sed 's/^[[:space:]]*//;s/^["\x27]//;s/["\x27]$//')
-```
-
-## Step 2: Validate arguments
-
-```bash
-if [ ${#PERSONAS[@]} -lt 2 ]; then
-    echo "✗ Party Mode requires ≥ 2 personas"
-    echo "Available: mary john winston amelia rachel oliver serena david emma"
-    exit 1
-fi
-
-if [ ${#PERSONAS[@]} -gt 5 ]; then
-    echo "⚠ More than 5 personas will make output hard to read. Recommend ≤ 5"
-fi
-
-if [ -z "$QUESTION" ]; then
-    echo "✗ Please provide a question"
-    exit 1
-fi
-```
-
-## Step 3: Build shared context
-
-All personas read the same background:
-
-```bash
-CONTEXT_FILES=()
-[ -f "CLAUDE.md" ] && CONTEXT_FILES+=("CLAUDE.md")
-[ -f ".flow/PROJECT.md" ] && CONTEXT_FILES+=(".flow/PROJECT.md")
-[ -f ".flow/CONTEXT.md" ] && CONTEXT_FILES+=(".flow/CONTEXT.md")
-
-# If there is an active spec, append
-ACTIVE=$(cat .flow/.active-spec 2>/dev/null)
-if [ -n "$ACTIVE" ]; then
-    for f in research.md requirements.md design.md; do
-        [ -f ".flow/specs/$ACTIVE/$f" ] && CONTEXT_FILES+=(".flow/specs/$ACTIVE/$f")
-    done
-fi
-```
-
-## Step 4: Dispatch each persona in parallel
-
-**Key**: call multiple Task tools **in a single message** at the same time (parallel execution).
-This way each persona thinks in an independent context without influencing the others.
-
-```
-# Parallel invocation (in a single message):
-Task(mary):
-  subagent_type: general-purpose
-  description: "Mary thinking about $QUESTION"
-  prompt: |
-    You are Mary (Senior Analyst). Full definition:
-    ${CLAUDE_PLUGIN_ROOT}/agents/persona-mary.md
-    
-    Shared context:
-    $(cat ${CONTEXT_FILES[@]} 2>/dev/null)
-    
-    Question: $QUESTION
-    
-    Answer from Mary's perspective:
-    - First list explicit assumptions
-    - Give 2-3 interpretations from a research / analysis perspective
-    - Clearly state open questions
-    - Provide an initial recommendation (if any)
-    
-    **Forbidden**:
-    - Speaking on behalf of other personas
-    - Claiming "synthesizing John's and Winston's opinions" (you don't know what they said)
-    - Echoing / converging
-    
-    Output a concise view of <200 words.
-
-Task(john):
-  ... [john's prompt]
-
-Task(winston):
-  ... [winston's prompt]
-```
-
-**Parallel execution**: Claude Code's Task tool supports multiple invocations in a single message running in parallel.
-
-## Step 5: Collect results
-
-Each Task returns an independent answer. The main agent (you) aggregates:
-
-```markdown
-## Party Mode Results: <QUESTION>
-
-### Mary (Senior Analyst)
-<Mary's answer>
-
-### John (Product Manager)
-<John's answer>
-
-### Winston (Architect)
-<Winston's answer>
-
-## Perspective comparison
-
-| Dimension | Mary | John | Winston |
-|-----------|------|------|---------|
-| Main concern | ... | ... | ... |
-| Recommended direction | ... | ... | ... |
-| Open questions | ... | ... | ... |
-
-## Points of disagreement
-
-1. Mary and Winston disagree on X: <specifics>
-2. Y raised by John that neither of the others considered: <specifics>
-
-## Consensus
-
-1. Everyone agrees on Z
-
-## Recommendation
-
-Based on multi-perspective synthesis:
-- If you care about A → follow Mary
-- If you care about B → follow Winston
-- Middle-ground option: Y proposed by John
-```
-
-## Step 6: Let the user decide
-
-```
-AskUserQuestion:
-  question: "Having seen the multi-perspective analysis, which direction do you lean toward?"
-  options:
-    - Follow Mary's direction
-    - Follow John's direction
-    - Follow Winston's direction
-    - Synthesis: <specific compromise>
-    - Other (user input)
-```
-
-After the user chooses, write the decision to STATE.md (as D-NN, via /curdx-flow:discuss or manually).
-
-## Typical usage
-
-### Architecture selection
-
-```
-/curdx-flow:party winston mary "JWT vs Session — which is more suitable in this project"
-```
-
-### Spec review
-
-```
-/curdx-flow:party john rachel oliver "are the ACs in requirements.md sufficient"
-```
-
-### Bug approach discussion
-
-```
-/curdx-flow:party david winston "should this crash be fixed at the root cause or wrapped in try-catch"
-```
-
-### UX decision
-
-```
-/curdx-flow:party emma john oliver "how to present login failure error messages"
-```
-
-## Forbidden
-
-- ✗ Dispatching only 1 agent (that's not a Party — just use Task directly)
-- ✗ Agents referencing each other (the point of independent thinking is isolation)
-- ✗ Sequential dispatch (must be parallel Task invocations)
-- ✗ Overly long agent output (each <300 words)
-
-## Why Party Mode has value
-
-### Single LLM playing multiple roles vs. true multi-agent
-
-Single LLM: "As Mary I think X... As Winston I think Y... Synthesizing the two views, Z"
-
-Problems:
-- Opinions have already converged in advance (the LLM generates in one pass; later parts are influenced by earlier ones)
-- "Synthesis" is done by the LLM itself, without real collision
-- Easily becomes "one voice imitating multiple people"
-
-True multi-agent (Party Mode):
-- Mary's context contains only "I am Mary" and the question
-- Winston's context contains only "I am Winston" and the question
-- The two have no idea what the other said
-- The output is truly independent thinking
-- The differences are real differences, not acted out
-
----
-
-_Source: BMAD's Party Mode, implemented in CurDX-Flow via parallel dispatch of Claude Code's Task tool._

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
-```