bms-speckit-plugin 2.1.1 → 3.0.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/package.json +1 -1
- package/skills/analyze/SKILL.md +33 -0
- package/skills/constitution/SKILL.md +48 -0
- package/skills/implement/SKILL.md +27 -0
- package/skills/plan/SKILL.md +25 -0
- package/skills/specify/SKILL.md +32 -0
- package/skills/speckit/SKILL.md +28 -94
- package/skills/tasks/SKILL.md +34 -0
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "bms-speckit-plugin",
|
|
3
|
-
"version": "
|
|
3
|
+
"version": "3.0.0",
|
|
4
4
|
"description": "Single-command automated development pipeline: /bms-speckit takes requirements and runs constitution → specify → plan → tasks → analyze → implement → verify",
|
|
5
5
|
"files": [
|
|
6
6
|
".claude-plugin/",
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: analyze
|
|
3
|
+
description: Review tasks and implementation for quality and constitution compliance
|
|
4
|
+
user-invocable: false
|
|
5
|
+
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Speckit Analyze
|
|
9
|
+
|
|
10
|
+
Review tasks and/or implementation for quality and compliance.
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
1. Read `specs/constitution.md` for governing principles.
|
|
15
|
+
|
|
16
|
+
2. Find and read the most recent `specs/*/tasks.md`.
|
|
17
|
+
|
|
18
|
+
3. If tasks are pending — review task quality:
|
|
19
|
+
- Granular enough? (5-15 min each)
|
|
20
|
+
- Each independently testable?
|
|
21
|
+
- Dependencies correct?
|
|
22
|
+
- Every task has test-first step?
|
|
23
|
+
- Acceptance criteria clear?
|
|
24
|
+
|
|
25
|
+
4. If tasks are completed — review implementation:
|
|
26
|
+
- Read the code written for completed tasks
|
|
27
|
+
- Check tests exist and are meaningful
|
|
28
|
+
- Check for code duplication
|
|
29
|
+
- Check error handling and UX feedback
|
|
30
|
+
|
|
31
|
+
5. Fix any issues found in tasks.md. Add new tasks if needed.
|
|
32
|
+
|
|
33
|
+
6. Commit if changes made.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: constitution
|
|
3
|
+
description: Establish engineering principles that govern all speckit development work
|
|
4
|
+
user-invocable: false
|
|
5
|
+
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Speckit Constitution
|
|
9
|
+
|
|
10
|
+
Establish the engineering constitution for this project.
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
1. Read the constitution text from the conversation context. If none provided, use the default principles below.
|
|
15
|
+
|
|
16
|
+
2. Create `specs/` directory if it doesn't exist.
|
|
17
|
+
|
|
18
|
+
3. Write `specs/constitution.md` with:
|
|
19
|
+
|
|
20
|
+
```markdown
|
|
21
|
+
# Engineering Constitution
|
|
22
|
+
|
|
23
|
+
Established: {current date}
|
|
24
|
+
|
|
25
|
+
## Principles
|
|
26
|
+
|
|
27
|
+
{constitution text, formatted as numbered principles}
|
|
28
|
+
|
|
29
|
+
## Enforcement
|
|
30
|
+
|
|
31
|
+
All speckit commands must comply with these principles.
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
4. Check if CLAUDE.md exists. If it does, verify it aligns with the constitution and update if needed.
|
|
35
|
+
|
|
36
|
+
5. Commit: `feat: establish engineering constitution`
|
|
37
|
+
|
|
38
|
+
## Default Principles
|
|
39
|
+
|
|
40
|
+
1. Code Quality — No hardcoded conditions, strict TypeScript, no shortcuts
|
|
41
|
+
2. TDD — Always write tests FIRST, confirm failure, then implement
|
|
42
|
+
3. Testing — Unit, component, integration, and API tests as appropriate
|
|
43
|
+
4. UX — Consistent, professional, user-friendly interfaces with clear feedback
|
|
44
|
+
5. Performance — Efficient architecture and resource management
|
|
45
|
+
6. Version Control — Commit after every meaningful change with descriptive messages
|
|
46
|
+
7. Reusability — Modular components, centralized business logic, no duplication
|
|
47
|
+
8. User Feedback — Informative progress reporting and error messages
|
|
48
|
+
9. Tool Leverage — Use all available skills, MCP tools, frameworks, and domain expertise
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: implement
|
|
3
|
+
description: Execute the next pending task from tasks.md using TDD
|
|
4
|
+
user-invocable: false
|
|
5
|
+
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent, WebSearch, WebFetch
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Speckit Implement
|
|
9
|
+
|
|
10
|
+
Execute the next pending task using TDD.
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
1. Find `specs/*/tasks.md`. Find the first task with status `pending`.
|
|
15
|
+
|
|
16
|
+
2. Update its status to `in_progress`.
|
|
17
|
+
|
|
18
|
+
3. Execute TDD cycle:
|
|
19
|
+
a. Write the test first
|
|
20
|
+
b. Run tests — verify they FAIL
|
|
21
|
+
c. Write minimal implementation to pass
|
|
22
|
+
d. Run ALL tests — verify they PASS
|
|
23
|
+
e. Commit with the task's commit message
|
|
24
|
+
|
|
25
|
+
4. Update task status to `completed`.
|
|
26
|
+
|
|
27
|
+
5. Report: task name, tests passing, files changed, next pending task (or "all done").
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: plan
|
|
3
|
+
description: Create an implementation plan from the most recent specification
|
|
4
|
+
user-invocable: false
|
|
5
|
+
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Speckit Plan
|
|
9
|
+
|
|
10
|
+
Create a detailed implementation plan from the most recent specification.
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
1. Read `specs/constitution.md` for governing principles.
|
|
15
|
+
|
|
16
|
+
2. Find and read the most recent `specs/*/specification.md`.
|
|
17
|
+
|
|
18
|
+
3. Create `specs/{feature-name}/plan.md` containing:
|
|
19
|
+
- Architecture overview and file structure
|
|
20
|
+
- Implementation phases: Foundation → Core → UI → Integration → Testing
|
|
21
|
+
- Technology stack with justification
|
|
22
|
+
- Testing strategy (what to test, coverage targets)
|
|
23
|
+
- Risk assessment
|
|
24
|
+
|
|
25
|
+
4. Commit: `feat: add implementation plan for {feature-name}`
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: specify
|
|
3
|
+
description: Create a detailed specification from user requirements
|
|
4
|
+
user-invocable: false
|
|
5
|
+
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent, WebSearch, WebFetch
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Speckit Specify
|
|
9
|
+
|
|
10
|
+
Create a detailed technical specification from the requirement provided in conversation context.
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
1. Read `specs/constitution.md` for governing principles.
|
|
15
|
+
|
|
16
|
+
2. Read the requirement from conversation context.
|
|
17
|
+
|
|
18
|
+
3. If database access is needed and MCP tools are available (list_tables, describe_table, query), explore the actual database schema.
|
|
19
|
+
|
|
20
|
+
4. Create a feature directory name from the requirements (kebab-case).
|
|
21
|
+
|
|
22
|
+
5. Write `specs/{feature-name}/specification.md` containing:
|
|
23
|
+
- Overview and user requirements
|
|
24
|
+
- Functional requirements (numbered, testable)
|
|
25
|
+
- Non-functional requirements (performance, security, UX)
|
|
26
|
+
- Technical analysis (database schema, API dependencies)
|
|
27
|
+
- Architecture (components, data flow)
|
|
28
|
+
- UI/UX design (screens, navigation, interactions)
|
|
29
|
+
- Data model (tables, relationships, queries)
|
|
30
|
+
- Constraints and success criteria
|
|
31
|
+
|
|
32
|
+
6. Commit: `feat: add specification for {feature-name}`
|
package/skills/speckit/SKILL.md
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: speckit
|
|
3
3
|
description: Full automated development workflow. This skill should be used when the user asks to "build an application", "create a dashboard", "develop a feature", "speckit", "bms-speckit", or provides a software requirement to implement end-to-end with TDD, specifications, and quality gates.
|
|
4
4
|
argument-hint: <your requirement description>
|
|
5
5
|
disable-model-invocation: true
|
|
@@ -8,117 +8,51 @@ allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Skill, Agent, WebSearch, Web
|
|
|
8
8
|
|
|
9
9
|
# BMS Speckit — Automated Development Pipeline
|
|
10
10
|
|
|
11
|
-
Takes a single requirement and runs the complete engineering workflow automatically
|
|
12
|
-
**constitution → specify → plan → tasks → analyze → implement → verify**
|
|
13
|
-
|
|
14
|
-
## Engineering Constitution
|
|
15
|
-
|
|
16
|
-
All work follows these principles:
|
|
17
|
-
|
|
18
|
-
1. **Code Quality** — No hardcoded conditions, strict TypeScript, no shortcuts
|
|
19
|
-
2. **TDD** — Always write tests FIRST, confirm failure, then implement
|
|
20
|
-
3. **Testing** — Unit, component, integration, and API tests as appropriate
|
|
21
|
-
4. **UX** — Consistent, professional, user-friendly interfaces with clear feedback
|
|
22
|
-
5. **Performance** — Efficient architecture and resource management
|
|
23
|
-
6. **Version Control** — Commit after every meaningful change with descriptive messages
|
|
24
|
-
7. **Reusability** — Modular components, centralized business logic, no duplication
|
|
25
|
-
8. **User Feedback** — Informative progress reporting and error messages
|
|
26
|
-
9. **Tool Leverage** — Use all available skills, MCP tools, frameworks, and domain expertise
|
|
27
|
-
|
|
28
|
-
## Workflow — Execute ALL steps in order, do NOT ask for confirmation
|
|
29
|
-
|
|
30
|
-
### Step 1: Setup Constitution
|
|
31
|
-
- Create `specs/` directory
|
|
32
|
-
- Write `specs/constitution.md` with the principles above
|
|
33
|
-
- Check CLAUDE.md compliance — update if needed
|
|
34
|
-
- Commit: `feat: establish engineering constitution`
|
|
35
|
-
|
|
36
|
-
### Step 2: Create Specification
|
|
37
|
-
- The user's requirement is provided as the command argument: $ARGUMENTS
|
|
38
|
-
- Analyze this requirement thoroughly
|
|
39
|
-
- If database access is needed and MCP tools are available (list_tables, describe_table, query), explore the actual database schema
|
|
40
|
-
- Create `specs/{feature-name}/specification.md` containing:
|
|
41
|
-
- Overview and user requirements
|
|
42
|
-
- Functional requirements (numbered, testable)
|
|
43
|
-
- Non-functional requirements (performance, security, UX)
|
|
44
|
-
- Technical analysis (database schema, API dependencies)
|
|
45
|
-
- Architecture (components, data flow)
|
|
46
|
-
- UI/UX design (screens, navigation, interactions)
|
|
47
|
-
- Data model (tables, relationships, queries)
|
|
48
|
-
- Constraints and success criteria
|
|
49
|
-
- Commit: `feat: add specification for {feature-name}`
|
|
50
|
-
|
|
51
|
-
### Step 3: Create Implementation Plan
|
|
52
|
-
- Read the specification
|
|
53
|
-
- Create `specs/{feature-name}/plan.md` containing:
|
|
54
|
-
- Architecture overview and file structure
|
|
55
|
-
- Implementation phases: Foundation → Core → UI → Integration → Testing
|
|
56
|
-
- Technology stack with justification
|
|
57
|
-
- Testing strategy (what to test, coverage targets)
|
|
58
|
-
- Risk assessment
|
|
59
|
-
- Commit: `feat: add implementation plan for {feature-name}`
|
|
60
|
-
|
|
61
|
-
### Step 4: Compact context (first)
|
|
62
|
-
- Run `/compact` to free up context window after the heavy specification and planning work
|
|
63
|
-
|
|
64
|
-
### Step 5: Create Task List
|
|
65
|
-
- Read the plan
|
|
66
|
-
- Create `specs/{feature-name}/tasks.md` with granular tasks (5-15 min each)
|
|
67
|
-
- Each task includes:
|
|
11
|
+
Takes a single requirement and runs the complete engineering workflow automatically by calling sub-skills in sequence. Do NOT ask for confirmation between steps.
|
|
68
12
|
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
13
|
+
## Step 1: Constitution
|
|
14
|
+
Invoke skill `bms-speckit:constitution` with the following constitution text:
|
|
15
|
+
|
|
16
|
+
Establish and enforce a comprehensive set of engineering principles that prioritize high code quality, strict adherence to Test-Driven Development (TDD) practices, and well-defined testing standards across unit, component, integration, and API levels to ensure system reliability and maintainability; maintain a consistent, user-friendly, and professional user interface aligned with strong user experience (UX) guidelines; optimize application performance through efficient architecture and resource management; enforce disciplined version control practices with frequent, atomic commits to minimize risk and improve traceability; promote the development and reuse of modular components and functions while centralizing business logic to avoid duplication and ensure consistency; provide clear, informative user feedback and progress reporting throughout system interactions; and leverage all available tools, frameworks, and domain-specific expertise to support developers in delivering robust, scalable, and high-quality applications.
|
|
17
|
+
|
|
18
|
+
## Step 2: Specify
|
|
19
|
+
Invoke skill `bms-speckit:specify` with this requirement: $ARGUMENTS
|
|
20
|
+
|
|
21
|
+
## Step 3: Plan
|
|
22
|
+
Invoke skill `bms-speckit:plan`
|
|
23
|
+
|
|
24
|
+
## Step 4: Compact
|
|
25
|
+
Run `/compact` to free context window after heavy specification and planning work.
|
|
80
26
|
|
|
81
|
-
|
|
82
|
-
|
|
27
|
+
## Step 5: Tasks
|
|
28
|
+
Invoke skill `bms-speckit:tasks`
|
|
83
29
|
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
- Granular enough? (5-15 min each)
|
|
87
|
-
- Each independently testable?
|
|
88
|
-
- Dependencies correct and explicit?
|
|
89
|
-
- Every task has test-first step?
|
|
90
|
-
- Acceptance criteria clear and measurable?
|
|
91
|
-
- Fix any issues found in tasks.md
|
|
92
|
-
- Commit if changes made
|
|
30
|
+
## Step 6: Analyze
|
|
31
|
+
Invoke skill `bms-speckit:analyze`
|
|
93
32
|
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
- Push to remote if configured
|
|
97
|
-
- This preserves work before the long implementation phase
|
|
33
|
+
## Step 7: Commit and push
|
|
34
|
+
Commit all spec files and push to remote if configured.
|
|
98
35
|
|
|
99
|
-
|
|
100
|
-
|
|
36
|
+
## Step 8: Compact
|
|
37
|
+
Run `/compact` to free context window before implementation.
|
|
101
38
|
|
|
102
|
-
|
|
39
|
+
## Step 9: Implement with ralph-loop
|
|
103
40
|
Invoke ralph-loop to implement all tasks automatically:
|
|
104
41
|
|
|
105
42
|
```
|
|
106
|
-
/ralph-loop:ralph-loop "
|
|
43
|
+
/ralph-loop:ralph-loop "Invoke skill bms-speckit:implement to execute the next pending task. Repeat until all tasks in specs/*/tasks.md are finished. Do not ask for any confirmation. Once all tasks are done, invoke skill bms-speckit:analyze to recheck and update tasks, accept any recommendations, and output <promise>FINISHED</promise> only after all tasks are completed and revalidated" --completion-promise "FINISHED" --max-iterations 10
|
|
107
44
|
```
|
|
108
45
|
|
|
109
|
-
|
|
46
|
+
## After ralph-loop completes
|
|
110
47
|
|
|
111
48
|
Output a final summary:
|
|
112
49
|
- What was built
|
|
113
50
|
- Total tests passing
|
|
114
51
|
- Files created/modified
|
|
115
52
|
- How to run the application
|
|
116
|
-
- Any remaining issues or recommendations
|
|
117
53
|
|
|
118
54
|
## CRITICAL RULES
|
|
119
|
-
- Do NOT ask for confirmation between steps
|
|
120
|
-
-
|
|
121
|
-
- Commit after EVERY completed task
|
|
55
|
+
- Do NOT ask for confirmation between steps
|
|
56
|
+
- Each step invokes its sub-skill — do not implement inline
|
|
122
57
|
- Use MCP tools if available (bms-session for database access)
|
|
123
|
-
- If blocked on a task, skip it and continue — come back later
|
|
124
58
|
- Push code if git remote is configured
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: tasks
|
|
3
|
+
description: Break an implementation plan into executable tasks with status tracking
|
|
4
|
+
user-invocable: false
|
|
5
|
+
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Speckit Tasks
|
|
9
|
+
|
|
10
|
+
Break the implementation plan into granular, executable tasks.
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
1. Read `specs/constitution.md` for governing principles.
|
|
15
|
+
|
|
16
|
+
2. Find and read the most recent `specs/*/plan.md`.
|
|
17
|
+
|
|
18
|
+
3. Create `specs/{feature-name}/tasks.md` with granular tasks (5-15 min each):
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
### Task N: {Name}
|
|
22
|
+
- **Status**: pending
|
|
23
|
+
- **Priority**: high | medium | low
|
|
24
|
+
- **Phase**: N
|
|
25
|
+
- **Files**: exact file paths
|
|
26
|
+
- **Description**: specific and actionable
|
|
27
|
+
- **Tests**: what tests to write first
|
|
28
|
+
- **Acceptance**: measurable verification criteria
|
|
29
|
+
- **Commit message**: descriptive message
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
4. Order: setup → data layer → business logic → UI → integration → polish
|
|
33
|
+
|
|
34
|
+
5. Commit: `feat: add task list for {feature-name}`
|