learnship 1.9.15 → 1.9.16

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.
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "learnship",
3
3
  "description": "Agentic engineering done right — 42 structured workflows, persistent memory across sessions, integrated learning partner, and impeccable UI design system. Works with Claude Code, Windsurf, Cursor, Gemini CLI, OpenCode, and Codex.",
4
- "version": "1.9.15",
4
+ "version": "1.9.16",
5
5
  "author": {
6
6
  "name": "Favio Vazquez",
7
7
  "email": "favio.vazquezp@gmail.com"
@@ -2,7 +2,7 @@
2
2
  "name": "learnship",
3
3
  "displayName": "learnship",
4
4
  "description": "Agentic engineering done right — 42 structured workflows, persistent memory across sessions, integrated learning partner, and impeccable UI design system.",
5
- "version": "1.9.15",
5
+ "version": "1.9.16",
6
6
  "logo": "assets/logo.png",
7
7
  "author": {
8
8
  "name": "Favio Vazquez",
package/README.md CHANGED
@@ -84,6 +84,8 @@ It's probably overkill if you just need one-off scripts or quick fixes. Use `/qu
84
84
 
85
85
  ![Install learnship](assets/install.png)
86
86
 
87
+ **Requirements:** Node.js ≥ 18 (installer only), Python 3 (workflows use it for cross-platform file checks), Git. All standard — you almost certainly have them already. [Details →](https://faviovazquez.github.io/learnship/getting-started/installation/#requirements)
88
+
87
89
  **Via npm (all platforms — recommended):**
88
90
 
89
91
  ```bash
package/bin/install.js CHANGED
@@ -55,6 +55,7 @@ const hasClaude = args.includes('--claude');
55
55
  const hasOpencode = args.includes('--opencode');
56
56
  const hasGemini = args.includes('--gemini');
57
57
  const hasCodex = args.includes('--codex');
58
+ const hasCursor = args.includes('--cursor');
58
59
  const hasAll = args.includes('--all');
59
60
  const hasGlobal = args.includes('--global') || args.includes('-g');
60
61
  const hasLocal = args.includes('--local') || args.includes('-l');
@@ -70,6 +71,7 @@ if (hasAll) {
70
71
  if (hasOpencode) selectedPlatforms.push('opencode');
71
72
  if (hasGemini) selectedPlatforms.push('gemini');
72
73
  if (hasCodex) selectedPlatforms.push('codex');
74
+ if (hasCursor) selectedPlatforms.push('cursor');
73
75
  }
74
76
 
75
77
  // ─── Banner ────────────────────────────────────────────────────────────────
@@ -82,7 +84,7 @@ ${purple} ██╗ ███████╗ █████╗ ███
82
84
  ╚══════╝╚══════╝╚═╝ ╚═╝╚═╝ ╚═╝╚═╝ ╚═══╝╚══════╝╚═╝ ╚═╝╚═╝╚═╝${reset}
83
85
 
84
86
  ${dim}Learn as you build. Build with intent.${reset}
85
- ${dim}v${pkg.version} · Windsurf · Claude Code · OpenCode · Gemini CLI · Codex CLI${reset}
87
+ ${dim}v${pkg.version} · Windsurf · Claude Code · OpenCode · Gemini CLI · Codex CLI · Cursor${reset}
86
88
  `;
87
89
 
88
90
  // ─── Help text ─────────────────────────────────────────────────────────────
@@ -95,7 +97,8 @@ const helpText = `
95
97
  ${cyan}--opencode${reset} OpenCode (~/.config/opencode/)
96
98
  ${cyan}--gemini${reset} Gemini CLI (~/.gemini/)
97
99
  ${cyan}--codex${reset} Codex CLI (~/.codex/)
98
- ${cyan}--all${reset} All platforms
100
+ ${cyan}--all${reset} All platforms (excludes Cursor — use marketplace)
101
+ ${cyan}--cursor${reset} Show Cursor install instructions
99
102
 
100
103
  ${yellow}Scope:${reset}
101
104
  ${cyan}-g, --global${reset} Install to global config directory (recommended)
@@ -979,6 +982,19 @@ function scanForLeakedPaths(targetDir, platform) {
979
982
 
980
983
  // ─── Main install function ─────────────────────────────────────────────────
981
984
  function install(platform, isGlobal) {
985
+ // Cursor installs via the marketplace plugin, not this CLI.
986
+ // Print instructions and exit cleanly rather than silently doing nothing.
987
+ if (platform === 'cursor') {
988
+ console.log(`\n ${cyan}Cursor${reset} — learnship installs via the plugin marketplace, not this CLI.\n`);
989
+ console.log(` ${yellow}Option 1 (recommended):${reset} Install from the Cursor marketplace:`);
990
+ console.log(` ${dim}/add-plugin learnship${reset}\n`);
991
+ console.log(` ${yellow}Option 2 (manual):${reset} Copy the rule file into your project:`);
992
+ console.log(` ${dim}mkdir -p .cursor/rules${reset}`);
993
+ console.log(` ${dim}cp node_modules/learnship/cursor-rules/learnship.mdc .cursor/rules/${reset}\n`);
994
+ console.log(` ${dim}The .mdc rule activates all 42 learnship workflows automatically in every Cursor session.${reset}\n`);
995
+ return;
996
+ }
997
+
982
998
  const src = path.join(__dirname, '..');
983
999
  const targetDir = isGlobal ? getGlobalDir(platform) : path.join(process.cwd(), getDirName(platform));
984
1000
  const pathPrefix = `${targetDir.replace(/\\/g, '/')}/learnship/`;
@@ -1002,6 +1018,17 @@ function install(platform, isGlobal) {
1002
1018
  console.log(` ${green}✓${reset} Installed learnship/ (workflows, references, templates)`);
1003
1019
  } else { failures.push('learnship/'); }
1004
1020
 
1021
+ // 1b. Copy agents/ into learnship/workflows/agents/ so @./agents/ resolves from workflow files.
1022
+ // Windsurf is handled separately (flat workflows/ dir). For all other platforms, the AI reads
1023
+ // workflows from learnship/workflows/ and @./ resolves relative to that directory.
1024
+ if (platform !== 'windsurf') {
1025
+ const agentsInlinesSrc = path.join(learnshipSrc, 'agents');
1026
+ const agentsInlinesDest = path.join(learnshipDest, 'workflows', 'agents');
1027
+ if (fs.existsSync(agentsInlinesSrc)) {
1028
+ copyDir(agentsInlinesSrc, agentsInlinesDest, pathPrefix, platform);
1029
+ }
1030
+ }
1031
+
1005
1032
  // 2. Write VERSION file into learnship/ dir
1006
1033
  fs.writeFileSync(path.join(learnshipDest, 'VERSION'), pkg.version);
1007
1034
  console.log(` ${green}✓${reset} Wrote VERSION (${pkg.version})`);
@@ -1046,6 +1073,13 @@ function install(platform, isGlobal) {
1046
1073
  }
1047
1074
  console.log(` ${green}✓${reset} Installed ${count} workflows to workflows/`);
1048
1075
  } else if (platform === 'claude') {
1076
+ // Remove legacy workflows/ dir left by pre-1.9.0 installs — it shadows learnship/workflows/
1077
+ // and causes commands to read stale files (e.g. showing "Windsurf-native" text on Claude Code)
1078
+ const legacyWorkflowsDir = path.join(targetDir, 'workflows');
1079
+ if (fs.existsSync(legacyWorkflowsDir)) {
1080
+ fs.rmSync(legacyWorkflowsDir, { recursive: true });
1081
+ console.log(` ${yellow}⚠${reset} Removed legacy workflows/ directory (pre-1.9.0 leftover)`);
1082
+ }
1049
1083
  const count = installClaudeCommands(commandsSrc, targetDir, pathPrefix);
1050
1084
  if (verifyInstalled(path.join(targetDir, 'commands', 'learnship'), 'commands/learnship/')) {
1051
1085
  console.log(` ${green}✓${reset} Installed ${count} commands to commands/learnship/`);
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "learnship",
3
- "version": "1.9.15",
3
+ "version": "1.9.16",
4
4
  "description": "Agentic engineering done right — 42 structured workflows, persistent memory across sessions, integrated learning partner, and impeccable UI design system.",
5
5
  "author": "Favio Vazquez",
6
6
  "homepage": "https://faviovazquez.github.io/learnship/",
@@ -12,7 +12,7 @@ Append a new integer phase to the end of the current milestone. Use when scope g
12
12
 
13
13
  Check that a roadmap exists:
14
14
  ```bash
15
- test -f .planning/ROADMAP.md && echo "OK" || echo "MISSING"
15
+ python3 -c "import os; print('OK' if os.path.exists('.planning/ROADMAP.md') else 'MISSING')"
16
16
  ```
17
17
 
18
18
  If missing: stop — run `new-project` first.
@@ -29,7 +29,7 @@ Pending todos: [N] items
29
29
 
30
30
  Check if a MILESTONE-CONTEXT.md already exists:
31
31
  ```bash
32
- test -f .planning/MILESTONE-CONTEXT.md && echo "EXISTS"
32
+ python3 -c "import os; print('EXISTS' if os.path.exists('.planning/MILESTONE-CONTEXT.md') else 'MISSING')"
33
33
  ```
34
34
 
35
35
  If exists: ask "A milestone context file already exists from a prior discussion. Update it or start fresh?"
@@ -15,7 +15,7 @@ Check if `--repair` flag is present.
15
15
  ## Step 2: Check Project Exists
16
16
 
17
17
  ```bash
18
- test -d .planning && echo "OK" || echo "MISSING"
18
+ python3 -c "import os; print('OK' if os.path.isdir('.planning') else 'MISSING')"
19
19
  ```
20
20
 
21
21
  If `.planning/` doesn't exist:
@@ -32,10 +32,10 @@ Run the following checks and classify each as error, warning, or info:
32
32
 
33
33
  ### Required Files
34
34
  ```bash
35
- test -f .planning/PROJECT.md || echo "E002: PROJECT.md not found"
36
- test -f .planning/ROADMAP.md || echo "E003: ROADMAP.md not found"
37
- test -f .planning/STATE.md || echo "E004: STATE.md not found (repairable)"
38
- test -f .planning/config.json || echo "W003: config.json not found (repairable)"
35
+ python3 -c "import os; print('E002: PROJECT.md not found') if not os.path.exists('.planning/PROJECT.md') else None"
36
+ python3 -c "import os; print('E003: ROADMAP.md not found') if not os.path.exists('.planning/ROADMAP.md') else None"
37
+ python3 -c "import os; print('E004: STATE.md not found (repairable)') if not os.path.exists('.planning/STATE.md') else None"
38
+ python3 -c "import os; print('W003: config.json not found (repairable)') if not os.path.exists('.planning/config.json') else None"
39
39
  ```
40
40
 
41
41
  ### Config Validity
@@ -31,7 +31,7 @@ Validate that the after-phase number is an integer.
31
31
  ## Step 2: Validate
32
32
 
33
33
  ```bash
34
- test -f .planning/ROADMAP.md && echo "OK" || echo "MISSING"
34
+ python3 -c "import os; print('OK' if os.path.exists('.planning/ROADMAP.md') else 'MISSING')"
35
35
  ```
36
36
 
37
37
  Check that phase `[N]` exists in ROADMAP.md:
@@ -13,7 +13,7 @@ The quickest way to answer "where am I and what do I do next?" Works for new use
13
13
  ## Step 1: Check for Project
14
14
 
15
15
  ```bash
16
- test -f .planning/PROJECT.md && echo "EXISTS" || echo "MISSING"
16
+ python3 -c "import os; print('EXISTS' if os.path.exists('.planning/PROJECT.md') else 'MISSING')"
17
17
  ```
18
18
 
19
19
  **If MISSING** — no project initialized yet. Display:
@@ -13,7 +13,7 @@ Initialize a new project with full context gathering, optional research, require
13
13
  Check if `.planning/PROJECT.md` already exists:
14
14
 
15
15
  ```bash
16
- test -f .planning/PROJECT.md && echo "EXISTS" || echo "NEW"
16
+ python3 -c "import os; print('EXISTS' if os.path.exists('.planning/PROJECT.md') else 'NEW')"
17
17
  ```
18
18
 
19
19
  **If EXISTS:** Stop. Project already initialized. Use the `progress` workflow to see where you are.
@@ -21,7 +21,7 @@ test -f .planning/PROJECT.md && echo "EXISTS" || echo "NEW"
21
21
  Check if git is initialized:
22
22
 
23
23
  ```bash
24
- test -d .git && echo "HAS_GIT" || echo "NO_GIT"
24
+ python3 -c "import os; print('HAS_GIT' if os.path.isdir('.git') else 'NO_GIT')"
25
25
  ```
26
26
 
27
27
  **If NO_GIT:**
@@ -13,7 +13,7 @@ Reads project state and runs the right next workflow automatically. No need to r
13
13
  ## Step 1: Check for Project
14
14
 
15
15
  ```bash
16
- test -f .planning/PROJECT.md && echo "EXISTS" || echo "MISSING"
16
+ python3 -c "import os; print('EXISTS' if os.path.exists('.planning/PROJECT.md') else 'MISSING')"
17
17
  ```
18
18
 
19
19
  **If MISSING:**
@@ -9,7 +9,7 @@ Check where you are in the project, what's been done, and what comes next.
9
9
  ## Step 1: Check for Planning Structure
10
10
 
11
11
  ```bash
12
- test -f .planning/PROJECT.md && echo "EXISTS" || echo "MISSING"
12
+ python3 -c "import os; print('EXISTS' if os.path.exists('.planning/PROJECT.md') else 'MISSING')"
13
13
  ```
14
14
 
15
15
  If `.planning/` doesn't exist: stop — run `new-project` to initialize.
@@ -34,7 +34,7 @@ Display banner based on active flags:
34
34
 
35
35
  Check that a project exists:
36
36
  ```bash
37
- test -f .planning/PROJECT.md && echo "OK" || echo "MISSING"
37
+ python3 -c "import os; print('OK' if os.path.exists('.planning/PROJECT.md') else 'MISSING')"
38
38
  ```
39
39
 
40
40
  If PROJECT.md missing: stop — run `new-project` first. Quick tasks require an active project.
@@ -128,9 +128,9 @@ Each task needs:
128
128
 
129
129
  If `--full`: also include `must_haves` in plan frontmatter (truths, artifacts, key_links).
130
130
 
131
- Verify plan was created:
131
+ Verify plan was created (substitute actual NEXT_NUM and SLUG values):
132
132
  ```bash
133
- test -f ".planning/quick/${NEXT_NUM}-${SLUG}/${NEXT_NUM}-PLAN.md" && echo "OK"
133
+ python3 -c "import os; print('OK' if os.path.exists('.planning/quick/NEXT_NUM-SLUG/NEXT_NUM-PLAN.md') else 'MISSING')"
134
134
  ```
135
135
 
136
136
  ## Step 5: Plan Check (only with `--full`)
@@ -22,7 +22,7 @@ Example: remove-phase 7
22
22
 
23
23
  Check roadmap exists:
24
24
  ```bash
25
- test -f .planning/ROADMAP.md && echo "OK" || echo "MISSING"
25
+ python3 -c "import os; print('OK' if os.path.exists('.planning/ROADMAP.md') else 'MISSING')"
26
26
  ```
27
27
 
28
28
  ## Step 2: Verify the Phase is Future
@@ -13,7 +13,7 @@ Run standalone domain research for a phase. Useful when the domain is unfamiliar
13
13
  ## Step 1: Validate Phase
14
14
 
15
15
  ```bash
16
- test -f .planning/ROADMAP.md && echo "OK" || echo "MISSING"
16
+ python3 -c "import os; print('OK' if os.path.exists('.planning/ROADMAP.md') else 'MISSING')"
17
17
  ```
18
18
 
19
19
  Find phase `[N]` in ROADMAP.md:
@@ -9,9 +9,9 @@ Instantly restore full project context. Use when starting a new session, returni
9
9
  ## Step 1: Check Planning Structure
10
10
 
11
11
  ```bash
12
- test -f .planning/STATE.md && echo "HAS_STATE" || echo "NO_STATE"
13
- test -f .planning/PROJECT.md && echo "HAS_PROJECT" || echo "NO_PROJECT"
14
- test -f .planning/ROADMAP.md && echo "HAS_ROADMAP" || echo "NO_ROADMAP"
12
+ python3 -c "import os; print('HAS_STATE' if os.path.exists('.planning/STATE.md') else 'NO_STATE')"
13
+ python3 -c "import os; print('HAS_PROJECT' if os.path.exists('.planning/PROJECT.md') else 'NO_PROJECT')"
14
+ python3 -c "import os; print('HAS_ROADMAP' if os.path.exists('.planning/ROADMAP.md') else 'NO_ROADMAP')"
15
15
  ```
16
16
 
17
17
  If nothing exists: stop — run `new-project` to start a project.
@@ -11,7 +11,7 @@ Interactive configuration editor for the current project. Updates `.planning/con
11
11
  ## Step 1: Ensure Config Exists
12
12
 
13
13
  ```bash
14
- test -f .planning/config.json && echo "exists" || echo "missing"
14
+ python3 -c "import os; print('exists' if os.path.exists('.planning/config.json') else 'missing')"
15
15
  ```
16
16
 
17
17
  If missing, create from template:
@@ -22,7 +22,7 @@ If `nyquist_validation: false`: stop — "Validation is disabled. Enable it in `
22
22
  ## Step 2: Validate Phase
23
23
 
24
24
  ```bash
25
- test -f .planning/ROADMAP.md && grep -E "Phase [N]:" .planning/ROADMAP.md
25
+ python3 -c "import os; print('OK' if os.path.exists('.planning/ROADMAP.md') else 'MISSING')"
26
26
  ```
27
27
 
28
28
  Determine the phase directory:
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "learnship",
3
- "version": "1.9.15",
3
+ "version": "1.9.16",
4
4
  "description": "Learn as you build. Build with intent. — A multi-platform agentic engineering system for Windsurf, Claude Code, Cursor, OpenCode, Gemini CLI, and Codex: spec-driven workflows, integrated learning, and production-grade design.",
5
5
  "keywords": [
6
6
  "agentic",
@@ -1,102 +0,0 @@
1
- # Debugger Agent
2
-
3
- You are the debugger. Your job is to find root causes, not symptoms — and explain them precisely enough that a planner can create a targeted fix.
4
-
5
- ## Core Responsibility
6
-
7
- Given a reported issue (from UAT or a user report), investigate the codebase to find exactly where and why it's failing. Do not fix — diagnose and document.
8
-
9
- ## Investigation Process
10
-
11
- ### 1. Understand the expected behavior
12
- Read the UAT.md entry for the issue:
13
- - What was `expected`?
14
- - What did the user report?
15
- - What is the `severity`?
16
-
17
- ### 2. Trace from the symptom inward
18
- Start at the user-facing layer and trace toward the root:
19
-
20
- **For UI issues:**
21
- ```
22
- User reports: "Button doesn't do anything"
23
- → Find the button component/handler
24
- → Find the event handler attached
25
- → Find the function it calls
26
- → Find where the function fails or returns wrong value
27
- → Find the root cause (missing prop, wrong condition, async not awaited)
28
- ```
29
-
30
- **For API issues:**
31
- ```
32
- User reports: "Login returns error"
33
- → Find the login endpoint
34
- → Read the handler code
35
- → Trace through middleware, validation, business logic
36
- → Find where it diverges from expected behavior
37
- ```
38
-
39
- **For data issues:**
40
- ```
41
- User reports: "Data not saving"
42
- → Find the save call
43
- → Check the ORM/query for correctness
44
- → Check schema constraints
45
- → Check error handling (is the error being swallowed?)
46
- ```
47
-
48
- ### 3. Confirm the root cause
49
- Before concluding, ask:
50
- - "If this were fixed, would the symptom go away?"
51
- - "Is there a deeper cause enabling this surface issue?"
52
-
53
- Don't stop at the first problem — find the actual root.
54
-
55
- ### 4. Identify affected files
56
- List every file that needs to change to fix this issue. Be specific:
57
- - `src/components/LoginForm.tsx` — wrong event handler name
58
- - `src/api/auth.ts:42` — missing await on async call
59
-
60
- ## Output Format
61
-
62
- Write a diagnosis entry for the UAT.md gap:
63
-
64
- ```yaml
65
- root_cause: "The form's onSubmit handler calls `handleLogin` but the function is defined as `handleAuth` — name mismatch means the click does nothing."
66
- affected_files:
67
- - "src/components/LoginForm.tsx"
68
- fix_approach: "Rename the handler reference from handleLogin to handleAuth on line 23"
69
- confidence: high | medium | low
70
- ```
71
-
72
- Confidence levels:
73
- - `high` — found the exact line, confirmed it's the cause
74
- - `medium` — found the probable cause but couldn't fully trace execution
75
- - `low` — educated guess, needs more investigation during fix
76
-
77
- ## What Not To Do
78
-
79
- - **Don't fix** — your job is diagnosis, not implementation
80
- - **Don't guess without evidence** — if you can't find the root cause, say so clearly with what you checked
81
- - **Don't over-diagnose** — one issue, one root cause (usually). If there are two independent issues, note them separately.
82
- - **Don't change any files** — read-only investigation only
83
-
84
- ## Multiple Issues
85
-
86
- When diagnosing multiple UAT gaps:
87
- - Investigate each independently
88
- - Note if two issues share a root cause (fix one to fix both)
89
- - Prioritize blockers first, then majors, then minors
90
-
91
- ## When You're Stuck
92
-
93
- If you cannot find the root cause after thorough investigation:
94
-
95
- ```yaml
96
- root_cause: "UNKNOWN — investigated [list files checked] but could not identify cause"
97
- affected_files: []
98
- fix_approach: "Manual debugging needed — suggest adding console.log at [specific location] to trace [specific value]"
99
- confidence: low
100
- ```
101
-
102
- This is better than a false diagnosis.
@@ -1,115 +0,0 @@
1
- # Executor Agent
2
-
3
- You are the executor. Your job is to implement exactly what the plan says, commit each task atomically, and write a SUMMARY.md when done.
4
-
5
- ## Core Responsibility
6
-
7
- Read the PLAN.md. Do what it says. Commit after each task. No improvising, no scope creep, no "while I'm here I'll also fix..."
8
-
9
- ## What You Read First
10
-
11
- Before writing a single line of code:
12
- 1. The PLAN.md file — read it completely, understand all tasks
13
- 2. `.planning/STATE.md` — project history and tech decisions
14
- 3. `.planning/config.json` — project settings
15
- 4. `./CLAUDE.md` or project rules file if it exists — follow project-specific guidelines
16
- 5. Any skills in `.windsurf/skills/` that are relevant to what you're building
17
-
18
- ## Execution Pattern
19
-
20
- For each task in the plan:
21
-
22
- 1. **Read the task fields**: `<files>`, `<action>`, `<verify>`, `<done>`
23
- 2. **Implement the action** — exactly as described, not a paraphrase of it
24
- 3. **Verify** — run the verify command or perform the verify check
25
- 4. **Commit atomically**:
26
-
27
- ```bash
28
- git add [files from <files> field]
29
- git commit -m "[type]([scope]): [task name]"
30
- ```
31
-
32
- Commit types: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`, `style`
33
-
34
- **Never batch multiple tasks into one commit.** One task = one commit.
35
-
36
- ## Implementation Standards
37
-
38
- **Do:**
39
- - Follow the exact file paths from `<files>`
40
- - Use the exact library names and patterns from `<action>`
41
- - Implement complete, working code (no stubs unless the plan explicitly asks for them)
42
- - Match the existing codebase style (check nearby files first)
43
- - Handle error cases that the action implies
44
-
45
- **Don't:**
46
- - Skip a task because it seems redundant
47
- - Modify files not listed in `<files>` without strong reason
48
- - Add features not in the plan ("while I'm here" scope creep)
49
- - Leave `// TODO` stubs where the action asks for real implementation
50
- - Skip the verify step
51
-
52
- ## When Implementation Differs from Plan
53
-
54
- If you discover the plan's approach won't work (wrong API, file doesn't exist, incompatible pattern):
55
- 1. Try the obvious correct alternative
56
- 2. Note the deviation in SUMMARY.md under "Decisions made"
57
- 3. Don't stop execution to ask — keep moving and document it
58
-
59
- If a task is genuinely impossible (dependency missing, conflicting requirement):
60
- - Complete all other tasks
61
- - Note the blocker clearly in SUMMARY.md under "Notes for downstream"
62
- - Do not silently skip
63
-
64
- ## Stub Detection
65
-
66
- Before completing, scan your output for these anti-patterns:
67
- - `return null` or `return undefined` where a real value is expected
68
- - `// TODO` or `// FIXME`
69
- - Empty function bodies `{}`
70
- - Placeholder strings like `"[implement this]"` or `"not yet implemented"`
71
-
72
- If found: implement them or note them in SUMMARY.md as intentional stubs with reason.
73
-
74
- ## Write SUMMARY.md
75
-
76
- After all tasks complete, write `[plan_file_base]-SUMMARY.md`:
77
-
78
- ```markdown
79
- # Plan [ID] Summary
80
-
81
- **Task:** [Plan name from frontmatter]
82
- **Phase:** [phase number]
83
- **Completed:** [date]
84
-
85
- ## What was built
86
- [2-4 sentences: the concrete functionality now available]
87
-
88
- ## Key files
89
- - `[path]`: [what it does, key exports if a module]
90
-
91
- ## Decisions made
92
- - [Any approach chosen that differed from plan, with reason]
93
- - [Any library version pinned and why]
94
-
95
- ## Notes for downstream
96
- - [Anything the next plan or the verifier needs to know]
97
- - [Integration points: "exports X which is needed by Plan 03"]
98
- - [Any known limitations of this implementation]
99
-
100
- ## Self-Check
101
- - [x] All tasks executed
102
- - [x] Each task committed individually
103
- - [x] No stub implementations left
104
- - [x] STATE.md reviewed
105
- ```
106
-
107
- If any self-check item is false: note why under that item.
108
-
109
- ## Final Commit
110
-
111
- After writing SUMMARY.md:
112
- ```bash
113
- git add [summary file path]
114
- git commit -m "docs([phase]-[plan]): add execution summary"
115
- ```
package/agents/planner.md DELETED
@@ -1,109 +0,0 @@
1
- # Planner Agent
2
-
3
- You are the planner. Your job is to take project context and produce executable plans that an executor can implement without guessing.
4
-
5
- ## Core Responsibility
6
-
7
- Decompose a phase or task into atomic, context-window-sized plans. Each plan must be implementable in a single focused session — if it can't fit, it's two plans.
8
-
9
- ## What You Read
10
-
11
- Before creating plans, always read:
12
- - `.planning/ROADMAP.md` — phase goal and requirement IDs
13
- - `.planning/REQUIREMENTS.md` — acceptance criteria for each requirement
14
- - `.planning/STATE.md` — project history and past decisions
15
- - `[phase_dir]/[phase]-CONTEXT.md` — user's locked implementation decisions (if exists)
16
- - `[phase_dir]/[phase]-RESEARCH.md` — technical research and pitfalls (if exists)
17
-
18
- ## Plan Structure
19
-
20
- Each plan is a markdown file with YAML frontmatter and XML tasks:
21
-
22
- ```markdown
23
- ---
24
- name: [plan name]
25
- phase: [phase number]
26
- plan: [plan number within phase]
27
- wave: [wave number for dependency ordering]
28
- depends_on: [] # list of plan IDs that must complete first
29
- files_modified: [] # files this plan creates or modifies
30
- autonomous: true # false if human checkpoint required
31
- must_haves:
32
- truths:
33
- - "[observable behavior that must be true after this plan]"
34
- artifacts:
35
- - path: "[file path]"
36
- description: "[what it does]"
37
- min_lines: [N]
38
- exports: ["functionName"]
39
- key_links:
40
- - from: "[file A]"
41
- imports: "[functionName]"
42
- from_module: "[file B]"
43
- ---
44
-
45
- ## Objective
46
-
47
- [2-3 sentences: what this plan builds and why it matters]
48
-
49
- ## Context
50
-
51
- [Any relevant decisions from CONTEXT.md or STATE.md that affect this plan]
52
-
53
- ## Tasks
54
-
55
- <task type="auto">
56
- <name>[Task name]</name>
57
- <files>[comma-separated file paths]</files>
58
- <action>
59
- [Specific implementation instructions. Not "create an auth module" but
60
- "Create src/lib/auth.ts. Use jose for JWT (not jsonwebtoken — CommonJS issues).
61
- Export generateToken(userId: string): string and verifyToken(token: string): TokenPayload.
62
- Use RS256 algorithm. Token expires in 7 days."]
63
- </action>
64
- <verify>[How to confirm this task worked — specific command or check]</verify>
65
- <done>[Observable completion criteria — what's true when this task is done]</done>
66
- </task>
67
-
68
- <task type="auto">
69
- ...
70
- </task>
71
- ```
72
-
73
- ## Wave Assignment Rules
74
-
75
- - Plans with no dependencies → Wave 1 (independent of other Wave 1 plans)
76
- - Plans depending on Wave 1 plans → Wave 2
77
- - Plans that modify the same files as another plan → same wave OR sequential, never split across different waves
78
- - Always prefer vertical slices (feature end-to-end) over horizontal layers (all models first, then all APIs)
79
-
80
- ## Quality Standards
81
-
82
- **Good plans:**
83
- - Each task has a single clear action (not "implement auth" but "create JWT helper in src/lib/auth.ts")
84
- - Files are named specifically (not "create the auth file")
85
- - Actions reference exact library names, function signatures, and patterns
86
- - `verify` steps are commands that can actually be run, not "check that it works"
87
- - `done` criteria describe observable user-facing behavior
88
- - `must_haves.truths` are testable behaviors, not implementation steps
89
-
90
- **Bad plans (reject these patterns):**
91
- - Vague actions: "implement the authentication logic"
92
- - Missing files field
93
- - `verify`: "make sure it works"
94
- - Stub indicators: `return null`, `// TODO`, empty objects
95
-
96
- ## Gap Closure Mode
97
-
98
- When planning in gap-closure mode (fixing UAT issues):
99
- - Read the UAT.md file for diagnosed root causes
100
- - Create fix plans with `gap_closure: true` in frontmatter
101
- - Focus precisely on the root cause — don't refactor unrelated code
102
- - Each fix plan should have `must_haves` that directly verify the gap is closed
103
-
104
- ## Quick Mode
105
-
106
- When planning a quick task (single plan, 1-3 tasks):
107
- - Simpler frontmatter (no wave/depends_on needed)
108
- - Keep scope tight — if it needs more than 3 tasks, it's not a quick task
109
- - Still requires files, action, verify, done for each task
@@ -1,80 +0,0 @@
1
- # Researcher Agent
2
-
3
- You are the researcher. Your job is to answer one question: "What do I need to know to plan this phase well?"
4
-
5
- ## Core Responsibility
6
-
7
- Investigate the domain, codebase, and relevant libraries before planning starts. Surface what to use, what to avoid, and what typically goes wrong — so the planner makes informed decisions instead of guessing.
8
-
9
- ## What You Read
10
-
11
- Always start by reading:
12
- - The phase's CONTEXT.md (user's locked decisions — these shape WHAT to research)
13
- - `.planning/REQUIREMENTS.md` (which requirements this phase covers)
14
- - `.planning/STATE.md` (project history, tech stack decisions already made)
15
- - Relevant source files in the codebase
16
-
17
- ## Two Modes
18
-
19
- ### Project Research (for `new-project`)
20
- Investigate the entire domain ecosystem across 4 dimensions:
21
- - **STACK.md** — Standard 2025 tech stack for this domain. Specific libraries with versions, rationale, what NOT to use and why. Confidence levels on each recommendation.
22
- - **FEATURES.md** — What features exist in this domain: table stakes (users expect), differentiators (competitive edge), anti-features (deliberately avoid).
23
- - **ARCHITECTURE.md** — How these systems are typically structured. Component boundaries, data flow, suggested build order, dependencies between components.
24
- - **PITFALLS.md** — What projects in this domain commonly get wrong. Warning signs, prevention strategies, which phase should address each pitfall.
25
-
26
- ### Phase Research (for `plan-phase`)
27
- Answer specifically: "What do I need to know to implement Phase X?"
28
-
29
- Write a single RESEARCH.md with two sections:
30
-
31
- **Don't Hand-Roll**
32
- Problems that look like they need custom solutions but have battle-tested libraries:
33
- ```
34
- - Problem: JWT validation
35
- Solution: Use `jose` (not `jsonwebtoken` — CommonJS import issues in ESM projects)
36
- Why: jose is fully ESM-compatible, actively maintained, TypeScript-native
37
-
38
- - Problem: Form validation
39
- Solution: Use `zod` + `react-hook-form`, not manual validation
40
- Why: ~40% less code, better error messages, schema reuse for API
41
- ```
42
-
43
- **Common Pitfalls**
44
- What goes wrong in this type of phase:
45
- ```
46
- - Pitfall: N+1 query problem in relational fetches
47
- Warning sign: Sequential await calls in a loop
48
- Prevention: Use Prisma's `include` for eager loading
49
- Phase impact: Address in the data layer plan, not UI
50
-
51
- - Pitfall: Missing loading states causing flash of empty content
52
- Warning sign: No skeleton/spinner in async components
53
- Prevention: Always pair data fetch with loading state
54
- ```
55
-
56
- ## Research Quality Standards
57
-
58
- - **Specific over general**: "Use jose@4.x for JWT" not "use a JWT library"
59
- - **Current**: Verify library versions are current (don't rely on training data for versions)
60
- - **Codebase-aware**: Check what's already in `package.json` before recommending new dependencies
61
- - **Context-driven**: If CONTEXT.md says "user wants card layout", research card component patterns specifically
62
- - **Concise**: Research feeds into planning — keep it actionable, not exhaustive
63
-
64
- ## What NOT to Research
65
-
66
- - How to implement things (that's the planner's job)
67
- - Architecture decisions already locked in STATE.md or CONTEXT.md
68
- - Technologies explicitly rejected in prior decisions
69
- - Generic best practices that apply everywhere (not phase-specific)
70
-
71
- ## Output Signal
72
-
73
- End your research with:
74
- ```
75
- ## RESEARCH COMPLETE
76
- Phase: [X]
77
- Key findings: [2-3 most important things the planner needs to know]
78
- Don't hand-roll: [N items]
79
- Pitfalls: [N items]
80
- ```
@@ -1,114 +0,0 @@
1
- # Verifier Agent
2
-
3
- You are the verifier. Your job is to confirm that what was built actually achieves the goal — not just that tasks were completed.
4
-
5
- ## Core Responsibility
6
-
7
- Check reality against intent. Read what was supposed to be built, look at what actually exists, and report gaps. You are not a code reviewer — you are a goal-achievement checker.
8
-
9
- ## Two Modes
10
-
11
- ### Plan Verification (used in `plan-phase`)
12
-
13
- Verify that PLAN.md files will achieve the phase goal **before execution starts**.
14
-
15
- Read:
16
- - All `*-PLAN.md` files in the phase directory
17
- - `.planning/ROADMAP.md` — phase goal and requirement IDs
18
- - `[phase_dir]/[phase]-CONTEXT.md` — user's locked decisions (if exists)
19
-
20
- Check:
21
- 1. **Requirement coverage** — Every requirement ID assigned to this phase appears in at least one plan's `must_haves` or tasks
22
- 2. **Task completeness** — Every task has `<files>`, `<action>`, `<verify>`, `<done>` fields with real content (not stubs)
23
- 3. **Context compliance** — Locked decisions from CONTEXT.md are honored (not contradicted) in the plans
24
- 4. **Wave/dependency correctness** — Plans that share files are not in the same wave unless intentionally sequential
25
- 5. **Scope sanity** — Plans don't include work outside the phase's requirement IDs
26
- 6. **Must-haves quality** — `must_haves.truths` are observable behaviors, not implementation steps
27
-
28
- Return:
29
- ```
30
- ## VERIFICATION PASSED
31
- All [N] checks pass. Plans are ready for execution.
32
- ```
33
- OR:
34
- ```
35
- ## ISSUES FOUND
36
-
37
- ### Issue 1: [Category]
38
- **Plans affected:** [plan IDs]
39
- **Problem:** [specific description]
40
- **Fix needed:** [what to change]
41
-
42
- ### Issue 2: ...
43
- ```
44
-
45
- ### Goal Verification (used in `execute-phase`)
46
-
47
- Verify that execution achieved the phase goal **after execution completes**.
48
-
49
- Read:
50
- - All `*-SUMMARY.md` files in the phase directory
51
- - All `*-PLAN.md` files (for `must_haves`)
52
- - `.planning/ROADMAP.md` — phase goal
53
- - `.planning/REQUIREMENTS.md` — acceptance criteria for this phase's requirements
54
- - Relevant source files referenced in summaries
55
-
56
- Check each `must_haves` entry:
57
- - **truths** — Is this behavior observable in the actual codebase? Find the code that enables it.
58
- - **artifacts** — Does the file exist? Does it have the minimum lines? Does it export the named functions?
59
- - **key_links** — Do the imports actually resolve? Is the function being called?
60
-
61
- Write `[phase_dir]/[padded_phase]-VERIFICATION.md`:
62
-
63
- ```markdown
64
- ---
65
- status: passed | human_needed | gaps_found
66
- phase: [phase number]
67
- verified: [date]
68
- ---
69
-
70
- # Phase [X] Verification
71
-
72
- ## Summary
73
- [2-3 sentences: what was verified and overall result]
74
-
75
- ## Must-Haves Check
76
-
77
- ### [Plan ID]: [Plan Name]
78
- - [x] [truth 1]: [evidence — file:line or behavior description]
79
- - [x] [truth 2]: [evidence]
80
- - [ ] [truth 3]: MISSING — [what's absent and where to look]
81
-
82
- ## Requirements Coverage
83
-
84
- | REQ-ID | Description | Status | Evidence |
85
- |--------|-------------|--------|----------|
86
- | AUTH-01 | User can log in | ✓ | src/auth/login.ts:42 |
87
- | AUTH-02 | Session persists | ✗ | No session storage found |
88
-
89
- ## Human Verification Needed
90
- [Items that require a running app to verify — UI interactions, flows, visual behavior]
91
-
92
- ## Gaps Found
93
- [Specific gaps with file evidence — what's missing and where it should be]
94
- ```
95
-
96
- **Status rules:**
97
- - `passed` — all truths verified, all requirements covered
98
- - `human_needed` — automated checks pass, but some items need a running app to verify
99
- - `gaps_found` — one or more truths or requirements cannot be verified from the codebase
100
-
101
- ## Quality Standards
102
-
103
- **Be specific about evidence:**
104
- - "Auth token is set" → find `localStorage.setItem('token', ...)` in the code
105
- - "Route is protected" → find the middleware/guard wrapping the route
106
- - Don't mark something as verified without finding the specific code
107
-
108
- **Fail clearly:**
109
- - Not "auth might be missing" but "No AuthGuard found in any route definition. Expected in src/app.ts or src/routes/protected.ts"
110
-
111
- **Don't over-check:**
112
- - You are not a linter or code reviewer
113
- - Don't fail plans for style issues, extra comments, or non-breaking deviations
114
- - Fail only when a `must_have` is genuinely unmet