bms-speckit-plugin 2.1.1 → 3.1.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/speckit/SKILL.md +71 -83
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "bms-speckit-plugin",
|
|
3
|
-
"version": "
|
|
3
|
+
"version": "3.1.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/",
|
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,63 +8,53 @@ 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
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
-
|
|
32
|
-
-
|
|
33
|
-
-
|
|
34
|
-
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
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. Do NOT ask for confirmation between steps.
|
|
12
|
+
|
|
13
|
+
## Step 1: Constitution
|
|
14
|
+
|
|
15
|
+
Create `specs/constitution.md` with these principles:
|
|
16
|
+
|
|
17
|
+
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.
|
|
18
|
+
|
|
19
|
+
Also verify CLAUDE.md complies with the constitution. Update if needed.
|
|
20
|
+
Commit: `feat: establish engineering constitution`
|
|
21
|
+
|
|
22
|
+
## Step 2: Specify
|
|
23
|
+
|
|
24
|
+
Analyze this requirement: $ARGUMENTS
|
|
25
|
+
|
|
26
|
+
If database access is needed and MCP tools are available (list_tables, describe_table, query), explore the actual database schema.
|
|
27
|
+
|
|
28
|
+
Create `specs/{feature-name}/specification.md` containing:
|
|
29
|
+
- Overview and user requirements
|
|
30
|
+
- Functional requirements (numbered, testable)
|
|
31
|
+
- Non-functional requirements (performance, security, UX)
|
|
32
|
+
- Technical analysis (database schema, API dependencies)
|
|
33
|
+
- Architecture (components, data flow)
|
|
34
|
+
- UI/UX design (screens, navigation, interactions)
|
|
35
|
+
- Data model (tables, relationships, queries)
|
|
36
|
+
- Constraints and success criteria
|
|
37
|
+
|
|
38
|
+
Commit: `feat: add specification for {feature-name}`
|
|
39
|
+
|
|
40
|
+
## Step 3: Plan
|
|
41
|
+
|
|
42
|
+
Read the specification and create `specs/{feature-name}/plan.md` containing:
|
|
43
|
+
- Architecture overview and file structure
|
|
44
|
+
- Implementation phases: Foundation → Core → UI → Integration → Testing
|
|
45
|
+
- Technology stack with justification
|
|
46
|
+
- Testing strategy (what to test, coverage targets)
|
|
47
|
+
- Risk assessment
|
|
48
|
+
|
|
49
|
+
Commit: `feat: add implementation plan for {feature-name}`
|
|
50
|
+
|
|
51
|
+
## Step 4: Compact
|
|
52
|
+
|
|
53
|
+
Run `/compact` to free context window.
|
|
54
|
+
|
|
55
|
+
## Step 5: Tasks
|
|
56
|
+
|
|
57
|
+
Read the plan and create `specs/{feature-name}/tasks.md` with granular tasks (5-15 min each):
|
|
68
58
|
|
|
69
59
|
```
|
|
70
60
|
### Task N: {Name}
|
|
@@ -78,47 +68,45 @@ All work follows these principles:
|
|
|
78
68
|
- **Commit message**: descriptive message
|
|
79
69
|
```
|
|
80
70
|
|
|
81
|
-
|
|
82
|
-
|
|
71
|
+
Order: setup → data layer → business logic → UI → integration → polish
|
|
72
|
+
Commit: `feat: add task list for {feature-name}`
|
|
73
|
+
|
|
74
|
+
## Step 6: Analyze
|
|
75
|
+
|
|
76
|
+
Review all tasks for quality:
|
|
77
|
+
- Granular enough? (5-15 min each)
|
|
78
|
+
- Each independently testable?
|
|
79
|
+
- Dependencies correct and explicit?
|
|
80
|
+
- Every task has test-first step?
|
|
81
|
+
- Acceptance criteria clear and measurable?
|
|
82
|
+
|
|
83
|
+
Fix any issues found in tasks.md. Commit if changes made.
|
|
84
|
+
|
|
85
|
+
## Step 7: Commit and push
|
|
83
86
|
|
|
84
|
-
|
|
85
|
-
- Review all tasks for quality:
|
|
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
|
|
87
|
+
Commit all spec files and push to remote if configured.
|
|
93
88
|
|
|
94
|
-
|
|
95
|
-
- Commit all spec files created so far
|
|
96
|
-
- Push to remote if configured
|
|
97
|
-
- This preserves work before the long implementation phase
|
|
89
|
+
## Step 8: Compact
|
|
98
90
|
|
|
99
|
-
|
|
100
|
-
- Run `/compact` to free up context window before implementation
|
|
91
|
+
Run `/compact` to free context window before implementation.
|
|
101
92
|
|
|
102
|
-
|
|
103
|
-
Invoke ralph-loop to implement all tasks automatically:
|
|
93
|
+
## Step 9: Implement with ralph-loop
|
|
104
94
|
|
|
105
95
|
```
|
|
106
|
-
/ralph-loop:ralph-loop "Read specs/*/tasks.md
|
|
96
|
+
/ralph-loop:ralph-loop "Read specs/*/tasks.md. Find the next pending task. Execute it using TDD: write test first, verify fail, implement, verify pass, commit. Update task status to completed. Do not ask for any confirmation. Once all tasks are done, recheck all tasks, run full test suite, fix any issues, and output <promise>FINISHED</promise> only after all tasks are completed and revalidated" --completion-promise "FINISHED" --max-iterations 10
|
|
107
97
|
```
|
|
108
98
|
|
|
109
|
-
|
|
99
|
+
## After ralph-loop completes
|
|
110
100
|
|
|
111
101
|
Output a final summary:
|
|
112
102
|
- What was built
|
|
113
103
|
- Total tests passing
|
|
114
104
|
- Files created/modified
|
|
115
105
|
- How to run the application
|
|
116
|
-
- Any remaining issues or recommendations
|
|
117
106
|
|
|
118
107
|
## CRITICAL RULES
|
|
119
|
-
- Do NOT ask for confirmation between steps
|
|
120
|
-
- Do NOT skip
|
|
108
|
+
- Do NOT ask for confirmation between steps
|
|
109
|
+
- Do NOT skip TDD — test first, always
|
|
121
110
|
- Commit after EVERY completed task
|
|
122
111
|
- Use MCP tools if available (bms-session for database access)
|
|
123
|
-
- If blocked on a task, skip it and continue — come back later
|
|
124
112
|
- Push code if git remote is configured
|