@fission-ai/openspec 0.12.0 → 0.13.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 +9 -3
- package/dist/core/archive.d.ts +1 -0
- package/dist/core/archive.js +3 -2
- package/dist/core/config.js +4 -0
- package/dist/core/configurators/cline.d.ts +8 -0
- package/dist/core/configurators/cline.js +15 -0
- package/dist/core/configurators/codebuddy.d.ts +8 -0
- package/dist/core/configurators/codebuddy.js +15 -0
- package/dist/core/configurators/registry.js +6 -0
- package/dist/core/configurators/slash/auggie.d.ts +9 -0
- package/dist/core/configurators/slash/auggie.js +31 -0
- package/dist/core/configurators/slash/cline.d.ts +9 -0
- package/dist/core/configurators/slash/cline.js +23 -0
- package/dist/core/configurators/slash/codebuddy.d.ts +9 -0
- package/dist/core/configurators/slash/codebuddy.js +37 -0
- package/dist/core/configurators/slash/crush.d.ts +9 -0
- package/dist/core/configurators/slash/crush.js +37 -0
- package/dist/core/configurators/slash/opencode.d.ts +3 -0
- package/dist/core/configurators/slash/opencode.js +35 -1
- package/dist/core/configurators/slash/registry.js +12 -0
- package/dist/core/parsers/requirement-blocks.d.ts +6 -0
- package/dist/core/parsers/requirement-blocks.js +28 -5
- package/dist/core/templates/agents-template.d.ts +1 -1
- package/dist/core/templates/agents-template.js +3 -5
- package/dist/core/templates/cline-template.d.ts +2 -0
- package/dist/core/templates/cline-template.js +2 -0
- package/dist/core/templates/index.d.ts +1 -0
- package/dist/core/templates/index.js +4 -0
- package/dist/core/templates/slash-command-templates.js +10 -4
- package/dist/core/validation/validator.d.ts +1 -0
- package/dist/core/validation/validator.js +57 -6
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -91,7 +91,9 @@ These tools have built-in OpenSpec commands. Select the OpenSpec integration whe
|
|
|
91
91
|
| Tool | Commands |
|
|
92
92
|
|------|----------|
|
|
93
93
|
| **Claude Code** | `/openspec:proposal`, `/openspec:apply`, `/openspec:archive` |
|
|
94
|
+
| **CodeBuddy Code (CLI)** | `/openspec:proposal`, `/openspec:apply`, `/openspec:archive` (`.codebuddy/commands/`) — see [docs](https://www.codebuddy.ai/cli) |
|
|
94
95
|
| **Cursor** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` |
|
|
96
|
+
| **Cline** | Rules in `.clinerules/` directory (`.clinerules/openspec-*.md`) |
|
|
95
97
|
| **Factory Droid** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` (`.factory/commands/`) |
|
|
96
98
|
| **OpenCode** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` |
|
|
97
99
|
| **Kilo Code** | `/openspec-proposal.md`, `/openspec-apply.md`, `/openspec-archive.md` (`.kilocode/workflows/`) |
|
|
@@ -99,6 +101,8 @@ These tools have built-in OpenSpec commands. Select the OpenSpec integration whe
|
|
|
99
101
|
| **Codex** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` (global: `~/.codex/prompts`, auto-installed) |
|
|
100
102
|
| **GitHub Copilot** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` (`.github/prompts/`) |
|
|
101
103
|
| **Amazon Q Developer** | `@openspec-proposal`, `@openspec-apply`, `@openspec-archive` (`.amazonq/prompts/`) |
|
|
104
|
+
| **Auggie (Augment CLI)** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` (`.augment/commands/`) |
|
|
105
|
+
|
|
102
106
|
|
|
103
107
|
Kilo Code discovers team workflows automatically. Save the generated files under `.kilocode/workflows/` and trigger them from the command palette with `/openspec-proposal.md`, `/openspec-apply.md`, or `/openspec-archive.md`.
|
|
104
108
|
|
|
@@ -138,13 +142,15 @@ openspec init
|
|
|
138
142
|
```
|
|
139
143
|
|
|
140
144
|
**What happens during initialization:**
|
|
141
|
-
- You'll be prompted to pick any natively supported AI tools (Claude Code, Cursor, OpenCode, etc.); other assistants always rely on the shared `AGENTS.md` stub
|
|
145
|
+
- You'll be prompted to pick any natively supported AI tools (Claude Code, CodeBuddy, Cursor, OpenCode, etc.); other assistants always rely on the shared `AGENTS.md` stub
|
|
142
146
|
- OpenSpec automatically configures slash commands for the tools you choose and always writes a managed `AGENTS.md` hand-off at the project root
|
|
143
147
|
- A new `openspec/` directory structure is created in your project
|
|
144
148
|
|
|
145
149
|
**After setup:**
|
|
146
150
|
- Primary AI tools can trigger `/openspec` workflows without additional configuration
|
|
147
151
|
- Run `openspec list` to verify the setup and view any active changes
|
|
152
|
+
- If your coding assistant doesn't surface the new slash commands right away, restart it. Slash commands are loaded at startup,
|
|
153
|
+
so a fresh launch ensures they appear
|
|
148
154
|
|
|
149
155
|
### Create Your First Change
|
|
150
156
|
|
|
@@ -211,7 +217,7 @@ Or run the command yourself in terminal:
|
|
|
211
217
|
$ openspec archive add-profile-filters --yes # Archive the completed change without prompts
|
|
212
218
|
```
|
|
213
219
|
|
|
214
|
-
**Note:** Tools with native slash commands (Claude Code, Cursor, Codex) can use the shortcuts shown. All other tools work with natural language requests to "create an OpenSpec proposal", "apply the OpenSpec change", or "archive the change".
|
|
220
|
+
**Note:** Tools with native slash commands (Claude Code, CodeBuddy, Cursor, Codex) can use the shortcuts shown. All other tools work with natural language requests to "create an OpenSpec proposal", "apply the OpenSpec change", or "archive the change".
|
|
215
221
|
|
|
216
222
|
## Command Reference
|
|
217
223
|
|
|
@@ -323,7 +329,7 @@ Without specs, AI coding assistants generate code from vague prompts, often miss
|
|
|
323
329
|
1. **Initialize OpenSpec** – Run `openspec init` in your repo.
|
|
324
330
|
2. **Start with new features** – Ask your AI to capture upcoming work as change proposals.
|
|
325
331
|
3. **Grow incrementally** – Each change archives into living specs that document your system.
|
|
326
|
-
4. **Stay flexible** – Different teammates can use Claude Code, Cursor, or any AGENTS.md-compatible tool while sharing the same specs.
|
|
332
|
+
4. **Stay flexible** – Different teammates can use Claude Code, CodeBuddy, Cursor, or any AGENTS.md-compatible tool while sharing the same specs.
|
|
327
333
|
|
|
328
334
|
Run `openspec update` whenever someone switches tools so your agents pick up the latest instructions and slash-command bindings.
|
|
329
335
|
|
package/dist/core/archive.d.ts
CHANGED
package/dist/core/archive.js
CHANGED
|
@@ -38,8 +38,9 @@ export class ArchiveCommand {
|
|
|
38
38
|
catch {
|
|
39
39
|
throw new Error(`Change '${changeName}' not found.`);
|
|
40
40
|
}
|
|
41
|
+
const skipValidation = options.validate === false || options.noValidate === true;
|
|
41
42
|
// Validate specs and change before archiving
|
|
42
|
-
if (!
|
|
43
|
+
if (!skipValidation) {
|
|
43
44
|
const validator = new Validator();
|
|
44
45
|
let hasValidationErrors = false;
|
|
45
46
|
// Validate proposal.md (non-blocking unless strict mode desired in future)
|
|
@@ -182,7 +183,7 @@ export class ArchiveCommand {
|
|
|
182
183
|
let totals = { added: 0, modified: 0, removed: 0, renamed: 0 };
|
|
183
184
|
for (const p of prepared) {
|
|
184
185
|
const specName = path.basename(path.dirname(p.update.target));
|
|
185
|
-
if (!
|
|
186
|
+
if (!skipValidation) {
|
|
186
187
|
const report = await new Validator().validateSpecContent(specName, p.rebuilt);
|
|
187
188
|
if (!report.valid) {
|
|
188
189
|
console.log(chalk.red(`\nValidation errors in rebuilt spec for ${specName} (will not write changes):`));
|
package/dist/core/config.js
CHANGED
|
@@ -4,7 +4,11 @@ export const OPENSPEC_MARKERS = {
|
|
|
4
4
|
end: '<!-- OPENSPEC:END -->'
|
|
5
5
|
};
|
|
6
6
|
export const AI_TOOLS = [
|
|
7
|
+
{ name: 'Auggie (Augment CLI)', value: 'auggie', available: true, successLabel: 'Auggie' },
|
|
7
8
|
{ name: 'Claude Code', value: 'claude', available: true, successLabel: 'Claude Code' },
|
|
9
|
+
{ name: 'Cline', value: 'cline', available: true, successLabel: 'Cline' },
|
|
10
|
+
{ name: 'CodeBuddy Code (CLI)', value: 'codebuddy', available: true, successLabel: 'CodeBuddy Code' },
|
|
11
|
+
{ name: 'Crush', value: 'crush', available: true, successLabel: 'Crush' },
|
|
8
12
|
{ name: 'Cursor', value: 'cursor', available: true, successLabel: 'Cursor' },
|
|
9
13
|
{ name: 'Factory Droid', value: 'factory', available: true, successLabel: 'Factory Droid' },
|
|
10
14
|
{ name: 'OpenCode', value: 'opencode', available: true, successLabel: 'OpenCode' },
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
import { ToolConfigurator } from './base.js';
|
|
2
|
+
export declare class ClineConfigurator implements ToolConfigurator {
|
|
3
|
+
name: string;
|
|
4
|
+
configFileName: string;
|
|
5
|
+
isAvailable: boolean;
|
|
6
|
+
configure(projectPath: string, openspecDir: string): Promise<void>;
|
|
7
|
+
}
|
|
8
|
+
//# sourceMappingURL=cline.d.ts.map
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
import path from 'path';
|
|
2
|
+
import { FileSystemUtils } from '../../utils/file-system.js';
|
|
3
|
+
import { TemplateManager } from '../templates/index.js';
|
|
4
|
+
import { OPENSPEC_MARKERS } from '../config.js';
|
|
5
|
+
export class ClineConfigurator {
|
|
6
|
+
name = 'Cline';
|
|
7
|
+
configFileName = 'CLINE.md';
|
|
8
|
+
isAvailable = true;
|
|
9
|
+
async configure(projectPath, openspecDir) {
|
|
10
|
+
const filePath = path.join(projectPath, this.configFileName);
|
|
11
|
+
const content = TemplateManager.getClineTemplate();
|
|
12
|
+
await FileSystemUtils.updateFileWithMarkers(filePath, content, OPENSPEC_MARKERS.start, OPENSPEC_MARKERS.end);
|
|
13
|
+
}
|
|
14
|
+
}
|
|
15
|
+
//# sourceMappingURL=cline.js.map
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
import { ToolConfigurator } from './base.js';
|
|
2
|
+
export declare class CodeBuddyConfigurator implements ToolConfigurator {
|
|
3
|
+
name: string;
|
|
4
|
+
configFileName: string;
|
|
5
|
+
isAvailable: boolean;
|
|
6
|
+
configure(projectPath: string, openspecDir: string): Promise<void>;
|
|
7
|
+
}
|
|
8
|
+
//# sourceMappingURL=codebuddy.d.ts.map
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
import path from 'path';
|
|
2
|
+
import { FileSystemUtils } from '../../utils/file-system.js';
|
|
3
|
+
import { TemplateManager } from '../templates/index.js';
|
|
4
|
+
import { OPENSPEC_MARKERS } from '../config.js';
|
|
5
|
+
export class CodeBuddyConfigurator {
|
|
6
|
+
name = 'CodeBuddy';
|
|
7
|
+
configFileName = 'CODEBUDDY.md';
|
|
8
|
+
isAvailable = true;
|
|
9
|
+
async configure(projectPath, openspecDir) {
|
|
10
|
+
const filePath = path.join(projectPath, this.configFileName);
|
|
11
|
+
const content = TemplateManager.getClaudeTemplate();
|
|
12
|
+
await FileSystemUtils.updateFileWithMarkers(filePath, content, OPENSPEC_MARKERS.start, OPENSPEC_MARKERS.end);
|
|
13
|
+
}
|
|
14
|
+
}
|
|
15
|
+
//# sourceMappingURL=codebuddy.js.map
|
|
@@ -1,12 +1,18 @@
|
|
|
1
1
|
import { ClaudeConfigurator } from './claude.js';
|
|
2
|
+
import { ClineConfigurator } from './cline.js';
|
|
3
|
+
import { CodeBuddyConfigurator } from './codebuddy.js';
|
|
2
4
|
import { AgentsStandardConfigurator } from './agents.js';
|
|
3
5
|
export class ToolRegistry {
|
|
4
6
|
static tools = new Map();
|
|
5
7
|
static {
|
|
6
8
|
const claudeConfigurator = new ClaudeConfigurator();
|
|
9
|
+
const clineConfigurator = new ClineConfigurator();
|
|
10
|
+
const codeBuddyConfigurator = new CodeBuddyConfigurator();
|
|
7
11
|
const agentsConfigurator = new AgentsStandardConfigurator();
|
|
8
12
|
// Register with the ID that matches the checkbox value
|
|
9
13
|
this.tools.set('claude', claudeConfigurator);
|
|
14
|
+
this.tools.set('cline', clineConfigurator);
|
|
15
|
+
this.tools.set('codebuddy', codeBuddyConfigurator);
|
|
10
16
|
this.tools.set('agents', agentsConfigurator);
|
|
11
17
|
}
|
|
12
18
|
static register(tool) {
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
import { SlashCommandConfigurator } from './base.js';
|
|
2
|
+
import { SlashCommandId } from '../../templates/index.js';
|
|
3
|
+
export declare class AuggieSlashCommandConfigurator extends SlashCommandConfigurator {
|
|
4
|
+
readonly toolId = "auggie";
|
|
5
|
+
readonly isAvailable = true;
|
|
6
|
+
protected getRelativePath(id: SlashCommandId): string;
|
|
7
|
+
protected getFrontmatter(id: SlashCommandId): string;
|
|
8
|
+
}
|
|
9
|
+
//# sourceMappingURL=auggie.d.ts.map
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
import { SlashCommandConfigurator } from './base.js';
|
|
2
|
+
const FILE_PATHS = {
|
|
3
|
+
proposal: '.augment/commands/openspec-proposal.md',
|
|
4
|
+
apply: '.augment/commands/openspec-apply.md',
|
|
5
|
+
archive: '.augment/commands/openspec-archive.md'
|
|
6
|
+
};
|
|
7
|
+
const FRONTMATTER = {
|
|
8
|
+
proposal: `---
|
|
9
|
+
description: Scaffold a new OpenSpec change and validate strictly.
|
|
10
|
+
argument-hint: feature description or request
|
|
11
|
+
---`,
|
|
12
|
+
apply: `---
|
|
13
|
+
description: Implement an approved OpenSpec change and keep tasks in sync.
|
|
14
|
+
argument-hint: change-id
|
|
15
|
+
---`,
|
|
16
|
+
archive: `---
|
|
17
|
+
description: Archive a deployed OpenSpec change and update specs.
|
|
18
|
+
argument-hint: change-id
|
|
19
|
+
---`
|
|
20
|
+
};
|
|
21
|
+
export class AuggieSlashCommandConfigurator extends SlashCommandConfigurator {
|
|
22
|
+
toolId = 'auggie';
|
|
23
|
+
isAvailable = true;
|
|
24
|
+
getRelativePath(id) {
|
|
25
|
+
return FILE_PATHS[id];
|
|
26
|
+
}
|
|
27
|
+
getFrontmatter(id) {
|
|
28
|
+
return FRONTMATTER[id];
|
|
29
|
+
}
|
|
30
|
+
}
|
|
31
|
+
//# sourceMappingURL=auggie.js.map
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
import { SlashCommandConfigurator } from './base.js';
|
|
2
|
+
import { SlashCommandId } from '../../templates/index.js';
|
|
3
|
+
export declare class ClineSlashCommandConfigurator extends SlashCommandConfigurator {
|
|
4
|
+
readonly toolId = "cline";
|
|
5
|
+
readonly isAvailable = true;
|
|
6
|
+
protected getRelativePath(id: SlashCommandId): string;
|
|
7
|
+
protected getFrontmatter(id: SlashCommandId): string | undefined;
|
|
8
|
+
}
|
|
9
|
+
//# sourceMappingURL=cline.d.ts.map
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
import { SlashCommandConfigurator } from './base.js';
|
|
2
|
+
const FILE_PATHS = {
|
|
3
|
+
proposal: '.clinerules/openspec-proposal.md',
|
|
4
|
+
apply: '.clinerules/openspec-apply.md',
|
|
5
|
+
archive: '.clinerules/openspec-archive.md'
|
|
6
|
+
};
|
|
7
|
+
export class ClineSlashCommandConfigurator extends SlashCommandConfigurator {
|
|
8
|
+
toolId = 'cline';
|
|
9
|
+
isAvailable = true;
|
|
10
|
+
getRelativePath(id) {
|
|
11
|
+
return FILE_PATHS[id];
|
|
12
|
+
}
|
|
13
|
+
getFrontmatter(id) {
|
|
14
|
+
const descriptions = {
|
|
15
|
+
proposal: 'Scaffold a new OpenSpec change and validate strictly.',
|
|
16
|
+
apply: 'Implement an approved OpenSpec change and keep tasks in sync.',
|
|
17
|
+
archive: 'Archive a deployed OpenSpec change and update specs.'
|
|
18
|
+
};
|
|
19
|
+
const description = descriptions[id];
|
|
20
|
+
return `# OpenSpec: ${id.charAt(0).toUpperCase() + id.slice(1)}\n\n${description}`;
|
|
21
|
+
}
|
|
22
|
+
}
|
|
23
|
+
//# sourceMappingURL=cline.js.map
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
import { SlashCommandConfigurator } from './base.js';
|
|
2
|
+
import { SlashCommandId } from '../../templates/index.js';
|
|
3
|
+
export declare class CodeBuddySlashCommandConfigurator extends SlashCommandConfigurator {
|
|
4
|
+
readonly toolId = "codebuddy";
|
|
5
|
+
readonly isAvailable = true;
|
|
6
|
+
protected getRelativePath(id: SlashCommandId): string;
|
|
7
|
+
protected getFrontmatter(id: SlashCommandId): string;
|
|
8
|
+
}
|
|
9
|
+
//# sourceMappingURL=codebuddy.d.ts.map
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
import { SlashCommandConfigurator } from './base.js';
|
|
2
|
+
const FILE_PATHS = {
|
|
3
|
+
proposal: '.codebuddy/commands/openspec/proposal.md',
|
|
4
|
+
apply: '.codebuddy/commands/openspec/apply.md',
|
|
5
|
+
archive: '.codebuddy/commands/openspec/archive.md'
|
|
6
|
+
};
|
|
7
|
+
const FRONTMATTER = {
|
|
8
|
+
proposal: `---
|
|
9
|
+
name: OpenSpec: Proposal
|
|
10
|
+
description: Scaffold a new OpenSpec change and validate strictly.
|
|
11
|
+
category: OpenSpec
|
|
12
|
+
tags: [openspec, change]
|
|
13
|
+
---`,
|
|
14
|
+
apply: `---
|
|
15
|
+
name: OpenSpec: Apply
|
|
16
|
+
description: Implement an approved OpenSpec change and keep tasks in sync.
|
|
17
|
+
category: OpenSpec
|
|
18
|
+
tags: [openspec, apply]
|
|
19
|
+
---`,
|
|
20
|
+
archive: `---
|
|
21
|
+
name: OpenSpec: Archive
|
|
22
|
+
description: Archive a deployed OpenSpec change and update specs.
|
|
23
|
+
category: OpenSpec
|
|
24
|
+
tags: [openspec, archive]
|
|
25
|
+
---`
|
|
26
|
+
};
|
|
27
|
+
export class CodeBuddySlashCommandConfigurator extends SlashCommandConfigurator {
|
|
28
|
+
toolId = 'codebuddy';
|
|
29
|
+
isAvailable = true;
|
|
30
|
+
getRelativePath(id) {
|
|
31
|
+
return FILE_PATHS[id];
|
|
32
|
+
}
|
|
33
|
+
getFrontmatter(id) {
|
|
34
|
+
return FRONTMATTER[id];
|
|
35
|
+
}
|
|
36
|
+
}
|
|
37
|
+
//# sourceMappingURL=codebuddy.js.map
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
import { SlashCommandConfigurator } from './base.js';
|
|
2
|
+
import { SlashCommandId } from '../../templates/index.js';
|
|
3
|
+
export declare class CrushSlashCommandConfigurator extends SlashCommandConfigurator {
|
|
4
|
+
readonly toolId = "crush";
|
|
5
|
+
readonly isAvailable = true;
|
|
6
|
+
protected getRelativePath(id: SlashCommandId): string;
|
|
7
|
+
protected getFrontmatter(id: SlashCommandId): string;
|
|
8
|
+
}
|
|
9
|
+
//# sourceMappingURL=crush.d.ts.map
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
import { SlashCommandConfigurator } from './base.js';
|
|
2
|
+
const FILE_PATHS = {
|
|
3
|
+
proposal: '.crush/commands/openspec/proposal.md',
|
|
4
|
+
apply: '.crush/commands/openspec/apply.md',
|
|
5
|
+
archive: '.crush/commands/openspec/archive.md'
|
|
6
|
+
};
|
|
7
|
+
const FRONTMATTER = {
|
|
8
|
+
proposal: `---
|
|
9
|
+
name: OpenSpec: Proposal
|
|
10
|
+
description: Scaffold a new OpenSpec change and validate strictly.
|
|
11
|
+
category: OpenSpec
|
|
12
|
+
tags: [openspec, change]
|
|
13
|
+
---`,
|
|
14
|
+
apply: `---
|
|
15
|
+
name: OpenSpec: Apply
|
|
16
|
+
description: Implement an approved OpenSpec change and keep tasks in sync.
|
|
17
|
+
category: OpenSpec
|
|
18
|
+
tags: [openspec, apply]
|
|
19
|
+
---`,
|
|
20
|
+
archive: `---
|
|
21
|
+
name: OpenSpec: Archive
|
|
22
|
+
description: Archive a deployed OpenSpec change and update specs.
|
|
23
|
+
category: OpenSpec
|
|
24
|
+
tags: [openspec, archive]
|
|
25
|
+
---`
|
|
26
|
+
};
|
|
27
|
+
export class CrushSlashCommandConfigurator extends SlashCommandConfigurator {
|
|
28
|
+
toolId = 'crush';
|
|
29
|
+
isAvailable = true;
|
|
30
|
+
getRelativePath(id) {
|
|
31
|
+
return FILE_PATHS[id];
|
|
32
|
+
}
|
|
33
|
+
getFrontmatter(id) {
|
|
34
|
+
return FRONTMATTER[id];
|
|
35
|
+
}
|
|
36
|
+
}
|
|
37
|
+
//# sourceMappingURL=crush.js.map
|
|
@@ -5,5 +5,8 @@ export declare class OpenCodeSlashCommandConfigurator extends SlashCommandConfig
|
|
|
5
5
|
readonly isAvailable = true;
|
|
6
6
|
protected getRelativePath(id: SlashCommandId): string;
|
|
7
7
|
protected getFrontmatter(id: SlashCommandId): string | undefined;
|
|
8
|
+
generateAll(projectPath: string, _openspecDir: string): Promise<string[]>;
|
|
9
|
+
updateExisting(projectPath: string, _openspecDir: string): Promise<string[]>;
|
|
10
|
+
private rewriteArchiveFile;
|
|
8
11
|
}
|
|
9
12
|
//# sourceMappingURL=opencode.d.ts.map
|
|
@@ -1,4 +1,6 @@
|
|
|
1
1
|
import { SlashCommandConfigurator } from "./base.js";
|
|
2
|
+
import { FileSystemUtils } from "../../../utils/file-system.js";
|
|
3
|
+
import { OPENSPEC_MARKERS } from "../../config.js";
|
|
2
4
|
const FILE_PATHS = {
|
|
3
5
|
proposal: ".opencode/command/openspec-proposal.md",
|
|
4
6
|
apply: ".opencode/command/openspec-apply.md",
|
|
@@ -21,7 +23,11 @@ description: Implement an approved OpenSpec change and keep tasks in sync.
|
|
|
21
23
|
archive: `---
|
|
22
24
|
agent: build
|
|
23
25
|
description: Archive a deployed OpenSpec change and update specs.
|
|
24
|
-
|
|
26
|
+
---
|
|
27
|
+
<ChangeId>
|
|
28
|
+
$ARGUMENTS
|
|
29
|
+
</ChangeId>
|
|
30
|
+
`,
|
|
25
31
|
};
|
|
26
32
|
export class OpenCodeSlashCommandConfigurator extends SlashCommandConfigurator {
|
|
27
33
|
toolId = "opencode";
|
|
@@ -32,5 +38,33 @@ export class OpenCodeSlashCommandConfigurator extends SlashCommandConfigurator {
|
|
|
32
38
|
getFrontmatter(id) {
|
|
33
39
|
return FRONTMATTER[id];
|
|
34
40
|
}
|
|
41
|
+
async generateAll(projectPath, _openspecDir) {
|
|
42
|
+
const createdOrUpdated = await super.generateAll(projectPath, _openspecDir);
|
|
43
|
+
await this.rewriteArchiveFile(projectPath);
|
|
44
|
+
return createdOrUpdated;
|
|
45
|
+
}
|
|
46
|
+
async updateExisting(projectPath, _openspecDir) {
|
|
47
|
+
const updated = await super.updateExisting(projectPath, _openspecDir);
|
|
48
|
+
const rewroteArchive = await this.rewriteArchiveFile(projectPath);
|
|
49
|
+
if (rewroteArchive && !updated.includes(FILE_PATHS.archive)) {
|
|
50
|
+
updated.push(FILE_PATHS.archive);
|
|
51
|
+
}
|
|
52
|
+
return updated;
|
|
53
|
+
}
|
|
54
|
+
async rewriteArchiveFile(projectPath) {
|
|
55
|
+
const archivePath = FileSystemUtils.joinPath(projectPath, FILE_PATHS.archive);
|
|
56
|
+
if (!await FileSystemUtils.fileExists(archivePath)) {
|
|
57
|
+
return false;
|
|
58
|
+
}
|
|
59
|
+
const body = this.getBody("archive");
|
|
60
|
+
const frontmatter = this.getFrontmatter("archive");
|
|
61
|
+
const sections = [];
|
|
62
|
+
if (frontmatter) {
|
|
63
|
+
sections.push(frontmatter.trim());
|
|
64
|
+
}
|
|
65
|
+
sections.push(`${OPENSPEC_MARKERS.start}\n${body}\n${OPENSPEC_MARKERS.end}`);
|
|
66
|
+
await FileSystemUtils.writeFile(archivePath, sections.join("\n") + "\n");
|
|
67
|
+
return true;
|
|
68
|
+
}
|
|
35
69
|
}
|
|
36
70
|
//# sourceMappingURL=opencode.js.map
|
|
@@ -1,4 +1,5 @@
|
|
|
1
1
|
import { ClaudeSlashCommandConfigurator } from './claude.js';
|
|
2
|
+
import { CodeBuddySlashCommandConfigurator } from './codebuddy.js';
|
|
2
3
|
import { CursorSlashCommandConfigurator } from './cursor.js';
|
|
3
4
|
import { WindsurfSlashCommandConfigurator } from './windsurf.js';
|
|
4
5
|
import { KiloCodeSlashCommandConfigurator } from './kilocode.js';
|
|
@@ -7,10 +8,14 @@ import { CodexSlashCommandConfigurator } from './codex.js';
|
|
|
7
8
|
import { GitHubCopilotSlashCommandConfigurator } from './github-copilot.js';
|
|
8
9
|
import { AmazonQSlashCommandConfigurator } from './amazon-q.js';
|
|
9
10
|
import { FactorySlashCommandConfigurator } from './factory.js';
|
|
11
|
+
import { AuggieSlashCommandConfigurator } from './auggie.js';
|
|
12
|
+
import { ClineSlashCommandConfigurator } from './cline.js';
|
|
13
|
+
import { CrushSlashCommandConfigurator } from './crush.js';
|
|
10
14
|
export class SlashCommandRegistry {
|
|
11
15
|
static configurators = new Map();
|
|
12
16
|
static {
|
|
13
17
|
const claude = new ClaudeSlashCommandConfigurator();
|
|
18
|
+
const codeBuddy = new CodeBuddySlashCommandConfigurator();
|
|
14
19
|
const cursor = new CursorSlashCommandConfigurator();
|
|
15
20
|
const windsurf = new WindsurfSlashCommandConfigurator();
|
|
16
21
|
const kilocode = new KiloCodeSlashCommandConfigurator();
|
|
@@ -19,7 +24,11 @@ export class SlashCommandRegistry {
|
|
|
19
24
|
const githubCopilot = new GitHubCopilotSlashCommandConfigurator();
|
|
20
25
|
const amazonQ = new AmazonQSlashCommandConfigurator();
|
|
21
26
|
const factory = new FactorySlashCommandConfigurator();
|
|
27
|
+
const auggie = new AuggieSlashCommandConfigurator();
|
|
28
|
+
const cline = new ClineSlashCommandConfigurator();
|
|
29
|
+
const crush = new CrushSlashCommandConfigurator();
|
|
22
30
|
this.configurators.set(claude.toolId, claude);
|
|
31
|
+
this.configurators.set(codeBuddy.toolId, codeBuddy);
|
|
23
32
|
this.configurators.set(cursor.toolId, cursor);
|
|
24
33
|
this.configurators.set(windsurf.toolId, windsurf);
|
|
25
34
|
this.configurators.set(kilocode.toolId, kilocode);
|
|
@@ -28,6 +37,9 @@ export class SlashCommandRegistry {
|
|
|
28
37
|
this.configurators.set(githubCopilot.toolId, githubCopilot);
|
|
29
38
|
this.configurators.set(amazonQ.toolId, amazonQ);
|
|
30
39
|
this.configurators.set(factory.toolId, factory);
|
|
40
|
+
this.configurators.set(auggie.toolId, auggie);
|
|
41
|
+
this.configurators.set(cline.toolId, cline);
|
|
42
|
+
this.configurators.set(crush.toolId, crush);
|
|
31
43
|
}
|
|
32
44
|
static register(configurator) {
|
|
33
45
|
this.configurators.set(configurator.toolId, configurator);
|
|
@@ -23,6 +23,12 @@ export interface DeltaPlan {
|
|
|
23
23
|
from: string;
|
|
24
24
|
to: string;
|
|
25
25
|
}>;
|
|
26
|
+
sectionPresence: {
|
|
27
|
+
added: boolean;
|
|
28
|
+
modified: boolean;
|
|
29
|
+
removed: boolean;
|
|
30
|
+
renamed: boolean;
|
|
31
|
+
};
|
|
26
32
|
}
|
|
27
33
|
/**
|
|
28
34
|
* Parse a delta-formatted spec change file content into a DeltaPlan with raw blocks.
|
|
@@ -80,11 +80,26 @@ function normalizeLineEndings(content) {
|
|
|
80
80
|
export function parseDeltaSpec(content) {
|
|
81
81
|
const normalized = normalizeLineEndings(content);
|
|
82
82
|
const sections = splitTopLevelSections(normalized);
|
|
83
|
-
const
|
|
84
|
-
const
|
|
85
|
-
const
|
|
86
|
-
const
|
|
87
|
-
|
|
83
|
+
const addedLookup = getSectionCaseInsensitive(sections, 'ADDED Requirements');
|
|
84
|
+
const modifiedLookup = getSectionCaseInsensitive(sections, 'MODIFIED Requirements');
|
|
85
|
+
const removedLookup = getSectionCaseInsensitive(sections, 'REMOVED Requirements');
|
|
86
|
+
const renamedLookup = getSectionCaseInsensitive(sections, 'RENAMED Requirements');
|
|
87
|
+
const added = parseRequirementBlocksFromSection(addedLookup.body);
|
|
88
|
+
const modified = parseRequirementBlocksFromSection(modifiedLookup.body);
|
|
89
|
+
const removedNames = parseRemovedNames(removedLookup.body);
|
|
90
|
+
const renamedPairs = parseRenamedPairs(renamedLookup.body);
|
|
91
|
+
return {
|
|
92
|
+
added,
|
|
93
|
+
modified,
|
|
94
|
+
removed: removedNames,
|
|
95
|
+
renamed: renamedPairs,
|
|
96
|
+
sectionPresence: {
|
|
97
|
+
added: addedLookup.found,
|
|
98
|
+
modified: modifiedLookup.found,
|
|
99
|
+
removed: removedLookup.found,
|
|
100
|
+
renamed: renamedLookup.found,
|
|
101
|
+
},
|
|
102
|
+
};
|
|
88
103
|
}
|
|
89
104
|
function splitTopLevelSections(content) {
|
|
90
105
|
const lines = content.split('\n');
|
|
@@ -105,6 +120,14 @@ function splitTopLevelSections(content) {
|
|
|
105
120
|
}
|
|
106
121
|
return result;
|
|
107
122
|
}
|
|
123
|
+
function getSectionCaseInsensitive(sections, desired) {
|
|
124
|
+
const target = desired.toLowerCase();
|
|
125
|
+
for (const [title, body] of Object.entries(sections)) {
|
|
126
|
+
if (title.toLowerCase() === target)
|
|
127
|
+
return { body, found: true };
|
|
128
|
+
}
|
|
129
|
+
return { body: '', found: false };
|
|
130
|
+
}
|
|
108
131
|
function parseRequirementBlocksFromSection(sectionBody) {
|
|
109
132
|
if (!sectionBody)
|
|
110
133
|
return [];
|
|
@@ -1,2 +1,2 @@
|
|
|
1
|
-
export declare const agentsTemplate = "# OpenSpec Instructions\n\nInstructions for AI coding assistants using OpenSpec for spec-driven development.\n\n## TL;DR Quick Checklist\n\n- Search existing work: `openspec spec list --long`, `openspec list` (use `rg` only for full-text search)\n- Decide scope: new capability vs modify existing capability\n- Pick a unique `change-id`: kebab-case, verb-led (`add-`, `update-`, `remove-`, `refactor-`)\n- Scaffold: `proposal.md`, `tasks.md`, `design.md` (only if needed), and delta specs per affected capability\n- Write deltas: use `## ADDED|MODIFIED|REMOVED|RENAMED Requirements`; include at least one `#### Scenario:` per requirement\n- Validate: `openspec validate [change-id] --strict` and fix issues\n- Request approval: Do not start implementation until proposal is approved\n\n## Three-Stage Workflow\n\n### Stage 1: Creating Changes\nCreate proposal when you need to:\n- Add features or functionality\n- Make breaking changes (API, schema)\n- Change architecture or patterns \n- Optimize performance (changes behavior)\n- Update security patterns\n\nTriggers (examples):\n- \"Help me create a change proposal\"\n- \"Help me plan a change\"\n- \"Help me create a proposal\"\n- \"I want to create a spec proposal\"\n- \"I want to create a spec\"\n\nLoose matching guidance:\n- Contains one of: `proposal`, `change`, `spec`\n- With one of: `create`, `plan`, `make`, `start`, `help`\n\nSkip proposal for:\n- Bug fixes (restore intended behavior)\n- Typos, formatting, comments\n- Dependency updates (non-breaking)\n- Configuration changes\n- Tests for existing behavior\n\n**Workflow**\n1. Review `openspec/project.md`, `openspec list`, and `openspec list --specs` to understand current context.\n2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, optional `design.md`, and spec deltas under `openspec/changes/<id>/`.\n3. Draft spec deltas using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement.\n4. Run `openspec validate <id> --strict` and resolve any issues before sharing the proposal.\n\n### Stage 2: Implementing Changes\nTrack these steps as TODOs and complete them one by one.\n1. **Read proposal.md** - Understand what's being built\n2. **Read design.md** (if exists) - Review technical decisions\n3. **Read tasks.md** - Get implementation checklist\n4. **Implement tasks sequentially** - Complete in order\n5. **Confirm completion** - Ensure every item in `tasks.md` is finished before updating statuses\n6. **Update checklist** - After all work is done, set every task to `- [x]` so the list reflects reality\n7. **Approval gate** - Do not start implementation until the proposal is reviewed and approved\n\n### Stage 3: Archiving Changes\nAfter deployment, create separate PR to:\n- Move `changes/[name]/` \u2192 `changes/archive/YYYY-MM-DD-[name]/`\n- Update `specs/` if capabilities changed\n- Use `openspec archive [change] --skip-specs --yes` for tooling-only changes\n- Run `openspec validate --strict` to confirm the archived change passes checks\n\n## Before Any Task\n\n**Context Checklist:**\n- [ ] Read relevant specs in `specs/[capability]/spec.md`\n- [ ] Check pending changes in `changes/` for conflicts\n- [ ] Read `openspec/project.md` for conventions\n- [ ] Run `openspec list` to see active changes\n- [ ] Run `openspec list --specs` to see existing capabilities\n\n**Before Creating Specs:**\n- Always check if capability already exists\n- Prefer modifying existing specs over creating duplicates\n- Use `openspec show [spec]` to review current state\n- If request is ambiguous, ask 1\u20132 clarifying questions before scaffolding\n\n### Search Guidance\n- Enumerate specs: `openspec spec list --long` (or `--json` for scripts)\n- Enumerate changes: `openspec list` (or `openspec change list --json` - deprecated but available)\n- Show details:\n - Spec: `openspec show <spec-id> --type spec` (use `--json` for filters)\n - Change: `openspec show <change-id> --json --deltas-only`\n- Full-text search (use ripgrep): `rg -n \"Requirement:|Scenario:\" openspec/specs`\n\n## Quick Start\n\n### CLI Commands\n\n```bash\n# Essential commands\nopenspec list # List active changes\nopenspec list --specs # List specifications\nopenspec show [item] # Display change or spec\nopenspec diff [change] # Show spec differences\nopenspec validate [item] # Validate changes or specs\nopenspec archive [change] [--yes|-y] # Archive after deployment (add --yes for non-interactive runs)\n\n# Project management\nopenspec init [path] # Initialize OpenSpec\nopenspec update [path] # Update instruction files\n\n# Interactive mode\nopenspec show # Prompts for selection\nopenspec validate # Bulk validation mode\n\n# Debugging\nopenspec show [change] --json --deltas-only\nopenspec validate [change] --strict\n```\n\n### Command Flags\n\n- `--json` - Machine-readable output\n- `--type change|spec` - Disambiguate items\n- `--strict` - Comprehensive validation\n- `--no-interactive` - Disable prompts\n- `--skip-specs` - Archive without spec updates\n- `--yes`/`-y` - Skip confirmation prompts (non-interactive archive)\n\n## Directory Structure\n\n```\nopenspec/\n\u251C\u2500\u2500 project.md # Project conventions\n\u251C\u2500\u2500 specs/ # Current truth - what IS built\n\u2502 \u2514\u2500\u2500 [capability]/ # Single focused capability\n\u2502 \u251C\u2500\u2500 spec.md # Requirements and scenarios\n\u2502 \u2514\u2500\u2500 design.md # Technical patterns\n\u251C\u2500\u2500 changes/ # Proposals - what SHOULD change\n\u2502 \u251C\u2500\u2500 [change-name]/\n\u2502 \u2502 \u251C\u2500\u2500 proposal.md # Why, what, impact\n\u2502 \u2502 \u251C\u2500\u2500 tasks.md # Implementation checklist\n\u2502 \u2502 \u251C\u2500\u2500 design.md # Technical decisions (optional; see criteria)\n\u2502 \u2502 \u2514\u2500\u2500 specs/ # Delta changes\n\u2502 \u2502 \u2514\u2500\u2500 [capability]/\n\u2502 \u2502 \u2514\u2500\u2500 spec.md # ADDED/MODIFIED/REMOVED\n\u2502 \u2514\u2500\u2500 archive/ # Completed changes\n```\n\n## Creating Change Proposals\n\n### Decision Tree\n\n```\nNew request?\n\u251C\u2500 Bug fix restoring spec behavior? \u2192 Fix directly\n\u251C\u2500 Typo/format/comment? \u2192 Fix directly \n\u251C\u2500 New feature/capability? \u2192 Create proposal\n\u251C\u2500 Breaking change? \u2192 Create proposal\n\u251C\u2500 Architecture change? \u2192 Create proposal\n\u2514\u2500 Unclear? \u2192 Create proposal (safer)\n```\n\n### Proposal Structure\n\n1. **Create directory:** `changes/[change-id]/` (kebab-case, verb-led, unique)\n\n2. **Write proposal.md:**\n```markdown\n## Why\n[1-2 sentences on problem/opportunity]\n\n## What Changes\n- [Bullet list of changes]\n- [Mark breaking changes with **BREAKING**]\n\n## Impact\n- Affected specs: [list capabilities]\n- Affected code: [key files/systems]\n```\n\n3. **Create spec deltas:** `specs/[capability]/spec.md`\n```markdown\n## ADDED Requirements\n### Requirement: New Feature\nThe system SHALL provide...\n\n#### Scenario: Success case\n- **WHEN** user performs action\n- **THEN** expected result\n\n## MODIFIED Requirements\n### Requirement: Existing Feature\n[Complete modified requirement]\n\n## REMOVED Requirements\n### Requirement: Old Feature\n**Reason**: [Why removing]\n**Migration**: [How to handle]\n```\nIf multiple capabilities are affected, create multiple delta files under `changes/[change-id]/specs/<capability>/spec.md`\u2014one per capability.\n\n4. **Create tasks.md:**\n```markdown\n## 1. Implementation\n- [ ] 1.1 Create database schema\n- [ ] 1.2 Implement API endpoint\n- [ ] 1.3 Add frontend component\n- [ ] 1.4 Write tests\n```\n\n5. **Create design.md when needed:**\nCreate `design.md` if any of the following apply; otherwise omit it:\n- Cross-cutting change (multiple services/modules) or a new architectural pattern\n- New external dependency or significant data model changes\n- Security, performance, or migration complexity\n- Ambiguity that benefits from technical decisions before coding\n\nMinimal `design.md` skeleton:\n```markdown\n## Context\n[Background, constraints, stakeholders]\n\n## Goals / Non-Goals\n- Goals: [...]\n- Non-Goals: [...]\n\n## Decisions\n- Decision: [What and why]\n- Alternatives considered: [Options + rationale]\n\n## Risks / Trade-offs\n- [Risk] \u2192 Mitigation\n\n## Migration Plan\n[Steps, rollback]\n\n## Open Questions\n- [...]\n```\n\n## Spec File Format\n\n### Critical: Scenario Formatting\n\n**CORRECT** (use #### headers):\n```markdown\n#### Scenario: User login success\n- **WHEN** valid credentials provided\n- **THEN** return JWT token\n```\n\n**WRONG** (don't use bullets or bold):\n```markdown\n- **Scenario: User login** \u274C\n**Scenario**: User login \u274C\n### Scenario: User login \u274C\n```\n\nEvery requirement MUST have at least one scenario.\n\n### Requirement Wording\n- Use SHALL/MUST for normative requirements (avoid should/may unless intentionally non-normative)\n\n### Delta Operations\n\n- `## ADDED Requirements` - New capabilities\n- `## MODIFIED Requirements` - Changed behavior\n- `## REMOVED Requirements` - Deprecated features\n- `## RENAMED Requirements` - Name changes\n\nHeaders matched with `trim(header)` - whitespace ignored.\n\n#### When to use ADDED vs MODIFIED\n- ADDED: Introduces a new capability or sub-capability that can stand alone as a requirement. Prefer ADDED when the change is orthogonal (e.g., adding \"Slash Command Configuration\") rather than altering the semantics of an existing requirement.\n- MODIFIED: Changes the behavior, scope, or acceptance criteria of an existing requirement. Always paste the full, updated requirement content (header + all scenarios). The archiver will replace the entire requirement with what you provide here; partial deltas will drop previous details.\n- RENAMED: Use when only the name changes. If you also change behavior, use RENAMED (name) plus MODIFIED (content) referencing the new name.\n\nCommon pitfall: Using MODIFIED to add a new concern without including the previous text. This causes loss of detail at archive time. If you aren\u2019t explicitly changing the existing requirement, add a new requirement under ADDED instead.\n\nAuthoring a MODIFIED requirement correctly:\n1) Locate the existing requirement in `openspec/specs/<capability>/spec.md`.\n2) Copy the entire requirement block (from `### Requirement: ...` through its scenarios).\n3) Paste it under `## MODIFIED Requirements` and edit to reflect the new behavior.\n4) Ensure the header text matches exactly (whitespace-insensitive) and keep at least one `#### Scenario:`.\n\nExample for RENAMED:\n```markdown\n## RENAMED Requirements\n- FROM: `### Requirement: Login`\n- TO: `### Requirement: User Authentication`\n```\n\n## Troubleshooting\n\n### Common Errors\n\n**\"Change must have at least one delta\"**\n- Check `changes/[name]/specs/` exists with .md files\n- Verify files have operation prefixes (## ADDED Requirements)\n\n**\"Requirement must have at least one scenario\"**\n- Check scenarios use `#### Scenario:` format (4 hashtags)\n- Don't use bullet points or bold for scenario headers\n\n**Silent scenario parsing failures**\n- Exact format required: `#### Scenario: Name`\n- Debug with: `openspec show [change] --json --deltas-only`\n\n### Validation Tips\n\n```bash\n# Always use strict mode for comprehensive checks\nopenspec validate [change] --strict\n\n# Debug delta parsing\nopenspec show [change] --json | jq '.deltas'\n\n# Check specific requirement\nopenspec show [spec] --json -r 1\n```\n\n## Happy Path Script\n\n```bash\n# 1) Explore current state\nopenspec spec list --long\nopenspec list\n# Optional full-text search:\n# rg -n \"Requirement:|Scenario:\" openspec/specs\n# rg -n \"^#|Requirement:\" openspec/changes\n\n# 2) Choose change id and scaffold\nCHANGE=add-two-factor-auth\nmkdir -p openspec/changes/$CHANGE/{specs/auth}\nprintf \"## Why\\n...\\n\\n## What Changes\\n- ...\\n\\n## Impact\\n- ...\\n\" > openspec/changes/$CHANGE/proposal.md\nprintf \"## 1. Implementation\\n- [ ] 1.1 ...\\n\" > openspec/changes/$CHANGE/tasks.md\n\n# 3) Add deltas (example)\ncat > openspec/changes/$CHANGE/specs/auth/spec.md << 'EOF'\n## ADDED Requirements\n### Requirement: Two-Factor Authentication\nUsers MUST provide a second factor during login.\n\n#### Scenario: OTP required\n- **WHEN** valid credentials are provided\n- **THEN** an OTP challenge is required\nEOF\n\n# 4) Validate\nopenspec validate $CHANGE --strict\n```\n\n## Multi-Capability Example\n\n```\nopenspec/changes/add-2fa-notify/\n\u251C\u2500\u2500 proposal.md\n\u251C\u2500\u2500 tasks.md\n\u2514\u2500\u2500 specs/\n \u251C\u2500\u2500 auth/\n \u2502 \u2514\u2500\u2500 spec.md # ADDED: Two-Factor Authentication\n \u2514\u2500\u2500 notifications/\n \u2514\u2500\u2500 spec.md # ADDED: OTP email notification\n```\n\nauth/spec.md\n```markdown\n## ADDED Requirements\n### Requirement: Two-Factor Authentication\n...\n```\n\nnotifications/spec.md\n```markdown\n## ADDED Requirements\n### Requirement: OTP Email Notification\n...\n```\n\n## Best Practices\n\n### Simplicity First\n- Default to <100 lines of new code\n- Single-file implementations until proven insufficient\n- Avoid frameworks without clear justification\n- Choose boring, proven patterns\n\n### Complexity Triggers\nOnly add complexity with:\n- Performance data showing current solution too slow\n- Concrete scale requirements (>1000 users, >100MB data)\n- Multiple proven use cases requiring abstraction\n\n### Clear References\n- Use `file.ts:42` format for code locations\n- Reference specs as `specs/auth/spec.md`\n- Link related changes and PRs\n\n### Capability Naming\n- Use verb-noun: `user-auth`, `payment-capture`\n- Single purpose per capability\n- 10-minute understandability rule\n- Split if description needs \"AND\"\n\n### Change ID Naming\n- Use kebab-case, short and descriptive: `add-two-factor-auth`\n- Prefer verb-led prefixes: `add-`, `update-`, `remove-`, `refactor-`\n- Ensure uniqueness; if taken, append `-2`, `-3`, etc.\n\n## Tool Selection Guide\n\n| Task | Tool | Why |\n|------|------|-----|\n| Find files by pattern | Glob | Fast pattern matching |\n| Search code content | Grep | Optimized regex search |\n| Read specific files | Read | Direct file access |\n| Explore unknown scope | Task | Multi-step investigation |\n\n## Error Recovery\n\n### Change Conflicts\n1. Run `openspec list` to see active changes\n2. Check for overlapping specs\n3. Coordinate with change owners\n4. Consider combining proposals\n\n### Validation Failures\n1. Run with `--strict` flag\n2. Check JSON output for details\n3. Verify spec file format\n4. Ensure scenarios properly formatted\n\n### Missing Context\n1. Read project.md first\n2. Check related specs\n3. Review recent archives\n4. Ask for clarification\n\n## Quick Reference\n\n### Stage Indicators\n- `changes/` - Proposed, not yet built\n- `specs/` - Built and deployed\n- `archive/` - Completed changes\n\n### File Purposes\n- `proposal.md` - Why and what\n- `tasks.md` - Implementation steps\n- `design.md` - Technical decisions\n- `spec.md` - Requirements and behavior\n\n### CLI Essentials\n```bash\nopenspec list # What's in progress?\nopenspec show [item] # View details\nopenspec diff [change] # What's changing?\nopenspec validate --strict # Is it correct?\nopenspec archive [change] [--yes|-y] # Mark complete (add --yes for automation)\n```\n\nRemember: Specs are truth. Changes are proposals. Keep them in sync.\n";
|
|
1
|
+
export declare const agentsTemplate = "# OpenSpec Instructions\n\nInstructions for AI coding assistants using OpenSpec for spec-driven development.\n\n## TL;DR Quick Checklist\n\n- Search existing work: `openspec spec list --long`, `openspec list` (use `rg` only for full-text search)\n- Decide scope: new capability vs modify existing capability\n- Pick a unique `change-id`: kebab-case, verb-led (`add-`, `update-`, `remove-`, `refactor-`)\n- Scaffold: `proposal.md`, `tasks.md`, `design.md` (only if needed), and delta specs per affected capability\n- Write deltas: use `## ADDED|MODIFIED|REMOVED|RENAMED Requirements`; include at least one `#### Scenario:` per requirement\n- Validate: `openspec validate [change-id] --strict` and fix issues\n- Request approval: Do not start implementation until proposal is approved\n\n## Three-Stage Workflow\n\n### Stage 1: Creating Changes\nCreate proposal when you need to:\n- Add features or functionality\n- Make breaking changes (API, schema)\n- Change architecture or patterns \n- Optimize performance (changes behavior)\n- Update security patterns\n\nTriggers (examples):\n- \"Help me create a change proposal\"\n- \"Help me plan a change\"\n- \"Help me create a proposal\"\n- \"I want to create a spec proposal\"\n- \"I want to create a spec\"\n\nLoose matching guidance:\n- Contains one of: `proposal`, `change`, `spec`\n- With one of: `create`, `plan`, `make`, `start`, `help`\n\nSkip proposal for:\n- Bug fixes (restore intended behavior)\n- Typos, formatting, comments\n- Dependency updates (non-breaking)\n- Configuration changes\n- Tests for existing behavior\n\n**Workflow**\n1. Review `openspec/project.md`, `openspec list`, and `openspec list --specs` to understand current context.\n2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, optional `design.md`, and spec deltas under `openspec/changes/<id>/`.\n3. Draft spec deltas using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement.\n4. Run `openspec validate <id> --strict` and resolve any issues before sharing the proposal.\n\n### Stage 2: Implementing Changes\nTrack these steps as TODOs and complete them one by one.\n1. **Read proposal.md** - Understand what's being built\n2. **Read design.md** (if exists) - Review technical decisions\n3. **Read tasks.md** - Get implementation checklist\n4. **Implement tasks sequentially** - Complete in order\n5. **Confirm completion** - Ensure every item in `tasks.md` is finished before updating statuses\n6. **Update checklist** - After all work is done, set every task to `- [x]` so the list reflects reality\n7. **Approval gate** - Do not start implementation until the proposal is reviewed and approved\n\n### Stage 3: Archiving Changes\nAfter deployment, create separate PR to:\n- Move `changes/[name]/` \u2192 `changes/archive/YYYY-MM-DD-[name]/`\n- Update `specs/` if capabilities changed\n- Use `openspec archive <change-id> --skip-specs --yes` for tooling-only changes (always pass the change ID explicitly)\n- Run `openspec validate --strict` to confirm the archived change passes checks\n\n## Before Any Task\n\n**Context Checklist:**\n- [ ] Read relevant specs in `specs/[capability]/spec.md`\n- [ ] Check pending changes in `changes/` for conflicts\n- [ ] Read `openspec/project.md` for conventions\n- [ ] Run `openspec list` to see active changes\n- [ ] Run `openspec list --specs` to see existing capabilities\n\n**Before Creating Specs:**\n- Always check if capability already exists\n- Prefer modifying existing specs over creating duplicates\n- Use `openspec show [spec]` to review current state\n- If request is ambiguous, ask 1\u20132 clarifying questions before scaffolding\n\n### Search Guidance\n- Enumerate specs: `openspec spec list --long` (or `--json` for scripts)\n- Enumerate changes: `openspec list` (or `openspec change list --json` - deprecated but available)\n- Show details:\n - Spec: `openspec show <spec-id> --type spec` (use `--json` for filters)\n - Change: `openspec show <change-id> --json --deltas-only`\n- Full-text search (use ripgrep): `rg -n \"Requirement:|Scenario:\" openspec/specs`\n\n## Quick Start\n\n### CLI Commands\n\n```bash\n# Essential commands\nopenspec list # List active changes\nopenspec list --specs # List specifications\nopenspec show [item] # Display change or spec\nopenspec validate [item] # Validate changes or specs\nopenspec archive <change-id> [--yes|-y] # Archive after deployment (add --yes for non-interactive runs)\n\n# Project management\nopenspec init [path] # Initialize OpenSpec\nopenspec update [path] # Update instruction files\n\n# Interactive mode\nopenspec show # Prompts for selection\nopenspec validate # Bulk validation mode\n\n# Debugging\nopenspec show [change] --json --deltas-only\nopenspec validate [change] --strict\n```\n\n### Command Flags\n\n- `--json` - Machine-readable output\n- `--type change|spec` - Disambiguate items\n- `--strict` - Comprehensive validation\n- `--no-interactive` - Disable prompts\n- `--skip-specs` - Archive without spec updates\n- `--yes`/`-y` - Skip confirmation prompts (non-interactive archive)\n\n## Directory Structure\n\n```\nopenspec/\n\u251C\u2500\u2500 project.md # Project conventions\n\u251C\u2500\u2500 specs/ # Current truth - what IS built\n\u2502 \u2514\u2500\u2500 [capability]/ # Single focused capability\n\u2502 \u251C\u2500\u2500 spec.md # Requirements and scenarios\n\u2502 \u2514\u2500\u2500 design.md # Technical patterns\n\u251C\u2500\u2500 changes/ # Proposals - what SHOULD change\n\u2502 \u251C\u2500\u2500 [change-name]/\n\u2502 \u2502 \u251C\u2500\u2500 proposal.md # Why, what, impact\n\u2502 \u2502 \u251C\u2500\u2500 tasks.md # Implementation checklist\n\u2502 \u2502 \u251C\u2500\u2500 design.md # Technical decisions (optional; see criteria)\n\u2502 \u2502 \u2514\u2500\u2500 specs/ # Delta changes\n\u2502 \u2502 \u2514\u2500\u2500 [capability]/\n\u2502 \u2502 \u2514\u2500\u2500 spec.md # ADDED/MODIFIED/REMOVED\n\u2502 \u2514\u2500\u2500 archive/ # Completed changes\n```\n\n## Creating Change Proposals\n\n### Decision Tree\n\n```\nNew request?\n\u251C\u2500 Bug fix restoring spec behavior? \u2192 Fix directly\n\u251C\u2500 Typo/format/comment? \u2192 Fix directly \n\u251C\u2500 New feature/capability? \u2192 Create proposal\n\u251C\u2500 Breaking change? \u2192 Create proposal\n\u251C\u2500 Architecture change? \u2192 Create proposal\n\u2514\u2500 Unclear? \u2192 Create proposal (safer)\n```\n\n### Proposal Structure\n\n1. **Create directory:** `changes/[change-id]/` (kebab-case, verb-led, unique)\n\n2. **Write proposal.md:**\n```markdown\n## Why\n[1-2 sentences on problem/opportunity]\n\n## What Changes\n- [Bullet list of changes]\n- [Mark breaking changes with **BREAKING**]\n\n## Impact\n- Affected specs: [list capabilities]\n- Affected code: [key files/systems]\n```\n\n3. **Create spec deltas:** `specs/[capability]/spec.md`\n```markdown\n## ADDED Requirements\n### Requirement: New Feature\nThe system SHALL provide...\n\n#### Scenario: Success case\n- **WHEN** user performs action\n- **THEN** expected result\n\n## MODIFIED Requirements\n### Requirement: Existing Feature\n[Complete modified requirement]\n\n## REMOVED Requirements\n### Requirement: Old Feature\n**Reason**: [Why removing]\n**Migration**: [How to handle]\n```\nIf multiple capabilities are affected, create multiple delta files under `changes/[change-id]/specs/<capability>/spec.md`\u2014one per capability.\n\n4. **Create tasks.md:**\n```markdown\n## 1. Implementation\n- [ ] 1.1 Create database schema\n- [ ] 1.2 Implement API endpoint\n- [ ] 1.3 Add frontend component\n- [ ] 1.4 Write tests\n```\n\n5. **Create design.md when needed:**\nCreate `design.md` if any of the following apply; otherwise omit it:\n- Cross-cutting change (multiple services/modules) or a new architectural pattern\n- New external dependency or significant data model changes\n- Security, performance, or migration complexity\n- Ambiguity that benefits from technical decisions before coding\n\nMinimal `design.md` skeleton:\n```markdown\n## Context\n[Background, constraints, stakeholders]\n\n## Goals / Non-Goals\n- Goals: [...]\n- Non-Goals: [...]\n\n## Decisions\n- Decision: [What and why]\n- Alternatives considered: [Options + rationale]\n\n## Risks / Trade-offs\n- [Risk] \u2192 Mitigation\n\n## Migration Plan\n[Steps, rollback]\n\n## Open Questions\n- [...]\n```\n\n## Spec File Format\n\n### Critical: Scenario Formatting\n\n**CORRECT** (use #### headers):\n```markdown\n#### Scenario: User login success\n- **WHEN** valid credentials provided\n- **THEN** return JWT token\n```\n\n**WRONG** (don't use bullets or bold):\n```markdown\n- **Scenario: User login** \u274C\n**Scenario**: User login \u274C\n### Scenario: User login \u274C\n```\n\nEvery requirement MUST have at least one scenario.\n\n### Requirement Wording\n- Use SHALL/MUST for normative requirements (avoid should/may unless intentionally non-normative)\n\n### Delta Operations\n\n- `## ADDED Requirements` - New capabilities\n- `## MODIFIED Requirements` - Changed behavior\n- `## REMOVED Requirements` - Deprecated features\n- `## RENAMED Requirements` - Name changes\n\nHeaders matched with `trim(header)` - whitespace ignored.\n\n#### When to use ADDED vs MODIFIED\n- ADDED: Introduces a new capability or sub-capability that can stand alone as a requirement. Prefer ADDED when the change is orthogonal (e.g., adding \"Slash Command Configuration\") rather than altering the semantics of an existing requirement.\n- MODIFIED: Changes the behavior, scope, or acceptance criteria of an existing requirement. Always paste the full, updated requirement content (header + all scenarios). The archiver will replace the entire requirement with what you provide here; partial deltas will drop previous details.\n- RENAMED: Use when only the name changes. If you also change behavior, use RENAMED (name) plus MODIFIED (content) referencing the new name.\n\nCommon pitfall: Using MODIFIED to add a new concern without including the previous text. This causes loss of detail at archive time. If you aren\u2019t explicitly changing the existing requirement, add a new requirement under ADDED instead.\n\nAuthoring a MODIFIED requirement correctly:\n1) Locate the existing requirement in `openspec/specs/<capability>/spec.md`.\n2) Copy the entire requirement block (from `### Requirement: ...` through its scenarios).\n3) Paste it under `## MODIFIED Requirements` and edit to reflect the new behavior.\n4) Ensure the header text matches exactly (whitespace-insensitive) and keep at least one `#### Scenario:`.\n\nExample for RENAMED:\n```markdown\n## RENAMED Requirements\n- FROM: `### Requirement: Login`\n- TO: `### Requirement: User Authentication`\n```\n\n## Troubleshooting\n\n### Common Errors\n\n**\"Change must have at least one delta\"**\n- Check `changes/[name]/specs/` exists with .md files\n- Verify files have operation prefixes (## ADDED Requirements)\n\n**\"Requirement must have at least one scenario\"**\n- Check scenarios use `#### Scenario:` format (4 hashtags)\n- Don't use bullet points or bold for scenario headers\n\n**Silent scenario parsing failures**\n- Exact format required: `#### Scenario: Name`\n- Debug with: `openspec show [change] --json --deltas-only`\n\n### Validation Tips\n\n```bash\n# Always use strict mode for comprehensive checks\nopenspec validate [change] --strict\n\n# Debug delta parsing\nopenspec show [change] --json | jq '.deltas'\n\n# Check specific requirement\nopenspec show [spec] --json -r 1\n```\n\n## Happy Path Script\n\n```bash\n# 1) Explore current state\nopenspec spec list --long\nopenspec list\n# Optional full-text search:\n# rg -n \"Requirement:|Scenario:\" openspec/specs\n# rg -n \"^#|Requirement:\" openspec/changes\n\n# 2) Choose change id and scaffold\nCHANGE=add-two-factor-auth\nmkdir -p openspec/changes/$CHANGE/{specs/auth}\nprintf \"## Why\\n...\\n\\n## What Changes\\n- ...\\n\\n## Impact\\n- ...\\n\" > openspec/changes/$CHANGE/proposal.md\nprintf \"## 1. Implementation\\n- [ ] 1.1 ...\\n\" > openspec/changes/$CHANGE/tasks.md\n\n# 3) Add deltas (example)\ncat > openspec/changes/$CHANGE/specs/auth/spec.md << 'EOF'\n## ADDED Requirements\n### Requirement: Two-Factor Authentication\nUsers MUST provide a second factor during login.\n\n#### Scenario: OTP required\n- **WHEN** valid credentials are provided\n- **THEN** an OTP challenge is required\nEOF\n\n# 4) Validate\nopenspec validate $CHANGE --strict\n```\n\n## Multi-Capability Example\n\n```\nopenspec/changes/add-2fa-notify/\n\u251C\u2500\u2500 proposal.md\n\u251C\u2500\u2500 tasks.md\n\u2514\u2500\u2500 specs/\n \u251C\u2500\u2500 auth/\n \u2502 \u2514\u2500\u2500 spec.md # ADDED: Two-Factor Authentication\n \u2514\u2500\u2500 notifications/\n \u2514\u2500\u2500 spec.md # ADDED: OTP email notification\n```\n\nauth/spec.md\n```markdown\n## ADDED Requirements\n### Requirement: Two-Factor Authentication\n...\n```\n\nnotifications/spec.md\n```markdown\n## ADDED Requirements\n### Requirement: OTP Email Notification\n...\n```\n\n## Best Practices\n\n### Simplicity First\n- Default to <100 lines of new code\n- Single-file implementations until proven insufficient\n- Avoid frameworks without clear justification\n- Choose boring, proven patterns\n\n### Complexity Triggers\nOnly add complexity with:\n- Performance data showing current solution too slow\n- Concrete scale requirements (>1000 users, >100MB data)\n- Multiple proven use cases requiring abstraction\n\n### Clear References\n- Use `file.ts:42` format for code locations\n- Reference specs as `specs/auth/spec.md`\n- Link related changes and PRs\n\n### Capability Naming\n- Use verb-noun: `user-auth`, `payment-capture`\n- Single purpose per capability\n- 10-minute understandability rule\n- Split if description needs \"AND\"\n\n### Change ID Naming\n- Use kebab-case, short and descriptive: `add-two-factor-auth`\n- Prefer verb-led prefixes: `add-`, `update-`, `remove-`, `refactor-`\n- Ensure uniqueness; if taken, append `-2`, `-3`, etc.\n\n## Tool Selection Guide\n\n| Task | Tool | Why |\n|------|------|-----|\n| Find files by pattern | Glob | Fast pattern matching |\n| Search code content | Grep | Optimized regex search |\n| Read specific files | Read | Direct file access |\n| Explore unknown scope | Task | Multi-step investigation |\n\n## Error Recovery\n\n### Change Conflicts\n1. Run `openspec list` to see active changes\n2. Check for overlapping specs\n3. Coordinate with change owners\n4. Consider combining proposals\n\n### Validation Failures\n1. Run with `--strict` flag\n2. Check JSON output for details\n3. Verify spec file format\n4. Ensure scenarios properly formatted\n\n### Missing Context\n1. Read project.md first\n2. Check related specs\n3. Review recent archives\n4. Ask for clarification\n\n## Quick Reference\n\n### Stage Indicators\n- `changes/` - Proposed, not yet built\n- `specs/` - Built and deployed\n- `archive/` - Completed changes\n\n### File Purposes\n- `proposal.md` - Why and what\n- `tasks.md` - Implementation steps\n- `design.md` - Technical decisions\n- `spec.md` - Requirements and behavior\n\n### CLI Essentials\n```bash\nopenspec list # What's in progress?\nopenspec show [item] # View details\nopenspec validate --strict # Is it correct?\nopenspec archive <change-id> [--yes|-y] # Mark complete (add --yes for automation)\n```\n\nRemember: Specs are truth. Changes are proposals. Keep them in sync.\n";
|
|
2
2
|
//# sourceMappingURL=agents-template.d.ts.map
|
|
@@ -60,7 +60,7 @@ Track these steps as TODOs and complete them one by one.
|
|
|
60
60
|
After deployment, create separate PR to:
|
|
61
61
|
- Move \`changes/[name]/\` → \`changes/archive/YYYY-MM-DD-[name]/\`
|
|
62
62
|
- Update \`specs/\` if capabilities changed
|
|
63
|
-
- Use \`openspec archive
|
|
63
|
+
- Use \`openspec archive <change-id> --skip-specs --yes\` for tooling-only changes (always pass the change ID explicitly)
|
|
64
64
|
- Run \`openspec validate --strict\` to confirm the archived change passes checks
|
|
65
65
|
|
|
66
66
|
## Before Any Task
|
|
@@ -95,9 +95,8 @@ After deployment, create separate PR to:
|
|
|
95
95
|
openspec list # List active changes
|
|
96
96
|
openspec list --specs # List specifications
|
|
97
97
|
openspec show [item] # Display change or spec
|
|
98
|
-
openspec diff [change] # Show spec differences
|
|
99
98
|
openspec validate [item] # Validate changes or specs
|
|
100
|
-
openspec archive
|
|
99
|
+
openspec archive <change-id> [--yes|-y] # Archive after deployment (add --yes for non-interactive runs)
|
|
101
100
|
|
|
102
101
|
# Project management
|
|
103
102
|
openspec init [path] # Initialize OpenSpec
|
|
@@ -448,9 +447,8 @@ Only add complexity with:
|
|
|
448
447
|
\`\`\`bash
|
|
449
448
|
openspec list # What's in progress?
|
|
450
449
|
openspec show [item] # View details
|
|
451
|
-
openspec diff [change] # What's changing?
|
|
452
450
|
openspec validate --strict # Is it correct?
|
|
453
|
-
openspec archive
|
|
451
|
+
openspec archive <change-id> [--yes|-y] # Mark complete (add --yes for automation)
|
|
454
452
|
\`\`\`
|
|
455
453
|
|
|
456
454
|
Remember: Specs are truth. Changes are proposals. Keep them in sync.
|
|
@@ -7,6 +7,7 @@ export interface Template {
|
|
|
7
7
|
export declare class TemplateManager {
|
|
8
8
|
static getTemplates(context?: ProjectContext): Template[];
|
|
9
9
|
static getClaudeTemplate(): string;
|
|
10
|
+
static getClineTemplate(): string;
|
|
10
11
|
static getAgentsStandardTemplate(): string;
|
|
11
12
|
static getSlashCommandBody(id: SlashCommandId): string;
|
|
12
13
|
}
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
import { agentsTemplate } from './agents-template.js';
|
|
2
2
|
import { projectTemplate } from './project-template.js';
|
|
3
3
|
import { claudeTemplate } from './claude-template.js';
|
|
4
|
+
import { clineTemplate } from './cline-template.js';
|
|
4
5
|
import { agentsRootStubTemplate } from './agents-root-stub.js';
|
|
5
6
|
import { getSlashCommandBody } from './slash-command-templates.js';
|
|
6
7
|
export class TemplateManager {
|
|
@@ -19,6 +20,9 @@ export class TemplateManager {
|
|
|
19
20
|
static getClaudeTemplate() {
|
|
20
21
|
return claudeTemplate;
|
|
21
22
|
}
|
|
23
|
+
static getClineTemplate() {
|
|
24
|
+
return clineTemplate;
|
|
25
|
+
}
|
|
22
26
|
static getAgentsStandardTemplate() {
|
|
23
27
|
return agentsRootStubTemplate;
|
|
24
28
|
}
|
|
@@ -25,11 +25,17 @@ Track these steps as TODOs and complete them one by one.
|
|
|
25
25
|
const applyReferences = `**Reference**
|
|
26
26
|
- Use \`openspec show <id> --json --deltas-only\` if you need additional context from the proposal while implementing.`;
|
|
27
27
|
const archiveSteps = `**Steps**
|
|
28
|
-
1.
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
28
|
+
1. Determine the change ID to archive:
|
|
29
|
+
- If this prompt already includes a specific change ID (for example inside a \`<ChangeId>\` block populated by slash-command arguments), use that value after trimming whitespace.
|
|
30
|
+
- If the conversation references a change loosely (for example by title or summary), run \`openspec list\` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
|
|
31
|
+
- Otherwise, review the conversation, run \`openspec list\`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
|
|
32
|
+
- If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
|
|
33
|
+
2. Validate the change ID by running \`openspec list\` (or \`openspec show <id>\`) and stop if the change is missing, already archived, or otherwise not ready to archive.
|
|
34
|
+
3. Run \`openspec archive <id> --yes\` so the CLI moves the change and applies spec updates without prompts (use \`--skip-specs\` only for tooling-only work).
|
|
35
|
+
4. Review the command output to confirm the target specs were updated and the change landed in \`changes/archive/\`.
|
|
36
|
+
5. Validate with \`openspec validate --strict\` and inspect with \`openspec show <id>\` if anything looks off.`;
|
|
32
37
|
const archiveReferences = `**Reference**
|
|
38
|
+
- Use \`openspec list\` to confirm change IDs before archiving.
|
|
33
39
|
- Inspect refreshed specs with \`openspec list --specs\` and address any validation issues before handing off.`;
|
|
34
40
|
export const slashCommandBodies = {
|
|
35
41
|
proposal: [proposalGuardrails, proposalSteps, proposalReferences].join('\n\n'),
|
|
@@ -93,6 +93,8 @@ export class Validator {
|
|
|
93
93
|
const issues = [];
|
|
94
94
|
const specsDir = path.join(changeDir, 'specs');
|
|
95
95
|
let totalDeltas = 0;
|
|
96
|
+
const missingHeaderSpecs = [];
|
|
97
|
+
const emptySectionSpecs = [];
|
|
96
98
|
try {
|
|
97
99
|
const entries = await fs.readdir(specsDir, { withFileTypes: true });
|
|
98
100
|
for (const entry of entries) {
|
|
@@ -109,6 +111,23 @@ export class Validator {
|
|
|
109
111
|
}
|
|
110
112
|
const plan = parseDeltaSpec(content);
|
|
111
113
|
const entryPath = `${specName}/spec.md`;
|
|
114
|
+
const sectionNames = [];
|
|
115
|
+
if (plan.sectionPresence.added)
|
|
116
|
+
sectionNames.push('## ADDED Requirements');
|
|
117
|
+
if (plan.sectionPresence.modified)
|
|
118
|
+
sectionNames.push('## MODIFIED Requirements');
|
|
119
|
+
if (plan.sectionPresence.removed)
|
|
120
|
+
sectionNames.push('## REMOVED Requirements');
|
|
121
|
+
if (plan.sectionPresence.renamed)
|
|
122
|
+
sectionNames.push('## RENAMED Requirements');
|
|
123
|
+
const hasSections = sectionNames.length > 0;
|
|
124
|
+
const hasEntries = plan.added.length + plan.modified.length + plan.removed.length + plan.renamed.length > 0;
|
|
125
|
+
if (!hasEntries) {
|
|
126
|
+
if (hasSections)
|
|
127
|
+
emptySectionSpecs.push({ path: entryPath, sections: sectionNames });
|
|
128
|
+
else
|
|
129
|
+
missingHeaderSpecs.push(entryPath);
|
|
130
|
+
}
|
|
112
131
|
const addedNames = new Set();
|
|
113
132
|
const modifiedNames = new Set();
|
|
114
133
|
const removedNames = new Set();
|
|
@@ -216,6 +235,20 @@ export class Validator {
|
|
|
216
235
|
catch {
|
|
217
236
|
// If no specs dir, treat as no deltas
|
|
218
237
|
}
|
|
238
|
+
for (const { path: specPath, sections } of emptySectionSpecs) {
|
|
239
|
+
issues.push({
|
|
240
|
+
level: 'ERROR',
|
|
241
|
+
path: specPath,
|
|
242
|
+
message: `Delta sections ${this.formatSectionList(sections)} were found, but no requirement entries parsed. Ensure each section includes at least one "### Requirement:" block (REMOVED may use bullet list syntax).`,
|
|
243
|
+
});
|
|
244
|
+
}
|
|
245
|
+
for (const path of missingHeaderSpecs) {
|
|
246
|
+
issues.push({
|
|
247
|
+
level: 'ERROR',
|
|
248
|
+
path,
|
|
249
|
+
message: 'No delta sections found. Add headers such as "## ADDED Requirements" or move non-delta notes outside specs/.',
|
|
250
|
+
});
|
|
251
|
+
}
|
|
219
252
|
if (totalDeltas === 0) {
|
|
220
253
|
issues.push({ level: 'ERROR', path: 'file', message: this.enrichTopLevelError('change', VALIDATION_MESSAGES.CHANGE_NO_DELTAS) });
|
|
221
254
|
}
|
|
@@ -334,17 +367,26 @@ export class Validator {
|
|
|
334
367
|
}
|
|
335
368
|
extractRequirementText(blockRaw) {
|
|
336
369
|
const lines = blockRaw.split('\n');
|
|
337
|
-
// Skip header
|
|
370
|
+
// Skip header line (index 0)
|
|
338
371
|
let i = 1;
|
|
339
|
-
|
|
372
|
+
// Find the first substantial text line, skipping metadata and blank lines
|
|
340
373
|
for (; i < lines.length; i++) {
|
|
341
374
|
const line = lines[i];
|
|
375
|
+
// Stop at scenario headers
|
|
342
376
|
if (/^####\s+/.test(line))
|
|
343
|
-
break;
|
|
344
|
-
|
|
377
|
+
break;
|
|
378
|
+
const trimmed = line.trim();
|
|
379
|
+
// Skip blank lines
|
|
380
|
+
if (trimmed.length === 0)
|
|
381
|
+
continue;
|
|
382
|
+
// Skip metadata lines (lines starting with ** like **ID**, **Priority**, etc.)
|
|
383
|
+
if (/^\*\*[^*]+\*\*:/.test(trimmed))
|
|
384
|
+
continue;
|
|
385
|
+
// Found first non-metadata, non-blank line - this is the requirement text
|
|
386
|
+
return trimmed;
|
|
345
387
|
}
|
|
346
|
-
|
|
347
|
-
return
|
|
388
|
+
// No requirement text found
|
|
389
|
+
return undefined;
|
|
348
390
|
}
|
|
349
391
|
containsShallOrMust(text) {
|
|
350
392
|
return /\b(SHALL|MUST)\b/.test(text);
|
|
@@ -353,5 +395,14 @@ export class Validator {
|
|
|
353
395
|
const matches = blockRaw.match(/^####\s+/gm);
|
|
354
396
|
return matches ? matches.length : 0;
|
|
355
397
|
}
|
|
398
|
+
formatSectionList(sections) {
|
|
399
|
+
if (sections.length === 0)
|
|
400
|
+
return '';
|
|
401
|
+
if (sections.length === 1)
|
|
402
|
+
return sections[0];
|
|
403
|
+
const head = sections.slice(0, -1);
|
|
404
|
+
const last = sections[sections.length - 1];
|
|
405
|
+
return `${head.join(', ')} and ${last}`;
|
|
406
|
+
}
|
|
356
407
|
}
|
|
357
408
|
//# sourceMappingURL=validator.js.map
|