@codename_inc/spectre 3.7.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +411 -0
- package/bin/spectre.js +8 -0
- package/package.json +23 -0
- package/plugins/spectre/.claude-plugin/plugin.json +5 -0
- package/plugins/spectre/agents/analyst.md +122 -0
- package/plugins/spectre/agents/dev.md +70 -0
- package/plugins/spectre/agents/finder.md +105 -0
- package/plugins/spectre/agents/patterns.md +207 -0
- package/plugins/spectre/agents/reviewer.md +128 -0
- package/plugins/spectre/agents/sync.md +151 -0
- package/plugins/spectre/agents/tester.md +209 -0
- package/plugins/spectre/agents/web-research.md +109 -0
- package/plugins/spectre/commands/architecture_review.md +120 -0
- package/plugins/spectre/commands/clean.md +313 -0
- package/plugins/spectre/commands/code_review.md +408 -0
- package/plugins/spectre/commands/create_plan.md +117 -0
- package/plugins/spectre/commands/create_tasks.md +374 -0
- package/plugins/spectre/commands/create_test_guide.md +120 -0
- package/plugins/spectre/commands/evaluate.md +50 -0
- package/plugins/spectre/commands/execute.md +87 -0
- package/plugins/spectre/commands/fix.md +61 -0
- package/plugins/spectre/commands/forget.md +58 -0
- package/plugins/spectre/commands/handoff.md +161 -0
- package/plugins/spectre/commands/kickoff.md +115 -0
- package/plugins/spectre/commands/learn.md +15 -0
- package/plugins/spectre/commands/plan.md +170 -0
- package/plugins/spectre/commands/plan_review.md +33 -0
- package/plugins/spectre/commands/quick_dev.md +101 -0
- package/plugins/spectre/commands/rebase.md +73 -0
- package/plugins/spectre/commands/recall.md +5 -0
- package/plugins/spectre/commands/research.md +159 -0
- package/plugins/spectre/commands/scope.md +119 -0
- package/plugins/spectre/commands/ship.md +172 -0
- package/plugins/spectre/commands/sweep.md +82 -0
- package/plugins/spectre/commands/test.md +380 -0
- package/plugins/spectre/commands/ux_spec.md +91 -0
- package/plugins/spectre/commands/validate.md +343 -0
- package/plugins/spectre/hooks/hooks.json +34 -0
- package/plugins/spectre/hooks/scripts/bootstrap.cjs +99 -0
- package/plugins/spectre/hooks/scripts/handoff-resume.cjs +410 -0
- package/plugins/spectre/hooks/scripts/lib.cjs +83 -0
- package/plugins/spectre/hooks/scripts/load-knowledge.cjs +120 -0
- package/plugins/spectre/hooks/scripts/precompact-warning.cjs +19 -0
- package/plugins/spectre/hooks/scripts/register_learning.cjs +144 -0
- package/plugins/spectre/hooks/scripts/test_bootstrap.cjs +84 -0
- package/plugins/spectre/hooks/scripts/test_handoff-resume.cjs +858 -0
- package/plugins/spectre/hooks/scripts/test_load-knowledge.cjs +285 -0
- package/plugins/spectre/hooks/scripts/test_register-learning.cjs +146 -0
- package/plugins/spectre/skills/spectre-apply/SKILL.md +189 -0
- package/plugins/spectre/skills/spectre-guide/SKILL.md +358 -0
- package/plugins/spectre/skills/spectre-learn/SKILL.md +635 -0
- package/plugins/spectre/skills/spectre-learn/references/recall-template.md +31 -0
- package/plugins/spectre/skills/spectre-tdd/SKILL.md +111 -0
- package/src/config.test.js +134 -0
- package/src/install.test.js +273 -0
- package/src/lib/config.js +516 -0
- package/src/lib/constants.js +60 -0
- package/src/lib/doctor.js +168 -0
- package/src/lib/install.js +482 -0
- package/src/lib/knowledge.js +217 -0
- package/src/lib/paths.js +98 -0
- package/src/lib/project.js +473 -0
- package/src/main.js +150 -0
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Investigate bugs & implement fixes - primary agent
|
|
3
|
+
---
|
|
4
|
+
# fix: Analyze bug and recommend fix
|
|
5
|
+
|
|
6
|
+
## Description
|
|
7
|
+
|
|
8
|
+
- **What** — Hypothesize root causes, investigate in parallel, recommend fix with logging
|
|
9
|
+
- **Outcome** — Root cause identified, solution recommendation with `[🪳 TEMP]` debug logging
|
|
10
|
+
|
|
11
|
+
## Variables
|
|
12
|
+
|
|
13
|
+
### Dynamic Variables
|
|
14
|
+
|
|
15
|
+
- `bug_report`: Error details, repro steps, context — (via ARGUMENTS: $ARGUMENTS)
|
|
16
|
+
|
|
17
|
+
### Static Variables
|
|
18
|
+
|
|
19
|
+
- `debug_prefix`: \[🪳 TEMP {TOPIC}\]
|
|
20
|
+
|
|
21
|
+
## ARGUMENTS Input
|
|
22
|
+
|
|
23
|
+
<ARGUMENTS> $ARGUMENTS </ARGUMENTS>
|
|
24
|
+
|
|
25
|
+
## Step (1/5) - Gather Bug Context
|
|
26
|
+
|
|
27
|
+
- **Action** — CheckInput: Verify bug report provided
|
|
28
|
+
- **If**: ARGUMENTS empty
|
|
29
|
+
- **Then**: Ask user for error message, repro steps, and relevant context
|
|
30
|
+
- **Else**: Use ARGUMENTS as bug report; request missing details if needed
|
|
31
|
+
- **Wait** — Bug report with error details and repro steps
|
|
32
|
+
|
|
33
|
+
## Step (2/5) - Generate Hypotheses
|
|
34
|
+
|
|
35
|
+
- **Action** — Brainstorm: Reflect on 5-7 possible sources of the problem
|
|
36
|
+
- **Action** — Prioritize: Distill to 1-2 most likely root causes
|
|
37
|
+
- Consider: the primary data flow for this component/module, recent changes, error patterns, stack traces, affected code paths
|
|
38
|
+
|
|
39
|
+
## Step (3/5) - Investigate in Parallel
|
|
40
|
+
|
|
41
|
+
- **Action** — DispatchAgents: Spawn parallel `@spectre:analyst` subagents to investigate top hypotheses
|
|
42
|
+
- Each agent gets one hypothesis to trace through codebase
|
|
43
|
+
- Agents search for: relevant code, recent commits, similar patterns, edge cases
|
|
44
|
+
|
|
45
|
+
## Step (4/5) - Summarize Findings
|
|
46
|
+
|
|
47
|
+
- **Action** — Synthesize: Summarize findings and solution recommendation
|
|
48
|
+
- Include: root cause, affected files, proposed fix approach
|
|
49
|
+
- **Rule**: Solution must include `{debug_prefix}` logging to verify fix and gather data if fix fails
|
|
50
|
+
- **Action** — HoldForApproval: Present analysis; do NOT write code yet
|
|
51
|
+
- **Wait** — User approval before implementing fix
|
|
52
|
+
|
|
53
|
+
## Step (5/5) - Execute
|
|
54
|
+
|
|
55
|
+
- **Action** — Load TDD Skill: Load @spectre:spectre-tdd SKILL to use TDD
|
|
56
|
+
- **Action** — Execute Fix: Add Logs and Implement Fix using TDD
|
|
57
|
+
- **Action** — When finished, summarize what you delivered, including providing specific steps for the user to validate.
|
|
58
|
+
|
|
59
|
+
## Next Steps
|
|
60
|
+
|
|
61
|
+
Use the spectre-guide Skills and render the Next Steps Footer per the skill guidance
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Clear session memory - archive all session files so next session starts fresh
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# forget: Clear Session Memory
|
|
6
|
+
|
|
7
|
+
## Description
|
|
8
|
+
- **What** — Archive all session files (handoffs, todos, history) so the SessionStart hook doesn't auto-resume
|
|
9
|
+
- **Outcome** — All session files moved to archive, user informed to start fresh session
|
|
10
|
+
|
|
11
|
+
## Step (1/2) - Archive Session Logs
|
|
12
|
+
|
|
13
|
+
- **Action** — ArchiveLogs: Move session logs to archive directory
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo unknown)
|
|
17
|
+
session_dir="docs/tasks/${branch}/session_logs"
|
|
18
|
+
archive_dir="${session_dir}/archive"
|
|
19
|
+
|
|
20
|
+
# Check if session logs exist
|
|
21
|
+
if [ ! -d "$session_dir" ] || [ -z "$(ls -A ${session_dir}/*.json 2>/dev/null)" ]; then
|
|
22
|
+
echo "NO_SESSIONS"
|
|
23
|
+
exit 0
|
|
24
|
+
fi
|
|
25
|
+
|
|
26
|
+
# Create archive and move all session files
|
|
27
|
+
mkdir -p "$archive_dir"
|
|
28
|
+
mv ${session_dir}/*_handoff.json "$archive_dir/" 2>/dev/null || true
|
|
29
|
+
mv ${session_dir}/*_todos.json "$archive_dir/" 2>/dev/null || true
|
|
30
|
+
mv ${session_dir}/todos_history.json "$archive_dir/" 2>/dev/null || true
|
|
31
|
+
|
|
32
|
+
# Count archived
|
|
33
|
+
archived_count=$(ls -1 ${archive_dir}/*_handoff.json 2>/dev/null | wc -l | xargs)
|
|
34
|
+
echo "ARCHIVED:${archived_count}"
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## Step (2/2) - Confirm to User
|
|
38
|
+
|
|
39
|
+
- **Action** — ConfirmCleared: Based on bash output, inform user
|
|
40
|
+
|
|
41
|
+
**If** output is `NO_SESSIONS`:
|
|
42
|
+
> No session logs found for this branch. Memory is already clear.
|
|
43
|
+
|
|
44
|
+
**Else** (output is `ARCHIVED:N`):
|
|
45
|
+
> ✓ Session memory cleared
|
|
46
|
+
>
|
|
47
|
+
> Archived {N} handoff file(s) to `docs/tasks/{branch}/session_logs/archive/`
|
|
48
|
+
>
|
|
49
|
+
> **Next**: Start a new session with `/clear` or close this terminal. Your next session will start fresh without auto-loaded context.
|
|
50
|
+
|
|
51
|
+
## Success Criteria
|
|
52
|
+
|
|
53
|
+
- [ ] Session logs directory checked for existence
|
|
54
|
+
- [ ] All `*_handoff.json` files moved to `archive/` subdirectory
|
|
55
|
+
- [ ] All `*_todos.json` files moved to `archive/` subdirectory
|
|
56
|
+
- [ ] `todos_history.json` moved to `archive/` subdirectory
|
|
57
|
+
- [ ] User informed of result (no sessions found OR count archived)
|
|
58
|
+
- [ ] Clear instructions provided for starting fresh session
|
|
@@ -0,0 +1,161 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Save state snapshot to session_logs for session resume
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# handoff: Fast Session State Snapshot
|
|
6
|
+
|
|
7
|
+
Generate progress update, gather context, output structured JSON for session resume. Output: `{timestamp}_handoff.json` in session_logs.
|
|
8
|
+
|
|
9
|
+
**Performance Target**: 2-3 tool calls depending on session history
|
|
10
|
+
|
|
11
|
+
**CRITICAL**: Do not narrate or explain what you're doing. No "Session count is 0, so..." or "Let me gather context...". Just execute the steps silently and output ONLY the final confirmation message. Every token matters at end of session.
|
|
12
|
+
|
|
13
|
+
## ARGUMENTS
|
|
14
|
+
|
|
15
|
+
<ARGUMENTS>
|
|
16
|
+
$ARGUMENTS
|
|
17
|
+
</ARGUMENTS>
|
|
18
|
+
|
|
19
|
+
## Step 1: Gather Context (Single Bash Call)
|
|
20
|
+
|
|
21
|
+
- **Action** — GatherContext: Run ONE bash command:
|
|
22
|
+
|
|
23
|
+
```bash
|
|
24
|
+
branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo unknown)
|
|
25
|
+
mkdir -p "docs/tasks/${branch}/session_logs"
|
|
26
|
+
|
|
27
|
+
# Count existing session logs for conditional flow
|
|
28
|
+
session_count=$(ls docs/tasks/${branch}/session_logs/*_handoff.json 2>/dev/null | wc -l | xargs)
|
|
29
|
+
|
|
30
|
+
beads_available=false
|
|
31
|
+
beads_tasks='[]'
|
|
32
|
+
beads_count=0
|
|
33
|
+
|
|
34
|
+
if command -v bd &>/dev/null && bd doctor &>/dev/null; then
|
|
35
|
+
beads_available=true
|
|
36
|
+
open=$(bd list --label "$branch" --status open --json 2>/dev/null || echo '[]')
|
|
37
|
+
in_prog=$(bd list --label "$branch" --status in_progress --json 2>/dev/null || echo '[]')
|
|
38
|
+
blocked=$(bd list --label "$branch" --status blocked --json 2>/dev/null || echo '[]')
|
|
39
|
+
beads_tasks=$(echo "$open $in_prog $blocked" | jq -s 'add // []')
|
|
40
|
+
beads_count=$(echo "$beads_tasks" | jq 'length' 2>/dev/null || echo 0)
|
|
41
|
+
fi
|
|
42
|
+
|
|
43
|
+
cat << EOF
|
|
44
|
+
{
|
|
45
|
+
"branch": "$branch",
|
|
46
|
+
"commit": "$(git rev-parse --short HEAD 2>/dev/null || echo unknown)",
|
|
47
|
+
"wip_count": $(git status --porcelain 2>/dev/null | wc -l | xargs),
|
|
48
|
+
"ts": "$(date +%Y-%m-%d-%H%M%S)",
|
|
49
|
+
"session_count": $session_count,
|
|
50
|
+
"beads_available": $beads_available,
|
|
51
|
+
"beads_count": $beads_count,
|
|
52
|
+
"beads": $beads_tasks
|
|
53
|
+
}
|
|
54
|
+
EOF
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
**Output**: JSON with branch, commit, wip_count, ts, session_count, beads_available, beads_count, beads[]
|
|
58
|
+
|
|
59
|
+
## Step 2: Compose Handoff Data
|
|
60
|
+
|
|
61
|
+
- **Action** — ComposeProgressUpdate: From session memory, compose using "WE" voice:
|
|
62
|
+
|
|
63
|
+
| Field | Required | Description |
|
|
64
|
+
|-------|----------|-------------|
|
|
65
|
+
| summary | ✓ | Slack-style paragraph a human would read |
|
|
66
|
+
| goal | ✓ | What we're building + success criteria |
|
|
67
|
+
| accomplished | ✓ | What we completed (2-5 bullets) |
|
|
68
|
+
| now | ✓ | **What you were actively working on when session ended** (critical!) |
|
|
69
|
+
| next_steps | ✓ | Upcoming work (2-4 bullets) |
|
|
70
|
+
| confidence | ✓ | high / medium / low |
|
|
71
|
+
| constraints | | Known constraints or assumptions |
|
|
72
|
+
| decisions | | Key decisions made (0-3 bullets) |
|
|
73
|
+
| blockers | | Things blocking progress |
|
|
74
|
+
| open_questions | | Questions needing answers |
|
|
75
|
+
| risks | | Identified risks |
|
|
76
|
+
|
|
77
|
+
**Tone**: "We finished the auth refactor and got tests passing. Hit a snag with OAuth callback - next we'll tackle session management."
|
|
78
|
+
|
|
79
|
+
- **Action** — BuildWorkingSet: Capture active context:
|
|
80
|
+
- `key_files`: Files actively edited
|
|
81
|
+
- `active_ids`: Beads task IDs in progress
|
|
82
|
+
- `recent_commands`: Recent terminal commands (test, build, etc.)
|
|
83
|
+
|
|
84
|
+
- **Action** — BuildBeadsTree (if available): From beads array, build hierarchy (epic → tasks → subtasks). Include task IDs for resume.
|
|
85
|
+
|
|
86
|
+
## Step 3: Conditional Write
|
|
87
|
+
|
|
88
|
+
Check `session_count` from Step 1:
|
|
89
|
+
|
|
90
|
+
### If session_count = 0 (First Session)
|
|
91
|
+
|
|
92
|
+
**Do not narrate. Just write the file and output the confirmation.**
|
|
93
|
+
|
|
94
|
+
Write directly to `docs/tasks/{branch}/session_logs/{ts}_handoff.json`
|
|
95
|
+
|
|
96
|
+
**JSON Schema**:
|
|
97
|
+
```json
|
|
98
|
+
{
|
|
99
|
+
"version": "1.1",
|
|
100
|
+
"timestamp": "{ts}",
|
|
101
|
+
"branch_name": "{branch}",
|
|
102
|
+
"task_name": "{ARGUMENTS or branch}",
|
|
103
|
+
"session_number": 1,
|
|
104
|
+
"progress_update": {
|
|
105
|
+
"summary": "string",
|
|
106
|
+
"goal": "string",
|
|
107
|
+
"accomplished": ["string"],
|
|
108
|
+
"now": "string (critical for resume)",
|
|
109
|
+
"next_steps": ["string"],
|
|
110
|
+
"confidence": "high|medium|low",
|
|
111
|
+
"constraints": ["string"],
|
|
112
|
+
"decisions": ["string"],
|
|
113
|
+
"blockers": ["string"],
|
|
114
|
+
"open_questions": ["string"],
|
|
115
|
+
"risks": ["string"]
|
|
116
|
+
},
|
|
117
|
+
"working_set": {
|
|
118
|
+
"key_files": ["path"],
|
|
119
|
+
"active_ids": ["bd-xxxxx"],
|
|
120
|
+
"recent_commands": ["command"]
|
|
121
|
+
},
|
|
122
|
+
"beads": { // OMIT ENTIRE SECTION if beads_available=false OR beads_count=0
|
|
123
|
+
"available": true,
|
|
124
|
+
"workspace_label": "{branch}",
|
|
125
|
+
"task_count": "number",
|
|
126
|
+
"epic_id": "bd-xxxxx|null",
|
|
127
|
+
"epic_title": "string|null",
|
|
128
|
+
"tasks": [{"id", "title", "status", "type", "parent", "children", "labels"}]
|
|
129
|
+
},
|
|
130
|
+
"context": {
|
|
131
|
+
"wip_state": "uncommitted|clean",
|
|
132
|
+
"last_commit": "abc1234"
|
|
133
|
+
}
|
|
134
|
+
}
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
Then respond: "✓ Handoff saved: {path}. First session recorded. Next session auto-resumes from this context."
|
|
138
|
+
|
|
139
|
+
### If session_count >= 1 (Continuation)
|
|
140
|
+
|
|
141
|
+
**Do not narrate. Just spawn the subagent and output the confirmation when done.**
|
|
142
|
+
|
|
143
|
+
Spawn `@sesh:sync` subagent with the composed data:
|
|
144
|
+
|
|
145
|
+
```
|
|
146
|
+
<current_session>
|
|
147
|
+
{full JSON object you composed above}
|
|
148
|
+
</current_session>
|
|
149
|
+
|
|
150
|
+
<session_logs_path>
|
|
151
|
+
docs/tasks/{branch}/session_logs
|
|
152
|
+
</session_logs_path>
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
The sync agent will:
|
|
156
|
+
1. Read up to 3 previous handoff.json files
|
|
157
|
+
2. Synthesize current context with historical arc
|
|
158
|
+
3. Write the final `{ts}_handoff.json` with enriched continuity
|
|
159
|
+
4. Return the file path
|
|
160
|
+
|
|
161
|
+
Then respond: "✓ Handoff saved: {path}. Session {n} recorded with continuity from {x} previous sessions. Next session auto-resumes from this context."
|
|
@@ -0,0 +1,115 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 👻 | Project kickoff with deep research & MVP pathfinding - primary agent
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# kickoff: Deep Codebase Research + MVP Path Discovery
|
|
6
|
+
|
|
7
|
+
Comprehensive codebase research, external best practices, and MVP implementation path with file:line evidence. Output: kickoff document with architecture insights, gap analysis, and implementation options saved to `docs/tasks/{task_name}/kickoff/`.
|
|
8
|
+
|
|
9
|
+
## ARGUMENTS
|
|
10
|
+
|
|
11
|
+
<ARGUMENTS>
|
|
12
|
+
$ARGUMENTS
|
|
13
|
+
</ARGUMENTS>
|
|
14
|
+
|
|
15
|
+
## Step 1: Acknowledge & Clarify
|
|
16
|
+
|
|
17
|
+
- **Action** — ImmediateReply: Respond before any tools.
|
|
18
|
+
- **If** ARGUMENTS → acknowledge context, identify: what we're exploring, what decision we're heading toward, what success looks like
|
|
19
|
+
- **Else** → prompt for project context
|
|
20
|
+
- **CRITICAL**: No tool calls in this step
|
|
21
|
+
|
|
22
|
+
## Step 2: Gather Context & Decompose
|
|
23
|
+
|
|
24
|
+
- **Action** — ReadMentionedDocs: Read referenced docs FULLY in main context (not subagent). Extract: vision, constraints, decisions made, open questions.
|
|
25
|
+
- **Action** — DecomposeResearchAreas: Break project into research areas. Consider: components to investigate, directories/files, architectural patterns, data flows, existing code to extend.
|
|
26
|
+
- **Action** — CreateResearchPlan: Use TodoWrite to track research subtasks.
|
|
27
|
+
|
|
28
|
+
## Step 3: Deep Parallel Research
|
|
29
|
+
|
|
30
|
+
- **Action** — SpawnResearchAgents: Launch parallel agents for comprehensive context.
|
|
31
|
+
|
|
32
|
+
| Agent | Task | Required Output |
|
|
33
|
+
|-------|------|-----------------|
|
|
34
|
+
| @finder | Find relevant files, entry points, handlers, models | File paths by domain |
|
|
35
|
+
| @analyst | Trace data flow, dependencies, behavior, edge cases | file:line refs for ALL findings |
|
|
36
|
+
| @patterns | Find similar implementations, patterns to follow/avoid | Code examples with file:line |
|
|
37
|
+
| @web-research | Best practices, similar solutions, pitfalls | Findings WITH LINKS |
|
|
38
|
+
|
|
39
|
+
**Strategy**: locator → analyzer on findings → parallel for breadth. Spawn follow-ups if shallow. Demand file:line evidence.
|
|
40
|
+
|
|
41
|
+
**3rd Party Libs**: Use Context7 MCP for central libraries.
|
|
42
|
+
|
|
43
|
+
- **Action** — WaitForAgents: ALL agents must complete before synthesis. Update TodoWrite as each completes.
|
|
44
|
+
|
|
45
|
+
## Step 4: Synthesize Understanding
|
|
46
|
+
|
|
47
|
+
- **Action** — CompileFindings: Synthesize with file:line refs throughout.
|
|
48
|
+
- Codebase: Connect findings across components, document data flow, answer "how does codebase handle [area]?"
|
|
49
|
+
- Architecture: Patterns to follow (with examples), conventions, constraints, reuse vs build new
|
|
50
|
+
- External: Industry patterns (with links), best practices, pitfalls
|
|
51
|
+
|
|
52
|
+
- **Action** — PerformGapAnalysis: Current capabilities (with file refs) vs required capabilities. What's missing vs needs modification.
|
|
53
|
+
|
|
54
|
+
- **Action** — IdentifyMVPAndOptions:
|
|
55
|
+
- MVP: Core value, minimum for value, what to defer (informed by codebase complexity)
|
|
56
|
+
- Options: 2-3 approaches with: summary, key decisions, code to leverage (file refs), new work, effort sense, trade-offs
|
|
57
|
+
- Decision points: Architecture, scope, technology, integration, patterns
|
|
58
|
+
|
|
59
|
+
## Step 5: Generate Document
|
|
60
|
+
|
|
61
|
+
- **Action** — DetermineOutputDir:
|
|
62
|
+
- Derive `task_name` from context (kebab-case)
|
|
63
|
+
- `OUT_DIR = user_specified || docs/tasks/{task_name}/kickoff`
|
|
64
|
+
- `mkdir -p "$OUT_DIR"`
|
|
65
|
+
|
|
66
|
+
- **Action** — CreateDocument: Structure with YAML frontmatter (date, git_commit, branch, repo, topic, tags, status).
|
|
67
|
+
|
|
68
|
+
**Sections**: Title → Metadata → Project Context → Research Summary → Detailed Codebase Findings (by area, file:line refs, code snippets) → Code References (table) → Architecture Insights (patterns, conventions, constraints) → External Research (with links) → Gap Analysis → MVP Suggestion → Implementation Options (2-3 with trade-offs) → Decision Points → Open Questions → Related Resources
|
|
69
|
+
|
|
70
|
+
- **Action** — AddGitHubPermalinks: If on main/pushed, convert file refs to `https://github.com/{owner}/{repo}/blob/{commit}/{file}#L{line}`
|
|
71
|
+
|
|
72
|
+
- **Action** — SaveDocument: Save as `{task_name}_kickoff.md` (timestamp variant if exists). **CRITICAL**: Save before Step 6.
|
|
73
|
+
|
|
74
|
+
## Step 6: Present & Scope
|
|
75
|
+
|
|
76
|
+
- **Action** — PresentSummary:
|
|
77
|
+
> **Kickoff Complete** — saved to `{path}`
|
|
78
|
+
>
|
|
79
|
+
> **Vision**: [1-2 sentences]
|
|
80
|
+
> **What Exists**: [key components with file:line refs]
|
|
81
|
+
> **Architecture Insights**: [patterns, conventions, constraints]
|
|
82
|
+
> **External Learnings**: [key insights with links]
|
|
83
|
+
> **Gap**: [have → need]
|
|
84
|
+
> **MVP Path**: [smallest valuable slice]
|
|
85
|
+
>
|
|
86
|
+
> **Scoping Questions** (before planning):
|
|
87
|
+
> 1. [Scope/boundary question] — Option A (leverages `code:line`) vs Option B
|
|
88
|
+
> 2. [Technical approach] — suggested vs alternative
|
|
89
|
+
> 3. [Priority/constraint question]
|
|
90
|
+
|
|
91
|
+
- **Action** — EngageInScoping: Wait for response, ask follow-ups. No planning until ambiguities resolved. Research answerable questions instead of asking.
|
|
92
|
+
|
|
93
|
+
## Step 7: Handle Follow-ups
|
|
94
|
+
|
|
95
|
+
- **Action** — HandleFollowUps:
|
|
96
|
+
- **If** clarifications → update doc with `## Scoping Clarifications [timestamp]`
|
|
97
|
+
- **If** more research needed → spawn agents, demand file:line evidence, update doc
|
|
98
|
+
- Continue until ambiguities resolved
|
|
99
|
+
|
|
100
|
+
## Step 8: Transition to Scope
|
|
101
|
+
|
|
102
|
+
- **Action** — SummarizeAndTransition:
|
|
103
|
+
> **Ready for Scope Definition**
|
|
104
|
+
>
|
|
105
|
+
> **Established**: User problem, user value, key findings (file:line), decisions made, remaining ambiguities
|
|
106
|
+
>
|
|
107
|
+
> **Options**:
|
|
108
|
+
> 1. "Proceed with scope" → `/spectre:scope` with FROM_KICKOFF=true, SKIP_EXPLORATION=true
|
|
109
|
+
> 2. "Skip to planning" → `/spectre:plan` with kickoff doc context
|
|
110
|
+
> 3. "Need to think" → `/spectre:handoff`
|
|
111
|
+
|
|
112
|
+
- **Action** — ExecuteChoice:
|
|
113
|
+
- **If** scope → invoke `/spectre:scope` with: FROM_KICKOFF=true, KICKOFF_DOC={path}, SKIP_EXPLORATION=true, context summary
|
|
114
|
+
- **If** planning → suggest `/spectre:plan`
|
|
115
|
+
- **If** pause → run `/spectre:handoff`
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "\ud83d\udc7b | Capture knowledge for future sessions"
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /learn - Capture Project Knowledge
|
|
6
|
+
|
|
7
|
+
Load the `spectre-learn` skill via `Skill(spectre-learn)` and **execute its workflow step-by-step**.
|
|
8
|
+
|
|
9
|
+
<CRITICAL>
|
|
10
|
+
This skill supersedes auto-memory. Do NOT write to MEMORY.md or any auto-memory directory. The skill defines the exclusive storage location, format, and registration workflow for captured knowledge.
|
|
11
|
+
|
|
12
|
+
Treat the skill output as a binding directive, not informational context.
|
|
13
|
+
</CRITICAL>
|
|
14
|
+
|
|
15
|
+
**Topic**: $ARGUMENTS
|
|
@@ -0,0 +1,170 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 👻 | Unified planning entry point - researches, assesses complexity, routes to workflow - primary agent
|
|
3
|
+
---
|
|
4
|
+
# plan: Intelligent Planning Router
|
|
5
|
+
|
|
6
|
+
## Description
|
|
7
|
+
|
|
8
|
+
- **What** — Research codebase, assess complexity, route to appropriate workflow (direct tasks or plan-first)
|
|
9
|
+
- **Outcome** — Detailed task breakdown ready for execution
|
|
10
|
+
|
|
11
|
+
## ARGUMENTS Input
|
|
12
|
+
|
|
13
|
+
<ARGUMENTS> $ARGUMENTS </ARGUMENTS>
|
|
14
|
+
|
|
15
|
+
## MANDATORY COMPLIANCE RULES
|
|
16
|
+
|
|
17
|
+
> **⚠️ NON-NEGOTIABLE**: This workflow MUST invoke slash commands via the Skill tool. Failure to invoke `/spectre:create_plan` and `/spectre:create_tasks` is a critical error. Do NOT summarize, describe, or skip these commands. INVOKE THEM.
|
|
18
|
+
|
|
19
|
+
**After ANY user conversation or questions:**
|
|
20
|
+
|
|
21
|
+
1. Re-read this prompt from Step 4
|
|
22
|
+
2. Determine where you are in the workflow
|
|
23
|
+
3. Execute the next required Skill invocation
|
|
24
|
+
|
|
25
|
+
**You MUST call these skills (not describe them):**
|
|
26
|
+
|
|
27
|
+
- Use the **Skill** tool with `skill: "spectre:create_plan"` and `args: "{path} --depth {tier}"` — generates plan.md
|
|
28
|
+
- Use the **Skill** tool with `skill: "spectre:create_tasks"` and `args: "{path}"` — generates tasks.md
|
|
29
|
+
|
|
30
|
+
## Instructions
|
|
31
|
+
|
|
32
|
+
- Research before routing; present architectural options for user buy-in
|
|
33
|
+
- Route based on hard-stops and clarity, not point-scoring
|
|
34
|
+
- Never overwrite existing `tasks.md` or `plan.md` — use scoped names
|
|
35
|
+
|
|
36
|
+
## Step 1 - Research Codebase
|
|
37
|
+
|
|
38
|
+
- **Action** — DetermineOutputDir:
|
|
39
|
+
|
|
40
|
+
- `OUT_DIR=docs/tasks/{branch_name}` (or user-specified)
|
|
41
|
+
- `mkdir -p "${OUT_DIR}"`
|
|
42
|
+
|
|
43
|
+
- **Action** — ScanExistingContext: Read all existing artifacts in `{OUT_DIR}/ (if you haven’t already)` and assess coverage across 4 dimensions.
|
|
44
|
+
|
|
45
|
+
Scan for: `task_context.md`, `specs/plan.md`, `concepts/scope.md`, `research/*.md`
|
|
46
|
+
|
|
47
|
+
| Dimension | Covered if artifact contains... | Covered by |
|
|
48
|
+
| --- | --- | --- |
|
|
49
|
+
| **File locations** | Specific file paths relevant to this feature, entry points, config files | `@finder` |
|
|
50
|
+
| **Code understanding** | Data flow analysis, dependency tracing, how current code works with file:line refs | `@analyst` |
|
|
51
|
+
| **Codebase patterns** | Similar implementations found in codebase, reusable components, naming/style conventions | `@patterns` |
|
|
52
|
+
| **External research** | Best practices, libraries/frameworks, prior art, common pitfalls with source links | `@web-research` |
|
|
53
|
+
|
|
54
|
+
For each dimension, assess: **covered** (artifact has substantive findings for this feature) or **gap** (missing, superficial, or about a different feature).
|
|
55
|
+
|
|
56
|
+
- **Action** — DispatchResearch: Spawn agents **only for dimensions marked as gaps**. Skip agents whose dimensions are already covered. Each prompt must include the feature/problem description from ARGUMENTS so the agent has full context.
|
|
57
|
+
|
|
58
|
+
- **If all 4 covered** → skip to SaveResearch (merge existing findings into task_context.md if scattered across files)
|
|
59
|
+
|
|
60
|
+
- **If gaps exist** → spawn only the needed agents in parallel:
|
|
61
|
+
|
|
62
|
+
- `@finder` *(if File locations = gap)* — "Find all files, components, entry points, routes, and configuration related to \[feature/problem\]. Include: (1) files that would need to be modified or extended, (2) entry points where this feature connects to the system (routes, handlers, event listeners, CLI commands), (3) configuration files, schemas, or migrations that may be affected, (4) test files covering the affected areas. Return file paths organized by relevance."
|
|
63
|
+
|
|
64
|
+
- `@analyst` *(if Code understanding = gap)* — "Analyze how the code paths related to \[feature/problem\] work end-to-end. Trace: (1) data flow from input through processing to storage and output, (2) key dependencies and how components interact, (3) state management patterns and data access methods in the affected areas, (4) error handling and edge cases in the current implementation. Return findings with specific file:line references."
|
|
65
|
+
|
|
66
|
+
- `@patterns` *(if Codebase patterns = gap)* — "Find existing implementations in this codebase that are similar to \[feature/problem\] and could serve as a reference. Look for: (1) analogous features already built — how were they structured?, (2) reusable components, utilities, or abstractions we should leverage, (3) conventions for naming, file organization, and code style in this area, (4) testing patterns used for similar features. Return concrete code examples with file:line references."
|
|
67
|
+
|
|
68
|
+
- `@web-research` *(if External research = gap)* — "Research best practices, proven patterns, relevant libraries/frameworks, and how other projects solve \[feature/problem\]. Focus on: (1) industry best practices and common pitfalls, (2) libraries or frameworks that simplify this work, (3) how well-known open-source projects approach similar problems, (4) architectural patterns recommended for this type of feature. Return findings with source links."
|
|
69
|
+
|
|
70
|
+
- **Wait** for all dispatched agents; read identified files
|
|
71
|
+
|
|
72
|
+
- **Action** — SaveResearch: Merge all findings (existing artifacts + new agent results) into `{OUT_DIR}/task_context.md` with sections: Architecture Patterns, Dependencies, Implementation Approaches, Impact Summary, and External Research (best practices, recommended libraries/frameworks, prior art, common pitfalls)
|
|
73
|
+
|
|
74
|
+
## Step 2 - Present Architectural Options
|
|
75
|
+
|
|
76
|
+
- **Action** — PresentOptions: 2-4 strategies (simplest to most robust)
|
|
77
|
+
- Each: core approach, trade-offs, when it makes sense
|
|
78
|
+
- **Wait** — User selects strategy
|
|
79
|
+
- **Action** — UpdateContext: Document selection in task_context.md
|
|
80
|
+
|
|
81
|
+
> **CHECKPOINT**: After architecture discussion, proceed IMMEDIATELY to Step 3. Do NOT end turn without continuing the workflow.
|
|
82
|
+
|
|
83
|
+
## Step 3 - Assess Complexity
|
|
84
|
+
|
|
85
|
+
Use research findings from Step 1 to determine appropriate planning depth.
|
|
86
|
+
|
|
87
|
+
- **Action** — AssessFromResearch: Score complexity signals from research:
|
|
88
|
+
|
|
89
|
+
| Signal | Source | Assessment |
|
|
90
|
+
| --- | --- | --- |
|
|
91
|
+
| Files impacted | @finder | 1-3 files = Low, 4-8 = Med, 9+ = High |
|
|
92
|
+
| Pattern match | @patterns | Clear existing pattern = Low, Adapt pattern = Med, New pattern = High |
|
|
93
|
+
| Components crossed | @analyst | 1 component = Low, 2-3 = Med, 4+ = High |
|
|
94
|
+
| Data model changes | Research findings | None = Low, Modify existing = Med, New models/schema = High |
|
|
95
|
+
| Integration points | Research findings | Internal only = Low, 1-2 external = Med, 3+ external = High |
|
|
96
|
+
| External complexity | @web-research | Well-documented with libraries = Low, Some prior art = Med, Novel/emerging = High |
|
|
97
|
+
|
|
98
|
+
- **Action** — CheckHardStops: Any true = automatic COMPREHENSIVE | db_schema_destructive | new_service_or_component | auth_or_pii_change | | payment_billing_logic | public_api_change | caching_consistency | slo_sla_risk |
|
|
99
|
+
|
|
100
|
+
- **Action** — DetermineTier:
|
|
101
|
+
|
|
102
|
+
- **LIGHT**: All/most Low signals, single component, clear pattern match, no hard-stops
|
|
103
|
+
- **STANDARD**: Mix of Low/Med signals, multi-file but contained scope, no hard-stops
|
|
104
|
+
- **COMPREHENSIVE**: Any High signal, multiple Med signals, or any hard-stop triggered
|
|
105
|
+
|
|
106
|
+
- **Action** — LogTier: Note the assessed tier in your response for transparency, then proceed immediately to Step 4. Do NOT ask for confirmation.
|
|
107
|
+
|
|
108
|
+
> **CHECKPOINT**: After determining tier, proceed IMMEDIATELY to Step 4. The ONLY valid next action is invoking a Skill. Do NOT end turn here. Do NOT ask user to confirm the tier.
|
|
109
|
+
|
|
110
|
+
## Step 4 - Route to Workflow
|
|
111
|
+
|
|
112
|
+
### ⛔ MANDATORY SKILL INVOCATION ⛔
|
|
113
|
+
|
|
114
|
+
```plaintext
|
|
115
|
+
┌────────────────────────────────────────────────────────────────────────┐
|
|
116
|
+
│ YOU MUST USE THE SKILL TOOL TO INVOKE THESE COMMANDS │
|
|
117
|
+
│ │
|
|
118
|
+
│ ❌ WRONG: "I'll now create the plan..." │
|
|
119
|
+
│ ❌ WRONG: "The next step would be to run /spectre:create_plan" │
|
|
120
|
+
│ ❌ WRONG: Ending turn without invoking Skill tool │
|
|
121
|
+
│ │
|
|
122
|
+
│ ✅ CORRECT: Skill tool with skill: "spectre:create_plan", args: "..." │
|
|
123
|
+
│ ✅ CORRECT: Skill tool with skill: "spectre:create_tasks", args: "..."│
|
|
124
|
+
└────────────────────────────────────────────────────────────────────────┘
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
**DO NOT:**
|
|
128
|
+
|
|
129
|
+
- Say you’ll create a plan or set of tasks yourself without running the skill tool
|
|
130
|
+
- Describe what you would do
|
|
131
|
+
- Summarize the plan/task steps yourself
|
|
132
|
+
- End your turn without invoking Skill
|
|
133
|
+
- Write plan.md or tasks.md content directly
|
|
134
|
+
|
|
135
|
+
**YOU MUST:**
|
|
136
|
+
|
|
137
|
+
- Use the Skill tool: `skill: "spectre:create_plan"`, `args: "{OUT_DIR}/task_context.md --depth {tier}"`
|
|
138
|
+
- Use the Skill tool: `skill: "spectre:create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
|
|
139
|
+
|
|
140
|
+
---
|
|
141
|
+
|
|
142
|
+
### Routing Logic
|
|
143
|
+
|
|
144
|
+
- **If LIGHT**:
|
|
145
|
+
|
|
146
|
+
- **INVOKE NOW** → Skill tool with `skill: "spectre:create_tasks"`, `args: "{OUT_DIR}/task_context.md --depth light"`
|
|
147
|
+
- **Wait** — Returns task breakdown with brief implementation approach
|
|
148
|
+
- Skip to footer
|
|
149
|
+
|
|
150
|
+
- **ElseIf STANDARD**:
|
|
151
|
+
|
|
152
|
+
- **INVOKE NOW** → Skill tool with `skill: "spectre:create_plan"`, `args: "{OUT_DIR}/task_context.md --depth standard"`
|
|
153
|
+
- **Wait** — Returns focused plan (Overview, Approach, Out of Scope)
|
|
154
|
+
- **Action** — PromptUser: "Review plan. Reply 'Approved' or provide feedback."
|
|
155
|
+
- **Wait** — User approval
|
|
156
|
+
- **INVOKE NOW** → Skill tool with `skill: "spectre:create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
|
|
157
|
+
- **Wait** — Returns task breakdown
|
|
158
|
+
|
|
159
|
+
- **ElseIf COMPREHENSIVE**:
|
|
160
|
+
|
|
161
|
+
- **INVOKE NOW** → Skill tool with `skill: "spectre:create_plan"`, `args: "{OUT_DIR}/task_context.md --depth comprehensive"`
|
|
162
|
+
- **Wait** — Returns full plan (all sections: Architecture, Phases, API Design, Testing Strategy, etc.)
|
|
163
|
+
- **Action** — PromptUser: "Review plan. Reply 'Approved' or provide feedback."
|
|
164
|
+
- **Wait** — User approval
|
|
165
|
+
- **INVOKE NOW** → Skill tool with `skill: "spectre:create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
|
|
166
|
+
- **Wait** — Returns task breakdown
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
- **Action** — RenderFooter: Use `@skill-spectre:spectre-guide` skill for Next Steps
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 👻 | Find simplifications in a plan or tasks
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
You are a senior staff engineer with deep expertise in system design, architecture, and pragmatic problem-solving. Your specialty is finding the simplest path to meet all requirements.
|
|
6
|
+
|
|
7
|
+
Review the following [plan/document/tasks/context] and identify opportunities to simplify while ensuring all requirements and functionality are delivered.
|
|
8
|
+
|
|
9
|
+
For each simplification opportunity, provide:
|
|
10
|
+
1. **What to simplify** - Specific component, process, or decision
|
|
11
|
+
2. **Why** - What complexity it removes (cognitive load, dependencies, maintenance burden, etc.)
|
|
12
|
+
3. **Impact** - Confirm that all original requirements remain satisfied
|
|
13
|
+
4. **Risk** - Any trade-offs or risks introduced by the simplification
|
|
14
|
+
|
|
15
|
+
Focus on:
|
|
16
|
+
- Removing unnecessary abstractions or indirection
|
|
17
|
+
- Consolidating duplicated logic or patterns
|
|
18
|
+
- Questioning assumptions that add complexity
|
|
19
|
+
- Identifying over-engineering
|
|
20
|
+
- Suggesting proven, boring solutions over novel approaches
|
|
21
|
+
|
|
22
|
+
## Testing Review
|
|
23
|
+
**Context**: We use fast TDD with 1 happy path test + 1 unhappy path test per feature. A separate task handles achieving 100% test coverage post-feature work.
|
|
24
|
+
|
|
25
|
+
Evaluate the testing approach and flag:
|
|
26
|
+
- **Over-testing**: Tests beyond 1 happy + 1 unhappy path that should be deferred to the coverage task
|
|
27
|
+
- **Wrong tests**: Testing implementation details instead of behavior, brittle tests that will break on refactors, or tests that don't actually validate requirements
|
|
28
|
+
- **Missing critical paths**: Cases where the 1+1 approach genuinely misses a requirement-breaking scenario (rare, but call it out)
|
|
29
|
+
- **Test complexity**: Overly elaborate test setup, mocking, or assertions that could be simpler
|
|
30
|
+
|
|
31
|
+
Remember: The goal is fast feedback during development. More comprehensive testing comes later.
|
|
32
|
+
|
|
33
|
+
End with a prioritized list of recommendations (high/medium/low impact).
|