@dv.nghiem/flowdeck 0.2.3 → 0.3.0

package/src/commands/fd-test-gap.md

@@ -1,54 +0,0 @@
----
-description: Test Gap Detector — identify areas of a proposed change weakly covered by tests and suggest minimum high-value tests to add
-argument-hint: [change description or file paths]
----
-
-# Test Gap
-
-Identify test gaps in a proposed change and recommend the minimum high-value tests to add.
-
-**Input:** $ARGUMENTS — description of the change or specific file paths
-
-## Steps
-
-Run two agents in parallel:
-
-- **@tester**: Find source files mentioned in `$ARGUMENTS` that have no corresponding test file; identify branches/edge cases in changed functions with no test coverage; look for missing error-path tests
-
-- **@researcher**: Check if the changed functions appear in any integration or end-to-end test; find prior test gaps in this area from git history (tests added reactively after bugs)
-
-## Gap Scoring
-
-For each identified gap:
-- **CRITICAL**: public API with no test at all
-- **HIGH**: error handling path with no test
-- **MEDIUM**: business logic branch not covered
-- **LOW**: edge case (empty input, max values) not tested
-
-## Report
-
-```
-════════════════════════════════════════════
-TEST GAP REPORT
-════════════════════════════════════════════
-Change: <summary>
-
-Gaps Found (<N>):
-
-  CRITICAL: <file> — no test file exists
-    Suggest: <test file path> testing <what>
-
-  HIGH: <function> in <file> — error path not tested
-    Suggest: test case for <error condition>
-
-  MEDIUM: <function> — branch "<condition>" not covered
-    Suggest: test case where <condition is true>
-
-────────────────────────────────────────────
-Minimum Tests to Add (prioritized):
-  1. <test description> — covers CRITICAL gap
-  2. <test description> — covers HIGH gap
-════════════════════════════════════════════
-```
-
-Ask: "Should I write these tests now?"

package/src/commands/fd-volatility-map.md

@@ -1,64 +0,0 @@
----
-description: Codebase Volatility Map — highlight unstable zones based on git churn, hotfix frequency, and TODO clusters. Updates .codebase/VOLATILITY.json
----
-
-# Volatility Map
-
-Generate a volatility map of the codebase to identify unstable, high-churn areas.
-
-## Steps
-
-Run three analyses in parallel:
-
-### 1. Git Churn (@researcher)
-```bash
-git log --follow --format="%ad" --date=short -- <file> | wc -l
-```
-Run for all source files (last 90 days). Identify files with the most commits.
-
-### 2. TODO/FIXME Scan (@researcher)
-Scan all source files for `TODO`, `FIXME`, `HACK`, `XXX` comments. Count per file.
-
-### 3. Hotfix Frequency (@researcher)
-Search git log for commit messages containing `fix`, `hotfix`, `patch`, `urgent`, `bug` (last 90 days). Count per file touched.
-
-## Scoring
-
-For each file, compute a volatility score (0.0–1.0):
-- `churn_score` = commits / max_commits (normalized)
-- `todo_score` = todo_count / max_todos (normalized)
-- `hotfix_score` = hotfix_commits / max_hotfixes (normalized)
-- `volatility = (churn * 0.4) + (hotfix * 0.4) + (todo * 0.2)`
-
-## Output
-
-Write results to `.codebase/VOLATILITY.json`:
-```json
-{
-  "generated_at": "<timestamp>",
-  "hotspots": [
-    { "path": "<file>", "score": 0.92, "commits": 47, "todos": 8, "hotfixes": 12 }
-  ],
-  "stable_zones": [
-    { "path": "<file>", "score": 0.05 }
-  ]
-}
-```
-
-## Report
-
-```
-════════════════════════════════
-VOLATILITY MAP
-════════════════════════════════
-Top Hotspots:
-  🔴 <file> — score: 0.92 (47 commits, 12 hotfixes)
-  🟠 <file> — score: 0.71 (23 commits, 5 hotfixes)
-  🟡 <file> — score: 0.45 (15 commits, 8 TODOs)
-
-Stable Zones:
-  🟢 <file> — score: 0.05
-
-Saved: .codebase/VOLATILITY.json
-════════════════════════════════
-```

package/src/commands/fd-workspace-status.md

@@ -1,34 +0,0 @@
----
-description: Display workspace overview — all repos, their current phase, status, and progress
----
-
-# Workspace Status
-
-Display an overview of all repositories registered in the workspace.
-
-## Steps
-
-1. Read `.planning/config.json` for the list of registered repos.
-   - If no repos registered, show status for the current directory only.
-
-2. For each repo, read its `.planning/STATE.md`:
-   - Current phase, status, last_updated
-   - Plan confirmed flag
-
-3. Display workspace overview:
-
-```
-════════════════════════════════════════════════════
-WORKSPACE OVERVIEW
-════════════════════════════════════════════════════
-  frontend   — Phase 2 | in_progress  | Plan: ✅ | Updated: <time>
-  backend    — Phase 3 | completed    | Plan: ✅ | Updated: <time>
-  shared     — Phase 1 | planned      | Plan: ❌ | Updated: <time>
-────────────────────────────────────────────────────
-Total: 3 repos | 1 in progress | 1 completed | 1 planned
-════════════════════════════════════════════════════
-```
-
-4. Highlight any repos with:
-   - `status: blocked` → show with ⚠️
-   - `plan_confirmed: false` + `status: in_progress` → note: "plan not confirmed"

package/src/skills/parallel-execute/SKILL.md

@@ -1,92 +0,0 @@
----
-name: parallel-execute
-description: Coordinate parallel agent execution for independent workstreams. Assign tasks to specialist agents by wave, merge outputs, handle conflicts. Use when a plan has parallel tasks.
-origin: FlowDeck
----
-
-# Parallel Execute Skill
-
-Maximizes throughput by running independent work simultaneously. Manages waves, verifies independence, handles merge conflicts.
-
-## When to Activate
-
-Activate when:
-- A plan has tasks that can run simultaneously
-- Multiple independent features need to be implemented
-- Research can happen in parallel with implementation
-
-## Core Principles
-
-- Parallel = different files + no shared state + not dependent on each other
-- Always wait for an entire wave before starting the next
-- Conflicts mean the tasks weren't truly independent — reassign as sequential
-- Brief each agent completely — they are stateless
-
-## Workflow
-
-1. **Identify Wave 1** — tasks with no dependencies
-2. **Verify independence** — confirm different files, no shared state
-3. **Spawn Wave 1 simultaneously** — delegate all Wave 1 tasks at once
-4. **Wait for all Wave 1** — do not start Wave 2 until all complete
-5. **Check for conflicts** — compare files changed by each agent
-6. **Spawn Wave 2** — tasks that depend on Wave 1 outputs
-
-## Wave Structure Example
-
-```
-Wave 1 (start simultaneously — ~2 hours):
-  Track A: @coder implements UserModel in src/models/user.ts
-  Track B: @researcher documents bcrypt API for password hashing
-  Track C: @tester writes tests for UserService in src/user.test.ts
-
-[Wait for all three to complete]
-
-Wave 2 (sequential — ~2 hours):
-  Task 2.A: @coder implements auth service using outputs from Track A + B
-  Task 2.B: @writer documents the public API using outputs from Track A
-
-[Wait for 2.A and 2.B to complete]
-
-Wave 3 (review — 30 min):
-  @reviewer reviews all changes together
-```
-
-Timing example:
-- Sequential total: 6.5 hours
-- Parallel total: ~4.5 hours (30% faster)
-
-## Independence Checklist
-
-Before marking tasks as parallel:
-- [ ] Task A and Task B touch different files
-- [ ] Neither task's output is needed as input by the other
-- [ ] Both tasks can be verified independently
-- [ ] If both complete correctly, integration will be straightforward
-
-## Conflict Resolution
-
-If two agents modified the same file:
-
-```
-CONFLICT: Track A and Track C both modified src/types/user.ts
-Resolution: Assigning @coder to reconcile both versions sequentially.
-Track A change: [description]
-Track C change: [description]
-```
-
-## Output Format
-
-```markdown
-## Parallel Execution Report
-
-### Wave 1 Results (all must complete before Wave 2)
-- Track A (@coder): ✅ src/models/user.ts created
-- Track B (@researcher): ✅ bcrypt docs ready
-- Track C (@tester): ✅ 8 tests written, 8 passing
-
-### Conflicts
-None detected.
-
-### Wave 2 Starting
-Task 2.A: @coder building auth service with Wave 1 outputs
-```

package/src/workflows/debug-flow.md

@@ -1,119 +0,0 @@
----
-name: debug-flow
-description: "Systematic debugging: reproduce → trace → write failing test → fix root cause → verify. Never suppress errors."
-triggers:
-  - /debug
-steps:
-  - name: reproduce
-    agent: "@debug-specialist"
-    action: Establish minimal reproduction case with expected vs actual behavior
-  - name: trace
-    agent: "@debug-specialist"
-    action: Debug-specialist traces execution path and identifies root cause
-  - name: write_test
-    agent: "@tester"
-    action: Tester writes failing regression test for the exact failure
-  - name: fix
-    agent: "@coder"
-    action: Coder fixes root cause with minimal change
-  - name: verify
-    agent: "@tester"
-    action: Run regression test + full suite to confirm fix
----
-
-# Debug Flow
-
-## Purpose
-
-Diagnose and fix unexpected behavior systematically. Prevents symptom-fixing and ensures reproducibility.
-
-## Rules
-
-- Never suppress an error to make a test pass
-- Fix the root cause, not the symptom
-- Always write a regression test before fixing
-- Read stack traces completely — never half-read
-
-## Process
-
-### Step 1: Reproduce
-
-Document the bug precisely:
-```
-Bug: [one-line description]
-Steps to reproduce:
-  1. ...
-  2. ...
-Expected: [what should happen]
-Actual: [what does happen]
-Stack trace: [if available]
-```
-
-Confirm you can reproduce it consistently before proceeding.
-
-### Step 2: Trace
-
-Spawn `@debug-specialist` to:
-
-1. Read the complete stack trace
-2. Identify the failing function and line
-3. Trace inputs backward to find where bad data enters
-4. Check recent changes: `git log --oneline -10 -- <file>`
-5. Identify root cause (not symptom)
-
-Common root causes:
-| Symptom | Look for |
-|---------|---------|
-| null/undefined error | Missing boundary check |
-| Wrong value | Type coercion, missing validation |
-| Race condition | Missing await, shared mutable state |
-| Auth failure | Missing middleware, wrong scope check |
-| Infinite loop | Missing base case, wrong termination |
-
-### Step 3: Write Failing Test
-
-Spawn `@tester` to write a regression test:
-- Must FAIL on current code (RED)
-- Tests the exact scenario from Step 1
-- Isolated from other tests
-
-```typescript
-test('should [expected] when [condition from bug report]', () => {
-  // Arrange: set up the exact failing scenario
-  // Act: call the failing code
-  // Assert: verify expected behavior
-});
-```
-
-### Step 4: Fix
-
-Spawn `@coder` to:
-- Fix the root cause identified in Step 2
-- Minimum change to make the regression test pass
-- Do NOT touch unrelated code
-
-If the fix requires more than 20 lines: STOP, reassess scope.
-
-### Step 5: Verify
-
-```bash
-# Regression test must pass
-npm test -- --grep "regression test name"
-
-# Full suite must still pass
-npm test
-```
-
-If any unrelated test breaks: the fix has unintended side effects. Investigate before proceeding.
-
-## Output
-
-```
-## Debug Complete
-
-Bug: [description]
-Root cause: [specific cause]
-Fix: [what changed, file:line]
-Regression test: [test name] ✅ PASS
-Suite: ✅ N/N tests passing
-```

package/src/workflows/deploy-check-flow.md

@@ -1,98 +0,0 @@
----
-name: deploy-check-flow
-description: "Pre-deployment checks: parallel tests + security scan + CVE audit + build verification → go/no-go decision"
-triggers:
-  - /deploy-check
-steps:
-  - name: parallel_checks
-    agent: "@parallel-coordinator"
-    action: Run tests, security scan, CVE audit, and build in parallel
-  - name: aggregate
-    agent: "@orchestrator"
-    action: Aggregate all results into a unified report
-  - name: decision
-    agent: "@orchestrator"
-    action: Produce explicit go/no-go decision with required fixes if no-go
----
-
-# Deploy Check Flow
-
-## Purpose
-
-Run a comprehensive pre-deployment check suite before releasing to production.
-
-## Process
-
-### Step 1: Parallel Checks
-
-Launch four checks simultaneously:
-
-**Check A: Test Suite**
-```bash
-npm test
-```
-All tests must pass. No failures, no skips without justification.
-
-**Check B: Security Scan**
-
-Spawn `@security-auditor` to check:
-- No hardcoded secrets in changed files
-- Input validation at trust boundaries
-- Auth/authz on all protected routes
-- No CRITICAL or HIGH vulnerabilities
-
-**Check C: Dependency CVE Audit**
-```bash
-npm audit --audit-level=high
-```
-No HIGH or CRITICAL CVEs unaddressed.
-
-**Check D: Build Verification**
-```bash
-npm run build
-```
-Build must succeed with zero errors.
-
-### Step 2: Aggregate Results
-
-```
-## Pre-Deployment Check
-
-| Check | Status | Details |
-|-------|--------|---------|
-| Tests | ✅ PASS / ❌ FAIL | N/N passed |
-| Security | ✅ PASS / ❌ FAIL | [findings] |
-| CVE Audit | ✅ PASS / ❌ FAIL | [vulnerabilities] |
-| Build | ✅ PASS / ❌ FAIL | [errors] |
-```
-
-### Step 3: Decision
-
-**🚀 GO** — all checks pass, proceed with deployment.
-
-**🛑 NO-GO** — one or more checks failed:
-```
-Verdict: NO-GO
-
-Required fixes before deploy:
-- [ ] [fix 1]
-- [ ] [fix 2]
-
-Run /deploy-check again after fixing.
-```
-
-## No-go conditions (automatic)
-
-Any of these → automatic NO-GO:
-- Test failures
-- CRITICAL security vulnerability
-- HIGH/CRITICAL CVE unpatched
-- Build error
-
-## Agent configuration
-
-| Agent | Purpose |
-|-------|---------|
-| @tester | Run test suite |
-| @security-auditor | Security vulnerability scan |
-| @researcher | CVE research and context |

package/src/workflows/discuss-flow.md

@@ -1,97 +0,0 @@
----
-name: discuss-flow
-description: "Orchestrates discuss phase (context load → @discusser Q&A → pause → decisions → save)"
-triggers:
-  - /discuss
-steps:
-  - name: load_context
-    agent: "@orchestrator"
-    priority: first
-    action: Load PROJECT.md and current phase STATE.md
-  - name: determine_phase
-    agent: "@orchestrator"
-    action: Extract current phase number from STATE.md
-  - name: invoke_discusser
-    agent: "@discusser"
-    action: Spawn @discusser agent with project context
-  - name: qa_loop
-    agent: "@discusser"
-    action: Discusser asks one question at a time; user responds; repeat until all topics covered
-  - name: save_decisions
-    agent: "@discusser"
-    action: Write all decisions to .planning/phases/phase-N/DISCUSS.md with D-XX numbering
-  - name: confirm_discuss
-    agent: "@orchestrator"
-    action: Present summary to user; require explicit confirmation before marking DISCUSS.md as confirmed
----
-
-# Discuss Flow
-
-## Purpose
-
-Extract project requirements and decisions via structured Q&A with the @discusser agent.
-
-## Process
-
-### Step 1: Load Context
-
-Read `.planning/PROJECT.md` to understand the project vision and goals.
-Read `.planning/STATE.md` to determine the current phase and context.
-
-### Step 2: Determine Phase
-
-Extract the current phase number from STATE.md.
-Decisions will be saved to `.planning/phases/phase-{N}/DISCUSS.md`.
-
-### Step 3: Invoke Discusser
-
-Spawn @discusser agent with:
-- Project context (from PROJECT.md)
-- Current phase number
-- Instructions to ask ONE question per turn
-
-### Step 4: Q&A Loop
-
-The @discusser agent asks one question at a time.
-After each user response:
-- Assign D-XX number to any new decision
-- Record: topic, choice, rationale
-- If response conflicts with previous decision, flag the conflict
-
-Continue until all required topics are covered or user says to stop early.
-
-### Step 5: Save Decisions
-
-Save all decisions to `.planning/phases/phase-N/DISCUSS.md`:
-```
-D-01: [Topic] — [Decision] ([Rationale])
-D-02: [Topic] — [Decision] ([Rationale])
-...
-```
-
-### Step 6: Confirm Discuss
-
-Present summary of decisions to user.
-Ask for explicit confirmation: "CONFIRMED" to proceed or "REVISION NEEDED" to revisit.
-
-If user confirms:
-- Update STATE.md to mark DISCUSS.md as confirmed
-- Proceed to plan phase
-
-If user requests revision:
-- Return to Step 4 (Q&A loop) for the specified topics
-
-## D-05 Compliance
-
-- Loads PROJECT.md + current phase STATE.md
-- Invokes @discusser agent
-- Saves decisions with D-XX numbering to DISCUSS.md
-- One question at a time (no compound questions)
-
-## Error Handling
-
-D-03: Fail fast with clear error
-- If PROJECT.md not found: error with "Run /new-project first"
-- If STATE.md not found: error with "Project not initialized"
-- If @discusser fails: error with "Discusser agent unavailable"
-- No partial state saved on error