learnship 2.0.11 → 2.1.1
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/.claude-plugin/plugin.json +2 -2
- package/.cursor-plugin/plugin.json +2 -2
- package/README.md +59 -14
- package/SKILL.md +24 -2
- package/agents/learnship-doc-writer.md +63 -0
- package/agents/learnship-security-auditor.md +67 -0
- package/bin/install.js +2 -0
- package/commands/learnship/discuss-phase.md +1 -1
- package/commands/learnship/docs-update.md +22 -0
- package/commands/learnship/execute-phase.md +2 -6
- package/commands/learnship/extract-learnings.md +22 -0
- package/commands/learnship/forensics.md +21 -0
- package/commands/learnship/help.md +2 -1
- package/commands/learnship/ideate.md +1 -1
- package/commands/learnship/milestone-summary.md +22 -0
- package/commands/learnship/note.md +22 -0
- package/commands/learnship/plan-phase.md +0 -1
- package/commands/learnship/quick.md +1 -5
- package/commands/learnship/secure-phase.md +23 -0
- package/commands/learnship/session-report.md +21 -0
- package/commands/learnship/undo.md +22 -0
- package/commands/learnship/verify-work.md +1 -1
- package/cursor-rules/learnship.mdc +12 -2
- package/gemini-extension.json +2 -2
- package/hooks/session-start +12 -1
- package/learnship/agents/doc-writer.md +63 -0
- package/learnship/agents/security-auditor.md +67 -0
- package/learnship/references/common-bug-patterns.md +92 -0
- package/learnship/references/context-budget.md +49 -0
- package/learnship/references/domain-probes.md +133 -0
- package/learnship/references/gates.md +72 -0
- package/learnship/references/planning-config.md +99 -9
- package/learnship/references/thinking-models.md +61 -0
- package/learnship/references/universal-anti-patterns.md +51 -0
- package/learnship/templates/agents.md +3 -0
- package/learnship/templates/context.md +207 -32
- package/learnship/templates/discussion-log.md +49 -0
- package/learnship/templates/security.md +61 -0
- package/learnship/templates/ui-spec.md +107 -0
- package/learnship/workflows/complete-milestone.md +4 -5
- package/learnship/workflows/compound.md +2 -0
- package/learnship/workflows/debug.md +2 -0
- package/learnship/workflows/discuss-phase.md +73 -15
- package/learnship/workflows/docs-update.md +144 -0
- package/learnship/workflows/execute-phase.md +35 -6
- package/learnship/workflows/extract-learnings.md +161 -0
- package/learnship/workflows/forensics.md +118 -0
- package/learnship/workflows/help.md +20 -2
- package/learnship/workflows/ideate.md +63 -4
- package/learnship/workflows/ls.md +1 -1
- package/learnship/workflows/milestone-summary.md +150 -0
- package/learnship/workflows/new-project.md +78 -8
- package/learnship/workflows/next.md +1 -1
- package/learnship/workflows/note.md +110 -0
- package/learnship/workflows/pause-work.md +2 -0
- package/learnship/workflows/plan-phase.md +17 -2
- package/learnship/workflows/quick.md +28 -8
- package/learnship/workflows/review.md +1 -0
- package/learnship/workflows/secure-phase.md +147 -0
- package/learnship/workflows/session-report.md +133 -0
- package/learnship/workflows/settings.md +40 -46
- package/learnship/workflows/ship.md +2 -0
- package/learnship/workflows/undo.md +151 -0
- package/learnship/workflows/verify-work.md +36 -4
- package/package.json +1 -1
- package/references/common-bug-patterns.md +92 -0
- package/references/context-budget.md +49 -0
- package/references/domain-probes.md +133 -0
- package/references/gates.md +72 -0
- package/references/planning-config.md +139 -0
- package/references/solution-schema.md +159 -0
- package/references/thinking-models.md +61 -0
- package/references/universal-anti-patterns.md +51 -0
- package/templates/agents.md +80 -7
- package/templates/config.json +28 -3
- package/templates/context.md +207 -32
- package/templates/discussion-log.md +49 -0
- package/templates/security.md +61 -0
- package/templates/ui-spec.md +107 -0
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
---
|
|
2
|
+
phase: {N}
|
|
3
|
+
slug: {phase-slug}
|
|
4
|
+
status: draft
|
|
5
|
+
created: {date}
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Phase {N} — UI Design Contract
|
|
9
|
+
|
|
10
|
+
> Visual and interaction contract for frontend phases. Verified against impeccable standards.
|
|
11
|
+
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
## Design System
|
|
15
|
+
|
|
16
|
+
| Property | Value |
|
|
17
|
+
|----------|-------|
|
|
18
|
+
| Component library | {library or "none"} |
|
|
19
|
+
| Icon library | {library} |
|
|
20
|
+
| Font | {font} |
|
|
21
|
+
| CSS approach | {tailwind / css modules / styled-components / etc.} |
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## Spacing Scale
|
|
26
|
+
|
|
27
|
+
Declared values (must be multiples of 4):
|
|
28
|
+
|
|
29
|
+
| Token | Value | Usage |
|
|
30
|
+
|-------|-------|-------|
|
|
31
|
+
| xs | 4px | Icon gaps, inline padding |
|
|
32
|
+
| sm | 8px | Compact element spacing |
|
|
33
|
+
| md | 16px | Default element spacing |
|
|
34
|
+
| lg | 24px | Section padding |
|
|
35
|
+
| xl | 32px | Layout gaps |
|
|
36
|
+
| 2xl | 48px | Major section breaks |
|
|
37
|
+
| 3xl | 64px | Page-level spacing |
|
|
38
|
+
|
|
39
|
+
Exceptions: {list any, or "none"}
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Typography
|
|
44
|
+
|
|
45
|
+
| Role | Size | Weight | Line Height |
|
|
46
|
+
|------|------|--------|-------------|
|
|
47
|
+
| Body | {px} | {weight} | {ratio} |
|
|
48
|
+
| Label | {px} | {weight} | {ratio} |
|
|
49
|
+
| Heading | {px} | {weight} | {ratio} |
|
|
50
|
+
| Display | {px} | {weight} | {ratio} |
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## Color
|
|
55
|
+
|
|
56
|
+
| Role | Value | Usage |
|
|
57
|
+
|------|-------|-------|
|
|
58
|
+
| Primary | {hex} | Buttons, links, active states |
|
|
59
|
+
| Secondary | {hex} | Supporting actions |
|
|
60
|
+
| Neutral | {hex} | Text, borders, backgrounds |
|
|
61
|
+
| Success | {hex} | Confirmations, positive states |
|
|
62
|
+
| Warning | {hex} | Cautions, pending states |
|
|
63
|
+
| Error | {hex} | Errors, destructive actions |
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
## Key Components
|
|
68
|
+
|
|
69
|
+
| Component | Spec |
|
|
70
|
+
|-----------|------|
|
|
71
|
+
| {component} | {key constraints: size, padding, border-radius, shadow} |
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
## Interaction Patterns
|
|
76
|
+
|
|
77
|
+
| Pattern | Behavior |
|
|
78
|
+
|---------|----------|
|
|
79
|
+
| Loading | {skeleton / spinner / progressive} |
|
|
80
|
+
| Empty state | {illustration + CTA / minimal text / guided action} |
|
|
81
|
+
| Error state | {inline / toast / modal / redirect} |
|
|
82
|
+
| Transitions | {duration, easing, what animates} |
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## Responsive Breakpoints
|
|
87
|
+
|
|
88
|
+
| Breakpoint | Width | Layout Changes |
|
|
89
|
+
|------------|-------|----------------|
|
|
90
|
+
| Mobile | < 640px | {description} |
|
|
91
|
+
| Tablet | 640-1024px | {description} |
|
|
92
|
+
| Desktop | > 1024px | {description} |
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
## Impeccable Checklist
|
|
97
|
+
|
|
98
|
+
- [ ] No overused fonts (Inter, Roboto, Arial)
|
|
99
|
+
- [ ] No AI palette (cyan-on-dark, purple-to-blue gradients)
|
|
100
|
+
- [ ] No pure black (#000) or pure white (#fff) — tinted neutrals
|
|
101
|
+
- [ ] No nested cards inside cards
|
|
102
|
+
- [ ] No large rounded icons above every heading
|
|
103
|
+
- [ ] At least one intentional, memorable design decision
|
|
104
|
+
- [ ] Typography has clear visual hierarchy with modular scale
|
|
105
|
+
- [ ] Spacing creates rhythm through variation, not uniformity
|
|
106
|
+
|
|
107
|
+
**If someone saw this interface and immediately thought AI made it — that is the problem.**
|
|
@@ -185,11 +185,10 @@ Ask: "Ready to start the next milestone?"
|
|
|
185
185
|
- **Not yet** → stop here
|
|
186
186
|
|
|
187
187
|
```
|
|
188
|
-
💡
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
💡 For ambitious next milestones,
|
|
192
|
-
before committing.
|
|
188
|
+
💡 Team onboarding? `/milestone-summary` — generate a comprehensive summary a new contributor can read
|
|
189
|
+
💡 Capture learnings? `/extract-learnings [N]` for each completed phase — decisions, lessons, patterns
|
|
190
|
+
💡 Not sure what to build next? `/ideate` — codebase-grounded idea generation
|
|
191
|
+
💡 For ambitious next milestones, `/challenge` to stress-test the scope before committing
|
|
193
192
|
```
|
|
194
193
|
|
|
195
194
|
---
|
|
@@ -271,6 +271,8 @@ File created:
|
|
|
271
271
|
|
|
272
272
|
Note: This was created in lightweight mode. For richer documentation
|
|
273
273
|
(cross-references, overlap detection), re-run /compound in a fresh session.
|
|
274
|
+
|
|
275
|
+
💡 Also consider: /extract-learnings [N] — captures decisions, lessons, patterns, surprises from the entire phase
|
|
274
276
|
```
|
|
275
277
|
|
|
276
278
|
**No subagents are launched. No parallel tasks. One file written.**
|
|
@@ -231,6 +231,8 @@ Debug session closed.
|
|
|
231
231
|
Session: .planning/debug/resolved/[session-file]
|
|
232
232
|
|
|
233
233
|
▶ If more issues remain: debug [new description]
|
|
234
|
+
▶ Stuck or need deeper investigation? /forensics — post-mortem analysis
|
|
235
|
+
▶ Need to revert the fix? /undo --last 1
|
|
234
236
|
```
|
|
235
237
|
|
|
236
238
|
---
|
|
@@ -8,7 +8,23 @@ Extract implementation decisions that downstream planning needs. Analyze the pha
|
|
|
8
8
|
|
|
9
9
|
**Usage:** Run `discuss-phase [N]` before `plan-phase [N]`.
|
|
10
10
|
|
|
11
|
-
**You are a thinking partner, not an interviewer.** The user is the visionary — you are the builder.
|
|
11
|
+
**You are a thinking partner, not an interviewer.** The user is the visionary — you are the builder. Your job is to capture decisions that will guide research and planning, not to figure out implementation yourself.
|
|
12
|
+
|
|
13
|
+
<downstream_awareness>
|
|
14
|
+
**CONTEXT.md feeds into:**
|
|
15
|
+
|
|
16
|
+
1. **Researcher** — Reads CONTEXT.md to know WHAT to research
|
|
17
|
+
- "User wants card-based layout" → researcher investigates card component patterns
|
|
18
|
+
- "Infinite scroll decided" → researcher looks into virtualization libraries
|
|
19
|
+
|
|
20
|
+
2. **Planner** — Reads CONTEXT.md to know WHAT decisions are locked
|
|
21
|
+
- "Pull-to-refresh on mobile" → planner includes that in task specs
|
|
22
|
+
- "Claude's Discretion: loading skeleton" → planner can decide approach
|
|
23
|
+
|
|
24
|
+
**Your job:** Capture decisions clearly enough that downstream agents can act on them without asking the user again.
|
|
25
|
+
|
|
26
|
+
**Not your job:** Figure out HOW to implement. That's what research and planning do with the decisions you capture.
|
|
27
|
+
</downstream_awareness>
|
|
12
28
|
|
|
13
29
|
## Step 1: Load Phase
|
|
14
30
|
|
|
@@ -72,6 +88,8 @@ Analyze the phase goal from ROADMAP.md. A gray area is an **implementation decis
|
|
|
72
88
|
- Something users **READ** → structure, tone, depth, flow
|
|
73
89
|
- Something being **ORGANIZED** → grouping criteria, naming, duplicates
|
|
74
90
|
|
|
91
|
+
**Use domain-aware probes** from `@./references/domain-probes.md` when the phase touches a known domain (auth, real-time, dashboard, API, database, search, file upload, caching, testing, deployment, AI/ML). Pick 2-3 most relevant probes, not all of them.
|
|
92
|
+
|
|
75
93
|
**Check prior decisions first** — don't re-ask what's already locked from earlier phases.
|
|
76
94
|
|
|
77
95
|
Generate 3-4 **phase-specific** gray areas. Not generic categories ("UI", "UX") — concrete decisions:
|
|
@@ -116,15 +134,31 @@ After all selected areas:
|
|
|
116
134
|
- Summarize decisions captured
|
|
117
135
|
- Ask: "Which gray areas remain unclear?" → "Explore more" or "I'm ready for context"
|
|
118
136
|
|
|
119
|
-
|
|
137
|
+
<scope_guardrail>
|
|
138
|
+
**No scope creep.** The phase boundary comes from ROADMAP.md and is FIXED. Discussion clarifies HOW to implement what's scoped, never WHETHER to add new capabilities.
|
|
139
|
+
|
|
140
|
+
**Allowed (clarifying ambiguity):**
|
|
141
|
+
- "How should posts be displayed?" (layout, density, info shown)
|
|
142
|
+
- "What happens on empty state?" (within the feature)
|
|
143
|
+
- "Pull to refresh or manual?" (behavior choice)
|
|
144
|
+
|
|
145
|
+
**Not allowed (scope creep):**
|
|
146
|
+
- "Should we also add comments?" (new capability)
|
|
147
|
+
- "What about search/filtering?" (new capability)
|
|
148
|
+
- "Maybe include bookmarking?" (new capability)
|
|
149
|
+
|
|
150
|
+
**The heuristic:** Does this clarify how we implement what's already in the phase, or does it add a new capability that could be its own phase?
|
|
151
|
+
|
|
152
|
+
**When user suggests scope creep:**
|
|
120
153
|
```
|
|
121
|
-
"[Feature X]
|
|
154
|
+
"[Feature X] would be a new capability — that's its own phase.
|
|
122
155
|
Want me to note it for the roadmap backlog?
|
|
123
156
|
|
|
124
|
-
|
|
157
|
+
For now, let's focus on [phase domain]."
|
|
125
158
|
```
|
|
126
159
|
|
|
127
|
-
|
|
160
|
+
Capture the idea in the "Deferred Ideas" section. Don't lose it, don't act on it.
|
|
161
|
+
</scope_guardrail>
|
|
128
162
|
|
|
129
163
|
## Step 6: Write CONTEXT.md
|
|
130
164
|
|
|
@@ -159,6 +193,26 @@ Write `.planning/phases/[padded_phase]-[phase_slug]/[padded_phase]-CONTEXT.md`:
|
|
|
159
193
|
|
|
160
194
|
</decisions>
|
|
161
195
|
|
|
196
|
+
<specifics>
|
|
197
|
+
## Specific Ideas
|
|
198
|
+
|
|
199
|
+
[Any "I want it like X" moments or specific references]
|
|
200
|
+
|
|
201
|
+
[If none: "No specific requirements — open to standard approaches"]
|
|
202
|
+
|
|
203
|
+
</specifics>
|
|
204
|
+
|
|
205
|
+
<canonical_refs>
|
|
206
|
+
## Canonical References
|
|
207
|
+
|
|
208
|
+
**Downstream agents MUST read these before planning or implementing.**
|
|
209
|
+
|
|
210
|
+
[List specs, ADRs, or design docs relevant to this phase with full relative paths.]
|
|
211
|
+
|
|
212
|
+
[If no external specs: "No external specs — requirements are fully captured in decisions above"]
|
|
213
|
+
|
|
214
|
+
</canonical_refs>
|
|
215
|
+
|
|
162
216
|
<code_context>
|
|
163
217
|
## Existing Code Insights
|
|
164
218
|
|
|
@@ -173,15 +227,6 @@ Write `.planning/phases/[padded_phase]-[phase_slug]/[padded_phase]-CONTEXT.md`:
|
|
|
173
227
|
|
|
174
228
|
</code_context>
|
|
175
229
|
|
|
176
|
-
<specifics>
|
|
177
|
-
## Specific Ideas
|
|
178
|
-
|
|
179
|
-
[Any "I want it like X" moments or specific references]
|
|
180
|
-
|
|
181
|
-
[If none: "No specific requirements — open to standard approaches"]
|
|
182
|
-
|
|
183
|
-
</specifics>
|
|
184
|
-
|
|
185
230
|
<deferred>
|
|
186
231
|
## Deferred Ideas
|
|
187
232
|
|
|
@@ -196,10 +241,23 @@ Write `.planning/phases/[padded_phase]-[phase_slug]/[padded_phase]-CONTEXT.md`:
|
|
|
196
241
|
*Context gathered: [date]*
|
|
197
242
|
```
|
|
198
243
|
|
|
199
|
-
## Step 7:
|
|
244
|
+
## Step 7: Write Discussion Log
|
|
245
|
+
|
|
246
|
+
Also write a discussion log for audit purposes using `@./templates/discussion-log.md`:
|
|
247
|
+
|
|
248
|
+
Write `.planning/phases/[padded_phase]-[phase_slug]/[padded_phase]-DISCUSSION-LOG.md` with:
|
|
249
|
+
- All options considered for each area (not just the selected one)
|
|
250
|
+
- The user's verbatim choice and rationale
|
|
251
|
+
- Areas delegated to Claude's discretion
|
|
252
|
+
- Deferred ideas
|
|
253
|
+
|
|
254
|
+
This file is for human audit trails only — it is NOT referenced by downstream agents.
|
|
255
|
+
|
|
256
|
+
## Step 8: Commit and Confirm
|
|
200
257
|
|
|
201
258
|
```bash
|
|
202
259
|
git add ".planning/phases/[padded_phase]-[phase_slug]/[padded_phase]-CONTEXT.md"
|
|
260
|
+
git add ".planning/phases/[padded_phase]-[phase_slug]/[padded_phase]-DISCUSSION-LOG.md"
|
|
203
261
|
git commit -m "docs([padded_phase]): capture phase context"
|
|
204
262
|
```
|
|
205
263
|
|
|
@@ -0,0 +1,144 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Generate, update, and verify project documentation — detects project type, builds doc queue, verifies against live codebase
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Docs Update
|
|
6
|
+
|
|
7
|
+
Generate, update, and verify project documentation. Detects the project's doc structure, assembles a work manifest, writes or updates docs, and verifies factual claims against the live codebase.
|
|
8
|
+
|
|
9
|
+
**Usage:** `docs-update` or `docs-update --force` (skip confirmations)
|
|
10
|
+
|
|
11
|
+
## Step 1: Detect Project Type
|
|
12
|
+
|
|
13
|
+
Scan the project root for signals:
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
ls package.json Makefile Cargo.toml go.mod setup.py pyproject.toml 2>/dev/null
|
|
17
|
+
ls .github/workflows/ .gitlab-ci.yml Dockerfile docker-compose.yml 2>/dev/null
|
|
18
|
+
ls LICENSE CONTRIBUTING.md 2>/dev/null
|
|
19
|
+
find . -maxdepth 2 -name "*.test.*" -o -name "*_test.*" -o -name "test_*" 2>/dev/null | head -5
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
Classify the project:
|
|
23
|
+
|
|
24
|
+
| Condition | Primary Type |
|
|
25
|
+
|-----------|-------------|
|
|
26
|
+
| Multiple package.json files at different levels | `monorepo` |
|
|
27
|
+
| `bin` field in package.json AND no API routes | `cli-tool` |
|
|
28
|
+
| API routes detected AND not open source | `saas` |
|
|
29
|
+
| LICENSE file AND no API routes | `open-source-library` |
|
|
30
|
+
| None of the above | `generic` |
|
|
31
|
+
|
|
32
|
+
## Step 2: Build Doc Queue
|
|
33
|
+
|
|
34
|
+
**Always-on docs (every project):**
|
|
35
|
+
1. README.md
|
|
36
|
+
2. ARCHITECTURE.md
|
|
37
|
+
3. GETTING-STARTED.md
|
|
38
|
+
4. DEVELOPMENT.md
|
|
39
|
+
5. TESTING.md
|
|
40
|
+
6. CONFIGURATION.md
|
|
41
|
+
|
|
42
|
+
**Conditional docs (add if signal matched):**
|
|
43
|
+
- API.md — if API routes detected
|
|
44
|
+
- CONTRIBUTING.md — if open source (LICENSE exists)
|
|
45
|
+
- DEPLOYMENT.md — if deploy config detected (Dockerfile, CI/CD)
|
|
46
|
+
|
|
47
|
+
**CHANGELOG.md is NEVER queued** — it's manually maintained.
|
|
48
|
+
|
|
49
|
+
Maximum 9 docs total.
|
|
50
|
+
|
|
51
|
+
## Step 3: Check Existing Docs
|
|
52
|
+
|
|
53
|
+
```bash
|
|
54
|
+
find . -maxdepth 2 -name "*.md" -not -path "./.planning/*" -not -path "./node_modules/*" 2>/dev/null
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
For each doc in the queue, determine mode:
|
|
58
|
+
- **Create** — doc doesn't exist yet
|
|
59
|
+
- **Update** — doc exists, check if it's stale
|
|
60
|
+
|
|
61
|
+
Display the plan:
|
|
62
|
+
```
|
|
63
|
+
learnship > DOCS UPDATE
|
|
64
|
+
|
|
65
|
+
Project type: [type]
|
|
66
|
+
Docs to create: [N]
|
|
67
|
+
Docs to update: [M]
|
|
68
|
+
|
|
69
|
+
| Doc | Mode | Status |
|
|
70
|
+
|-----|------|--------|
|
|
71
|
+
| README.md | update | exists, checking freshness |
|
|
72
|
+
| ARCHITECTURE.md | create | new |
|
|
73
|
+
| ... | ... | ... |
|
|
74
|
+
|
|
75
|
+
[Proceed] / [Customize queue] / [Cancel]
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
## Step 4: Write/Update Docs
|
|
79
|
+
|
|
80
|
+
For each doc in the queue:
|
|
81
|
+
|
|
82
|
+
### Create mode
|
|
83
|
+
|
|
84
|
+
Read relevant source files to understand the project structure, then write the doc grounded in the actual codebase. Every claim must be verifiable.
|
|
85
|
+
|
|
86
|
+
### Update mode
|
|
87
|
+
|
|
88
|
+
Read the existing doc AND the current codebase. Identify stale sections (references to renamed files, outdated instructions, missing new features). Update only stale sections — preserve the author's voice and structure.
|
|
89
|
+
|
|
90
|
+
For each doc, after writing:
|
|
91
|
+
```bash
|
|
92
|
+
git add [doc path]
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
## Step 5: Verify Docs Against Codebase
|
|
96
|
+
|
|
97
|
+
For each written/updated doc, verify factual claims:
|
|
98
|
+
|
|
99
|
+
- File paths mentioned in docs actually exist
|
|
100
|
+
- Commands shown in docs actually work
|
|
101
|
+
- Configuration examples match the actual schema
|
|
102
|
+
- API endpoints documented match the actual routes
|
|
103
|
+
|
|
104
|
+
```bash
|
|
105
|
+
# Example: check all file references in a doc
|
|
106
|
+
grep -oE '\`[a-zA-Z0-9_./-]+\.[a-z]+\`' [doc] | tr -d '`' | while read f; do
|
|
107
|
+
[ -f "$f" ] || echo "MISSING: $f referenced in [doc]"
|
|
108
|
+
done
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
If verification finds issues: fix the doc, don't flag it as a separate issue.
|
|
112
|
+
|
|
113
|
+
## Step 6: Commit and Report
|
|
114
|
+
|
|
115
|
+
```bash
|
|
116
|
+
git add -A
|
|
117
|
+
git commit -m "docs: update project documentation ([N] docs)"
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
```
|
|
121
|
+
learnship > DOCS UPDATE COMPLETE
|
|
122
|
+
|
|
123
|
+
| Doc | Mode | Verified |
|
|
124
|
+
|-----|------|----------|
|
|
125
|
+
| README.md | updated | yes |
|
|
126
|
+
| ARCHITECTURE.md | created | yes |
|
|
127
|
+
| ... | ... | ... |
|
|
128
|
+
|
|
129
|
+
[N] docs written/updated, all verified against codebase.
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
---
|
|
133
|
+
|
|
134
|
+
## Learning Checkpoint
|
|
135
|
+
|
|
136
|
+
Read `learning_mode` from `.planning/config.json`.
|
|
137
|
+
|
|
138
|
+
**If `auto`:**
|
|
139
|
+
|
|
140
|
+
> **Learning moment:** Writing documentation forces you to articulate what was built:
|
|
141
|
+
>
|
|
142
|
+
> `@agentic-learning explain [project topic]` — Explain the architecture or a key feature in your own words. Gaps in the explanation reveal gaps in understanding. Writes a comprehension log to `docs/project-knowledge.md`.
|
|
143
|
+
|
|
144
|
+
**If `manual`:** Add quietly: *"Tip: `@agentic-learning explain [topic]` to test your understanding of what was documented."*
|
|
@@ -6,13 +6,32 @@ description: Execute all plans in a phase using wave-based ordered execution —
|
|
|
6
6
|
|
|
7
7
|
Execute all plans in a phase. Plans run in waves — ordered by dependencies. On platforms with subagent support (Claude Code, OpenCode, Codex), plans within a wave are dispatched to dedicated executor agents. On all other platforms, plans execute sequentially.
|
|
8
8
|
|
|
9
|
-
**Usage:** `execute-phase [N]`
|
|
9
|
+
**Usage:** `execute-phase [N]` or `execute-phase [N] --wave [W]`
|
|
10
10
|
|
|
11
11
|
**Core principle:** Orchestrate, don't implement directly. Describe each plan's objective clearly, execute each plan in sequence (or in parallel via subagents), collect results.
|
|
12
12
|
|
|
13
|
-
> **Platform note:** This workflow detects whether subagent spawning is available by reading `parallelization` from `.planning/config.json`. Set `"parallelization": true` to enable parallel agent spawning on supported platforms. Defaults to `false` (sequential — always safe).
|
|
13
|
+
> **Platform note:** This workflow detects whether subagent spawning is available by reading `parallelization.enabled` from `.planning/config.json`. Set `"parallelization": { "enabled": true }` to enable parallel agent spawning on supported platforms. Defaults to `false` (sequential — always safe). The legacy flat `"parallelization": true` is also honored for backward compatibility.
|
|
14
14
|
|
|
15
|
-
|
|
15
|
+
<runtime_compatibility>
|
|
16
|
+
**Subagent spawning is runtime-specific:**
|
|
17
|
+
- **Claude Code:** Uses `Task(subagent_type=..., ...)` — blocks until complete, returns result
|
|
18
|
+
- **OpenCode / Codex:** Subagent spawning supported with platform-native dispatch
|
|
19
|
+
- **Windsurf / Cursor:** No subagent spawning — always use sequential inline execution
|
|
20
|
+
- **Gemini CLI:** Subagents exist but parallel execution limited — default to sequential
|
|
21
|
+
|
|
22
|
+
**Fallback rule:** If a spawned agent completes its work (commits visible, SUMMARY.md exists) but the orchestrator never receives the completion signal, treat it as successful based on spot-checks and continue to the next wave/plan. Never block indefinitely.
|
|
23
|
+
</runtime_compatibility>
|
|
24
|
+
|
|
25
|
+
## Step 1: Parse Arguments
|
|
26
|
+
|
|
27
|
+
Parse `$ARGUMENTS` for:
|
|
28
|
+
- First positional token → `PHASE_ARG` (phase number)
|
|
29
|
+
- Optional `--wave N` → `WAVE_FILTER` (execute only wave N)
|
|
30
|
+
- Optional `--gaps-only` → execute only gap-closure plans
|
|
31
|
+
|
|
32
|
+
If `--wave` is absent, execute all incomplete waves in the phase.
|
|
33
|
+
|
|
34
|
+
## Step 1b: Initialize
|
|
16
35
|
|
|
17
36
|
Read the phase directory:
|
|
18
37
|
```bash
|
|
@@ -31,6 +50,8 @@ If no plans found: stop — run `plan-phase [N]` first.
|
|
|
31
50
|
Read `.planning/STATE.md` for project context.
|
|
32
51
|
Read `.planning/config.json` for settings.
|
|
33
52
|
|
|
53
|
+
**Context window scaling:** Check for `context_window` in config (default: 200000). At < 500000 tokens: read only frontmatter from prior phase SUMMARYs. At >= 500000: full body reads permitted for direct-dependency phases. See `@./references/context-budget.md` for the complete table.
|
|
54
|
+
|
|
34
55
|
## Step 2: Discover and Group Plans
|
|
35
56
|
|
|
36
57
|
Read each PLAN.md's frontmatter to extract:
|
|
@@ -105,7 +126,13 @@ Both inline (`@./agents/executor.md`) and subagent (`learnship-executor`) execut
|
|
|
105
126
|
|
|
106
127
|
## Step 3: Execute Waves
|
|
107
128
|
|
|
108
|
-
Read `parallelization` from `.planning/config.json
|
|
129
|
+
Read `parallelization` from `.planning/config.json`. Supports both:
|
|
130
|
+
- New format: `parallelization.enabled` (boolean)
|
|
131
|
+
- Legacy format: `parallelization` (flat boolean)
|
|
132
|
+
|
|
133
|
+
Defaults to `false` if not found.
|
|
134
|
+
|
|
135
|
+
If `WAVE_FILTER` is set, skip all waves except the specified one.
|
|
109
136
|
|
|
110
137
|
For each wave, in sequence:
|
|
111
138
|
|
|
@@ -126,7 +153,7 @@ Executing [count] plan(s)...
|
|
|
126
153
|
|
|
127
154
|
### Execute the plans
|
|
128
155
|
|
|
129
|
-
**If
|
|
156
|
+
**If parallelization is enabled (subagent mode — Claude Code, OpenCode, Codex):**
|
|
130
157
|
|
|
131
158
|
For each plan in the wave, spawn a dedicated executor subagent. Pass paths only — each executor reads files itself with a fresh context budget.
|
|
132
159
|
|
|
@@ -159,7 +186,7 @@ Task(
|
|
|
159
186
|
|
|
160
187
|
Spawn all plans in the wave before waiting. Wait for all agents to complete, then proceed to spot-checks.
|
|
161
188
|
|
|
162
|
-
**If
|
|
189
|
+
**If parallelization is disabled (sequential mode — Windsurf, Cursor, Gemini CLI, or user preference):**
|
|
163
190
|
|
|
164
191
|
For each plan in the wave, using `@./agents/executor.md` as your execution persona:
|
|
165
192
|
|
|
@@ -361,6 +388,8 @@ git commit -m "docs: update AGENTS.md — phase [X] complete"
|
|
|
361
388
|
Then: /review → /ship → /compound
|
|
362
389
|
Then: discuss-phase [X+1] → plan-phase [X+1]
|
|
363
390
|
|
|
391
|
+
💡 Security: `/secure-phase [X]` — run STRIDE threat verification on this phase
|
|
392
|
+
💡 Learnings: `/extract-learnings [X]` — capture decisions, lessons, patterns while fresh
|
|
364
393
|
💡 Working on sensitive files? Run `/guard [scope]` to enable safety mode.
|
|
365
394
|
```
|
|
366
395
|
|
|
@@ -0,0 +1,161 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Extract structured learnings from completed phase artifacts — decisions, lessons, patterns, surprises
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Extract Learnings
|
|
6
|
+
|
|
7
|
+
Extract decisions, lessons learned, patterns discovered, and surprises encountered from completed phase artifacts into a structured LEARNINGS.md file. Captures institutional knowledge that would otherwise be lost between phases.
|
|
8
|
+
|
|
9
|
+
**Usage:** `extract-learnings [N]` — extract from phase N
|
|
10
|
+
|
|
11
|
+
**Complements `/compound`:** compound captures reusable solutions, extract-learnings captures meta-knowledge (why things worked, what surprised you, what patterns emerged).
|
|
12
|
+
|
|
13
|
+
## Step 1: Initialize
|
|
14
|
+
|
|
15
|
+
Find the phase directory:
|
|
16
|
+
```bash
|
|
17
|
+
ls ".planning/phases/" | grep "^[0-9]" | sort
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
Find the phase matching `[N]`. If not found, stop and list available phases.
|
|
21
|
+
|
|
22
|
+
Verify required artifacts exist:
|
|
23
|
+
```bash
|
|
24
|
+
ls ".planning/phases/[padded_phase]-[phase_slug]/"*-PLAN.md 2>/dev/null
|
|
25
|
+
ls ".planning/phases/[padded_phase]-[phase_slug]/"*-SUMMARY.md 2>/dev/null
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
If PLAN.md or SUMMARY.md files are missing: "Required artifacts missing. PLAN.md and SUMMARY.md are required for learning extraction."
|
|
29
|
+
|
|
30
|
+
## Step 2: Collect Artifacts
|
|
31
|
+
|
|
32
|
+
**Required (must exist):**
|
|
33
|
+
- All `*-PLAN.md` files for the phase
|
|
34
|
+
- All `*-SUMMARY.md` files for the phase
|
|
35
|
+
|
|
36
|
+
**Optional (read if available, skip if not):**
|
|
37
|
+
- `*-VERIFICATION.md` — verification results
|
|
38
|
+
- `*-UAT.md` — user acceptance test results
|
|
39
|
+
- `*-SECURITY.md` — security verification
|
|
40
|
+
- `.planning/STATE.md` — project state with decisions and blockers
|
|
41
|
+
|
|
42
|
+
Track which optional artifacts are missing for the frontmatter.
|
|
43
|
+
|
|
44
|
+
## Step 3: Extract Learnings
|
|
45
|
+
|
|
46
|
+
Analyze all collected artifacts and extract learnings into 4 categories:
|
|
47
|
+
|
|
48
|
+
### 1. Decisions
|
|
49
|
+
Technical and architectural decisions made during the phase:
|
|
50
|
+
- Explicit decisions documented in PLAN.md or SUMMARY.md
|
|
51
|
+
- Technology choices and their rationale
|
|
52
|
+
- Trade-offs that were evaluated
|
|
53
|
+
|
|
54
|
+
Each entry: **What** was decided, **Why** (rationale), **Source** (which artifact).
|
|
55
|
+
|
|
56
|
+
### 2. Lessons
|
|
57
|
+
What worked well and what didn't:
|
|
58
|
+
- Approaches that succeeded or failed
|
|
59
|
+
- Time estimates vs actual (if observable from git timestamps)
|
|
60
|
+
- Unexpected complexity or simplicity
|
|
61
|
+
|
|
62
|
+
Each entry: **What happened**, **Why it matters**, **Source**.
|
|
63
|
+
|
|
64
|
+
### 3. Patterns
|
|
65
|
+
Reusable patterns that emerged:
|
|
66
|
+
- Code patterns used across multiple tasks
|
|
67
|
+
- Process patterns that worked well
|
|
68
|
+
- Integration patterns between components
|
|
69
|
+
|
|
70
|
+
Each entry: **Pattern name**, **When to use**, **Source**.
|
|
71
|
+
|
|
72
|
+
### 4. Surprises
|
|
73
|
+
Things that didn't go as expected:
|
|
74
|
+
- Unexpected bugs or behaviors
|
|
75
|
+
- Assumptions that were wrong
|
|
76
|
+
- External factors that affected the work
|
|
77
|
+
|
|
78
|
+
Each entry: **What was surprising**, **Impact**, **Source**.
|
|
79
|
+
|
|
80
|
+
## Step 4: Write LEARNINGS.md
|
|
81
|
+
|
|
82
|
+
Write `.planning/phases/[padded_phase]-[phase_slug]/[padded_phase]-LEARNINGS.md`:
|
|
83
|
+
|
|
84
|
+
```markdown
|
|
85
|
+
---
|
|
86
|
+
phase: [N]
|
|
87
|
+
phase_name: [name]
|
|
88
|
+
extracted: [date]
|
|
89
|
+
plan_count: [N]
|
|
90
|
+
summary_count: [N]
|
|
91
|
+
missing_artifacts: [list or "none"]
|
|
92
|
+
---
|
|
93
|
+
|
|
94
|
+
# Phase [N]: [Name] — Learnings
|
|
95
|
+
|
|
96
|
+
## Decisions
|
|
97
|
+
|
|
98
|
+
### D1: [Decision title]
|
|
99
|
+
**What:** [what was decided]
|
|
100
|
+
**Why:** [rationale]
|
|
101
|
+
**Source:** [artifact file]
|
|
102
|
+
|
|
103
|
+
## Lessons
|
|
104
|
+
|
|
105
|
+
### L1: [Lesson title]
|
|
106
|
+
**What happened:** [description]
|
|
107
|
+
**Why it matters:** [impact on future work]
|
|
108
|
+
**Source:** [artifact file]
|
|
109
|
+
|
|
110
|
+
## Patterns
|
|
111
|
+
|
|
112
|
+
### P1: [Pattern name]
|
|
113
|
+
**When to use:** [conditions]
|
|
114
|
+
**Source:** [artifact file]
|
|
115
|
+
|
|
116
|
+
## Surprises
|
|
117
|
+
|
|
118
|
+
### S1: [Surprise title]
|
|
119
|
+
**What was surprising:** [description]
|
|
120
|
+
**Impact:** [how it affected the work]
|
|
121
|
+
**Source:** [artifact file]
|
|
122
|
+
|
|
123
|
+
---
|
|
124
|
+
|
|
125
|
+
*Extracted from Phase [N] artifacts on [date]*
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
## Step 5: Commit and Report
|
|
129
|
+
|
|
130
|
+
```bash
|
|
131
|
+
git add ".planning/phases/[padded_phase]-[phase_slug]/[padded_phase]-LEARNINGS.md"
|
|
132
|
+
git commit -m "docs([padded_phase]): extract phase learnings"
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
```
|
|
136
|
+
learnship > LEARNINGS EXTRACTED
|
|
137
|
+
|
|
138
|
+
Phase [N]: [Name]
|
|
139
|
+
Decisions: [N] | Lessons: [N] | Patterns: [N] | Surprises: [N]
|
|
140
|
+
|
|
141
|
+
Report: [path to LEARNINGS.md]
|
|
142
|
+
|
|
143
|
+
These learnings feed into future planning — the planner will reference them
|
|
144
|
+
when working on related phases.
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
---
|
|
148
|
+
|
|
149
|
+
## Learning Checkpoint
|
|
150
|
+
|
|
151
|
+
Read `learning_mode` from `.planning/config.json`.
|
|
152
|
+
|
|
153
|
+
**If `auto`:**
|
|
154
|
+
|
|
155
|
+
> **Learning moment:** You just extracted meta-knowledge from a phase. Make it stick:
|
|
156
|
+
>
|
|
157
|
+
> `@agentic-learning space` — Schedule the key patterns and lessons for spaced review. The extraction just identified WHAT you learned — spacing ensures you RETAIN it.
|
|
158
|
+
>
|
|
159
|
+
> `@agentic-learning interleave [phase topic]` — Mix these learnings with concepts from earlier phases to strengthen cross-cutting understanding.
|
|
160
|
+
|
|
161
|
+
**If `manual`:** Add quietly: *"Tip: `@agentic-learning space` to schedule these learnings for spaced review."*
|