superkit-mcp-server 1.2.2 → 1.2.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/ARCHITECTURE.md +102 -102
- package/README.md +71 -71
- package/SUPERKIT.md +168 -168
- package/agents/code-archaeologist.md +106 -106
- package/agents/coder.md +90 -90
- package/agents/data-engineer.md +28 -28
- package/agents/devops-engineer.md +242 -242
- package/agents/git-manager.md +203 -203
- package/agents/orchestrator.md +420 -420
- package/agents/penetration-tester.md +188 -188
- package/agents/performance-optimizer.md +187 -187
- package/agents/planner.md +270 -270
- package/agents/qa-automation-engineer.md +103 -103
- package/agents/quant-developer.md +32 -32
- package/agents/reviewer.md +100 -100
- package/agents/scout.md +222 -222
- package/agents/security-auditor.md +3 -2
- package/agents/tester.md +274 -274
- package/agents/ui-designer.md +208 -208
- package/build/index.js +18 -9
- package/build/tools/__tests__/loggerTools.test.js +5 -5
- package/build/tools/archTools.js +2 -19
- package/build/tools/autoPreview.js +2 -2
- package/build/tools/compoundTools.js +4 -4
- package/build/tools/docsTools.js +5 -10
- package/build/tools/loggerTools.js +1 -1
- package/build/tools/todoTools.js +39 -39
- package/build/tools/validators/__tests__/apiSchema.test.js +23 -23
- package/build/tools/validators/__tests__/convertRules.test.js +5 -5
- package/build/tools/validators/__tests__/frontendDesign.test.js +12 -12
- package/build/tools/validators/__tests__/geoChecker.test.js +19 -19
- package/build/tools/validators/__tests__/mobileAudit.test.js +12 -12
- package/build/tools/validators/__tests__/reactPerformanceChecker.test.js +17 -17
- package/build/tools/validators/__tests__/securityScan.test.js +6 -6
- package/build/tools/validators/__tests__/seoChecker.test.js +16 -16
- package/build/tools/validators/__tests__/typeCoverage.test.js +14 -14
- package/build/tools/validators/convertRules.js +2 -2
- package/commands/README.md +122 -122
- package/commands/ask.toml +72 -72
- package/commands/brainstorm.toml +119 -119
- package/commands/chat.toml +77 -77
- package/commands/code-preview.toml +37 -37
- package/commands/code.toml +28 -28
- package/commands/content.toml +200 -200
- package/commands/cook.toml +77 -77
- package/commands/copywrite.toml +131 -131
- package/commands/db.toml +192 -192
- package/commands/debug.toml +166 -166
- package/commands/design.toml +158 -158
- package/commands/dev-rules.toml +14 -14
- package/commands/do.toml +117 -117
- package/commands/doc-rules.toml +14 -14
- package/commands/docs.toml +148 -148
- package/commands/fix.toml +440 -440
- package/commands/fullstack.toml +175 -175
- package/commands/git.toml +235 -235
- package/commands/help.toml +84 -84
- package/commands/integrate.toml +127 -127
- package/commands/journal.toml +136 -136
- package/commands/kit-setup.toml +40 -40
- package/commands/mcp.toml +183 -183
- package/commands/orchestration.toml +15 -15
- package/commands/plan.toml +171 -171
- package/commands/pm.toml +148 -148
- package/commands/pr.toml +50 -50
- package/commands/project.toml +32 -32
- package/commands/research.toml +117 -117
- package/commands/review-pr.toml +63 -63
- package/commands/review.toml +190 -190
- package/commands/scout-ext.toml +97 -97
- package/commands/scout.toml +79 -79
- package/commands/screenshot.toml +65 -65
- package/commands/session.toml +102 -102
- package/commands/skill.toml +384 -384
- package/commands/status.toml +22 -22
- package/commands/team.toml +56 -56
- package/commands/test.toml +164 -164
- package/commands/ticket.toml +70 -70
- package/commands/use.toml +106 -106
- package/commands/video.toml +83 -83
- package/commands/watzup.toml +71 -71
- package/commands/workflow.toml +14 -14
- package/package.json +35 -35
- package/skills/meta/README.md +30 -30
- package/skills/meta/api-design/SKILL.md +134 -134
- package/skills/meta/code-review/SKILL.md +44 -44
- package/skills/meta/code-review/checklists/pre-merge.md +25 -25
- package/skills/meta/code-review/workflows/architecture-pass.md +26 -26
- package/skills/meta/code-review/workflows/performance-pass.md +27 -27
- package/skills/meta/code-review/workflows/security-pass.md +29 -29
- package/skills/meta/compound-docs/SKILL.md +133 -133
- package/skills/meta/debug/SKILL.md +40 -40
- package/skills/meta/debug/templates/bug-report.template.md +31 -31
- package/skills/meta/debug/workflows/reproduce-issue.md +20 -20
- package/skills/meta/docker/SKILL.md +126 -126
- package/skills/meta/examples/supabase/SKILL.md +46 -46
- package/skills/meta/examples/supabase/references/best-practices.md +319 -319
- package/skills/meta/examples/supabase/references/common-patterns.md +373 -373
- package/skills/meta/examples/supabase/templates/migration-template.sql +49 -49
- package/skills/meta/examples/supabase/templates/rls-policy-template.sql +77 -77
- package/skills/meta/examples/supabase/workflows/debugging.md +260 -260
- package/skills/meta/examples/supabase/workflows/migration-workflow.md +211 -211
- package/skills/meta/examples/supabase/workflows/rls-policies.md +244 -244
- package/skills/meta/examples/supabase/workflows/schema-design.md +321 -321
- package/skills/meta/file-todos/SKILL.md +88 -88
- package/skills/meta/mobile/SKILL.md +140 -140
- package/skills/meta/nextjs/SKILL.md +101 -101
- package/skills/meta/performance/SKILL.md +130 -130
- package/skills/meta/react-patterns/SKILL.md +83 -83
- package/skills/meta/security/SKILL.md +114 -114
- package/skills/meta/session-resume/SKILL.md +96 -96
- package/skills/meta/tailwind/SKILL.md +139 -139
- package/skills/meta/testing/SKILL.md +43 -43
- package/skills/meta/testing/references/vitest-patterns.md +45 -45
- package/skills/meta/testing/templates/component-test.template.tsx +37 -37
- package/skills/tech/alpha-vantage/SKILL.md +142 -142
- package/skills/tech/alpha-vantage/references/commodities.md +153 -153
- package/skills/tech/alpha-vantage/references/economic-indicators.md +158 -158
- package/skills/tech/alpha-vantage/references/forex-crypto.md +154 -154
- package/skills/tech/alpha-vantage/references/fundamentals.md +223 -223
- package/skills/tech/alpha-vantage/references/intelligence.md +138 -138
- package/skills/tech/alpha-vantage/references/options.md +93 -93
- package/skills/tech/alpha-vantage/references/technical-indicators.md +374 -374
- package/skills/tech/alpha-vantage/references/time-series.md +157 -157
- package/skills/tech/doc.md +6 -6
- package/skills/tech/financial-modeling/SKILL.md +18 -18
- package/skills/tech/financial-modeling/skills/3-statements/SKILL.md +368 -368
- package/skills/tech/financial-modeling/skills/3-statements/references/formatting.md +118 -118
- package/skills/tech/financial-modeling/skills/3-statements/references/formulas.md +292 -292
- package/skills/tech/financial-modeling/skills/3-statements/references/sec-filings.md +125 -125
- package/skills/tech/financial-modeling/skills/dcf-model/SKILL.md +1210 -1210
- package/skills/tech/financial-modeling/skills/dcf-model/TROUBLESHOOTING.md +40 -40
- package/skills/tech/financial-modeling/skills/dcf-model/requirements.txt +8 -8
- package/skills/tech/financial-modeling/skills/dcf-model/scripts/validate_dcf.py +292 -292
- package/skills/tech/financial-modeling/skills/lbo-model/SKILL.md +236 -236
- package/skills/tech/financial-modeling/skills/merger-model/SKILL.md +108 -108
- package/skills/workflows/README.md +203 -203
- package/skills/workflows/adr.md +174 -174
- package/skills/workflows/changelog.md +74 -74
- package/skills/workflows/compound.md +323 -323
- package/skills/workflows/compound_health.md +74 -74
- package/skills/workflows/create-agent-skill.md +138 -139
- package/skills/workflows/cycle.md +144 -144
- package/skills/workflows/deploy-docs.md +84 -84
- package/skills/workflows/development-rules.md +42 -42
- package/skills/workflows/doc.md +95 -95
- package/skills/workflows/documentation-management.md +34 -34
- package/skills/workflows/explore.md +146 -146
- package/skills/workflows/generate_command.md +106 -106
- package/skills/workflows/heal-skill.md +97 -97
- package/skills/workflows/housekeeping.md +229 -229
- package/skills/workflows/kit-setup.md +102 -102
- package/skills/workflows/map-codebase.md +78 -78
- package/skills/workflows/orchestration-protocol.md +43 -43
- package/skills/workflows/plan-compound.md +439 -439
- package/skills/workflows/plan_review.md +269 -269
- package/skills/workflows/primary-workflow.md +37 -37
- package/skills/workflows/promote_pattern.md +86 -86
- package/skills/workflows/release-docs.md +82 -82
- package/skills/workflows/report-bug.md +135 -135
- package/skills/workflows/reproduce-bug.md +118 -118
- package/skills/workflows/resolve_pr.md +133 -133
- package/skills/workflows/resolve_todo.md +128 -128
- package/skills/workflows/review-compound.md +376 -376
- package/skills/workflows/skill-review.md +127 -127
- package/skills/workflows/specs.md +257 -257
- package/skills/workflows/triage-sprint.md +102 -102
- package/skills/workflows/triage.md +152 -152
- package/skills/workflows/work.md +399 -399
- package/skills/workflows/xcode-test.md +93 -93
|
@@ -1,269 +1,269 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Review implementation plans for quality and completeness. Use before starting work on a plan.
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# /plan_review - Plan Quality Review
|
|
6
|
-
|
|
7
|
-
Review an implementation plan for completeness and quality before execution.
|
|
8
|
-
|
|
9
|
-
> **Why review plans?** A flawed plan leads to wasted effort. 10 minutes of review can save hours of rework.
|
|
10
|
-
|
|
11
|
-
## When To Use
|
|
12
|
-
|
|
13
|
-
- Before starting `/work` on any plan
|
|
14
|
-
- When inheriting a plan from another session
|
|
15
|
-
- For self-review of your own plans
|
|
16
|
-
- Reviewing a specification from `/specs`
|
|
17
|
-
|
|
18
|
-
---
|
|
19
|
-
|
|
20
|
-
## Workflow
|
|
21
|
-
|
|
22
|
-
### Step 0: Search for Existing Solutions
|
|
23
|
-
|
|
24
|
-
> [!CAUTION]
|
|
25
|
-
> **BLOCKING STEP.** Before reviewing the plan's approach, verify we're not reinventing the wheel.
|
|
26
|
-
|
|
27
|
-
```bash
|
|
28
|
-
// turbo
|
|
29
|
-
Call MCP `call_tool_logger_manager` { action: "logWorkflow", name: "/plan_review", outcome: "success" }
|
|
30
|
-
Call MCP `call_tool_compound_manager` { action: "search", terms: [ "{main problem keywords}"] }
|
|
31
|
-
Call MCP `call_tool_logger_manager` { action: "logSkill", name: "compound-docs", outcome: "workflow" }
|
|
32
|
-
```
|
|
33
|
-
|
|
34
|
-
**See also:** `skills/compound-docs/SKILL.md` for cross-referencing findings.
|
|
35
|
-
|
|
36
|
-
**If solutions found:**
|
|
37
|
-
1. Cross-reference with the plan's approach — are we reinventing?
|
|
38
|
-
2. Update references if the plan should use existing solutions:
|
|
39
|
-
```bash
|
|
40
|
-
// turbo
|
|
41
|
-
Call MCP `call_tool_compound_manager` { action: "updateRef", files: ["{paths}"] }
|
|
42
|
-
```
|
|
43
|
-
|
|
44
|
-
#### ⛔ CHECKPOINT: Did the plan author run compound-search?
|
|
45
|
-
|
|
46
|
-
- [ ] Plan includes "## Prior Solutions" section (or explicitly states "none found")?
|
|
47
|
-
- [ ] If existing solutions apply, are they referenced in the approach?
|
|
48
|
-
|
|
49
|
-
**Flag missing compound search as a review concern.**
|
|
50
|
-
|
|
51
|
-
---
|
|
52
|
-
|
|
53
|
-
### Step 1: Load Plan
|
|
54
|
-
|
|
55
|
-
Read the plan file and understand the scope:
|
|
56
|
-
|
|
57
|
-
```bash
|
|
58
|
-
cat plans/{plan-name}.md
|
|
59
|
-
```
|
|
60
|
-
|
|
61
|
-
---
|
|
62
|
-
|
|
63
|
-
### Step 2: Check Completeness
|
|
64
|
-
|
|
65
|
-
**Requirements:**
|
|
66
|
-
- [ ] Problem statement clear and specific
|
|
67
|
-
- [ ] Success criteria defined and measurable
|
|
68
|
-
- [ ] Scope boundaries explicit (what's in/out)
|
|
69
|
-
|
|
70
|
-
**Research:**
|
|
71
|
-
- [ ] Codebase patterns referenced
|
|
72
|
-
- [ ] Best practices cited or linked
|
|
73
|
-
- [ ] Alternatives considered and rejected with reasons
|
|
74
|
-
|
|
75
|
-
**Implementation:**
|
|
76
|
-
- [ ] Steps actionable (not vague)
|
|
77
|
-
- [ ] Dependencies identified
|
|
78
|
-
- [ ] Risks acknowledged with mitigations
|
|
79
|
-
|
|
80
|
-
**Lifecycle:**
|
|
81
|
-
- [ ] Verification plan included
|
|
82
|
-
- [ ] Related specs/todos referenced (if any)
|
|
83
|
-
|
|
84
|
-
---
|
|
85
|
-
|
|
86
|
-
### Step 2.5: Spec-Specific Checks (If Reviewing a Spec)
|
|
87
|
-
|
|
88
|
-
**If verifying a `docs/specs/` document:**
|
|
89
|
-
- [ ] Phases have clear exit criteria in `03-tasks.md`
|
|
90
|
-
- [ ] `00-START-HERE.md` restores context in <2 minutes
|
|
91
|
-
- [ ] `04-decisions.md` initialized (even if empty)
|
|
92
|
-
- [ ] `README.md` dashboard accurately reflects current status
|
|
93
|
-
|
|
94
|
-
---
|
|
95
|
-
|
|
96
|
-
### Step 3: Deep Gap Analysis
|
|
97
|
-
|
|
98
|
-
> [!CAUTION]
|
|
99
|
-
> This step requires deliberate, slow thinking. Question everything.
|
|
100
|
-
|
|
101
|
-
**Did the plan think hard enough?**
|
|
102
|
-
- [ ] Are 2nd-4th order effects considered?
|
|
103
|
-
- [ ] Are long-term implications (6mo, 1yr) addressed?
|
|
104
|
-
- [ ] Is the approach reversible if assumptions are wrong?
|
|
105
|
-
|
|
106
|
-
**Edge Case Coverage (Leave No Stone Unturned):**
|
|
107
|
-
- [ ] Boundary conditions (min, max, at-limit)
|
|
108
|
-
- [ ] Failure modes (network, DB, external services)
|
|
109
|
-
- [ ] Concurrent access / race conditions
|
|
110
|
-
- [ ] Data extremes and migration scenarios
|
|
111
|
-
- [ ] User behavior edge cases
|
|
112
|
-
|
|
113
|
-
**Security & Privacy Analysis (@mcp:superkit):**
|
|
114
|
-
- [ ] Does the plan introduce potential Injection, Broken Access Control, or Privilege Escalation flaws?
|
|
115
|
-
- [ ] Are Privacy Sources (e.g. PII) routed properly and sanitized before reaching Privacy Sinks?
|
|
116
|
-
- [ ] Execute security review prompts/checks utilizing `@mcp:superkit` for architectural security validation.
|
|
117
|
-
|
|
118
|
-
**Reproducibility and Transparency (Scientific Review):**
|
|
119
|
-
- [ ] **Data/State Availability:** Are initial states, dummy data, or prerequisites clearly defined?
|
|
120
|
-
- [ ] **Methodological Detail:** Could an independent agent perfectly execute this plan without asking you clarifying questions?
|
|
121
|
-
- [ ] **Reporting Standards:** Does the plan link to specific codebase conventions (e.g. `CONVENTIONS.md`)?
|
|
122
|
-
|
|
123
|
-
**Stakeholder Impact (Who else is affected?):**
|
|
124
|
-
- [ ] End users notified of behavior changes?
|
|
125
|
-
- [ ] Breaking changes communicated to other devs?
|
|
126
|
-
- [ ] Ops/support aware of new failure modes?
|
|
127
|
-
- [ ] Downstream integrations considered?
|
|
128
|
-
|
|
129
|
-
**Standard Gap Checks:**
|
|
130
|
-
- [ ] Missing dependencies
|
|
131
|
-
- [ ] Unclear requirements / unstated assumptions
|
|
132
|
-
- [ ] **Missing compound solutions** (did we search before planning?)
|
|
133
|
-
|
|
134
|
-
---
|
|
135
|
-
|
|
136
|
-
### Step 4: Provide Feedback
|
|
137
|
-
|
|
138
|
-
Maintain a constructive, objective, and professional tone (Scientific Peer Review Standard):
|
|
139
|
-
- **Be constructive:** Frame criticism as opportunities for improvement.
|
|
140
|
-
- **Be specific:** Provide concrete examples and actionable suggestions.
|
|
141
|
-
- **Be balanced:** Acknowledge strengths as well as weaknesses.
|
|
142
|
-
|
|
143
|
-
```markdown
|
|
144
|
-
## Plan Review: {Plan Name}
|
|
145
|
-
|
|
146
|
-
### Summary Statement
|
|
147
|
-
- {Brief synopsis of the plan and bottom-line assessment of soundness}
|
|
148
|
-
|
|
149
|
-
### Strengths
|
|
150
|
-
- {What's good about the plan}
|
|
151
|
-
|
|
152
|
-
### Major Concerns (Critical)
|
|
153
|
-
- {Issues that fundamentally break the plan or block reproducibility}
|
|
154
|
-
|
|
155
|
-
### Minor Suggestions (Improvements)
|
|
156
|
-
- {Improvements to consider}
|
|
157
|
-
|
|
158
|
-
### Questions for Author
|
|
159
|
-
- {Clarifications needed before execution}
|
|
160
|
-
|
|
161
|
-
### Existing Solutions Referenced
|
|
162
|
-
- {Any solutions from docs/solutions/ that apply}
|
|
163
|
-
|
|
164
|
-
### Verdict
|
|
165
|
-
- [ ] Ready to execute
|
|
166
|
-
- [ ] Needs minor revisions
|
|
167
|
-
- [ ] Needs major revisions
|
|
168
|
-
```
|
|
169
|
-
|
|
170
|
-
---
|
|
171
|
-
|
|
172
|
-
### Step 5: Update Plan Status
|
|
173
|
-
|
|
174
|
-
If approved, update the plan:
|
|
175
|
-
|
|
176
|
-
```markdown
|
|
177
|
-
> Status: Completed ✓
|
|
178
|
-
```
|
|
179
|
-
|
|
180
|
-
---
|
|
181
|
-
|
|
182
|
-
### Step 6: Proceed to Execution (If Approved)
|
|
183
|
-
|
|
184
|
-
Once the plan is approved and the status is updated:
|
|
185
|
-
|
|
186
|
-
> [!IMPORTANT]
|
|
187
|
-
> **Workflow Transition**
|
|
188
|
-
> Do not execute the plan ad-hoc. Transition immediately to the **/work** workflow.
|
|
189
|
-
|
|
190
|
-
```bash
|
|
191
|
-
# Start the work workflow
|
|
192
|
-
/work
|
|
193
|
-
```
|
|
194
|
-
|
|
195
|
-
---
|
|
196
|
-
|
|
197
|
-
### Step 7: Create Revision Todo (CONDITIONAL)
|
|
198
|
-
|
|
199
|
-
**If Verdict is "Needs major revisions":**
|
|
200
|
-
|
|
201
|
-
> [!CAUTION]
|
|
202
|
-
> **Action Required.** Don't just leave feedback in the chat. Create a todo for the revision work.
|
|
203
|
-
|
|
204
|
-
```bash
|
|
205
|
-
Call MCP `call_tool_todo_manager` { action: "create", priority: "p1", title: "Revise Plan: ${plan_name}", description: "TODO description" }
|
|
206
|
-
"Plan review identified major issues in plans/${plan_name}.md that need to be addressed before execution can proceed.\n\nConcerns:\n(Paste summary of concerns here)" \
|
|
207
|
-
"Revise plan to address concerns" \
|
|
208
|
-
"Re-request review"
|
|
209
|
-
```
|
|
210
|
-
|
|
211
|
-
---
|
|
212
|
-
|
|
213
|
-
### Phase 5: Completion & Handoff
|
|
214
|
-
|
|
215
|
-
#### Step 1: Establish Terminal UI State
|
|
216
|
-
|
|
217
|
-
> [!IMPORTANT]
|
|
218
|
-
> **Visual Completion Signal**
|
|
219
|
-
> Call `task_boundary` one last time to signal completion in the user's UI. This prevents the "task" from appearing active after you've finished.
|
|
220
|
-
|
|
221
|
-
```javascript
|
|
222
|
-
await task_boundary({
|
|
223
|
-
TaskName: "[COMPLETED] Plan Review: {Plan Name}",
|
|
224
|
-
TaskStatus: "Review complete. Offering next steps.",
|
|
225
|
-
Mode: "VERIFICATION",
|
|
226
|
-
TaskSummary: "Completed plan review for {plan name}. Verdict: {Ready/Needs Revisions}. {Key findings summary}."
|
|
227
|
-
});
|
|
228
|
-
```
|
|
229
|
-
|
|
230
|
-
#### Step 2: Mandatory Handoff
|
|
231
|
-
|
|
232
|
-
> [!IMPORTANT]
|
|
233
|
-
> **Exit Transition**
|
|
234
|
-
> Do not stop here. Offer the user clear paths to the next logical workflow.
|
|
235
|
-
|
|
236
|
-
```bash
|
|
237
|
-
✓ Review complete
|
|
238
|
-
|
|
239
|
-
Next steps:
|
|
240
|
-
1. /work - Execute the approved plan (if verdict: Ready)
|
|
241
|
-
2. Revise plan - Address review concerns (if verdict: Needs Revisions)
|
|
242
|
-
3. /specs - Elevate to specification if scope expanded during review
|
|
243
|
-
4. Create revision todo - For major revision tracking
|
|
244
|
-
```
|
|
245
|
-
|
|
246
|
-
---
|
|
247
|
-
|
|
248
|
-
## Quality Guidelines
|
|
249
|
-
|
|
250
|
-
**Good reviews:**
|
|
251
|
-
- ✅ Check compound solutions first
|
|
252
|
-
- ✅ Verify measurable success criteria
|
|
253
|
-
- ✅ Confirm scope boundaries
|
|
254
|
-
- ✅ Validate risks are acknowledged
|
|
255
|
-
|
|
256
|
-
**Avoid:**
|
|
257
|
-
- ❌ Rubber-stamping without reading
|
|
258
|
-
- ❌ Skipping compound search
|
|
259
|
-
- ❌ Ignoring missing success criteria
|
|
260
|
-
|
|
261
|
-
---
|
|
262
|
-
|
|
263
|
-
## References
|
|
264
|
-
|
|
265
|
-
- Create plans: `/plan`
|
|
266
|
-
- Execute plans: `/work`
|
|
267
|
-
- Search solutions: `Call MCP `call_tool_compound_manager` { action: "search", terms: [] }`
|
|
268
|
-
- Archive when done: `/housekeeping`
|
|
269
|
-
|
|
1
|
+
---
|
|
2
|
+
description: Review implementation plans for quality and completeness. Use before starting work on a plan.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /plan_review - Plan Quality Review
|
|
6
|
+
|
|
7
|
+
Review an implementation plan for completeness and quality before execution.
|
|
8
|
+
|
|
9
|
+
> **Why review plans?** A flawed plan leads to wasted effort. 10 minutes of review can save hours of rework.
|
|
10
|
+
|
|
11
|
+
## When To Use
|
|
12
|
+
|
|
13
|
+
- Before starting `/work` on any plan
|
|
14
|
+
- When inheriting a plan from another session
|
|
15
|
+
- For self-review of your own plans
|
|
16
|
+
- Reviewing a specification from `/specs`
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## Workflow
|
|
21
|
+
|
|
22
|
+
### Step 0: Search for Existing Solutions
|
|
23
|
+
|
|
24
|
+
> [!CAUTION]
|
|
25
|
+
> **BLOCKING STEP.** Before reviewing the plan's approach, verify we're not reinventing the wheel.
|
|
26
|
+
|
|
27
|
+
```bash
|
|
28
|
+
// turbo
|
|
29
|
+
Call MCP `call_tool_logger_manager` { action: "logWorkflow", name: "/plan_review", outcome: "success" }
|
|
30
|
+
Call MCP `call_tool_compound_manager` { action: "search", terms: [ "{main problem keywords}"] }
|
|
31
|
+
Call MCP `call_tool_logger_manager` { action: "logSkill", name: "compound-docs", outcome: "workflow" }
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
**See also:** `skills/compound-docs/SKILL.md` for cross-referencing findings.
|
|
35
|
+
|
|
36
|
+
**If solutions found:**
|
|
37
|
+
1. Cross-reference with the plan's approach — are we reinventing?
|
|
38
|
+
2. Update references if the plan should use existing solutions:
|
|
39
|
+
```bash
|
|
40
|
+
// turbo
|
|
41
|
+
Call MCP `call_tool_compound_manager` { action: "updateRef", files: ["{paths}"] }
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
#### ⛔ CHECKPOINT: Did the plan author run compound-search?
|
|
45
|
+
|
|
46
|
+
- [ ] Plan includes "## Prior Solutions" section (or explicitly states "none found")?
|
|
47
|
+
- [ ] If existing solutions apply, are they referenced in the approach?
|
|
48
|
+
|
|
49
|
+
**Flag missing compound search as a review concern.**
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
### Step 1: Load Plan
|
|
54
|
+
|
|
55
|
+
Read the plan file and understand the scope:
|
|
56
|
+
|
|
57
|
+
```bash
|
|
58
|
+
cat plans/{plan-name}.md
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
### Step 2: Check Completeness
|
|
64
|
+
|
|
65
|
+
**Requirements:**
|
|
66
|
+
- [ ] Problem statement clear and specific
|
|
67
|
+
- [ ] Success criteria defined and measurable
|
|
68
|
+
- [ ] Scope boundaries explicit (what's in/out)
|
|
69
|
+
|
|
70
|
+
**Research:**
|
|
71
|
+
- [ ] Codebase patterns referenced
|
|
72
|
+
- [ ] Best practices cited or linked
|
|
73
|
+
- [ ] Alternatives considered and rejected with reasons
|
|
74
|
+
|
|
75
|
+
**Implementation:**
|
|
76
|
+
- [ ] Steps actionable (not vague)
|
|
77
|
+
- [ ] Dependencies identified
|
|
78
|
+
- [ ] Risks acknowledged with mitigations
|
|
79
|
+
|
|
80
|
+
**Lifecycle:**
|
|
81
|
+
- [ ] Verification plan included
|
|
82
|
+
- [ ] Related specs/todos referenced (if any)
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
### Step 2.5: Spec-Specific Checks (If Reviewing a Spec)
|
|
87
|
+
|
|
88
|
+
**If verifying a `docs/specs/` document:**
|
|
89
|
+
- [ ] Phases have clear exit criteria in `03-tasks.md`
|
|
90
|
+
- [ ] `00-START-HERE.md` restores context in <2 minutes
|
|
91
|
+
- [ ] `04-decisions.md` initialized (even if empty)
|
|
92
|
+
- [ ] `README.md` dashboard accurately reflects current status
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
### Step 3: Deep Gap Analysis
|
|
97
|
+
|
|
98
|
+
> [!CAUTION]
|
|
99
|
+
> This step requires deliberate, slow thinking. Question everything.
|
|
100
|
+
|
|
101
|
+
**Did the plan think hard enough?**
|
|
102
|
+
- [ ] Are 2nd-4th order effects considered?
|
|
103
|
+
- [ ] Are long-term implications (6mo, 1yr) addressed?
|
|
104
|
+
- [ ] Is the approach reversible if assumptions are wrong?
|
|
105
|
+
|
|
106
|
+
**Edge Case Coverage (Leave No Stone Unturned):**
|
|
107
|
+
- [ ] Boundary conditions (min, max, at-limit)
|
|
108
|
+
- [ ] Failure modes (network, DB, external services)
|
|
109
|
+
- [ ] Concurrent access / race conditions
|
|
110
|
+
- [ ] Data extremes and migration scenarios
|
|
111
|
+
- [ ] User behavior edge cases
|
|
112
|
+
|
|
113
|
+
**Security & Privacy Analysis (@mcp:superkit):**
|
|
114
|
+
- [ ] Does the plan introduce potential Injection, Broken Access Control, or Privilege Escalation flaws?
|
|
115
|
+
- [ ] Are Privacy Sources (e.g. PII) routed properly and sanitized before reaching Privacy Sinks?
|
|
116
|
+
- [ ] Execute security review prompts/checks utilizing `@mcp:superkit` for architectural security validation.
|
|
117
|
+
|
|
118
|
+
**Reproducibility and Transparency (Scientific Review):**
|
|
119
|
+
- [ ] **Data/State Availability:** Are initial states, dummy data, or prerequisites clearly defined?
|
|
120
|
+
- [ ] **Methodological Detail:** Could an independent agent perfectly execute this plan without asking you clarifying questions?
|
|
121
|
+
- [ ] **Reporting Standards:** Does the plan link to specific codebase conventions (e.g. `CONVENTIONS.md`)?
|
|
122
|
+
|
|
123
|
+
**Stakeholder Impact (Who else is affected?):**
|
|
124
|
+
- [ ] End users notified of behavior changes?
|
|
125
|
+
- [ ] Breaking changes communicated to other devs?
|
|
126
|
+
- [ ] Ops/support aware of new failure modes?
|
|
127
|
+
- [ ] Downstream integrations considered?
|
|
128
|
+
|
|
129
|
+
**Standard Gap Checks:**
|
|
130
|
+
- [ ] Missing dependencies
|
|
131
|
+
- [ ] Unclear requirements / unstated assumptions
|
|
132
|
+
- [ ] **Missing compound solutions** (did we search before planning?)
|
|
133
|
+
|
|
134
|
+
---
|
|
135
|
+
|
|
136
|
+
### Step 4: Provide Feedback
|
|
137
|
+
|
|
138
|
+
Maintain a constructive, objective, and professional tone (Scientific Peer Review Standard):
|
|
139
|
+
- **Be constructive:** Frame criticism as opportunities for improvement.
|
|
140
|
+
- **Be specific:** Provide concrete examples and actionable suggestions.
|
|
141
|
+
- **Be balanced:** Acknowledge strengths as well as weaknesses.
|
|
142
|
+
|
|
143
|
+
```markdown
|
|
144
|
+
## Plan Review: {Plan Name}
|
|
145
|
+
|
|
146
|
+
### Summary Statement
|
|
147
|
+
- {Brief synopsis of the plan and bottom-line assessment of soundness}
|
|
148
|
+
|
|
149
|
+
### Strengths
|
|
150
|
+
- {What's good about the plan}
|
|
151
|
+
|
|
152
|
+
### Major Concerns (Critical)
|
|
153
|
+
- {Issues that fundamentally break the plan or block reproducibility}
|
|
154
|
+
|
|
155
|
+
### Minor Suggestions (Improvements)
|
|
156
|
+
- {Improvements to consider}
|
|
157
|
+
|
|
158
|
+
### Questions for Author
|
|
159
|
+
- {Clarifications needed before execution}
|
|
160
|
+
|
|
161
|
+
### Existing Solutions Referenced
|
|
162
|
+
- {Any solutions from docs/solutions/ that apply}
|
|
163
|
+
|
|
164
|
+
### Verdict
|
|
165
|
+
- [ ] Ready to execute
|
|
166
|
+
- [ ] Needs minor revisions
|
|
167
|
+
- [ ] Needs major revisions
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
---
|
|
171
|
+
|
|
172
|
+
### Step 5: Update Plan Status
|
|
173
|
+
|
|
174
|
+
If approved, update the plan:
|
|
175
|
+
|
|
176
|
+
```markdown
|
|
177
|
+
> Status: Completed ✓
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
---
|
|
181
|
+
|
|
182
|
+
### Step 6: Proceed to Execution (If Approved)
|
|
183
|
+
|
|
184
|
+
Once the plan is approved and the status is updated:
|
|
185
|
+
|
|
186
|
+
> [!IMPORTANT]
|
|
187
|
+
> **Workflow Transition**
|
|
188
|
+
> Do not execute the plan ad-hoc. Transition immediately to the **/work** workflow.
|
|
189
|
+
|
|
190
|
+
```bash
|
|
191
|
+
# Start the work workflow
|
|
192
|
+
/work
|
|
193
|
+
```
|
|
194
|
+
|
|
195
|
+
---
|
|
196
|
+
|
|
197
|
+
### Step 7: Create Revision Todo (CONDITIONAL)
|
|
198
|
+
|
|
199
|
+
**If Verdict is "Needs major revisions":**
|
|
200
|
+
|
|
201
|
+
> [!CAUTION]
|
|
202
|
+
> **Action Required.** Don't just leave feedback in the chat. Create a todo for the revision work.
|
|
203
|
+
|
|
204
|
+
```bash
|
|
205
|
+
Call MCP `call_tool_todo_manager` { action: "create", priority: "p1", title: "Revise Plan: ${plan_name}", description: "TODO description" }
|
|
206
|
+
"Plan review identified major issues in plans/${plan_name}.md that need to be addressed before execution can proceed.\n\nConcerns:\n(Paste summary of concerns here)" \
|
|
207
|
+
"Revise plan to address concerns" \
|
|
208
|
+
"Re-request review"
|
|
209
|
+
```
|
|
210
|
+
|
|
211
|
+
---
|
|
212
|
+
|
|
213
|
+
### Phase 5: Completion & Handoff
|
|
214
|
+
|
|
215
|
+
#### Step 1: Establish Terminal UI State
|
|
216
|
+
|
|
217
|
+
> [!IMPORTANT]
|
|
218
|
+
> **Visual Completion Signal**
|
|
219
|
+
> Call `task_boundary` one last time to signal completion in the user's UI. This prevents the "task" from appearing active after you've finished.
|
|
220
|
+
|
|
221
|
+
```javascript
|
|
222
|
+
await task_boundary({
|
|
223
|
+
TaskName: "[COMPLETED] Plan Review: {Plan Name}",
|
|
224
|
+
TaskStatus: "Review complete. Offering next steps.",
|
|
225
|
+
Mode: "VERIFICATION",
|
|
226
|
+
TaskSummary: "Completed plan review for {plan name}. Verdict: {Ready/Needs Revisions}. {Key findings summary}."
|
|
227
|
+
});
|
|
228
|
+
```
|
|
229
|
+
|
|
230
|
+
#### Step 2: Mandatory Handoff
|
|
231
|
+
|
|
232
|
+
> [!IMPORTANT]
|
|
233
|
+
> **Exit Transition**
|
|
234
|
+
> Do not stop here. Offer the user clear paths to the next logical workflow.
|
|
235
|
+
|
|
236
|
+
```bash
|
|
237
|
+
✓ Review complete
|
|
238
|
+
|
|
239
|
+
Next steps:
|
|
240
|
+
1. /work - Execute the approved plan (if verdict: Ready)
|
|
241
|
+
2. Revise plan - Address review concerns (if verdict: Needs Revisions)
|
|
242
|
+
3. /specs - Elevate to specification if scope expanded during review
|
|
243
|
+
4. Create revision todo - For major revision tracking
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
---
|
|
247
|
+
|
|
248
|
+
## Quality Guidelines
|
|
249
|
+
|
|
250
|
+
**Good reviews:**
|
|
251
|
+
- ✅ Check compound solutions first
|
|
252
|
+
- ✅ Verify measurable success criteria
|
|
253
|
+
- ✅ Confirm scope boundaries
|
|
254
|
+
- ✅ Validate risks are acknowledged
|
|
255
|
+
|
|
256
|
+
**Avoid:**
|
|
257
|
+
- ❌ Rubber-stamping without reading
|
|
258
|
+
- ❌ Skipping compound search
|
|
259
|
+
- ❌ Ignoring missing success criteria
|
|
260
|
+
|
|
261
|
+
---
|
|
262
|
+
|
|
263
|
+
## References
|
|
264
|
+
|
|
265
|
+
- Create plans: `/plan`
|
|
266
|
+
- Execute plans: `/work`
|
|
267
|
+
- Search solutions: `Call MCP `call_tool_compound_manager` { action: "search", terms: [] }`
|
|
268
|
+
- Archive when done: `/housekeeping`
|
|
269
|
+
|
|
@@ -1,37 +1,37 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: primary-workflow
|
|
3
|
-
description: Information about the primary workflow commands, including /cook for complex features and other quick tasks.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Primary Workflow
|
|
7
|
-
|
|
8
|
-
## The `/cook` Workflow
|
|
9
|
-
|
|
10
|
-
```
|
|
11
|
-
/cook [task description]
|
|
12
|
-
```
|
|
13
|
-
|
|
14
|
-
### Steps
|
|
15
|
-
|
|
16
|
-
1. **Planning** - `/plan`
|
|
17
|
-
2. **Scouting** - `/scout`
|
|
18
|
-
3. **Coding** - Implement
|
|
19
|
-
4. **Testing** - `/test`
|
|
20
|
-
5. **Reviewing** - `/review`
|
|
21
|
-
6. **Committing** - `/git`
|
|
22
|
-
|
|
23
|
-
## Quick Workflows
|
|
24
|
-
|
|
25
|
-
| Task | Command |
|
|
26
|
-
|------|---------|
|
|
27
|
-
| New feature | `/cook implement` |
|
|
28
|
-
| Bug fix | `/cook fix` |
|
|
29
|
-
| Refactoring | `/cook refactor` |
|
|
30
|
-
| Full audit | `/cook full review` |
|
|
31
|
-
|
|
32
|
-
## When to Use
|
|
33
|
-
|
|
34
|
-
- **Simple change**: `/code` or `/fix`
|
|
35
|
-
- **Complex feature**: `/cook`
|
|
36
|
-
- **Code quality**: `/review`
|
|
37
|
-
- **Explore**: `/scout`
|
|
1
|
+
---
|
|
2
|
+
name: primary-workflow
|
|
3
|
+
description: Information about the primary workflow commands, including /cook for complex features and other quick tasks.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Primary Workflow
|
|
7
|
+
|
|
8
|
+
## The `/cook` Workflow
|
|
9
|
+
|
|
10
|
+
```
|
|
11
|
+
/cook [task description]
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
### Steps
|
|
15
|
+
|
|
16
|
+
1. **Planning** - `/plan`
|
|
17
|
+
2. **Scouting** - `/scout`
|
|
18
|
+
3. **Coding** - Implement
|
|
19
|
+
4. **Testing** - `/test`
|
|
20
|
+
5. **Reviewing** - `/review`
|
|
21
|
+
6. **Committing** - `/git`
|
|
22
|
+
|
|
23
|
+
## Quick Workflows
|
|
24
|
+
|
|
25
|
+
| Task | Command |
|
|
26
|
+
|------|---------|
|
|
27
|
+
| New feature | `/cook implement` |
|
|
28
|
+
| Bug fix | `/cook fix` |
|
|
29
|
+
| Refactoring | `/cook refactor` |
|
|
30
|
+
| Full audit | `/cook full review` |
|
|
31
|
+
|
|
32
|
+
## When to Use
|
|
33
|
+
|
|
34
|
+
- **Simple change**: `/code` or `/fix`
|
|
35
|
+
- **Complex feature**: `/cook`
|
|
36
|
+
- **Code quality**: `/review`
|
|
37
|
+
- **Explore**: `/scout`
|