@dv.nghiem/flowdeck 0.2.4 → 0.3.0

package/src/commands/fd-learn.md

@@ -1,36 +0,0 @@
----
-description: Capture a repeatable pattern from this session and save it as a reusable FlowDeck skill
-argument-hint: [skill-name]
----
-
-# Learn: Capture Session Knowledge
-
-Review what happened in this session and create a reusable skill from the most significant learning.
-
-**Input:** `$ARGUMENTS` — optional kebab-case name for the skill (the agent will choose one if omitted)
-
-## Steps
-
-1. **Identify what is worth capturing.** Look for:
-   - A novel problem that required figuring out a non-obvious solution
-   - A pattern that required human guidance or clarification to resolve
-   - A workflow or sequence that would save significant time if remembered
-   - A pitfall that was hit and corrected
-
-   If nothing significant was discovered, reply: "No new patterns to capture from this session." and stop.
-
-2. **Draft the skill.** Structure it as:
-   - `## When to Activate` — concrete triggers (e.g., "when X file pattern exists", "when the user asks about Y")
-   - `## Steps` — ordered, concrete steps to apply the skill
-   - `## Examples` — at least one short, concrete example
-   - `## Pitfalls` — common mistakes to avoid
-
-3. **Choose the skill name.** Use `$ARGUMENTS` if provided, otherwise derive a kebab-case name from the pattern.
-
-4. **Write the skill** using the `create-skill` tool with:
-   - `name`: kebab-case identifier
-   - `description`: one sentence summarising what the skill does
-   - `content`: the full Markdown body from step 2
-   - `tags`: 2–4 relevant tags
-
-5. **Report** what was captured, why it is useful, and remind the user to restart OpenCode to activate it.

package/src/commands/fd-progress.md

@@ -1,50 +0,0 @@
----
-description: Display project progress — STATE.md summary, active PLAN.md steps, and recent results
-argument-hint: [--json]
----
-
-# Progress
-
-Display current project progress from planning files.
-
-**Input:** $ARGUMENTS (pass `--json` for machine-readable output)
-
-## Steps
-
-1. Check `.planning/STATE.md` exists — if not, return error: "Initialize project first with /fd-new-project."
-
-2. Read STATE.md and parse:
-   - Current phase number
-   - Status (planned/in_progress/completed)
-   - Last updated timestamp
-   - `plan_confirmed` flag
-
-3. Read `.planning/phases/phase-<N>/PLAN.md` if it exists:
-   - Count total steps (lines matching `- [ ]` or `- [x]`)
-   - Count completed steps (lines matching `- [x]`)
-
-4. Check for recent RESULT.md files in the last 3 phases.
-
-5. Display:
-
-```
-════════════════════════════════════════════════════════════
-Phase: <N>  |  Status: <status>  |  Updated: <timestamp>
-────────────────────────────────────────────────────────────
-Plan: <X> steps (<Y> complete)
-Plan confirmed: <yes/no>
-Recent results: Phase <N-1>, Phase <N>
-════════════════════════════════════════════════════════════
-```
-
-If `--json`, output structured JSON instead:
-```json
-{
-  "phase": N,
-  "status": "...",
-  "plan_confirmed": true,
-  "steps_total": X,
-  "steps_complete": Y,
-  "last_updated": "..."
-}
-```

package/src/commands/fd-regression-predict.md

@@ -1,57 +0,0 @@
----
-description: Regression Prediction — estimate the most likely regression categories for a proposed change
-argument-hint: [change description]
----
-
-# Regression Predict
-
-Predict the most likely regression categories for a proposed change before implementing it.
-
-**Input:** $ARGUMENTS — description of the proposed change
-
-## Steps
-
-Run two agents in parallel:
-
-- **@researcher**: Map the changed code paths in `$ARGUMENTS` to regression category keywords and patterns; check `.codebase/FAILURES.json` for prior regressions in the same area
-
-- **@tester**: Analyze existing test coverage for the affected paths; identify which regression categories are under-tested
-
-## Regression Categories
-
-| Category | Indicators |
-|----------|-----------|
-| **Performance** | touching caching, DB queries, loops, response serialization |
-| **Auth / Security** | touching middleware, tokens, sessions, permissions |
-| **Schema / Data** | touching DB models, migrations, serializers |
-| **UI States** | touching frontend components, state management, events |
-| **Async Flows** | touching queues, workers, webhooks, timeouts |
-| **API Contracts** | touching public endpoints, request/response shapes |
-| **Integration** | touching external service calls, adapters |
-
-## Report
-
-```
-════════════════════════════════════════════
-REGRESSION PREDICTION
-════════════════════════════════════════════
-Change: <summary of $ARGUMENTS>
-
-Likely Regressions (ranked by probability):
-
-  🔴 HIGH — Auth/Security
-     Reason: change touches middleware X
-     Prior: FAILURES.json F-12 (×3 recurrences)
-
-  🟠 MEDIUM — API Contracts  
-     Reason: modifies response shape of /api/checkout
-
-  🟡 LOW — Performance
-     Reason: adds DB query in hot path
-
-────────────────────────────────────────────
-Recommended Tests to Add:
-  1. <specific test scenario>
-  2. <specific test scenario>
-════════════════════════════════════════════
-```

package/src/commands/fd-review-code.md

@@ -1,96 +0,0 @@
----
-description: Parallel reviewer + researcher + tester — aggregates findings into critical/major/minor report
-argument-hint: [--scope=path | --focus=security,quality,tdd]
----
-
-# Review Code
-
-Run a comprehensive parallel code review before merging or deploying.
-
-**Input:** $ARGUMENTS — optional `--scope=<path>` and `--focus=<areas>`
-
-## Process
-
-### Step 1: Identify Scope
-
-If `/review-code [scope]` provided: review files matching scope.
-If no scope: review all files changed since last commit.
-
-```bash
-git diff --name-only HEAD~1
-```
-
-If no changes found, report: "Nothing to review."
-
-### Step 2: Parallel Review
-
-Spawn three agents simultaneously:
-
-**@reviewer**
-- Security: secrets, injection, auth, XSS
-- Quality: function size, nesting, error handling
-- Conventions: naming, import style, patterns
-
-**@researcher**
-- Look up best practices for flagged patterns
-- Check if flagged patterns are known vulnerabilities
-- Provide context for MEDIUM findings
-
-**@tester**
-- Check coverage for changed files
-- Identify untested paths
-- Run existing tests
-
-### Step 3: Aggregate Results
-
-Merge all findings by severity:
-
-```
-## Code Review: <scope>
-
-### 🔴 CRITICAL (block merge)
-- [finding with file:line and fix]
-
-### 🟠 HIGH (strongly recommend fix)
-- [finding]
-
-### 🟡 MEDIUM (consider fixing)
-- [finding]
-
-### 🟢 LOW (optional)
-- [finding]
-
-### Coverage
-- Changed files: N%
-- Untested paths: [list]
-
-### Verdict: PASS | FAIL | PASS_WITH_NOTES
-```
-
-### Step 4: Decision
-
-- **CRITICAL found** → Block. Fix before merge.
-- **HIGH found** → Strongly recommend fix. Document if proceeding anyway.
-- **MEDIUM/LOW** → Document. Proceed.
-- **PASS** → Ready to merge.
-
-## Agent Configuration
-
-| Agent | Model | Purpose |
-|-------|-------|---------|
-| @reviewer | google/gemini-2.5-flash | Security and quality |
-| @researcher | anthropic/claude-sonnet-4-5 | Context and best practices |
-| @tester | anthropic/claude-sonnet-4-5 | Coverage analysis |
-
-## Severity Classification
-
-| Severity | Meaning | Action |
-|----------|---------|--------|
-| CRITICAL | Security vulnerability or data loss risk | **BLOCK** - Must fix before merge |
-| HIGH | Bug or significant quality issue | **WARN** - Should fix before merge |
-| MEDIUM | Maintainability concern | **INFO** - Consider fixing |
-| LOW | Style or minor suggestion | **NOTE** - Optional |
-
-## Output
-
-Report: files reviewed, findings by severity, coverage, verdict.

package/src/commands/fd-review-route.md

@@ -1,54 +0,0 @@
----
-description: Human Review Routing — route risky patches to the right reviewer type based on change nature and risk score
-argument-hint: [change description or PR number]
----
-
-# Review Route
-
-Determine the right reviewer type for a proposed change based on its nature and risk.
-
-**Input:** $ARGUMENTS — change description or PR number/URL
-
-## Steps
-
-1. Analyze the change described in `$ARGUMENTS`:
-   - Read affected files and their categories
-   - Check `.codebase/VOLATILITY.json` for risk scores if available
-   - Check `.codebase/FAILURES.json` for prior failures in this area
-
-2. Classify change by domain:
-
-| Domain Signals | Reviewer Type |
-|---------------|---------------|
-| Auth, tokens, sessions, permissions | **Security reviewer** |
-| DB migrations, schema, models | **Backend/DB reviewer** |
-| Infrastructure, CI/CD, containers | **Infra reviewer** |
-| Public APIs, SDK changes | **API owner** |
-| High-churn or volatile file (score >0.7) | **Domain owner** |
-| New external dependency | **Security + Arch reviewer** |
-| Low risk, no sensitive paths | **Any peer reviewer** |
-
-## Report
-
-```
-════════════════════════════════════════════
-REVIEW ROUTING
-════════════════════════════════════════════
-Change: <summary>
-Risk score: <0-10>
-
-Recommended Reviewers:
-
-  PRIMARY:   <reviewer type> — <reason>
-  SECONDARY: <reviewer type> — <reason>
-
-Why:
-  - <specific signal that triggered routing>
-  - <prior failures in this area if any>
-
-SLA:
-  - <high risk: same-day | medium: 24h | low: 48h>
-════════════════════════════════════════════
-```
-
-If risk score < 3: "Low risk — any peer reviewer is sufficient."

package/src/commands/fd-roadmap.md

@@ -1,46 +0,0 @@
----
-description: View or update project roadmap — displays ROADMAP.md, shows phase statuses, add new phase, or mark phase complete
-argument-hint: [--add "Phase Name" | --complete N | --list]
----
-
-# Roadmap
-
-View or update the project roadmap.
-
-**Input:** $ARGUMENTS
-
-## Behavior
-
-### View Roadmap (no args or `--list`)
-
-1. Read `.planning/ROADMAP.md` — if not found, error: "Run /fd-new-project first."
-2. Read `.planning/STATE.md` for current phase and completed phases.
-3. Display the roadmap with status indicators:
-
-```
-═══════════════════════════════════════
-PROJECT ROADMAP
-═══════════════════════════════════════
-  ✅ Phase 1: <name> — completed
-  🔄 Phase 2: <name> — in progress  ← current
-  ⏳ Phase 3: <name> — planned
-═══════════════════════════════════════
-Current: Phase 2 | Status: in_progress
-```
-
-### Add Phase (`--add "Phase Name"`)
-
-Append a new phase row to the `ROADMAP.md` overview table with status `planned`.
-
-Update STATE.md `total_phases` counter.
-
-Report: "Phase <N> '<name>' added."
-
-### Mark Complete (`--complete N`)
-
-1. Update ROADMAP.md to mark phase N as completed.
-2. Update STATE.md:
-   - Increment `completed_phases`
-   - Advance `phase` to N+1 if N is current phase
-   - Set new phase `status: planned`
-3. Report: "Phase N marked complete. Now on phase N+1."

package/src/commands/fd-settings.md

@@ -1,57 +0,0 @@
----
-description: View or update FlowDeck settings — agent models, quality profiles, and workflow toggles
-argument-hint: [key=value | --list]
----
-
-# Settings
-
-View or update FlowDeck configuration.
-
-**Input:** $ARGUMENTS
-
-## Behavior
-
-### List Settings (`--list` or no arguments)
-
-Read `.planning/config.json` (create with defaults if missing) and display current settings:
-
-| Setting | Value | Description |
-|---------|-------|-------------|
-| `model_profile` | balanced | Agent quality profile (quality/balanced/economy) |
-| `tdd_enforced` | true | Require TDD red-green-refactor cycle |
-| `approval_required` | false | Require human approval for risky changes |
-| `volatility_threshold` | 0.7 | Risk score that triggers approval gate |
-| `default_agent` | orchestrator | Default agent for commands |
-
-### Set a Value (`key=value`)
-
-Parse `$ARGUMENTS` as `key=value` pairs (space-separated for multiple).
-
-Valid keys:
-- `model_profile` — `quality`, `balanced`, `economy`
-- `tdd_enforced` — `true`, `false`
-- `approval_required` — `true`, `false`  
-- `volatility_threshold` — number between 0.0 and 1.0
-- `default_agent` — agent name string
-
-Update `.planning/config.json` with the new values.
-
-Report what was changed.
-
-### Invalid Key
-
-Report error with list of valid keys.
-
-## Default Config
-
-If `.planning/config.json` does not exist, create it with defaults:
-
-```json
-{
-  "model_profile": "balanced",
-  "tdd_enforced": true,
-  "approval_required": false,
-  "volatility_threshold": 0.7,
-  "default_agent": "orchestrator"
-}
-```

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