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 CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "bms-speckit-plugin",
3
- "version": "2.1.1",
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}`
@@ -1,5 +1,5 @@
1
1
  ---
2
- name: bms-speckit
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
- ### Task N: {Name}
71
- - **Status**: pending
72
- - **Priority**: high | medium | low
73
- - **Phase**: N
74
- - **Files**: exact file paths
75
- - **Description**: specific and actionable
76
- - **Tests**: what tests to write first
77
- - **Acceptance**: measurable verification criteria
78
- - **Commit message**: descriptive message
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
- - Order: setup → data layer → business logic → UI → integration → polish
82
- - Commit: `feat: add task list for {feature-name}`
27
+ ## Step 5: Tasks
28
+ Invoke skill `bms-speckit:tasks`
83
29
 
84
- ### Step 6: Analyze Tasks
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
30
+ ## Step 6: Analyze
31
+ Invoke skill `bms-speckit:analyze`
93
32
 
94
- ### Step 7: Commit and push
95
- - Commit all spec files created so far
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
- ### Step 8: Compact context (second)
100
- - Run `/compact` to free up context window before implementation
36
+ ## Step 8: Compact
37
+ Run `/compact` to free context window before implementation.
101
38
 
102
- ### Step 9: Implement with ralph-loop
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 "Read specs/*/tasks.md and implement the next pending task using TDD (write test first, verify fail, implement, verify pass, commit). Update task status to completed after each task. Do not ask for any confirmation. Once all tasks are done, run analysis: read specs/*/tasks.md and verify all tasks are completed, run the full test suite, check all specification requirements are met, fix any issues found, and output <promise>FINISHED</promise> only after all tasks are completed and revalidated" --completion-promise "FINISHED" --max-iterations 10
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
- ### After ralph-loop completes
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 — run everything automatically
120
- - Do NOT skip the TDD cycle test first, always
121
- - Commit after EVERY completed task
55
+ - Do NOT ask for confirmation between steps
56
+ - Each step invokes its sub-skilldo 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}`