bms-speckit-plugin 3.1.0 → 3.3.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.
Files changed (2) hide show
  1. package/package.json +1 -1
  2. package/skills/speckit/SKILL.md +21 -82
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "bms-speckit-plugin",
3
- "version": "3.1.0",
3
+ "version": "3.3.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,105 +8,44 @@ 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
+ Execute the following steps in exact order. Do NOT ask for confirmation between steps. Do NOT skip any step.
12
12
 
13
- ## Step 1: Constitution
13
+ ## Step 1
14
14
 
15
- Create `specs/constitution.md` with these principles:
15
+ /speckit.constitution 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.
16
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.
17
+ ## Step 2
18
18
 
19
- Also verify CLAUDE.md complies with the constitution. Update if needed.
20
- Commit: `feat: establish engineering constitution`
19
+ Make sure that CLAUDE.md complies with the constitution above. Update CLAUDE.md if needed.
21
20
 
22
- ## Step 2: Specify
21
+ ## Step 3
23
22
 
24
- Analyze this requirement: $ARGUMENTS
23
+ /speckit.specify $ARGUMENTS
25
24
 
26
- If database access is needed and MCP tools are available (list_tables, describe_table, query), explore the actual database schema.
25
+ ## Step 4
27
26
 
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
27
+ /speckit.plan
37
28
 
38
- Commit: `feat: add specification for {feature-name}`
29
+ ## Step 5
39
30
 
40
- ## Step 3: Plan
31
+ /compact
41
32
 
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
33
+ ## Step 6
48
34
 
49
- Commit: `feat: add implementation plan for {feature-name}`
35
+ /speckit.tasks
50
36
 
51
- ## Step 4: Compact
37
+ ## Step 7
52
38
 
53
- Run `/compact` to free context window.
39
+ /speckit.analyze
54
40
 
55
- ## Step 5: Tasks
41
+ ## Step 8
56
42
 
57
- Read the plan and create `specs/{feature-name}/tasks.md` with granular tasks (5-15 min each):
43
+ Commit and push code.
58
44
 
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
- ```
45
+ ## Step 9
70
46
 
71
- Order: setup → data layer → business logic → UI → integration → polish
72
- Commit: `feat: add task list for {feature-name}`
47
+ /compact
73
48
 
74
- ## Step 6: Analyze
49
+ ## Step 10
75
50
 
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
86
-
87
- Commit all spec files and push to remote if configured.
88
-
89
- ## Step 8: Compact
90
-
91
- Run `/compact` to free context window before implementation.
92
-
93
- ## Step 9: Implement with ralph-loop
94
-
95
- ```
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
97
- ```
98
-
99
- ## After ralph-loop completes
100
-
101
- Output a final summary:
102
- - What was built
103
- - Total tests passing
104
- - Files created/modified
105
- - How to run the application
106
-
107
- ## CRITICAL RULES
108
- - Do NOT ask for confirmation between steps
109
- - Do NOT skip TDD — test first, always
110
- - Commit after EVERY completed task
111
- - Use MCP tools if available (bms-session for database access)
112
- - Push code if git remote is configured
51
+ /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