@curdx/flow 1.1.11 → 2.0.0-beta.2

package/commands/research.md

@@ -1,141 +0,0 @@
----
-name: research
-description: Run the research stage — dispatch the flow-researcher agent to deeply explore the problem, producing research.md
-argument-hint: "[spec-name]"
-allowed-tools: [Read, Write, Bash, Task]
----
-
-# Research Stage
-
-Dispatch the `flow-researcher` agent to complete the research stage of a spec.
-
-## Step 1: Resolve target spec
-
-```bash
-# Use the argument if provided; otherwise use the active spec
-if [ -n "$ARGUMENTS" ]; then
-    SPEC_NAME="$ARGUMENTS"
-else
-    SPEC_NAME=$(cat .flow/.active-spec 2>/dev/null)
-fi
-
-if [ -z "$SPEC_NAME" ] || [ ! -d ".flow/specs/$SPEC_NAME" ]; then
-    echo "❌ Spec does not exist. Use /curdx-flow:start <name> \"<goal>\" to create a new spec"
-    exit 1
-fi
-```
-
-## Step 2: Preflight checks
-
-```bash
-# The research stage has no prerequisites; just verify the spec directory is ready
-if [ ! -f ".flow/specs/$SPEC_NAME/.state.json" ]; then
-    echo "❌ Spec state file missing. Run /curdx-flow:start to re-initialize"
-    exit 1
-fi
-```
-
-If research.md already exists with status=completed:
-- Ask the user whether to overwrite (AskUserQuestion)
-- Default: do not overwrite; suggest `/curdx-flow:requirements` to move to the next step
-
-## Step 3: Update state
-
-```bash
-# Mark the research stage as in_progress
-python3 <<'EOF'
-import json
-from pathlib import Path
-state_file = Path(f".flow/specs/$SPEC_NAME/.state.json")
-state = json.loads(state_file.read_text())
-state.setdefault("phase_status", {})["research"] = "in_progress"
-state["phase"] = "research"
-state_file.write_text(json.dumps(state, indent=2, ensure_ascii=False))
-EOF
-```
-
-## Step 4: Dispatch the flow-researcher agent
-
-Using the Task tool:
-
-```
-Task:
-  subagent_type: general-purpose
-  description: "Research $SPEC_NAME"
-  prompt: |
-    You are the flow-researcher agent. Your full responsibilities and workflow are at:
-    ${CLAUDE_PLUGIN_ROOT}/agents/flow-researcher.md
-    
-    Spec prerequisites to read:
-    - .flow/specs/$SPEC_NAME/.state.json (goal + state)
-    - .flow/PROJECT.md
-    - .flow/CONTEXT.md  
-    - .flow/STATE.md
-    
-    Template (you must populate and write to research.md):
-    ${CLAUDE_PLUGIN_ROOT}/templates/research.md.tmpl
-    
-    Output file:
-    .flow/specs/$SPEC_NAME/research.md
-    
-    Workflow requirements:
-    1. Load context (Step 1)
-    2. Call mcp__claude_mem__search to retrieve history (Step 2)
-    3. sequential-thinking 5+ rounds for problem understanding (Step 3)
-    4. Glob/Grep to scan existing code (Step 4)
-    5. context7 to look up the latest docs for 2-3 technical options (Step 5)
-    6. WebSearch to supplement (Step 6, if needed)
-    7. Write research.md (based on the template, replacing placeholders)
-    8. Update .state.json and .progress.md (Step 8)
-    
-    Success criteria:
-    - research.md exists and matches the template structure
-    - Problem understanding section has 3+ explicit assumptions
-    - 2-3 technical options, each referencing context7 results
-    - Code analysis includes actual file paths found
-    - Recommended direction + rationale is clear
-    - At least 1 open question (unless the research is fully unambiguous)
-    
-    Forbidden:
-    - Writing library APIs from memory
-    - Skipping context7 queries
-    - sequentialthinking < 5 rounds
-    - Creating any new files outside research.md
-    
-    When done, return a brief (findings, recommendations, open questions).
-```
-
-## Step 5: After the agent completes
-
-Read the agent-generated research.md and verify that key sections exist:
-
-```bash
-for section in "Problem Understanding" "Technical Options" "Existing Code Analysis" "Feasibility" "Recommended Direction"; do
-    if ! grep -q "$section" ".flow/specs/$SPEC_NAME/research.md" 2>/dev/null; then
-        echo "⚠ research.md missing section: $section"
-    fi
-done
-```
-
-If any section is missing, emit a warning but do not block (the user decides whether to re-run).
-
-## Step 6: Output suggestions
-
-```
-✓ research stage complete
-
-File:     .flow/specs/$SPEC_NAME/research.md
-
-Next steps:
-  - Read research.md and confirm the recommended direction is reasonable
-  - Answer the open questions listed by the agent (if any)
-  - /curdx-flow:requirements  — enter the requirements stage
-  
-  To re-research, just run /curdx-flow:research again
-```
-
-## Error recovery
-
-- research.md generation fails → check MCP status (/curdx-flow:doctor), retry
-- Agent exceeds 40 turns → the research is too complex, narrow the target scope
-- context7 unavailable → the agent falls back to WebSearch, but must explicitly inform the user

package/commands/security.md

@@ -1,109 +0,0 @@
----
-name: security
-description: Security audit — OWASP Top 10 + STRIDE + dependency CVEs. Dispatches flow-security-auditor (Serena).
-argument-hint: "[spec-name]"
-allowed-tools: [Read, Write, Bash, Task, Grep, Glob, WebSearch]
----
-
-# Flow Security — Security Audit
-
-@${CLAUDE_PLUGIN_ROOT}/gates/security-gate.md
-
-Dispatches `flow-security-auditor` (Serena) to perform a full security audit.
-
-## When to use
-
-- Specs touching authentication / authorization / payments / PII
-- Pre-release gate
-- After adding new API endpoints
-- After dependency upgrades
-
-## Step 1: Preflight
-
-```bash
-SPEC_NAME="${ARGUMENTS:-$(cat .flow/.active-spec 2>/dev/null)}"
-
-# Can still run without an active spec (global security scan)
-if [ -z "$SPEC_NAME" ]; then
-    echo "ℹ No active spec; running a security scan across the entire codebase"
-    SPEC_NAME="_global"
-fi
-```
-
-## Step 2: Dispatch Serena
-
-```
-Task:
-  subagent_type: general-purpose
-  description: "Security Audit: $SPEC_NAME"
-  prompt: |
-    You are the flow-security-auditor agent (Serena). Full definition:
-    ${CLAUDE_PLUGIN_ROOT}/agents/flow-security-auditor.md
-    
-    Audit scope:
-    $([ "$SPEC_NAME" = "_global" ] && echo "Entire codebase" || echo ".flow/specs/$SPEC_NAME/ + related code")
-    
-    Prerequisites:
-    - OWASP Top 10 (2021) checklist
-    - STRIDE threat modeling
-    - package.json (npm audit)
-    - Project auth / data-layer code
-    
-    Workflow:
-    1. Scan OWASP 10 categories in parallel
-       - A01: Broken access control
-       - A02: Cryptography
-       - A03: Injection
-       - A04: Insecure Design
-       - A05: Misconfiguration
-       - A06: CVE (npm audit)
-       - A07: Auth failures
-       - A08: Integrity
-       - A09: Logging
-       - A10: SSRF
-    2. STRIDE threat modeling (≥6 rounds of sequential-thinking)
-    3. context7 to check CVEs for critical dependencies
-    4. Manual review of suspicious areas
-    5. Generate security-audit.md
-    
-    Output:
-    - .flow/specs/$SPEC_NAME/security-audit.md (or .flow/security-audit-global.md)
-    
-    Return to me:
-    - Findings classified by risk (high/medium/low)
-    - Number of must-fix items
-    - Recommended order
-```
-
-## Step 3: Output
-
-```bash
-REPORT=".flow/specs/$SPEC_NAME/security-audit.md"
-[ "$SPEC_NAME" = "_global" ] && REPORT=".flow/security-audit-global.md"
-
-HIGH=$(grep -c "\[High\]" "$REPORT" || echo 0)
-MED=$(grep -c "\[Medium\]" "$REPORT" || echo 0)
-LOW=$(grep -c "\[Low\]" "$REPORT" || echo 0)
-```
-
-```
-🔒 Security Audit complete
-
-Risk distribution:
-  High:   $HIGH (must fix, blocks release)
-  Medium: $MED (recommended to fix)
-  Low:    $LOW (as needed)
-
-Report: $REPORT
-
-Next steps:
-- High risk → /curdx-flow:implement adds fix tasks
-- Or STATE.md explicitly waives + commits to a fix timeline
-- After fixing → /curdx-flow:security to re-audit
-```
-
-## Error recovery
-
-- npm audit requires package.json → non-Node projects skip this class
-- context7 unavailable → use WebSearch to supplement CVE queries
-- No active spec → global scan mode

package/commands/sketch.md

@@ -1,118 +0,0 @@
----
-name: sketch
-description: UI design sketch — invokes the frontend-design skill to generate multiple HTML variants. Dispatches flow-ux-designer (Emma).
-argument-hint: "[spec-name] [\"<description>\"]"
-allowed-tools: [Read, Write, Bash, Task, WebSearch, AskUserQuestion]
----
-
-# Flow Sketch — UI Sketch
-
-Dispatches `flow-ux-designer` (Emma) to use the **frontend-design skill** to generate tasteful UI variants.
-
-## Step 1: Parse arguments
-
-```bash
-ARGS="$ARGUMENTS"
-# The first word may be spec-name (if such a spec exists); otherwise it is the description
-
-SPEC_NAME=""
-DESCRIPTION=""
-
-FIRST_WORD=$(echo "$ARGS" | awk '{print $1}')
-if [ -d ".flow/specs/$FIRST_WORD" ]; then
-    SPEC_NAME="$FIRST_WORD"
-    DESCRIPTION=$(echo "$ARGS" | sed "s/^$FIRST_WORD//" | sed 's/^["\x27]//;s/["\x27]$//' | xargs)
-else
-    DESCRIPTION=$(echo "$ARGS" | sed 's/^["\x27]//;s/["\x27]$//')
-fi
-
-[ -z "$SPEC_NAME" ] && SPEC_NAME=$(cat .flow/.active-spec 2>/dev/null)
-```
-
-## Step 2: Preflight checks
-
-```bash
-# Requires at least an active spec (to read CONTEXT.md)
-if [ -z "$SPEC_NAME" ] && [ -z "$DESCRIPTION" ]; then
-    echo "Usage: /curdx-flow:sketch [spec] \"<description of what to sketch>\""
-    echo "Example: /curdx-flow:sketch \"login form\""
-    exit 1
-fi
-
-# Check frontend-design skill (if unavailable, fall back)
-```
-
-## Step 3: Ask for the variant count
-
-```
-AskUserQuestion:
-  Question: "How many variants to generate?"
-  Options:
-    - 2 (compare minimalist vs distinctive)
-    - 3 (recommended — adds a dense variant)
-    - Custom
-```
-
-## Step 4: Dispatch Emma
-
-```
-Task:
-  subagent_type: general-purpose
-  description: "UI Sketch: $DESCRIPTION"
-  prompt: |
-    You are the flow-ux-designer agent (Emma). Full definition:
-    ${CLAUDE_PLUGIN_ROOT}/agents/flow-ux-designer.md
-    
-    Task:
-    - Description: $DESCRIPTION
-    - Spec: $SPEC_NAME (optional)
-    - Variant count: $VARIANT_COUNT
-    
-    Prerequisites:
-    - .flow/CONTEXT.md (user UI preferences)
-    - .flow/specs/$SPEC_NAME/requirements.md (if present)
-    - .flow/specs/$SPEC_NAME/design.md (if present)
-    - .flow/specs/$SPEC_NAME/ui-research.md (if /curdx-flow:ui-research has been run)
-    
-    Workflow:
-    1. Detect the frontend-design skill
-       - Available: activate it to guide design choices
-       - Unavailable: use Tailwind + shadcn defaults and explicitly announce the fallback
-    2. Read user preferences (CONTEXT.md)
-    3. Generate N variant HTMLs (each a single file, zero dependencies, CDN Tailwind)
-    4. Generate an index.html comparison page (iframes side by side)
-    5. Generate decisions.md explaining the rationale for each variant
-    
-    Output directory:
-    .flow/specs/$SPEC_NAME/ui-sketch/ (or .flow/sketches/<slug>/)
-    
-    Return to me:
-    - The list of generated variants + what distinguishes each
-    - Recommended direction (based on CONTEXT.md)
-    - Preview command (how to open index.html)
-```
-
-## Step 5: Output
-
-```
-🎨 Sketch complete
-
-Variants:
-  variant-a-minimalist.html   (system font + whitespace)
-  variant-b-distinctive.html  (custom font + micro animations)
-  variant-c-dense.html        (information-dense — suited for admin)
-
-Decisions: .flow/specs/<name>/ui-sketch/decisions.md
-Comparison page: open .flow/specs/<name>/ui-sketch/index.html
-
-Next steps:
-- Pick a variant → tell me → I'll convert the HTML into production components
-- Or /curdx-flow:qa to verify interactions in the browser
-- Clone another reference → /curdx-flow:ui-research <feature>
-```
-
-## Error recovery
-
-- frontend-design skill not installed → Emma falls back and announces it
-- Variants are too similar → ask the user to re-run with more specific guidance
-- No spec and no description → at least one must be supplied

package/commands/spike.md

@@ -1,181 +0,0 @@
----
-name: spike
-description: feasibility experiment — validate an idea with 2-5 small tests, no production code. Output conclusions to STATE.md
-argument-hint: "\"<hypothesis to validate>\""
-allowed-tools: [Read, Write, Edit, Bash, WebSearch, Grep, Glob]
----
-
-# Flow Spike — Feasibility Experiment
-
-@${CLAUDE_PLUGIN_ROOT}/agent-preamble/preamble.md
-
-**A spike is a short-duration experiment**, aimed at answering one technical question: "Can this approach work?" It is not about delivering a feature.
-
-## Typical Scenarios
-
-- "Can Redis Streams replace Kafka?"
-- "How much faster is Bun than Node? Is our scenario a good fit?"
-- "Is this API's rate limit 10 qps?"
-- "Can the new TypeScript const generic solve problem X?"
-
-## Step 1: Clarify the Hypothesis
-
-```bash
-HYPOTHESIS="$ARGUMENTS"
-[ -z "$HYPOTHESIS" ] && { echo "Usage: /curdx-flow:spike \"<hypothesis>\""; exit 1; }
-```
-
-Confirm with the user:
-```
-Hypothesis to validate: <HYPOTHESIS>
-
-My understanding:
-  - What to validate: <...>
-  - Pass criteria: <...>
-  - What if it fails: <...>
-  - Time budget: recommend 30-60 minutes
-
-Continue? (yes / correct me)
-```
-
-Use AskUserQuestion (unless quickMode).
-
-## Step 2: Design 2-5 Small Tests
-
-**Rules**:
-- Each test is independent
-- Minimal code (50 lines max)
-- Explicit pass/fail criteria
-- Do not touch production code
-
-Example (validating Redis Streams performance):
-
-```
-Test 1: Throughput of writing 1000 messages
-  Code: spike/redis-streams-write.ts
-  Expected: >= 10K msg/sec
-  
-Test 2: Consumer group latency
-  Code: spike/redis-streams-consume.ts
-  Expected: P99 < 10ms
-  
-Test 3: Persistence overhead
-  Code: compare AOF vs RDB
-  Expected: AOF write latency increase < 20%
-```
-
-## Step 3: Create the spike directory
-
-```bash
-mkdir -p spike/$(date +%Y-%m-%d)-${HYPOTHESIS_SLUG}
-```
-
-All experimental code lives here. **Absolutely do not touch production code**.
-
-## Step 4: Run the Tests
-
-```bash
-for test in Test 1 2 3:
-    write code
-    run
-    record results
-    if blocked:
-      not "fix bug and continue", but record "blocker X, cannot test"
-```
-
-**context7 is mandatory**: look up all library APIs via context7, do not rely on memory.
-
-## Step 5: Record Results
-
-Create `spike/<date>-<slug>/RESULTS.md`:
-
-```markdown
-# Spike Results: <hypothesis>
-
-Date: YYYY-MM-DD
-Time: actually took N minutes
-
-## Test Matrix
-
-| Test | Expected | Actual | Conclusion |
-|------|-----|------|------|
-| 1 | >=10K msg/sec | 12K msg/sec | ✓ |
-| 2 | P99 < 10ms | P99 = 15ms | ✗ |
-| 3 | < 20% | 8% | ✓ |
-
-## Conclusion
-
-Hypothesis <HYPOTHESIS> is:
-  ☐ Fully correct — recommended for adoption
-  ☑ Partially correct — P99 latency exceeds expectations, needs deeper optimization
-  ☐ Fully incorrect — not recommended
-
-## Key Findings
-
-- <finding 1>
-- <finding 2>
-
-## Recommendation
-
-<how to handle this hypothesis if used in a real spec>
-
-## Open Questions
-
-<edges not yet tested>
-```
-
-## Step 6: Sync to STATE.md (if in a flow project)
-
-```bash
-if [ -f ".flow/STATE.md" ]; then
-    append to STATE.md:
-      ## Spike: <hypothesis> (YYYY-MM-DD)
-      Conclusion: partially correct
-      Details: spike/<date>-<slug>/RESULTS.md
-fi
-```
-
-This way, subsequent spec discussions can reference it.
-
-## Step 7: Cleanup Decision
-
-Ask the user:
-```
-Spike complete. Code is in spike/<date>-<slug>/
-Keep it?
-  [keep]   may reference later
-  [delete] conclusion recorded, code no longer valuable
-  [commit] commit into git as a historical reference
-```
-
-## Output
-
-```
-✓ Spike complete: <hypothesis>
-
-Conclusion:    partially correct (see RESULTS.md)
-Tests:         3 / 3 executed
-Actual time:   47 minutes
-
-Next step suggestions:
-  - Go deeper: /curdx-flow:start <name> "do <specific feature> based on spike results"
-  - Abandon:   recorded to STATE.md, do not adopt this direction
-
-Artifacts:
-  spike/<date>-<slug>/RESULTS.md
-  spike/<date>-<slug>/*.ts (test code)
-```
-
-## Forbidden
-
-- ✗ Mixing spike code into production code (src/)
-- ✗ Spikes exceeding 2 hours (that's not a spike, that's a mini project)
-- ✗ Claiming validation complete without recording results
-- ✗ Using a spike to replace the real spec workflow
-
-## spike vs research phase
-
-- **spike** is **actually running code** to validate a hypothesis
-- **research phase** is **reading docs / thinking** to determine direction
-
-Research thinks approach A is feasible but has concerns → use a spike to verify → write the conclusion back into the "feasibility" section of research.md.

package/commands/status.md

@@ -1,139 +0,0 @@
----
-name: status
-description: view the current state of the CurDX-Flow project (specs, phases, progress)
-argument-hint: "[--all | <spec-name>]"
-allowed-tools: [Read, Bash, Glob]
----
-
-# Project Status
-
-Shows an overview of the current state of the CurDX-Flow project.
-
-## Execution Steps
-
-### Step 1: Confirm the Project
-
-```bash
-if [ ! -d ".flow" ]; then
-    echo "✗ Current directory is not a CurDX-Flow project. Run /curdx-flow:init to initialize."
-    exit 0
-fi
-```
-
-### Step 2: Load Global State
-
-```bash
-# Active spec
-ACTIVE=$(cat .flow/.active-spec 2>/dev/null || echo "(none)")
-
-# Project config
-if [ -f ".flow/config.json" ]; then
-    MODE=$(python3 -c "import json; print(json.load(open('.flow/config.json')).get('mode','standard'))")
-fi
-```
-
-### Step 3: Scan Specs
-
-```bash
-# List all specs
-SPECS=$(ls -1 .flow/specs/ 2>/dev/null)
-
-# List all Epics
-EPICS=$(ls -1 .flow/_epics/ 2>/dev/null)
-```
-
-For each spec, read `.state.json` to get phase and progress:
-
-```bash
-for spec in $SPECS; do
-    STATE_FILE=".flow/specs/$spec/.state.json"
-    if [ -f "$STATE_FILE" ]; then
-        PHASE=$(python3 -c "import json; print(json.load(open('$STATE_FILE')).get('phase','unknown'))")
-        # Can also fetch task_index, total_tasks, etc.
-    fi
-done
-```
-
-### Step 4: Output Format
-
-**Default (no arguments)** — global overview:
-
-```
-📋 CurDX-Flow Project Status
-═══════════════════════════════════════
-
-Project:       my-awesome-app
-Mode:          standard
-Active spec:   auth-system
-
-Spec list:
-  ● auth-system          design          (45% — tasks pending)
-  ○ user-profile         execute         (60% — 12/20 tasks)
-  ✓ onboarding-flow      completed       (archived)
-
-Epic list:
-  ● payment-system       3/5 sub-specs   (in progress)
-
-Recent decisions (STATE.md):
-  D-05: use JWT instead of session cookie (2026-04-15)
-  D-06: bcrypt cost factor = 12 (2026-04-15)
-
-═══════════════════════════════════════
-Next step suggestion: /curdx-flow:tasks   — generate task list for auth-system
-```
-
-**`<spec-name>`** — detail for a specific spec:
-
-```
-📋 Spec: auth-system
-═══════════════════════════════════════
-
-Phase:      design
-Progress:   45%
-Created:    2026-04-12
-
-Completed phases:
-  ✓ research        (research.md, 320 lines)
-  ✓ requirements    (requirements.md, 8 stories)
-  ● design          (design.md, in progress)
-  ○ tasks
-  ○ execute
-
-Related decisions:
-  D-05: use JWT instead of session cookie
-
-.progress.md summary:
-  - Confirmed JWT + refresh token architecture
-  - Researched bcrypt vs argon2, chose bcrypt (team familiarity)
-  - TODO: design token refresh flow
-
-Next step: /curdx-flow:tasks — generate task list
-```
-
-**`--all`** — detailed mode, every spec expanded.
-
-### Step 5: Empty-State Handling
-
-If `.flow/` exists but no specs:
-
-```
-📋 CurDX-Flow Project
-═══════════════════════════════════════
-
-Project:       my-awesome-app (just initialized)
-Mode:          standard
-Active spec:   (none)
-
-No specs yet.
-
-Start your first feature:
-  /curdx-flow:start <name> "<describe what you want to do>"
-
-Example:
-  /curdx-flow:start auth-system "Add JWT authentication to API"
-```
-
-## Notes
-
-- State data is read-only; this command does not modify any files
-- If `.state.json` is corrupted or missing, degrade gracefully (show "state unknown" instead of failing)