specdacular 0.10.1 → 0.11.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/README.md +3 -3
- package/bin/install.js +3 -1
- package/bin/specd.js +135 -0
- package/commands/specd.best-practices.md +75 -0
- package/commands/specd.docs.md +81 -0
- package/commands/specd.docs.review.md +80 -0
- package/commands/specd.generate-skills.learn.md +65 -0
- package/commands/specd.new-runner-task.md +52 -0
- package/commands/specd.new.md +6 -6
- package/commands/specd.runner-status.md +27 -0
- package/package.json +6 -2
- package/runner/main/agent/parser.js +39 -0
- package/runner/main/agent/runner.js +137 -0
- package/runner/main/agent/template.js +16 -0
- package/runner/main/bootstrap.js +69 -0
- package/runner/main/db.js +45 -0
- package/runner/main/index.js +103 -0
- package/runner/main/ipc.js +72 -0
- package/runner/main/notifications/telegram.js +45 -0
- package/runner/main/orchestrator.js +193 -0
- package/runner/main/paths.js +36 -0
- package/runner/main/pipeline/resolver.js +20 -0
- package/runner/main/pipeline/sequencer.js +42 -0
- package/runner/main/server/api.js +125 -0
- package/runner/main/server/index.js +33 -0
- package/runner/main/server/websocket.js +24 -0
- package/runner/main/state/manager.js +83 -0
- package/runner/main/template-manager.js +41 -0
- package/runner/main/test/agent-parser.test.js +44 -0
- package/runner/main/test/bootstrap.test.js +58 -0
- package/runner/main/test/db.test.js +72 -0
- package/runner/main/test/paths.test.js +29 -0
- package/runner/main/test/state-manager.test.js +72 -0
- package/runner/main/test/template-manager.test.js +66 -0
- package/runner/main/worktree/manager.js +95 -0
- package/runner/package.json +22 -0
- package/runner/preload.js +19 -0
- package/specdacular/HELP.md +14 -11
- package/specdacular/agents/best-practices-researcher.md +271 -0
- package/specdacular/references/load-context.md +4 -7
- package/specdacular/templates/orchestrator/CONCERNS.md +1 -1
- package/specdacular/templates/orchestrator/PROJECTS.md +3 -4
- package/specdacular/templates/tasks/PLAN.md +2 -2
- package/specdacular/workflows/best-practices.md +472 -0
- package/specdacular/workflows/context-add.md +16 -30
- package/specdacular/workflows/context-manual-review.md +7 -7
- package/specdacular/workflows/docs-review.md +273 -0
- package/specdacular/workflows/docs.md +420 -0
- package/specdacular/workflows/generate-learn-skill.md +214 -0
- package/specdacular/workflows/new.md +5 -4
- package/specdacular/workflows/orchestrator/new.md +4 -4
- package/specdacular/workflows/orchestrator/plan.md +6 -6
- package/commands/specd.codebase.map.md +0 -72
- package/commands/specd.codebase.review.md +0 -39
- package/specdacular/workflows/map-codebase.md +0 -715
package/README.md
CHANGED
|
@@ -101,13 +101,13 @@ In Claude Code:
|
|
|
101
101
|
|
|
102
102
|
## Quick Start
|
|
103
103
|
|
|
104
|
-
###
|
|
104
|
+
### Generate Codebase Docs
|
|
105
105
|
|
|
106
106
|
```
|
|
107
|
-
/specd.
|
|
107
|
+
/specd.docs
|
|
108
108
|
```
|
|
109
109
|
|
|
110
|
-
|
|
110
|
+
Spawns 4 parallel agents to analyze your codebase, then merges their outputs into topic-specific docs in `docs/` and writes a `CLAUDE.md` routing table. Topics are dynamically determined from what your codebase actually uses. Review docs with `/specd.docs.review`.
|
|
111
111
|
|
|
112
112
|
### Plan a Feature
|
|
113
113
|
|
package/bin/install.js
CHANGED
|
@@ -467,7 +467,9 @@ function install(isGlobal) {
|
|
|
467
467
|
${green}Done!${reset} Launch Claude Code and run ${cyan}/specd.help${reset}.
|
|
468
468
|
|
|
469
469
|
${yellow}Commands:${reset}
|
|
470
|
-
/specd.
|
|
470
|
+
/specd.docs - Generate topic docs and CLAUDE.md routing table
|
|
471
|
+
/specd.docs.review - Review docs for accuracy and staleness
|
|
472
|
+
/specd.generate-skills.learn - Generate a /learn skill for your project
|
|
471
473
|
/specd.update - Update to latest version
|
|
472
474
|
/specd.help - Show all commands
|
|
473
475
|
`);
|
package/bin/specd.js
ADDED
|
@@ -0,0 +1,135 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
|
|
3
|
+
// bin/specd.js — unified CLI entry point
|
|
4
|
+
// Usage:
|
|
5
|
+
// specd llm-init [--local] — install commands/agents/workflows
|
|
6
|
+
// specd runner — launch Electron app
|
|
7
|
+
// specd runner register <path> — register a folder
|
|
8
|
+
// specd runner unregister <id> — remove a project
|
|
9
|
+
// specd runner projects — list projects
|
|
10
|
+
// specd runner status — show task status
|
|
11
|
+
|
|
12
|
+
import { resolve, join } from 'path';
|
|
13
|
+
import { existsSync, readFileSync, writeFileSync, mkdirSync } from 'fs';
|
|
14
|
+
import { homedir, platform } from 'os';
|
|
15
|
+
import { execSync, spawn } from 'child_process';
|
|
16
|
+
|
|
17
|
+
const args = process.argv.slice(2);
|
|
18
|
+
const command = args[0];
|
|
19
|
+
|
|
20
|
+
function getAppDataDir() {
|
|
21
|
+
if (platform() === 'darwin') {
|
|
22
|
+
return join(homedir(), 'Library', 'Application Support', 'Specd');
|
|
23
|
+
}
|
|
24
|
+
return join(homedir(), '.config', 'specd');
|
|
25
|
+
}
|
|
26
|
+
|
|
27
|
+
function getDbPath() {
|
|
28
|
+
return join(getAppDataDir(), 'db.json');
|
|
29
|
+
}
|
|
30
|
+
|
|
31
|
+
function loadDb() {
|
|
32
|
+
const dbPath = getDbPath();
|
|
33
|
+
if (!existsSync(dbPath)) return { projects: [] };
|
|
34
|
+
return JSON.parse(readFileSync(dbPath, 'utf-8'));
|
|
35
|
+
}
|
|
36
|
+
|
|
37
|
+
function saveDb(data) {
|
|
38
|
+
const dbPath = getDbPath();
|
|
39
|
+
mkdirSync(join(dbPath, '..'), { recursive: true });
|
|
40
|
+
writeFileSync(dbPath, JSON.stringify(data, null, 2));
|
|
41
|
+
}
|
|
42
|
+
|
|
43
|
+
if (command === 'llm-init') {
|
|
44
|
+
// Delegate to existing install.js
|
|
45
|
+
const installScript = join(import.meta.dirname, 'install.js');
|
|
46
|
+
const isLocal = args.includes('--local');
|
|
47
|
+
process.argv = ['node', installScript, isLocal ? '--local' : '--global'];
|
|
48
|
+
await import(installScript);
|
|
49
|
+
} else if (command === 'runner') {
|
|
50
|
+
const subcommand = args[1];
|
|
51
|
+
|
|
52
|
+
if (subcommand === 'register') {
|
|
53
|
+
const folderPath = resolve(args[2] || '.');
|
|
54
|
+
if (!existsSync(folderPath)) {
|
|
55
|
+
console.error(`Path does not exist: ${folderPath}`);
|
|
56
|
+
process.exit(1);
|
|
57
|
+
}
|
|
58
|
+
const name = args[3] || folderPath.split('/').pop();
|
|
59
|
+
const db = loadDb();
|
|
60
|
+
const existing = db.projects.find(p => p.path === folderPath);
|
|
61
|
+
if (existing) {
|
|
62
|
+
console.log(`Already registered: ${existing.name} (${existing.id})`);
|
|
63
|
+
process.exit(0);
|
|
64
|
+
}
|
|
65
|
+
const id = Math.random().toString(36).slice(2, 10);
|
|
66
|
+
db.projects.push({
|
|
67
|
+
id,
|
|
68
|
+
name,
|
|
69
|
+
path: folderPath,
|
|
70
|
+
active: true,
|
|
71
|
+
registeredAt: new Date().toISOString(),
|
|
72
|
+
});
|
|
73
|
+
saveDb(db);
|
|
74
|
+
console.log(`Registered: ${name} (${id}) → ${folderPath}`);
|
|
75
|
+
} else if (subcommand === 'unregister') {
|
|
76
|
+
const id = args[2];
|
|
77
|
+
if (!id) { console.error('Usage: specd runner unregister <id>'); process.exit(1); }
|
|
78
|
+
const db = loadDb();
|
|
79
|
+
db.projects = db.projects.filter(p => p.id !== id);
|
|
80
|
+
saveDb(db);
|
|
81
|
+
console.log(`Unregistered: ${id}`);
|
|
82
|
+
} else if (subcommand === 'projects') {
|
|
83
|
+
const db = loadDb();
|
|
84
|
+
if (db.projects.length === 0) {
|
|
85
|
+
console.log('No projects registered. Run: specd runner register <path>');
|
|
86
|
+
} else {
|
|
87
|
+
for (const p of db.projects) {
|
|
88
|
+
console.log(` ${p.id} ${p.name} ${p.path} ${p.active ? '●' : '○'}`);
|
|
89
|
+
}
|
|
90
|
+
}
|
|
91
|
+
} else if (subcommand === 'status') {
|
|
92
|
+
try {
|
|
93
|
+
const resp = await fetch('http://localhost:3700/api/status');
|
|
94
|
+
if (!resp.ok) throw new Error(`HTTP ${resp.status}`);
|
|
95
|
+
const status = await resp.json();
|
|
96
|
+
for (const [projectId, state] of Object.entries(status)) {
|
|
97
|
+
console.log(`\n${projectId}:`);
|
|
98
|
+
for (const [taskId, task] of Object.entries(state.tasks || {})) {
|
|
99
|
+
const icon = { done: '✓', in_progress: '▸', failed: '✗', queued: '○' }[task.status] || '?';
|
|
100
|
+
console.log(` ${icon} ${taskId}: ${task.name} [${task.status}]`);
|
|
101
|
+
}
|
|
102
|
+
}
|
|
103
|
+
} catch {
|
|
104
|
+
console.error('Runner not running. Start it with: specd runner');
|
|
105
|
+
}
|
|
106
|
+
} else {
|
|
107
|
+
// No subcommand — launch Electron app
|
|
108
|
+
const runnerDir = join(import.meta.dirname, '..', 'runner');
|
|
109
|
+
const electronPath = join(getAppDataDir(), 'electron', 'node_modules', '.bin', 'electron');
|
|
110
|
+
|
|
111
|
+
if (!existsSync(electronPath)) {
|
|
112
|
+
console.log('First run — installing Electron runtime...');
|
|
113
|
+
const electronDir = join(getAppDataDir(), 'electron');
|
|
114
|
+
mkdirSync(electronDir, { recursive: true });
|
|
115
|
+
writeFileSync(join(electronDir, 'package.json'), JSON.stringify({ name: 'specd-electron', private: true }));
|
|
116
|
+
execSync('npm install electron@latest', { cwd: electronDir, stdio: 'inherit' });
|
|
117
|
+
console.log('Electron installed.');
|
|
118
|
+
}
|
|
119
|
+
|
|
120
|
+
const child = spawn(electronPath, [runnerDir], {
|
|
121
|
+
detached: true,
|
|
122
|
+
stdio: 'ignore',
|
|
123
|
+
});
|
|
124
|
+
child.unref();
|
|
125
|
+
console.log('Specd Runner launched.');
|
|
126
|
+
}
|
|
127
|
+
} else {
|
|
128
|
+
console.log('Usage:');
|
|
129
|
+
console.log(' specd llm-init [--local] Install Claude Code commands/agents');
|
|
130
|
+
console.log(' specd runner Launch the Specd Runner app');
|
|
131
|
+
console.log(' specd runner register <path> Register a project folder');
|
|
132
|
+
console.log(' specd runner unregister <id> Remove a project');
|
|
133
|
+
console.log(' specd runner projects List registered projects');
|
|
134
|
+
console.log(' specd runner status Show task status');
|
|
135
|
+
}
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: specd.best-practices
|
|
3
|
+
description: Detect repo tech stack and generate a curated best-practices reference doc with project patterns, Claude Code tools, and tooling recommendations
|
|
4
|
+
argument-hint: ""
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Bash
|
|
8
|
+
- Glob
|
|
9
|
+
- Grep
|
|
10
|
+
- Write
|
|
11
|
+
- Edit
|
|
12
|
+
- Agent
|
|
13
|
+
- AskUserQuestion
|
|
14
|
+
- WebSearch
|
|
15
|
+
- WebFetch
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
<objective>
|
|
19
|
+
Detect a repo's tech stack, spawn research agents to discover best practices, Claude Code ecosystem tools, and recommended tooling, then produce a curated `docs/best-practices.md` reference doc.
|
|
20
|
+
|
|
21
|
+
Agents use web search to find current patterns, MCP servers, skills, hooks, and tooling for the detected stack. The output presents options with tradeoffs — not opinionated prescriptions.
|
|
22
|
+
|
|
23
|
+
Output: `docs/best-practices.md` in the target repo.
|
|
24
|
+
</objective>
|
|
25
|
+
|
|
26
|
+
<execution_context>
|
|
27
|
+
@~/.claude/specdacular/workflows/best-practices.md
|
|
28
|
+
</execution_context>
|
|
29
|
+
|
|
30
|
+
<context>
|
|
31
|
+
**How it works:**
|
|
32
|
+
1. Detects all tech stacks in the repo (marker files + dependency parsing)
|
|
33
|
+
2. Asks user for focus areas before research
|
|
34
|
+
3. Spawns 3 parallel research agents (stack patterns, Claude Code ecosystem, tooling/DX)
|
|
35
|
+
4. Merges findings into a structured reference doc
|
|
36
|
+
|
|
37
|
+
**Key principles:**
|
|
38
|
+
- Auto-detects stack — user doesn't need to specify what tech they use
|
|
39
|
+
- Presents options with context and tradeoffs, not single prescriptions
|
|
40
|
+
- User steers research focus before agents run
|
|
41
|
+
- Output is self-contained and readable without re-running the command
|
|
42
|
+
- Does NOT modify CLAUDE.md — the doc is for the user, not necessarily for Claude
|
|
43
|
+
</context>
|
|
44
|
+
|
|
45
|
+
<when_to_use>
|
|
46
|
+
**Use /specd.best-practices for:**
|
|
47
|
+
- Starting a new project and want to know what tools/patterns exist for your stack
|
|
48
|
+
- Joining an existing project and want to understand available Claude Code integrations
|
|
49
|
+
- Exploring what MCP servers, skills, and hooks are available for your tech
|
|
50
|
+
- Getting current tooling recommendations (linters, formatters, testing, CI)
|
|
51
|
+
|
|
52
|
+
**Skip /specd.best-practices for:**
|
|
53
|
+
- Projects where you already have a well-established toolchain
|
|
54
|
+
- When you need docs about your existing codebase (use `/specd.docs` instead)
|
|
55
|
+
</when_to_use>
|
|
56
|
+
|
|
57
|
+
<process>
|
|
58
|
+
1. Detect tech stacks from repo marker files and dependencies
|
|
59
|
+
2. Present detected stacks to user (ask to select if 3+ found)
|
|
60
|
+
3. Ask user for focus areas (everything, structure, Claude Code tools, or tooling/DX)
|
|
61
|
+
4. Spawn 3 parallel research agents with stack and focus context
|
|
62
|
+
5. Collect and merge agent outputs
|
|
63
|
+
6. Write `docs/best-practices.md` with categorized findings
|
|
64
|
+
7. Show summary to user
|
|
65
|
+
</process>
|
|
66
|
+
|
|
67
|
+
<success_criteria>
|
|
68
|
+
- [ ] Tech stack auto-detected from repo files
|
|
69
|
+
- [ ] User asked for focus areas before research
|
|
70
|
+
- [ ] 3 research agents spawned with stack-aware prompts
|
|
71
|
+
- [ ] Output organized by category: stack patterns, Claude Code ecosystem, tooling/DX
|
|
72
|
+
- [ ] Each recommendation includes context, tradeoffs, and when to use it
|
|
73
|
+
- [ ] Doc is self-contained and readable
|
|
74
|
+
- [ ] CLAUDE.md is NOT modified
|
|
75
|
+
</success_criteria>
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: specd.docs
|
|
3
|
+
description: Generate topic-based docs and CLAUDE.md routing table from codebase analysis
|
|
4
|
+
argument-hint: ""
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Bash
|
|
8
|
+
- Glob
|
|
9
|
+
- Grep
|
|
10
|
+
- Write
|
|
11
|
+
- Edit
|
|
12
|
+
- Task
|
|
13
|
+
- Agent
|
|
14
|
+
- AskUserQuestion
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
<objective>
|
|
18
|
+
Generate AI-optimized documentation using a context-engineering approach.
|
|
19
|
+
|
|
20
|
+
Spawns 4 parallel mapper agents for raw codebase analysis, then merges their outputs into topic-specific docs in `docs/`. Writes CLAUDE.md as a pure routing table — no inline rules.
|
|
21
|
+
|
|
22
|
+
Output: `docs/` folder with topic-specific docs + `CLAUDE.md` routing table.
|
|
23
|
+
</objective>
|
|
24
|
+
|
|
25
|
+
<execution_context>
|
|
26
|
+
@~/.claude/specdacular/workflows/docs.md
|
|
27
|
+
</execution_context>
|
|
28
|
+
|
|
29
|
+
<context>
|
|
30
|
+
**Context engineering approach:**
|
|
31
|
+
|
|
32
|
+
CLAUDE.md is a thin routing table — "Working on X? Read docs/Y.md". All knowledge lives in `docs/`:
|
|
33
|
+
|
|
34
|
+
| File | Purpose |
|
|
35
|
+
|------|---------|
|
|
36
|
+
| `docs/rules.md` | Always-true rules (imports, naming, conventions) |
|
|
37
|
+
| `docs/{topic}.md` | Topic-specific patterns and guidance |
|
|
38
|
+
| `CLAUDE.md` | Router only — points to the right doc for the context |
|
|
39
|
+
|
|
40
|
+
**Key principles:**
|
|
41
|
+
- Topics are dynamic — detected from what the codebase actually uses
|
|
42
|
+
- Every doc has frontmatter (`last_reviewed`, `generated_by`) for staleness tracking
|
|
43
|
+
- `rules.md` is always generated — contains project-wide rules
|
|
44
|
+
- CLAUDE.md merge is non-destructive — preserves existing user content
|
|
45
|
+
- No external research during generation — docs reflect actual code patterns
|
|
46
|
+
</context>
|
|
47
|
+
|
|
48
|
+
<when_to_use>
|
|
49
|
+
**Use /specd.docs for:**
|
|
50
|
+
- First time working with a codebase
|
|
51
|
+
- Before planning a new feature
|
|
52
|
+
- After significant refactoring
|
|
53
|
+
- When existing docs are stale or missing
|
|
54
|
+
|
|
55
|
+
**Skip /specd.docs for:**
|
|
56
|
+
- Trivial codebases (<10 files)
|
|
57
|
+
- When you have recently generated docs (use `/specd.docs.review` instead)
|
|
58
|
+
</when_to_use>
|
|
59
|
+
|
|
60
|
+
<process>
|
|
61
|
+
1. Discover docs location (check CLAUDE.md for existing path, default to `docs/`)
|
|
62
|
+
2. Check for existing specd-generated docs (offer refresh or skip)
|
|
63
|
+
3. Scan for existing project documentation (README, ARCHITECTURE, etc.)
|
|
64
|
+
4. Spawn 4 parallel mapper agents to temp directory
|
|
65
|
+
5. Merge agent outputs into topic clusters (dynamic topic detection)
|
|
66
|
+
6. Propose doc list to user for approval
|
|
67
|
+
7. Generate topic docs + `rules.md` with YAML frontmatter
|
|
68
|
+
8. Write/update CLAUDE.md routing table (non-destructive merge)
|
|
69
|
+
9. Clean up temp files
|
|
70
|
+
</process>
|
|
71
|
+
|
|
72
|
+
<success_criteria>
|
|
73
|
+
- [ ] Topic-specific docs generated in `docs/` (or user-configured location)
|
|
74
|
+
- [ ] `docs/rules.md` always generated with project-wide rules
|
|
75
|
+
- [ ] All docs have YAML frontmatter (`last_reviewed`, `generated_by`)
|
|
76
|
+
- [ ] CLAUDE.md routing table written (new or merged into existing)
|
|
77
|
+
- [ ] CLAUDE.md has zero inline rules — purely a router
|
|
78
|
+
- [ ] Topics dynamically determined from codebase analysis
|
|
79
|
+
- [ ] User approved doc list before generation
|
|
80
|
+
- [ ] Existing CLAUDE.md content preserved during merge
|
|
81
|
+
</success_criteria>
|
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: specd.docs.review
|
|
3
|
+
description: Review and audit codebase docs for accuracy, staleness, and coverage gaps
|
|
4
|
+
argument-hint: ""
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Bash
|
|
8
|
+
- Glob
|
|
9
|
+
- Grep
|
|
10
|
+
- Write
|
|
11
|
+
- Edit
|
|
12
|
+
- Agent
|
|
13
|
+
- AskUserQuestion
|
|
14
|
+
- WebSearch
|
|
15
|
+
- WebFetch
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
<objective>
|
|
19
|
+
Audit existing topic docs for accuracy, staleness, and coverage gaps. Optionally research best practices for the detected stack. Updates frontmatter review dates after approval.
|
|
20
|
+
|
|
21
|
+
Output: Review findings with actionable suggestions, updated docs and review dates.
|
|
22
|
+
</objective>
|
|
23
|
+
|
|
24
|
+
<execution_context>
|
|
25
|
+
@~/.claude/specdacular/workflows/docs-review.md
|
|
26
|
+
</execution_context>
|
|
27
|
+
|
|
28
|
+
<context>
|
|
29
|
+
**Review approach:**
|
|
30
|
+
|
|
31
|
+
Each doc has YAML frontmatter with `last_reviewed` and `generated_by` fields. The review workflow:
|
|
32
|
+
|
|
33
|
+
1. Reads frontmatter dates to detect stale docs
|
|
34
|
+
2. Spot-checks code references in docs against current codebase
|
|
35
|
+
3. Detects coverage gaps (technologies in code not covered by docs)
|
|
36
|
+
4. Optionally researches best practices for improvement suggestions
|
|
37
|
+
5. Presents findings and lets user choose what to update
|
|
38
|
+
|
|
39
|
+
**Staleness detection:**
|
|
40
|
+
- Compare `last_reviewed` against today and recent git history
|
|
41
|
+
- Flag docs where significant code changes happened since last review
|
|
42
|
+
- Check if referenced file paths, function signatures, and patterns still exist
|
|
43
|
+
|
|
44
|
+
**Research agents (optional):**
|
|
45
|
+
- Only used during review, never during generation (DEC-008)
|
|
46
|
+
- Investigate current best practices for detected technologies
|
|
47
|
+
- Suggest improvements, not mandates
|
|
48
|
+
</context>
|
|
49
|
+
|
|
50
|
+
<when_to_use>
|
|
51
|
+
**Use /specd.docs.review for:**
|
|
52
|
+
- After significant code changes (refactoring, new features)
|
|
53
|
+
- Periodically (monthly or quarterly)
|
|
54
|
+
- When docs feel out of date
|
|
55
|
+
- When wanting best-practice improvement suggestions
|
|
56
|
+
|
|
57
|
+
**Skip /specd.docs.review for:**
|
|
58
|
+
- Right after running /specd.docs (docs are fresh)
|
|
59
|
+
- Trivial changes that don't affect patterns
|
|
60
|
+
</when_to_use>
|
|
61
|
+
|
|
62
|
+
<process>
|
|
63
|
+
1. Find all specd-generated docs (scan for frontmatter)
|
|
64
|
+
2. Assess freshness (compare review dates against git history)
|
|
65
|
+
3. Check accuracy (spot-check code references)
|
|
66
|
+
4. Detect gaps (technologies not covered by docs)
|
|
67
|
+
5. Optionally research best practices
|
|
68
|
+
6. Present findings with per-doc status
|
|
69
|
+
7. Apply user-selected updates and update review dates
|
|
70
|
+
</process>
|
|
71
|
+
|
|
72
|
+
<success_criteria>
|
|
73
|
+
- [ ] All specd-generated docs found and assessed
|
|
74
|
+
- [ ] Stale docs flagged with days since review
|
|
75
|
+
- [ ] Drifted docs identified with specific inaccuracies
|
|
76
|
+
- [ ] Coverage gaps detected (new technologies, obsolete docs)
|
|
77
|
+
- [ ] Research suggestions provided (if user opted in)
|
|
78
|
+
- [ ] Review dates updated on approved docs
|
|
79
|
+
- [ ] CLAUDE.md routing table updated if docs added/removed
|
|
80
|
+
</success_criteria>
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: specd.generate-skills.learn
|
|
3
|
+
description: Generate a /learn skill that captures lessons into project docs
|
|
4
|
+
argument-hint: "[namespace]"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Bash
|
|
8
|
+
- Glob
|
|
9
|
+
- Grep
|
|
10
|
+
- Write
|
|
11
|
+
- AskUserQuestion
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
<objective>
|
|
15
|
+
Generate a project-specific `/{namespace}:learn` skill that captures coding lessons, mistakes, and patterns from conversations into the project's `docs/` files.
|
|
16
|
+
|
|
17
|
+
The skill is customized to the project's actual documentation structure — it knows which doc files exist, what sections they have, and what format they use.
|
|
18
|
+
|
|
19
|
+
Output: `.claude/commands/{namespace}/learn.md`
|
|
20
|
+
</objective>
|
|
21
|
+
|
|
22
|
+
<execution_context>
|
|
23
|
+
@~/.claude/specdacular/workflows/generate-learn-skill.md
|
|
24
|
+
</execution_context>
|
|
25
|
+
|
|
26
|
+
<context>
|
|
27
|
+
**What the learn skill does:**
|
|
28
|
+
|
|
29
|
+
When a user runs `/{ns}:learn` during a conversation, it:
|
|
30
|
+
1. Extracts lessons from the conversation (or from an explicit argument)
|
|
31
|
+
2. Classifies each as a Rule (hard constraint) or Pattern (technique)
|
|
32
|
+
3. Maps it to the right doc file and section
|
|
33
|
+
4. Checks for duplicates
|
|
34
|
+
5. Writes it in the existing format
|
|
35
|
+
|
|
36
|
+
**Prerequisites:**
|
|
37
|
+
- `docs/` folder with topic docs (run `/specd.docs` first if missing)
|
|
38
|
+
- `CLAUDE.md` routing table
|
|
39
|
+
|
|
40
|
+
**After generation**, users can refine the skill with the `/skill-creator` plugin (Anthropic-verified) which provides eval, improve, and benchmark modes.
|
|
41
|
+
</context>
|
|
42
|
+
|
|
43
|
+
<when_to_use>
|
|
44
|
+
**Use after:**
|
|
45
|
+
- Running `/specd.docs` to generate project documentation
|
|
46
|
+
- When you want conversations to feed back into project docs
|
|
47
|
+
|
|
48
|
+
**Prerequisites:**
|
|
49
|
+
- `docs/` folder exists with topic docs
|
|
50
|
+
</when_to_use>
|
|
51
|
+
|
|
52
|
+
<process>
|
|
53
|
+
1. Check docs/ exists, read all doc files
|
|
54
|
+
2. Derive namespace from project name or user argument
|
|
55
|
+
3. Build doc target table from actual doc files
|
|
56
|
+
4. Generate the learn skill file
|
|
57
|
+
5. Suggest /skill-creator for refinement
|
|
58
|
+
</process>
|
|
59
|
+
|
|
60
|
+
<success_criteria>
|
|
61
|
+
- [ ] Namespace derived from project or user input
|
|
62
|
+
- [ ] `.claude/commands/{namespace}/learn.md` generated
|
|
63
|
+
- [ ] Skill references actual doc files that exist in the project
|
|
64
|
+
- [ ] Doc target table matches real docs with accurate descriptions
|
|
65
|
+
</success_criteria>
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: specd.new-runner-task
|
|
3
|
+
description: Create a new task in the Specd Runner app
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<objective>
|
|
7
|
+
Create a task in the Specd Runner by talking to its local API. Auto-detects the project from the current working directory.
|
|
8
|
+
</objective>
|
|
9
|
+
|
|
10
|
+
<instructions>
|
|
11
|
+
|
|
12
|
+
## Step 1: Detect project
|
|
13
|
+
|
|
14
|
+
Use Bash to find the matching project:
|
|
15
|
+
|
|
16
|
+
```bash
|
|
17
|
+
curl -s "http://localhost:3700/api/projects/by-path?path=$(pwd)" 2>/dev/null
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
If the runner is not running or no project matches, tell the user:
|
|
21
|
+
- "The Specd Runner doesn't seem to be running. Start it with `specd runner`."
|
|
22
|
+
- Or: "No project registered for this directory. Register with `specd runner register <path>`."
|
|
23
|
+
|
|
24
|
+
## Step 2: Gather task details
|
|
25
|
+
|
|
26
|
+
Ask the user for:
|
|
27
|
+
1. **Task name** — short description (e.g., "Add dark mode support")
|
|
28
|
+
2. **Description/spec** — what should be built (can be multi-line)
|
|
29
|
+
3. **Working directory** — which subdirectory to work in (default: ".")
|
|
30
|
+
4. **Pipeline** — which pipeline to use (default: "default")
|
|
31
|
+
5. **Priority** — 1 (highest) to 99 (lowest), default 10
|
|
32
|
+
|
|
33
|
+
## Step 3: Create the task
|
|
34
|
+
|
|
35
|
+
```bash
|
|
36
|
+
curl -s -X POST "http://localhost:3700/api/projects/{PROJECT_ID}/tasks" \
|
|
37
|
+
-H "Content-Type: application/json" \
|
|
38
|
+
-d '{
|
|
39
|
+
"name": "TASK_NAME",
|
|
40
|
+
"description": "DESCRIPTION",
|
|
41
|
+
"working_dir": "WORKING_DIR",
|
|
42
|
+
"pipeline": "PIPELINE",
|
|
43
|
+
"priority": PRIORITY,
|
|
44
|
+
"spec": "SPEC_CONTENT"
|
|
45
|
+
}'
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
## Step 4: Confirm
|
|
49
|
+
|
|
50
|
+
Show the user the created task ID and confirm it's queued for execution.
|
|
51
|
+
|
|
52
|
+
</instructions>
|
package/commands/specd.new.md
CHANGED
|
@@ -33,14 +33,14 @@ Initialize a task folder and start the first discussion. Creates structure, asks
|
|
|
33
33
|
Task name: $ARGUMENTS
|
|
34
34
|
|
|
35
35
|
**Codebase context discovery:**
|
|
36
|
-
1. Check for
|
|
37
|
-
2. If no
|
|
38
|
-
3. If neither found, offer `/specd.
|
|
36
|
+
1. Check for `CLAUDE.md` routing table — if exists, read referenced docs
|
|
37
|
+
2. If no CLAUDE.md, check for `docs/` directory with specd-generated docs
|
|
38
|
+
3. If neither found, offer `/specd.docs`
|
|
39
39
|
|
|
40
40
|
**Referenced docs (when available):**
|
|
41
|
-
- `
|
|
42
|
-
- `
|
|
43
|
-
- `
|
|
41
|
+
- `CLAUDE.md` — Routing table pointing to topic docs
|
|
42
|
+
- `docs/rules.md` — Project-wide rules
|
|
43
|
+
- `docs/*.md` — Topic-specific patterns and guidance
|
|
44
44
|
</context>
|
|
45
45
|
|
|
46
46
|
<process>
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: specd.runner-status
|
|
3
|
+
description: Show Specd Runner task status
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<objective>
|
|
7
|
+
Fetch and display the current status of all tasks across all projects from the Specd Runner.
|
|
8
|
+
</objective>
|
|
9
|
+
|
|
10
|
+
<instructions>
|
|
11
|
+
|
|
12
|
+
## Step 1: Fetch status
|
|
13
|
+
|
|
14
|
+
```bash
|
|
15
|
+
curl -s "http://localhost:3700/api/status" 2>/dev/null
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
If the runner is not running, tell the user to start it with `specd runner`.
|
|
19
|
+
|
|
20
|
+
## Step 2: Display
|
|
21
|
+
|
|
22
|
+
Format the status as a readable table showing for each project:
|
|
23
|
+
- Project name
|
|
24
|
+
- Task list with status icons (done, running, failed, queued)
|
|
25
|
+
- Current stage and progress for running tasks
|
|
26
|
+
|
|
27
|
+
</instructions>
|
package/package.json
CHANGED
|
@@ -1,9 +1,9 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "specdacular",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.11.0",
|
|
4
4
|
"description": "Feature planning system for existing codebases. Map, understand, and plan features in large projects.",
|
|
5
5
|
"bin": {
|
|
6
|
-
"
|
|
6
|
+
"specd": "bin/specd.js"
|
|
7
7
|
},
|
|
8
8
|
"files": [
|
|
9
9
|
"bin",
|
|
@@ -11,6 +11,10 @@
|
|
|
11
11
|
"agents",
|
|
12
12
|
"specdacular",
|
|
13
13
|
"hooks",
|
|
14
|
+
"runner/main",
|
|
15
|
+
"runner/renderer/dist",
|
|
16
|
+
"runner/preload.js",
|
|
17
|
+
"runner/package.json",
|
|
14
18
|
"README.md"
|
|
15
19
|
],
|
|
16
20
|
"keywords": [
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
import { EventEmitter } from 'events';
|
|
2
|
+
|
|
3
|
+
export class StreamParser extends EventEmitter {
|
|
4
|
+
constructor() {
|
|
5
|
+
super();
|
|
6
|
+
this.inBlock = null;
|
|
7
|
+
this.blockLines = [];
|
|
8
|
+
}
|
|
9
|
+
|
|
10
|
+
feed(line) {
|
|
11
|
+
if (line.startsWith('```specd-status')) {
|
|
12
|
+
this.inBlock = 'status';
|
|
13
|
+
this.blockLines = [];
|
|
14
|
+
return;
|
|
15
|
+
}
|
|
16
|
+
if (line.startsWith('```specd-result')) {
|
|
17
|
+
this.inBlock = 'result';
|
|
18
|
+
this.blockLines = [];
|
|
19
|
+
return;
|
|
20
|
+
}
|
|
21
|
+
if (line === '```' && this.inBlock) {
|
|
22
|
+
const content = this.blockLines.join('\n');
|
|
23
|
+
try {
|
|
24
|
+
const parsed = JSON.parse(content);
|
|
25
|
+
this.emit(this.inBlock, parsed);
|
|
26
|
+
} catch (err) {
|
|
27
|
+
this.emit('error', err);
|
|
28
|
+
}
|
|
29
|
+
this.inBlock = null;
|
|
30
|
+
this.blockLines = [];
|
|
31
|
+
return;
|
|
32
|
+
}
|
|
33
|
+
if (this.inBlock) {
|
|
34
|
+
this.blockLines.push(line);
|
|
35
|
+
} else {
|
|
36
|
+
this.emit('output', line);
|
|
37
|
+
}
|
|
38
|
+
}
|
|
39
|
+
}
|