@dv.nghiem/flowdeck 0.3.1 → 0.3.3
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 +11 -7
- package/dist/hooks/patch-trust.d.ts.map +1 -1
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +201 -108
- package/dist/tools/memory-status.d.ts +3 -0
- package/dist/tools/memory-status.d.ts.map +1 -0
- package/docs/commands.md +102 -9
- package/docs/quick-start.md +44 -23
- package/docs/workflows.md +10 -8
- package/package.json +1 -1
- package/src/commands/fd-execute.md +192 -0
- package/src/commands/fd-new-feature.md +44 -157
- package/src/commands/fd-new-project.md +1 -2
- package/src/commands/fd-plan.md +1 -1
- package/src/commands/fd-suggest.md +84 -0
- package/src/commands/fd-verify.md +126 -0
- package/src/rules/common/agent-orchestration.md +5 -5
- package/src/rules/common/coding-style.md +17 -0
|
@@ -1,192 +1,79 @@
|
|
|
1
1
|
---
|
|
2
|
-
description:
|
|
3
|
-
argument-hint: [feature description]
|
|
2
|
+
description: Start a new feature — initialize feature context in .planning/, capture description, and guide through discuss → plan → execute → verify
|
|
3
|
+
argument-hint: [feature name or description]
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# New Feature
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Initialize a new feature and guide through the full FlowDeck feature workflow.
|
|
9
9
|
|
|
10
|
-
**Input:** $ARGUMENTS — description of the feature to
|
|
10
|
+
**Input:** $ARGUMENTS — name or short description of the feature to build
|
|
11
11
|
|
|
12
12
|
## Pre-flight
|
|
13
13
|
|
|
14
14
|
1. Check `.planning/` exists — if not, error: "Run /fd-new-project first."
|
|
15
|
-
2.
|
|
16
|
-
3.
|
|
17
|
-
4. Read `.codebase/ARCHITECTURE.md` if it exists — pass as context.
|
|
18
|
-
|
|
19
|
-
## TDD Cycle Per Step
|
|
20
|
-
|
|
21
|
-
Each plan step follows the TDD cycle:
|
|
22
|
-
|
|
23
|
-
```
|
|
24
|
-
BEHAVIOR → RED → GREEN → REFACTOR → next step
|
|
25
|
-
↑_________| |
|
|
26
|
-
(loop if needed) Only if GREEN
|
|
27
|
-
```
|
|
15
|
+
2. Read `.planning/STATE.md` to determine the current phase number N.
|
|
16
|
+
3. Create `.planning/phases/phase-<N>/` directory if it does not exist.
|
|
28
17
|
|
|
29
18
|
## Process
|
|
30
19
|
|
|
31
|
-
### Step 1:
|
|
32
|
-
|
|
33
|
-
Verify prerequisites:
|
|
34
|
-
- `.planning/` directory exists
|
|
35
|
-
- `.codebase/` directory exists
|
|
36
|
-
- `STATE.md` has `plan_confirmed: true`
|
|
37
|
-
- `PLAN.md` exists in current phase directory
|
|
38
|
-
|
|
39
|
-
Initialize TDD state:
|
|
40
|
-
```yaml
|
|
41
|
-
tdd:
|
|
42
|
-
stage: behavior
|
|
43
|
-
cycle: 1
|
|
44
|
-
behaviors: []
|
|
45
|
-
regression_test_links: []
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
### Step 2: Load Plan
|
|
49
|
-
|
|
50
|
-
Read the active PLAN.md from the current phase directory.
|
|
51
|
-
Parse the tasks list and identify which steps are complete.
|
|
52
|
-
|
|
53
|
-
### Step 3: Define Behaviors
|
|
54
|
-
|
|
55
|
-
Spawn `@orchestrator` to generate behavior checklist from PLAN.md:
|
|
56
|
-
- Acceptance cases for each step
|
|
57
|
-
- Edge cases to test
|
|
58
|
-
- Expected behaviors
|
|
59
|
-
|
|
60
|
-
Store in TDD state.
|
|
61
|
-
|
|
62
|
-
### Step 4: Identify Next Step
|
|
63
|
-
|
|
64
|
-
From PLAN.md, find the first step NOT in `steps_complete`.
|
|
65
|
-
Check TDD stage — only proceed if stage is appropriate for the step.
|
|
66
|
-
|
|
67
|
-
### Step 5: Write Failing Tests (RED)
|
|
20
|
+
### Step 1: Capture Feature Description
|
|
68
21
|
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
- Cover acceptance cases and edge cases
|
|
72
|
-
- Use AAA pattern (Arrange-Act-Assert)
|
|
22
|
+
If $ARGUMENTS is empty, ask the user:
|
|
23
|
+
> "What feature do you want to build? Describe it in one or two sentences."
|
|
73
24
|
|
|
74
|
-
|
|
25
|
+
Use the provided description as the feature name/summary.
|
|
75
26
|
|
|
76
|
-
|
|
77
|
-
- **GUARD: Do NOT proceed to Step 7 until tests fail**
|
|
78
|
-
- If tests pass unexpectedly, tests don't correctly describe behavior
|
|
27
|
+
### Step 2: Initialize Feature Context
|
|
79
28
|
|
|
80
|
-
|
|
29
|
+
Create `.planning/phases/phase-<N>/FEATURE.md`:
|
|
81
30
|
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
- No speculative features
|
|
85
|
-
- No over-engineering
|
|
31
|
+
```markdown
|
|
32
|
+
# Feature: $ARGUMENTS
|
|
86
33
|
|
|
87
|
-
|
|
34
|
+
**Phase:** <N>
|
|
35
|
+
**Created:** <current timestamp>
|
|
36
|
+
**Status:** defined
|
|
88
37
|
|
|
89
|
-
|
|
90
|
-
- **GUARD: Do NOT proceed to Step 9 until tests pass**
|
|
91
|
-
- If tests fail, return to Step 7
|
|
38
|
+
## Description
|
|
92
39
|
|
|
93
|
-
|
|
40
|
+
$ARGUMENTS
|
|
94
41
|
|
|
95
|
-
|
|
96
|
-
- Clean up code for this step
|
|
97
|
-
- Remove dead code
|
|
98
|
-
- Improve readability
|
|
99
|
-
- **GUARD: Do not refactor if not GREEN**
|
|
42
|
+
## Acceptance Criteria
|
|
100
43
|
|
|
101
|
-
|
|
44
|
+
(to be defined in /fd-discuss)
|
|
102
45
|
|
|
103
|
-
|
|
104
|
-
- All tests must pass
|
|
105
|
-
- If any fails, revert refactoring
|
|
46
|
+
## Out of Scope
|
|
106
47
|
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
Spawn `@reviewer` to check:
|
|
110
|
-
- Code quality, security, conventions
|
|
111
|
-
- TDD discipline followed
|
|
112
|
-
- Test coverage >= 80%
|
|
113
|
-
- No missing or weak tests (flag as major finding)
|
|
114
|
-
|
|
115
|
-
### Step 12: Update State
|
|
116
|
-
|
|
117
|
-
Mark step complete via planning-state tool:
|
|
118
|
-
```yaml
|
|
119
|
-
steps_complete: [N, ...]
|
|
120
|
-
last_action: "Step N complete via TDD: [behavior]"
|
|
121
|
-
tdd:
|
|
122
|
-
stage: behavior # Ready for next step
|
|
48
|
+
(to be defined in /fd-discuss)
|
|
123
49
|
```
|
|
124
50
|
|
|
125
|
-
### Step
|
|
126
|
-
|
|
127
|
-
If more steps pending:
|
|
128
|
-
- Return to Step 3 (define behaviors for next step)
|
|
129
|
-
|
|
130
|
-
If all steps complete:
|
|
131
|
-
- Update phase status to "complete"
|
|
132
|
-
- Update ROADMAP.md progress
|
|
133
|
-
- Present completion summary
|
|
134
|
-
|
|
135
|
-
## Wave-Based Execution
|
|
136
|
-
|
|
137
|
-
WF-03 respects wave structure from PLAN.md:
|
|
138
|
-
- Wave 1 steps execute first (with TDD cycle per step)
|
|
139
|
-
- Wave 2 steps execute after Wave 1 completes
|
|
140
|
-
- Wave 3 steps execute after Wave 2 completes
|
|
141
|
-
- No intra-wave dependencies (parallel execution)
|
|
51
|
+
### Step 3: Update STATE.md
|
|
142
52
|
|
|
143
|
-
|
|
53
|
+
Update the current phase entry in STATE.md:
|
|
54
|
+
- Set `feature` to the feature name/description
|
|
55
|
+
- Set `status` to `defined`
|
|
56
|
+
- Set `last_action` to `"Feature defined: $ARGUMENTS"`
|
|
144
57
|
|
|
145
|
-
|
|
146
|
-
|-----------|-------|-------------|
|
|
147
|
-
| behavior → red | Test written and fails | Block until test fails |
|
|
148
|
-
| red → green | Test exists and fails | Block until test passes |
|
|
149
|
-
| green → refactor | Tests are green | Block until green |
|
|
150
|
-
| refactor → verify | All tests pass | Block until all pass |
|
|
58
|
+
### Step 4: Present Feature Workflow
|
|
151
59
|
|
|
152
|
-
|
|
60
|
+
Report what was created and present the next steps clearly:
|
|
153
61
|
|
|
154
|
-
User can override with `/fd-new-feature --override`:
|
|
155
|
-
- Every override is logged in `override_log`
|
|
156
|
-
- Surface override in next review
|
|
157
|
-
- Flag in deploy check
|
|
158
|
-
|
|
159
|
-
## Error Handling
|
|
160
|
-
|
|
161
|
-
D-03: Fail fast with clear error
|
|
162
|
-
- If guard check fails: abort with clear error and remediation
|
|
163
|
-
- If @coder fails: report failure, offer retry or skip
|
|
164
|
-
- If @reviewer finds critical issues: return to Step 7 for fixes
|
|
165
|
-
- No partial state saved on error
|
|
166
|
-
|
|
167
|
-
## State Updates
|
|
168
|
-
|
|
169
|
-
STATE.md updates after each step:
|
|
170
|
-
```yaml
|
|
171
|
-
steps_complete: [1, 2] # Added after step 2
|
|
172
|
-
steps_pending: [3, 4, 5] # Removed step 2
|
|
173
|
-
last_action: "Step 2 TDD complete: [behavior] (RED→GREEN→REFACTOR)"
|
|
174
|
-
tdd:
|
|
175
|
-
stage: behavior
|
|
176
|
-
cycle: 2
|
|
177
|
-
behaviors_completed: 2
|
|
178
62
|
```
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
|
|
186
|
-
|
|
187
|
-
|
|
63
|
+
✅ Feature initialized: $ARGUMENTS
|
|
64
|
+
Phase: <N>
|
|
65
|
+
File: .planning/phases/phase-<N>/FEATURE.md
|
|
66
|
+
|
|
67
|
+
Next steps (in order):
|
|
68
|
+
1. /fd-discuss — capture requirements, scope, and acceptance criteria
|
|
69
|
+
2. /fd-plan — create implementation plan from discussion decisions
|
|
70
|
+
3. /fd-execute — run TDD pipeline to implement the plan
|
|
71
|
+
4. /fd-verify — run full test + review + deploy-check pipeline
|
|
188
72
|
```
|
|
189
73
|
|
|
190
|
-
##
|
|
74
|
+
## Error Handling
|
|
75
|
+
|
|
76
|
+
- If `.planning/` not found: error "Run /fd-new-project first."
|
|
77
|
+
- If STATE.md not found: error "Project not initialized. Run /fd-new-project first."
|
|
78
|
+
- No partial state saved on error.
|
|
191
79
|
|
|
192
|
-
Report: feature implemented, tests status, reviewer findings, files changed.
|
|
@@ -111,6 +111,5 @@ confirmed_at: none
|
|
|
111
111
|
```
|
|
112
112
|
|
|
113
113
|
5. Report success with the list of files created and next steps:
|
|
114
|
-
- Run `/fd-
|
|
115
|
-
- Run `/fd-plan` to create an implementation plan
|
|
114
|
+
- Run `/fd-new-feature` to define your first feature
|
|
116
115
|
- Edit `.planning/config.json` directly to change settings
|
package/src/commands/fd-plan.md
CHANGED
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Analyze codebase and suggest new features with implementation instructions
|
|
3
|
+
argument-hint: [--category=TYPE] [--limit=N]
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Suggest Features
|
|
7
|
+
|
|
8
|
+
Analyze the codebase and generate actionable feature suggestions with implementation guidance.
|
|
9
|
+
|
|
10
|
+
**Input:** $ARGUMENTS (optional --category for focus area: tools|hooks|agents|skills, --limit for number of suggestions, default 5)
|
|
11
|
+
|
|
12
|
+
## Process
|
|
13
|
+
|
|
14
|
+
### Step 1: Detect Environment
|
|
15
|
+
|
|
16
|
+
Check if `.planning/` directory exists:
|
|
17
|
+
- If it exists: Use current project context, analyze within existing architecture
|
|
18
|
+
- If not: This is a standalone analysis, scan the codebase root
|
|
19
|
+
|
|
20
|
+
### Step 2: Run Analysis Tools
|
|
21
|
+
|
|
22
|
+
Execute tools to gather insight data:
|
|
23
|
+
|
|
24
|
+
1. **Volatility Map** — `volatility-map` tool to find high-change areas (instability signals)
|
|
25
|
+
2. **Decision Trace** — `decision-trace` tool to find incomplete orTODO decisions
|
|
26
|
+
3. **Failure Replay** — `failure-replay` tool to find recurring failure patterns
|
|
27
|
+
4. **Codebase State** — `codebase-state` tool to get overall project structure
|
|
28
|
+
|
|
29
|
+
### Step 3: Scan for Gaps
|
|
30
|
+
|
|
31
|
+
Analyze the codebase structure to identify gaps:
|
|
32
|
+
|
|
33
|
+
- **Tools** — Are all tool categories covered? (planning, state, execution, analysis)
|
|
34
|
+
- **Hooks** — Are lifecycle hooks comprehensive?
|
|
35
|
+
- **Agents** — Are agent types sufficient for common tasks?
|
|
36
|
+
- **Skills** — Are there skill coverage gaps for major frameworks?
|
|
37
|
+
|
|
38
|
+
### Step 4: Generate Suggestions
|
|
39
|
+
|
|
40
|
+
For each valid suggestion (up to --limit), produce:
|
|
41
|
+
|
|
42
|
+
```
|
|
43
|
+
## Suggestion N: [Feature Name]
|
|
44
|
+
|
|
45
|
+
**Category:** tools|hooks|agents|skills
|
|
46
|
+
**Impact:** HIGH|MEDIUM|LOW
|
|
47
|
+
**Complexity:** HIGH|MEDIUM|LOW
|
|
48
|
+
|
|
49
|
+
### Problem Statement
|
|
50
|
+
[What issue this solves, with evidence from analysis]
|
|
51
|
+
|
|
52
|
+
### Proposed Solution
|
|
53
|
+
[Brief description of the approach]
|
|
54
|
+
|
|
55
|
+
### Implementation Steps
|
|
56
|
+
1. [Step with TDD approach - write test first]
|
|
57
|
+
2. [Step referencing existing patterns]
|
|
58
|
+
3. [Step with integration points]
|
|
59
|
+
|
|
60
|
+
### Files Affected
|
|
61
|
+
- `src/tools/xxx.ts` or `src/hooks/xxx.ts` or `src/agents/xxx.ts`
|
|
62
|
+
- `src/skills/xxx/SKILL.md` (if applicable)
|
|
63
|
+
- `docs/xxx.md` (if applicable)
|
|
64
|
+
|
|
65
|
+
### Integration
|
|
66
|
+
- How this connects to existing FlowDeck tools/agents
|
|
67
|
+
- Any new dependencies or configuration needed
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
### Step 5: Rank and Present
|
|
71
|
+
|
|
72
|
+
Sort suggestions by impact/complexity ratio (highest first).
|
|
73
|
+
|
|
74
|
+
Present:
|
|
75
|
+
```
|
|
76
|
+
# Feature Suggestions
|
|
77
|
+
|
|
78
|
+
Found N suggestions ranked by impact:
|
|
79
|
+
|
|
80
|
+
[Suggestions 1-N]
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
Run /fd-discuss [topic] to start a discussion on any suggestion.
|
|
84
|
+
```
|
|
@@ -0,0 +1,126 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Verify feature completion — run full test suite, reviewer, and deploy check against the current phase
|
|
3
|
+
argument-hint: [--phase=N] [--env=staging|production]
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Verify
|
|
7
|
+
|
|
8
|
+
Run the full verification pipeline for the current feature: tests, code review, and deploy check.
|
|
9
|
+
|
|
10
|
+
**Input:** $ARGUMENTS — optional `--phase=N` to target a specific phase, `--env` for deploy check environment
|
|
11
|
+
|
|
12
|
+
## Pre-flight
|
|
13
|
+
|
|
14
|
+
1. Check `.planning/STATE.md` exists — if not, error: "Run /fd-new-project first."
|
|
15
|
+
2. Read current phase N from STATE.md.
|
|
16
|
+
3. Confirm `steps_complete` in STATE.md is non-empty — if empty, warn: "No steps completed yet. Run /fd-execute first."
|
|
17
|
+
|
|
18
|
+
## Process
|
|
19
|
+
|
|
20
|
+
### Step 1: Gather Scope
|
|
21
|
+
|
|
22
|
+
Collect files changed in the current feature:
|
|
23
|
+
```bash
|
|
24
|
+
git diff --name-only HEAD
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
If no changed files, use all files in the current phase directory as scope.
|
|
28
|
+
|
|
29
|
+
### Step 2: Run Checks in Parallel
|
|
30
|
+
|
|
31
|
+
Launch all four checks simultaneously:
|
|
32
|
+
|
|
33
|
+
**Check A: Full Test Suite (@tester)**
|
|
34
|
+
```bash
|
|
35
|
+
npm test
|
|
36
|
+
```
|
|
37
|
+
All tests must pass. No failures, no unexplained skips.
|
|
38
|
+
|
|
39
|
+
**Check B: Code Review (@reviewer)**
|
|
40
|
+
Review all changed files:
|
|
41
|
+
- Security: secrets, injection vulnerabilities, auth gaps
|
|
42
|
+
- Quality: critical bugs, missing error handling, TDD discipline
|
|
43
|
+
- Conventions: naming, patterns, import style
|
|
44
|
+
- Test coverage >= 80% for changed files — flag as HIGH if below
|
|
45
|
+
|
|
46
|
+
**Check C: Security Scan (@security-auditor)**
|
|
47
|
+
- No hardcoded secrets
|
|
48
|
+
- Input validation at trust boundaries
|
|
49
|
+
- Auth/authz on all protected routes
|
|
50
|
+
- No CRITICAL or HIGH vulnerabilities
|
|
51
|
+
|
|
52
|
+
**Check D: Deploy Check**
|
|
53
|
+
Run pre-deployment suite:
|
|
54
|
+
```bash
|
|
55
|
+
npm audit --audit-level=high
|
|
56
|
+
npm run build
|
|
57
|
+
```
|
|
58
|
+
No HIGH/CRITICAL CVEs. Build must succeed.
|
|
59
|
+
|
|
60
|
+
### Step 3: Aggregate Results
|
|
61
|
+
|
|
62
|
+
Present consolidated report:
|
|
63
|
+
|
|
64
|
+
```
|
|
65
|
+
════════════════════════════════════════════════════
|
|
66
|
+
VERIFICATION: Phase <N> — <feature name>
|
|
67
|
+
════════════════════════════════════════════════════
|
|
68
|
+
|
|
69
|
+
| Check | Status | Details |
|
|
70
|
+
|---------------|------------------|----------------------|
|
|
71
|
+
| Tests | ✅ PASS / ❌ FAIL | N/N passed |
|
|
72
|
+
| Code Review | ✅ PASS / ❌ FAIL | [findings summary] |
|
|
73
|
+
| Security | ✅ PASS / ❌ FAIL | [findings summary] |
|
|
74
|
+
| CVE Audit | ✅ PASS / ❌ FAIL | [vulnerabilities] |
|
|
75
|
+
| Build | ✅ PASS / ❌ FAIL | [errors] |
|
|
76
|
+
|
|
77
|
+
────────────────────────────────────────────────────
|
|
78
|
+
Verdict: ✅ VERIFIED | ❌ NOT VERIFIED
|
|
79
|
+
════════════════════════════════════════════════════
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
### Step 4: Go / No-Go
|
|
83
|
+
|
|
84
|
+
**✅ VERIFIED** — all checks pass:
|
|
85
|
+
- Update STATE.md: set `status` to `verified`, `last_action` to `"Phase N verified"`
|
|
86
|
+
- Report next steps (deploy, increment phase, etc.)
|
|
87
|
+
|
|
88
|
+
**❌ NOT VERIFIED** — one or more checks failed:
|
|
89
|
+
```
|
|
90
|
+
Verdict: NOT VERIFIED
|
|
91
|
+
|
|
92
|
+
Required fixes:
|
|
93
|
+
- [ ] [fix 1]
|
|
94
|
+
- [ ] [fix 2]
|
|
95
|
+
|
|
96
|
+
Run /fd-verify again after fixing.
|
|
97
|
+
```
|
|
98
|
+
Do NOT update STATE.md to verified status.
|
|
99
|
+
|
|
100
|
+
## No-Go Conditions (automatic)
|
|
101
|
+
|
|
102
|
+
Any of these → automatic NOT VERIFIED:
|
|
103
|
+
- Test failures
|
|
104
|
+
- CRITICAL security vulnerability
|
|
105
|
+
- HIGH/CRITICAL CVE unpatched
|
|
106
|
+
- Build error
|
|
107
|
+
- Code review CRITICAL finding
|
|
108
|
+
|
|
109
|
+
## State Update on Success
|
|
110
|
+
|
|
111
|
+
```yaml
|
|
112
|
+
status: verified
|
|
113
|
+
last_action: "Phase N verified — all checks passed"
|
|
114
|
+
verified_at: "<timestamp>"
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
## Error Handling
|
|
118
|
+
|
|
119
|
+
- If `.planning/` not found: error "Run /fd-new-project first."
|
|
120
|
+
- If STATE.md not found: error "Project not initialized."
|
|
121
|
+
- If test runner not found: error with remediation (e.g., "No test script in package.json")
|
|
122
|
+
- No partial state update on error.
|
|
123
|
+
|
|
124
|
+
## Completion
|
|
125
|
+
|
|
126
|
+
Report: verification result, check statuses, any required fixes, and suggested next step.
|
|
@@ -15,7 +15,7 @@ FlowDeck provides 23 specialist agents. Each has a specific role. Using the righ
|
|
|
15
15
|
| `@discusser` | Extract requirements via Q&A | Starting a new feature or phase |
|
|
16
16
|
| `@doc-updater` | Update docs after code changes | After implementation completes |
|
|
17
17
|
| `@plan-checker` | Review PLAN.md before execution | Before executing any plan |
|
|
18
|
-
| `@mapper` | Map codebase to .codebase/ docs | Running /map-codebase |
|
|
18
|
+
| `@mapper` | Map codebase to .codebase/ docs | Running /fd-map-codebase |
|
|
19
19
|
| `@orchestrator` | Coordinate multi-agent execution | Managing a full feature delivery |
|
|
20
20
|
| `@parallel-coordinator` | Run parallel agent workstreams | When tasks can run simultaneously |
|
|
21
21
|
| `@performance-optimizer` | Profile and fix performance issues | When app is slow or before release |
|
|
@@ -76,9 +76,9 @@ discuss → plan → execute → review
|
|
|
76
76
|
|
|
77
77
|
| Phase | Agent | Command |
|
|
78
78
|
|-------|-------|---------|
|
|
79
|
-
| discuss | `@discusser` | `/discuss` |
|
|
80
|
-
| plan | `@planner` → `@plan-checker` | `/plan` |
|
|
81
|
-
| execute | `@orchestrator` → `@coder`, `@tester`, etc. | `/new-feature` |
|
|
82
|
-
| review | `@reviewer` + `@security-auditor` | `/review-code` |
|
|
79
|
+
| discuss | `@discusser` | `/fd-discuss` |
|
|
80
|
+
| plan | `@planner` → `@plan-checker` | `/fd-plan` |
|
|
81
|
+
| execute | `@orchestrator` → `@coder`, `@tester`, etc. | `/fd-new-feature` |
|
|
82
|
+
| review | `@reviewer` + `@security-auditor` | `/fd-review-code` |
|
|
83
83
|
|
|
84
84
|
Do not skip phases. The orchestrator enforces phase gating automatically.
|
|
@@ -2,6 +2,23 @@
|
|
|
2
2
|
|
|
3
3
|
Language-agnostic coding conventions followed by all FlowDeck agents.
|
|
4
4
|
|
|
5
|
+
## Core Principles
|
|
6
|
+
|
|
7
|
+
| # | Rule | Description |
|
|
8
|
+
|---|------|-------------|
|
|
9
|
+
| 1 | **No Redundant Code** | No redundant arguments, methods, or attributes. Each piece of code must serve a purpose. |
|
|
10
|
+
| 2 | **Simplicity** | Code should be simple and easy to understand. Prefer clarity over cleverness. |
|
|
11
|
+
| 3 | **Clear Commands** | Code should have clear, explicit commands. No ambiguity in intent. |
|
|
12
|
+
| 4 | **Extensibility** | Code must be easily extendable. Design for growth, not just current needs. |
|
|
13
|
+
| 5 | **Documentation** | Code must have clear documentation at the beginning of every file. |
|
|
14
|
+
| 6 | **Information Security** | Comply with information security best practices. No secrets, no injections, no XSS. |
|
|
15
|
+
| 7 | **Memory Optimization** | Optimize memory usage to the minimum possible. Avoid unnecessary allocations. |
|
|
16
|
+
| 8 | **Speed** | Process speed should be as fast as possible. Prefer efficient algorithms and data structures. |
|
|
17
|
+
| 9 | **Single Responsibility** | Each function/class does one thing well. Easier to test, debug, and extend. |
|
|
18
|
+
| 10 | **Testability** | Code should be easy to test in isolation. Avoid hidden dependencies and global state. |
|
|
19
|
+
| 11 | **Consistency** | Follow existing patterns in the codebase. Consistency over personal preference. |
|
|
20
|
+
| 12 | **Resource Cleanup** | Always release resources (connections, file handles, timers). Use try-finally or defer. |
|
|
21
|
+
|
|
5
22
|
## Immutability
|
|
6
23
|
|
|
7
24
|
Always create new objects and arrays. Never mutate parameters.
|