bms-speckit-plugin 3.1.0 → 3.2.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 +8 -55
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "bms-speckit-plugin",
|
|
3
|
-
"version": "3.
|
|
3
|
+
"version": "3.2.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
|
@@ -8,45 +8,21 @@ 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. Do NOT ask for confirmation between steps.
|
|
11
|
+
Takes a single requirement and runs the complete engineering workflow by calling speckit skills. Do NOT ask for confirmation between steps.
|
|
12
12
|
|
|
13
13
|
## Step 1: Constitution
|
|
14
14
|
|
|
15
|
-
|
|
15
|
+
Invoke `/speckit:constitution` with:
|
|
16
16
|
|
|
17
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
18
|
|
|
19
|
-
Also verify CLAUDE.md complies with the constitution. Update if needed.
|
|
20
|
-
Commit: `feat: establish engineering constitution`
|
|
21
|
-
|
|
22
19
|
## Step 2: Specify
|
|
23
20
|
|
|
24
|
-
|
|
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}`
|
|
21
|
+
Invoke `/speckit:specify` with: $ARGUMENTS
|
|
39
22
|
|
|
40
23
|
## Step 3: Plan
|
|
41
24
|
|
|
42
|
-
|
|
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}`
|
|
25
|
+
Invoke `/speckit:plan`
|
|
50
26
|
|
|
51
27
|
## Step 4: Compact
|
|
52
28
|
|
|
@@ -54,33 +30,11 @@ Run `/compact` to free context window.
|
|
|
54
30
|
|
|
55
31
|
## Step 5: Tasks
|
|
56
32
|
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
```
|
|
60
|
-
### Task N: {Name}
|
|
61
|
-
- **Status**: pending
|
|
62
|
-
- **Priority**: high | medium | low
|
|
63
|
-
- **Phase**: N
|
|
64
|
-
- **Files**: exact file paths
|
|
65
|
-
- **Description**: specific and actionable
|
|
66
|
-
- **Tests**: what tests to write first
|
|
67
|
-
- **Acceptance**: measurable verification criteria
|
|
68
|
-
- **Commit message**: descriptive message
|
|
69
|
-
```
|
|
70
|
-
|
|
71
|
-
Order: setup → data layer → business logic → UI → integration → polish
|
|
72
|
-
Commit: `feat: add task list for {feature-name}`
|
|
33
|
+
Invoke `/speckit:tasks`
|
|
73
34
|
|
|
74
35
|
## Step 6: Analyze
|
|
75
36
|
|
|
76
|
-
|
|
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.
|
|
37
|
+
Invoke `/speckit:analyze`
|
|
84
38
|
|
|
85
39
|
## Step 7: Commit and push
|
|
86
40
|
|
|
@@ -93,7 +47,7 @@ Run `/compact` to free context window before implementation.
|
|
|
93
47
|
## Step 9: Implement with ralph-loop
|
|
94
48
|
|
|
95
49
|
```
|
|
96
|
-
/ralph-loop:ralph-loop "
|
|
50
|
+
/ralph-loop:ralph-loop "use skill /speckit:implement until all tasks in specs/*/tasks.md are finished; do not ask for any confirmation; once all tasks are done, use skill /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
|
|
97
51
|
```
|
|
98
52
|
|
|
99
53
|
## After ralph-loop completes
|
|
@@ -106,7 +60,6 @@ Output a final summary:
|
|
|
106
60
|
|
|
107
61
|
## CRITICAL RULES
|
|
108
62
|
- Do NOT ask for confirmation between steps
|
|
109
|
-
-
|
|
110
|
-
- Commit after EVERY completed task
|
|
63
|
+
- Each step calls the speckit skill directly
|
|
111
64
|
- Use MCP tools if available (bms-session for database access)
|
|
112
65
|
- Push code if git remote is configured
|