@dv.nghiem/flowdeck 0.2.4 → 0.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +24 -41
- package/dist/hooks/memory-hook.d.ts +21 -0
- package/dist/hooks/memory-hook.d.ts.map +1 -0
- package/dist/hooks/orchestrator-guard-hook.d.ts.map +1 -1
- package/dist/hooks/todo-hook.d.ts +1 -7
- package/dist/hooks/todo-hook.d.ts.map +1 -1
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +709 -420
- package/dist/services/memory-store.d.ts +40 -0
- package/dist/services/memory-store.d.ts.map +1 -0
- package/dist/tools/memory-search.d.ts +3 -0
- package/dist/tools/memory-search.d.ts.map +1 -0
- package/docs/commands/fd-doctor.md +21 -0
- package/docs/commands/fd-quick.md +33 -0
- package/docs/commands/fd-reflect.md +23 -0
- package/docs/commands/fd-status.md +31 -0
- package/docs/commands/fd-translate-intent.md +17 -0
- package/docs/commands.md +209 -271
- package/docs/configuration.md +1 -2
- package/docs/index.md +22 -28
- package/docs/memory.md +69 -0
- package/docs/quick-start.md +1 -1
- package/package.json +1 -1
- package/src/commands/fd-deploy-check.md +131 -11
- package/src/commands/fd-new-project.md +14 -1
- package/src/commands/fd-quick.md +60 -0
- package/src/commands/fd-reflect.md +41 -2
- package/src/commands/fd-status.md +84 -0
- package/src/rules/README.md +8 -7
- package/src/skills/agent-harness-construction/SKILL.md +227 -0
- package/src/skills/api-design/SKILL.md +5 -0
- package/src/skills/backend-patterns/SKILL.md +105 -0
- package/src/skills/clean-architecture/SKILL.md +85 -0
- package/src/skills/cqrs/SKILL.md +230 -0
- package/src/skills/ddd-architecture/SKILL.md +104 -0
- package/src/skills/django-patterns/SKILL.md +304 -0
- package/src/skills/django-tdd/SKILL.md +297 -0
- package/src/skills/event-driven-architecture/SKILL.md +152 -0
- package/src/skills/frontend-pattern/SKILL.md +159 -0
- package/src/skills/hexagonal-architecture/SKILL.md +80 -0
- package/src/skills/layered-architecture/SKILL.md +64 -0
- package/src/skills/postgres-patterns/SKILL.md +74 -0
- package/src/skills/python-patterns/SKILL.md +5 -0
- package/src/skills/saga-architecture/SKILL.md +113 -0
- package/dist/tools/run-parallel.d.ts +0 -4
- package/dist/tools/run-parallel.d.ts.map +0 -1
- package/docs/command-migration.md +0 -175
- package/docs/commands/fd-analyze-change.md +0 -107
- package/docs/commands/fd-dashboard.md +0 -11
- package/docs/commands/fd-evaluate-risk.md +0 -134
- package/docs/commands/fd-guarded-edit.md +0 -105
- package/docs/commands/fd-progress.md +0 -11
- package/docs/commands/fd-review-code.md +0 -29
- package/docs/commands/fd-roadmap.md +0 -10
- package/docs/commands/fd-settings.md +0 -10
- package/docs/parallel-execution.md +0 -255
- package/src/commands/fd-analyze-change.md +0 -57
- package/src/commands/fd-approve.md +0 -64
- package/src/commands/fd-blast-radius.md +0 -49
- package/src/commands/fd-dashboard.md +0 -57
- package/src/commands/fd-evaluate-risk.md +0 -62
- package/src/commands/fd-guarded-edit.md +0 -69
- package/src/commands/fd-impact-radar.md +0 -51
- package/src/commands/fd-learn.md +0 -36
- package/src/commands/fd-progress.md +0 -50
- package/src/commands/fd-regression-predict.md +0 -57
- package/src/commands/fd-review-code.md +0 -96
- package/src/commands/fd-review-route.md +0 -54
- package/src/commands/fd-roadmap.md +0 -46
- package/src/commands/fd-settings.md +0 -57
- package/src/commands/fd-test-gap.md +0 -54
- package/src/commands/fd-volatility-map.md +0 -64
- package/src/commands/fd-workspace-status.md +0 -34
- package/src/skills/parallel-execute/SKILL.md +0 -92
package/docs/configuration.md
CHANGED
|
@@ -269,7 +269,7 @@ These are enabled by default. If you have API keys (e.g., `CONTEXT7_API_KEY`, `E
|
|
|
269
269
|
| `FLOWDECK_CONTEXT_LIMIT` | `200000` | Token limit used by the Context Window Monitor to warn when context usage exceeds 70% |
|
|
270
270
|
| `FLOWDECK_DISABLE_MCP` | (empty) | Comma-separated list of remote MCPs to disable. Valid options: `context7`, `websearch`, `grep_app` |
|
|
271
271
|
| `FLOWDECK_ORCHESTRATOR_GUARD` | `off` | Enable the orchestrator guard hook. When `on`, the orchestrator session cannot use write/bash tools directly and must delegate all implementation work. |
|
|
272
|
-
| `TELEMETRY_ENABLED` | `false` | Enable telemetry events from
|
|
272
|
+
| `TELEMETRY_ENABLED` | `false` | Enable telemetry events from hooks. When `true`, events are written to `.codebase/TELEMETRY.jsonl`. |
|
|
273
273
|
|
|
274
274
|
---
|
|
275
275
|
|
|
@@ -280,7 +280,6 @@ When the `@dv.nghiem/flowdeck` plugin is loaded, six tools become available to e
|
|
|
280
280
|
| `planning-state` | Read and write `.planning/` state files (`STATE.md`, `PLAN.md`, `DISCUSS.md`, `config.json`). Used by every agent that needs project context. |
|
|
281
281
|
| `codebase-state` | Read `.codebase/` documentation files generated by `@mapper`. Gives agents access to `STACK.md`, `ARCHITECTURE.md`, and `CONVENTIONS.md`. |
|
|
282
282
|
| `workspace-state` | Read workspace and multi-repo metadata. Returns the current project config, sub-repo list, and active phase. |
|
|
283
|
-
| `run-parallel` | Fan out a set of independent agent tasks simultaneously. Used by `@parallel-coordinator` to execute wave tasks concurrently. |
|
|
284
283
|
| `run-pipeline` | Execute a sequence of agent tasks in strict order, passing each step's output as input to the next. Used by `@orchestrator` for ordered workflows. |
|
|
285
284
|
| `delegate` | Invoke a specific named agent with a given prompt and context. The core primitive used by orchestration agents to hand off work. |
|
|
286
285
|
| `hash-edit` | Reliable file editing with content verification. Takes target content and its expected hash to prevent edits on stale versions. |
|
package/docs/index.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# FlowDeck Documentation
|
|
2
2
|
|
|
3
|
-
FlowDeck is an OpenCode plugin that brings structured, multi-agent workflow orchestration to your development sessions. It coordinates
|
|
3
|
+
FlowDeck is an OpenCode plugin that brings structured, multi-agent workflow orchestration to your development sessions. It coordinates specialist agents through a four-phase cycle — discuss, plan, execute, review — with persistent state stored in your project's `.planning/` directory.
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -18,12 +18,13 @@ FlowDeck is an OpenCode plugin that brings structured, multi-agent workflow orch
|
|
|
18
18
|
|
|
19
19
|
| Document | Description |
|
|
20
20
|
|----------|-------------|
|
|
21
|
-
| [Agents](agents.md) | All
|
|
22
|
-
| [Skills](skills.md) |
|
|
23
|
-
| [Commands](commands.md) | All
|
|
24
|
-
| [Workflows](workflows.md) |
|
|
21
|
+
| [Agents](agents.md) | All specialist agents — names, roles, models, and when to invoke each one |
|
|
22
|
+
| [Skills](skills.md) | Reusable skill patterns for common tasks |
|
|
23
|
+
| [Commands](commands.md) | All 18 slash commands — syntax, arguments, and what each command triggers |
|
|
24
|
+
| [Workflows](workflows.md) | Built-in workflows for common scenarios |
|
|
25
25
|
| [Rules](rules.md) | Language and common rule files — what they enforce and how to activate them |
|
|
26
|
-
| [Intelligence Features](intelligence.md) |
|
|
26
|
+
| [Intelligence Features](intelligence.md) | AI-safety features for pre-change analysis and risk assessment |
|
|
27
|
+
| [Memory System](memory.md) | Persistent memory — recall past sessions, tool executions, and context across sessions |
|
|
27
28
|
|
|
28
29
|
---
|
|
29
30
|
|
|
@@ -31,7 +32,6 @@ FlowDeck is an OpenCode plugin that brings structured, multi-agent workflow orch
|
|
|
31
32
|
|
|
32
33
|
| Document | Description |
|
|
33
34
|
|----------|-------------|
|
|
34
|
-
| [Parallel Execution](parallel-execution.md) | How FlowDeck fans out independent tasks across multiple agents simultaneously |
|
|
35
35
|
| [Multi-Repo](multi-repo.md) | Coordinating changes across two or more repositories in a single session |
|
|
36
36
|
| [Notifications](notifications.md) | Desktop and system alerts for long-running task completion |
|
|
37
37
|
|
|
@@ -50,26 +50,20 @@ FlowDeck is an OpenCode plugin that brings structured, multi-agent workflow orch
|
|
|
50
50
|
|
|
51
51
|
| Command | What it does |
|
|
52
52
|
|---------|--------------|
|
|
53
|
-
| `/fd-new-project <name>` | Initialize
|
|
54
|
-
| `/fd-discuss <
|
|
55
|
-
| `/fd-plan
|
|
56
|
-
| `/fd-new-feature "<description>"` | Execute full feature workflow
|
|
57
|
-
| `/fd-review-code [staged\|branch]` | Parallel review by `@reviewer`, `@security-auditor`, `@tester` |
|
|
53
|
+
| `/fd-new-project <name>` | Initialize project with planning structure and default config |
|
|
54
|
+
| `/fd-discuss <topic>` | Run structured requirements Q&A to capture decisions |
|
|
55
|
+
| `/fd-plan [--phase=N]` | Generate implementation plan from decisions (requires CONFIRM) |
|
|
56
|
+
| `/fd-new-feature "<description>"` | Execute full feature workflow with TDD discipline |
|
|
58
57
|
| `/fd-fix-bug "<description>"` | Diagnose and fix a bug with regression test |
|
|
58
|
+
| `/fd-deploy-check [--check=deploy,review,analysis]` | Pre-deploy checks, code review, or pre-change analysis |
|
|
59
|
+
| `/fd-status [--roadmap\|--workspace\|--phase=N]` | Combined status, roadmap, and workspace view |
|
|
59
60
|
| `/fd-checkpoint` | Save current state — safe to close the session after this |
|
|
60
|
-
| `/fd-resume` | Reload
|
|
61
|
-
| `/fd-
|
|
62
|
-
| `/fd-map-codebase` | Generate `.codebase/` documentation
|
|
63
|
-
| `/fd-
|
|
64
|
-
| `/fd-
|
|
65
|
-
| `/fd-
|
|
66
|
-
| `/fd-
|
|
67
|
-
| `/fd-
|
|
68
|
-
| `/fd-
|
|
69
|
-
| `/fd-impact-radar` | Predict affected files/APIs/tests before editing |
|
|
70
|
-
| `/fd-blast-radius` | Show downstream consequences and hidden dependencies of a change |
|
|
71
|
-
| `/fd-translate-intent` | Convert vague request into ranked concrete implementation options |
|
|
72
|
-
| `/fd-volatility-map` | Show unstable code zones by churn and hotfix frequency |
|
|
73
|
-
| `/fd-regression-predict` | Estimate likely regression categories before making a change |
|
|
74
|
-
| `/fd-test-gap` | Identify weakly-tested areas in a proposed change |
|
|
75
|
-
| `/fd-review-route` | Route risky patches to security, backend, infra, or domain reviewers |
|
|
61
|
+
| `/fd-resume [--yes]` | Reload STATE.md and PLAN.md to continue interrupted session |
|
|
62
|
+
| `/fd-reflect [--mode=reflect,learn]` | Post-session reflection or capture skill from session |
|
|
63
|
+
| `/fd-map-codebase [--incremental]` | Generate `.codebase/` documentation |
|
|
64
|
+
| `/fd-write-docs [--scope=path]` | Generate documentation from public APIs |
|
|
65
|
+
| `/fd-multi-repo <list\|add\|remove\|status>` | Manage multi-repo configuration |
|
|
66
|
+
| `/fd-translate-intent "<vague request>"` | Convert vague request into ranked implementation options |
|
|
67
|
+
| `/fd-ask "<question>"` | Route question to specialist agent |
|
|
68
|
+
| `/fd-quick "<task>"` | Quick focused task with automatic agent selection |
|
|
69
|
+
| `/fd-doctor` | Check FlowDeck installation and environment health |
|
package/docs/memory.md
ADDED
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
# Memory System
|
|
2
|
+
|
|
3
|
+
FlowDeck includes a persistent memory system that stores tool executions, assistant messages, and session summaries. This helps agents recall what was worked on in previous sessions.
|
|
4
|
+
|
|
5
|
+
## How It Works
|
|
6
|
+
|
|
7
|
+
Memory is automatically captured during sessions:
|
|
8
|
+
|
|
9
|
+
1. **Session Start** — Session is registered with project directory
|
|
10
|
+
2. **Tool Execution** — Every tool call (Read, Write, Edit, Bash, etc.) is stored
|
|
11
|
+
3. **Assistant Messages** — Agent responses are captured
|
|
12
|
+
4. **Session Compact/Summary** — End-of-session summaries are stored
|
|
13
|
+
|
|
14
|
+
## Storage
|
|
15
|
+
|
|
16
|
+
- **Location**: `~/.flowdeck-memory/memory.db`
|
|
17
|
+
- **Format**: SQLite database (using `bun:sqlite`)
|
|
18
|
+
- **Tables**:
|
|
19
|
+
- `sessions` — Session metadata (project, directory, timestamps)
|
|
20
|
+
- `observations` — Tool executions and messages
|
|
21
|
+
- `summaries` — Session summaries
|
|
22
|
+
|
|
23
|
+
## Using Memory
|
|
24
|
+
|
|
25
|
+
### Search Tool
|
|
26
|
+
|
|
27
|
+
Use the `memory-search` tool to query past observations:
|
|
28
|
+
|
|
29
|
+
```
|
|
30
|
+
tool: memory-search
|
|
31
|
+
args: { query: "authentication", limit: 5 }
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
**Arguments:**
|
|
35
|
+
- `query` (optional) — Search text for tool names, inputs, and outputs
|
|
36
|
+
- `session_id` (optional) — Retrieve all observations from a specific session
|
|
37
|
+
- `limit` (optional) — Max results (default: 10)
|
|
38
|
+
|
|
39
|
+
### Example Queries
|
|
40
|
+
|
|
41
|
+
```javascript
|
|
42
|
+
// Search for specific work
|
|
43
|
+
tool: memory-search
|
|
44
|
+
args: { query: "Redis cache" }
|
|
45
|
+
|
|
46
|
+
// Get recent sessions
|
|
47
|
+
tool: memory-search
|
|
48
|
+
args: { limit: 10 }
|
|
49
|
+
|
|
50
|
+
// Get all observations from a session
|
|
51
|
+
tool: memory-search
|
|
52
|
+
args: { session_id: "abc-123" }
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
## Context Injection
|
|
56
|
+
|
|
57
|
+
When a new session starts in the same directory, FlowDeck can optionally inject relevant context from previous sessions. This helps maintain continuity across sessions.
|
|
58
|
+
|
|
59
|
+
## Privacy
|
|
60
|
+
|
|
61
|
+
- Memory is stored per-user at `~/.flowdeck-memory/`
|
|
62
|
+
- Each project directory has its own session tracking
|
|
63
|
+
- Use session.delete event to remove specific sessions
|
|
64
|
+
|
|
65
|
+
## Configuration
|
|
66
|
+
|
|
67
|
+
No configuration required — memory is enabled by default.
|
|
68
|
+
|
|
69
|
+
To disable memory tracking for a project, you would need to modify the session tracking hooks in the FlowDeck plugin configuration.
|
package/docs/quick-start.md
CHANGED
|
@@ -123,7 +123,7 @@ Once the plan is confirmed, start implementation:
|
|
|
123
123
|
3. **Wave 3** — `@tester` writes and runs tests against the completed implementation
|
|
124
124
|
4. **Wave 4** — `@reviewer` reviews the full changeset
|
|
125
125
|
|
|
126
|
-
You see progress updates as each wave completes. Independent tasks within a wave run simultaneously via
|
|
126
|
+
You see progress updates as each wave completes. Independent tasks within a wave run simultaneously via OpenCode's multi-agent capabilities.
|
|
127
127
|
|
|
128
128
|
---
|
|
129
129
|
|
package/package.json
CHANGED
|
@@ -1,13 +1,30 @@
|
|
|
1
1
|
---
|
|
2
|
-
description:
|
|
3
|
-
argument-hint: [--env=staging|production]
|
|
2
|
+
description: Pre-deployment checks, code review, and pre-change analysis — all-in-one quality gate
|
|
3
|
+
argument-hint: [--env=staging|production] [--check=deploy,review,analysis] [--scope=path]
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Deploy Check
|
|
7
7
|
|
|
8
|
-
Run
|
|
8
|
+
Run comprehensive checks before deployment or review code changes.
|
|
9
9
|
|
|
10
|
-
**Input:** $ARGUMENTS
|
|
10
|
+
**Input:** $ARGUMENTS
|
|
11
|
+
|
|
12
|
+
## Check Types
|
|
13
|
+
|
|
14
|
+
### Deploy Check (`--check=deploy` or default)
|
|
15
|
+
Run full pre-deployment suite. See Steps 1-3 below.
|
|
16
|
+
|
|
17
|
+
### Code Review (`--check=review`)
|
|
18
|
+
Run parallel reviewer + researcher + tester on changed files. See Steps 4-6 below.
|
|
19
|
+
|
|
20
|
+
### Pre-Change Analysis (`--check=analysis`)
|
|
21
|
+
Run comprehensive pre-change analysis. See Step 7 below.
|
|
22
|
+
|
|
23
|
+
## Common Pre-flight
|
|
24
|
+
|
|
25
|
+
1. If `--scope` provided: use that path
|
|
26
|
+
2. If no scope with `--check=review`: use files changed since last commit
|
|
27
|
+
3. If no scope with `--check=deploy`: use all changed files since last commit
|
|
11
28
|
|
|
12
29
|
## Process
|
|
13
30
|
|
|
@@ -83,11 +100,114 @@ Any of these → automatic NO-GO:
|
|
|
83
100
|
- HIGH/CRITICAL CVE unpatched
|
|
84
101
|
- Build error
|
|
85
102
|
|
|
86
|
-
|
|
103
|
+
### Step 4: Code Review Scope (--check=review)
|
|
104
|
+
|
|
105
|
+
If `/deploy-check --check=review [scope]` provided: review files matching scope.
|
|
106
|
+
If no scope: review all files changed since last commit.
|
|
107
|
+
|
|
108
|
+
```bash
|
|
109
|
+
git diff --name-only HEAD~1
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
If no changes found, report: "Nothing to review."
|
|
113
|
+
|
|
114
|
+
### Step 5: Parallel Review
|
|
115
|
+
|
|
116
|
+
Spawn three agents simultaneously:
|
|
117
|
+
|
|
118
|
+
**@reviewer**
|
|
119
|
+
- Security: secrets, injection, auth, XSS
|
|
120
|
+
- Quality: function size, nesting, error handling
|
|
121
|
+
- Conventions: naming, import style, patterns
|
|
122
|
+
|
|
123
|
+
**@researcher**
|
|
124
|
+
- Look up best practices for flagged patterns
|
|
125
|
+
- Check if flagged patterns are known vulnerabilities
|
|
126
|
+
- Provide context for MEDIUM findings
|
|
127
|
+
|
|
128
|
+
**@tester**
|
|
129
|
+
- Check coverage for changed files
|
|
130
|
+
- Identify untested paths
|
|
131
|
+
- Run existing tests
|
|
132
|
+
|
|
133
|
+
### Step 6: Aggregate Review Results
|
|
134
|
+
|
|
135
|
+
Merge all findings by severity:
|
|
136
|
+
|
|
137
|
+
```
|
|
138
|
+
## Code Review: <scope>
|
|
139
|
+
|
|
140
|
+
### 🔴 CRITICAL (block merge)
|
|
141
|
+
- [finding with file:line and fix]
|
|
142
|
+
|
|
143
|
+
### 🟠 HIGH (strongly recommend fix)
|
|
144
|
+
- [finding]
|
|
145
|
+
|
|
146
|
+
### 🟡 MEDIUM (consider fixing)
|
|
147
|
+
- [finding]
|
|
148
|
+
|
|
149
|
+
### 🟢 LOW (optional)
|
|
150
|
+
- [finding]
|
|
151
|
+
|
|
152
|
+
### Coverage
|
|
153
|
+
- Changed files: N%
|
|
154
|
+
- Untested paths: [list]
|
|
155
|
+
|
|
156
|
+
### Verdict: PASS | FAIL | PASS_WITH_NOTES
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
### Step 7: Pre-Change Analysis (--check=analysis)
|
|
160
|
+
|
|
161
|
+
Run all analyses in parallel:
|
|
162
|
+
|
|
163
|
+
1. **Impact Radar** — which files/APIs/tests are affected
|
|
164
|
+
2. **Blast Radius** — downstream consequences and hidden couplings
|
|
165
|
+
3. **Regression Predict** — most likely regression categories
|
|
166
|
+
4. **Test Gap** — coverage gaps to fill before implementing
|
|
167
|
+
5. **Volatility** — check hotspot scores on affected files
|
|
168
|
+
6. **Review Route** — who should review this change
|
|
169
|
+
|
|
170
|
+
## Consolidated Analysis Report
|
|
171
|
+
|
|
172
|
+
```
|
|
173
|
+
════════════════════════════════════════════════════
|
|
174
|
+
PRE-CHANGE ANALYSIS: "$ARGUMENTS"
|
|
175
|
+
════════════════════════════════════════════════════
|
|
176
|
+
|
|
177
|
+
IMPACT (<N> files affected)
|
|
178
|
+
- <top 5 affected files with reason>
|
|
179
|
+
|
|
180
|
+
BLAST RADIUS (risk: <low|medium|high>)
|
|
181
|
+
- <key downstream risks>
|
|
182
|
+
|
|
183
|
+
REGRESSIONS (top 3 risks)
|
|
184
|
+
🔴 <category> — <reason>
|
|
185
|
+
🟠 <category> — <reason>
|
|
186
|
+
|
|
187
|
+
TEST GAPS (<N> gaps found)
|
|
188
|
+
- CRITICAL: <gap>
|
|
189
|
+
- HIGH: <gap>
|
|
190
|
+
|
|
191
|
+
VOLATILITY
|
|
192
|
+
Hot zones touched: <list or "none">
|
|
193
|
+
|
|
194
|
+
REVIEW ROUTING
|
|
195
|
+
→ <reviewer type> (<reason>)
|
|
196
|
+
|
|
197
|
+
────────────────────────────────────────────────────
|
|
198
|
+
RECOMMENDATION: <proceed | add tests first | redesign | review required>
|
|
199
|
+
|
|
200
|
+
Next steps:
|
|
201
|
+
1. <most important action>
|
|
202
|
+
2. <second action>
|
|
203
|
+
════════════════════════════════════════════════════
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
## Severity Classification
|
|
87
207
|
|
|
88
|
-
|
|
|
89
|
-
|
|
90
|
-
|
|
|
91
|
-
|
|
|
92
|
-
|
|
|
93
|
-
|
|
|
208
|
+
| Severity | Meaning | Action |
|
|
209
|
+
|----------|---------|--------|
|
|
210
|
+
| CRITICAL | Security vulnerability or data loss risk | **BLOCK** - Must fix before merge |
|
|
211
|
+
| HIGH | Bug or significant quality issue | **WARN** - Should fix before merge |
|
|
212
|
+
| MEDIUM | Maintainability concern | **INFO** - Consider fixing |
|
|
213
|
+
| LOW | Style or minor suggestion | **NOTE** - Optional |
|
|
@@ -98,6 +98,19 @@ confirmed_at: none
|
|
|
98
98
|
|
|
99
99
|
3. Also create `.planning/phases/phase-1/` directory.
|
|
100
100
|
|
|
101
|
-
4.
|
|
101
|
+
4. Create `.planning/config.json` with default settings:
|
|
102
|
+
|
|
103
|
+
```json
|
|
104
|
+
{
|
|
105
|
+
"model_profile": "balanced",
|
|
106
|
+
"tdd_enforced": true,
|
|
107
|
+
"approval_required": false,
|
|
108
|
+
"volatility_threshold": 0.7,
|
|
109
|
+
"default_agent": "orchestrator"
|
|
110
|
+
}
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
5. Report success with the list of files created and next steps:
|
|
102
114
|
- Run `/fd-discuss` to capture project decisions
|
|
103
115
|
- Run `/fd-plan` to create an implementation plan
|
|
116
|
+
- Edit `.planning/config.json` directly to change settings
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Quick task execution — analyze, implement, review, or investigate a specific piece of work without the full discuss -> plan -> execute workflow
|
|
3
|
+
argument-hint: [task description]
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Quick Task
|
|
7
|
+
|
|
8
|
+
Execute a focused task without the full workflow. Analyzes the request, selects the best specialist agent, and returns the result directly.
|
|
9
|
+
|
|
10
|
+
**Input:** $ARGUMENTS — what you need done
|
|
11
|
+
|
|
12
|
+
## Analysis
|
|
13
|
+
|
|
14
|
+
Parse `$ARGUMENTS` to determine:
|
|
15
|
+
|
|
16
|
+
1. **Type of task** — what kind of work is it?
|
|
17
|
+
2. **Scope** — single file, directory, or whole codebase?
|
|
18
|
+
3. **Required capability** — what must the agent be able to do?
|
|
19
|
+
|
|
20
|
+
## Agent Selection Matrix
|
|
21
|
+
|
|
22
|
+
| Task Type | Signal Keywords | Agent |
|
|
23
|
+
|-----------|-----------------|-------|
|
|
24
|
+
| Write or edit code | implement, add, create, fix, refactor, update | `@coder` |
|
|
25
|
+
| Explore and understand | trace, map, find, explore, understand, what does | `@code-explorer` |
|
|
26
|
+
| Review code quality | review, check, audit, analyze | `@reviewer` |
|
|
27
|
+
| Security review | security, auth, vulnerability, injection, OWASP | `@security-auditor` |
|
|
28
|
+
| Design or architecture | design, architect, schema, API, structure | `@architect` |
|
|
29
|
+
| Write tests | test, coverage, regression, TDD | `@tester` |
|
|
30
|
+
| Documentation | docs, README, document, write | `@writer` |
|
|
31
|
+
| Research | research, find, look up, how to use, compare | `@researcher` |
|
|
32
|
+
| Debug | debug, trace, root cause, why is, fix error | `@debug-specialist` |
|
|
33
|
+
| Performance | performance, slow, optimize, bottleneck | `@performance-optimizer` |
|
|
34
|
+
| Build error | build error, compile, types, missing import | `@build-error-resolver` |
|
|
35
|
+
| Refactoring | refactor, extract, rename, restructure | `@refactor-guide` |
|
|
36
|
+
| Write/update docs | document, write docs, update README | `@doc-updater` |
|
|
37
|
+
|
|
38
|
+
**Default:** If unclear or mixed, use `@orchestrator`.
|
|
39
|
+
|
|
40
|
+
## Execution
|
|
41
|
+
|
|
42
|
+
1. Select the best agent from the matrix above.
|
|
43
|
+
2. Construct a focused prompt with:
|
|
44
|
+
- The task from `$ARGUMENTS`
|
|
45
|
+
- Relevant context (file paths, architecture info, existing code)
|
|
46
|
+
- Clear success criteria
|
|
47
|
+
3. Execute directly — no intermediate steps.
|
|
48
|
+
|
|
49
|
+
## Output
|
|
50
|
+
|
|
51
|
+
Return the agent's output with:
|
|
52
|
+
- Which agent was used
|
|
53
|
+
- The result (be direct, no padding)
|
|
54
|
+
- If the task is partial or incomplete, note what still needs doing
|
|
55
|
+
|
|
56
|
+
## Guardrails
|
|
57
|
+
|
|
58
|
+
- **Small tasks only** — if the task would require more than ~15 minutes of work, suggest `/fd-new-feature` instead.
|
|
59
|
+
- **Single scope** — do not attempt multi-file refactors or cross-repo changes via this command.
|
|
60
|
+
- **No workflow overhead** — skip STATE.md updates, phase transitions, and plan markers.
|
|
@@ -1,11 +1,22 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: Post-session reflection — analyse artifacts
|
|
2
|
+
description: Post-session reflection and skill capture — analyse artifacts, propose improvements, capture session patterns
|
|
3
|
+
argument-hint: [--mode=reflect,learn]
|
|
3
4
|
---
|
|
4
5
|
|
|
5
|
-
# Reflect
|
|
6
|
+
# Reflect
|
|
6
7
|
|
|
7
8
|
Analyse session artifacts and propose concrete improvements to FlowDeck's knowledge base.
|
|
8
9
|
|
|
10
|
+
**Input:** $ARGUMENTS — optional `--mode=reflect` (default) or `--mode=learn`
|
|
11
|
+
|
|
12
|
+
## Modes
|
|
13
|
+
|
|
14
|
+
### Reflect (default)
|
|
15
|
+
Post-session self-improvement analysis. See Steps below.
|
|
16
|
+
|
|
17
|
+
### Learn (`--mode=learn`)
|
|
18
|
+
Capture a repeatable pattern from this session as a reusable FlowDeck skill.
|
|
19
|
+
|
|
9
20
|
## Steps
|
|
10
21
|
|
|
11
22
|
1. Call the `reflect` tool to gather session artifacts and generate the reflection context.
|
|
@@ -28,3 +39,31 @@ Analyse session artifacts and propose concrete improvements to FlowDeck's knowle
|
|
|
28
39
|
- What was captured (new skills created)
|
|
29
40
|
- What requires human review (policy proposals, workflow changes)
|
|
30
41
|
- 3–5 bullet summary of this session's most impactful learnings
|
|
42
|
+
|
|
43
|
+
## Learn Mode
|
|
44
|
+
|
|
45
|
+
When `--mode=learn`:
|
|
46
|
+
|
|
47
|
+
1. **Identify what is worth capturing.** Look for:
|
|
48
|
+
- A novel problem that required figuring out a non-obvious solution
|
|
49
|
+
- A pattern that required human guidance or clarification to resolve
|
|
50
|
+
- A workflow or sequence that would save significant time if remembered
|
|
51
|
+
- A pitfall that was hit and corrected
|
|
52
|
+
|
|
53
|
+
If nothing significant was discovered, reply: "No new patterns to capture from this session." and stop.
|
|
54
|
+
|
|
55
|
+
2. **Draft the skill.** Structure it as:
|
|
56
|
+
- `## When to Activate` — concrete triggers (e.g., "when X file pattern exists", "when the user asks about Y")
|
|
57
|
+
- `## Steps` — ordered, concrete steps to apply the skill
|
|
58
|
+
- `## Examples` — at least one short, concrete example
|
|
59
|
+
- `## Pitfalls` — common mistakes to avoid
|
|
60
|
+
|
|
61
|
+
3. **Choose the skill name.** Use `$ARGUMENTS` if provided as skill name, otherwise derive a kebab-case name from the pattern.
|
|
62
|
+
|
|
63
|
+
4. **Write the skill** using the `create-skill` tool with:
|
|
64
|
+
- `name`: kebab-case identifier
|
|
65
|
+
- `description`: one sentence summarising what the skill does
|
|
66
|
+
- `content`: the full Markdown body from step 2
|
|
67
|
+
- `tags`: 2–4 relevant tags
|
|
68
|
+
|
|
69
|
+
5. **Report** what was captured, why it is useful, and remind the user to restart OpenCode to activate it.
|
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: View project status — combined status, roadmap, workspace overview, and progress
|
|
3
|
+
argument-hint: [--roadmap | --workspace | --phase=N]
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Status
|
|
7
|
+
|
|
8
|
+
View project status combining progress, roadmap, and workspace overview.
|
|
9
|
+
|
|
10
|
+
**Input:** $ARGUMENTS — optional flags
|
|
11
|
+
|
|
12
|
+
## Modes
|
|
13
|
+
|
|
14
|
+
### Default (no flags)
|
|
15
|
+
|
|
16
|
+
Read `.planning/STATE.md` and display combined status:
|
|
17
|
+
|
|
18
|
+
```
|
|
19
|
+
════════════════════════════════════════════════════════════
|
|
20
|
+
Phase: <N> | Status: <status> | Updated: <timestamp>
|
|
21
|
+
────────────────────────────────────────────────────────────
|
|
22
|
+
Plan: <X> steps (<Y> complete)
|
|
23
|
+
Plan confirmed: <yes/no>
|
|
24
|
+
════════════════════════════════════════════════════════════
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
### Roadmap (`--roadmap`)
|
|
28
|
+
|
|
29
|
+
Display project roadmap with phase statuses:
|
|
30
|
+
|
|
31
|
+
```
|
|
32
|
+
═══════════════════════════════════════
|
|
33
|
+
PROJECT ROADMAP
|
|
34
|
+
═══════════════════════════════════════
|
|
35
|
+
✅ Phase 1: <name> — completed
|
|
36
|
+
🔄 Phase 2: <name> — in progress ← current
|
|
37
|
+
⏳ Phase 3: <name> — planned
|
|
38
|
+
═══════════════════════════════════════
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
Read from `.planning/ROADMAP.md` and `.planning/STATE.md`.
|
|
42
|
+
|
|
43
|
+
### Workspace (`--workspace`)
|
|
44
|
+
|
|
45
|
+
Display overview of all registered repositories:
|
|
46
|
+
|
|
47
|
+
```
|
|
48
|
+
════════════════════════════════════════════════════
|
|
49
|
+
WORKSPACE OVERVIEW
|
|
50
|
+
════════════════════════════════════════════════════
|
|
51
|
+
frontend — Phase 2 | in_progress | Plan: ✅ | Updated: <time>
|
|
52
|
+
backend — Phase 3 | completed | Plan: ✅ | Updated: <time>
|
|
53
|
+
shared — Phase 1 | planned | Plan: ❌ | Updated: <time>
|
|
54
|
+
────────────────────────────────────────────────────
|
|
55
|
+
Total: 3 repos | 1 in progress | 1 completed | 1 planned
|
|
56
|
+
════════════════════════════════════════════════════
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
Read from `.planning/config.json` for repo list, each repo's STATE.md for phase/status.
|
|
60
|
+
|
|
61
|
+
### Phase Detail (`--phase=N`)
|
|
62
|
+
|
|
63
|
+
Show detailed progress for a specific phase:
|
|
64
|
+
|
|
65
|
+
```
|
|
66
|
+
════════════════════════════════════════════════════════════
|
|
67
|
+
PHASE <N> DETAIL
|
|
68
|
+
════════════════════════════════════════════════════════════
|
|
69
|
+
Status: <status>
|
|
70
|
+
Plan file: <path>
|
|
71
|
+
Plan confirmed: <yes/no>
|
|
72
|
+
|
|
73
|
+
Steps:
|
|
74
|
+
✅ Step 1: <name> — completed
|
|
75
|
+
🔄 Step 2: <name> — in progress
|
|
76
|
+
⬜ Step 3: <name> — pending
|
|
77
|
+
⬜ Step 4: <name> — pending
|
|
78
|
+
════════════════════════════════════════════════════════════
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
## Error Handling
|
|
82
|
+
|
|
83
|
+
- If `.planning/STATE.md` not found: "No active project. Run /fd-new-project first."
|
|
84
|
+
- If `--phase` requested but phase directory doesn't exist: "Phase N not found."
|
package/src/rules/README.md
CHANGED
|
@@ -2,22 +2,23 @@
|
|
|
2
2
|
|
|
3
3
|
Coding standards for projects using FlowDeck. These define conventions that FlowDeck agents follow automatically.
|
|
4
4
|
|
|
5
|
-
## How
|
|
5
|
+
## How It Works
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
Rules are loaded **automatically** by the FlowDeck plugin. No manual configuration is needed — when FlowDeck is installed, all rule files in this directory are injected into OpenCode's `instructions` at startup.
|
|
8
|
+
|
|
9
|
+
## Selective Rules (Optional)
|
|
10
|
+
|
|
11
|
+
If you want to override the default set and load only specific rules, add them to `opencode.json` under `instructions`:
|
|
8
12
|
|
|
9
13
|
```json
|
|
10
14
|
{
|
|
11
15
|
"instructions": [
|
|
12
|
-
".flowdeck/rules/common/coding-style.md",
|
|
13
|
-
".flowdeck/rules/
|
|
14
|
-
".flowdeck/rules/typescript/patterns.md"
|
|
16
|
+
"node_modules/@dv.nghiem/flowdeck/src/rules/common/coding-style.md",
|
|
17
|
+
"node_modules/@dv.nghiem/flowdeck/src/rules/typescript/patterns.md"
|
|
15
18
|
]
|
|
16
19
|
}
|
|
17
20
|
```
|
|
18
21
|
|
|
19
|
-
Agents will read these files and follow the conventions defined in them.
|
|
20
|
-
|
|
21
22
|
## Available Rules
|
|
22
23
|
|
|
23
24
|
### Common Rules (language-agnostic)
|