bms-speckit-plugin 1.0.0 → 2.0.1

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "bms-speckit",
-  "version": "1.0.0",
-  "description": "Structured development workflow: constitution → specify → plan → tasks → analyze → implement. Takes requirements through a full engineering pipeline with TDD, quality gates, and automated task execution.",
+  "version": "2.0.0",
+  "description": "Single-command automated development pipeline. /bms-speckit takes requirements and runs the full engineering workflow with TDD and quality gates.",
   "author": {
     "name": "manoirx"
   },

package/package.json

@@ -1,10 +1,9 @@
 {
   "name": "bms-speckit-plugin",
-  "version": "1.0.0",
-  "description": "Claude Code plugin for structured development workflow: constitution → specify → plan → tasks → analyze → implement",
+  "version": "2.0.1",
+  "description": "Single-command automated development pipeline: /bms-speckit takes requirements and runs constitution → specify → plan → tasks → analyze → implement → verify",
   "files": [
     ".claude-plugin/",
-    "commands/",
     "skills/"
   ],
   "keywords": [

package/skills/speckit/SKILL.md

@@ -1,74 +1,127 @@
 ---
 name: bms-speckit
-description: This skill should be used when the user mentions "speckit", "bms-speckit", uses any bms-speckit command (/bms-speckit:constitution, /bms-speckit:specify, /bms-speckit:plan, /bms-speckit:tasks, /bms-speckit:analyze, /bms-speckit:implement), or asks about the development workflow pipeline. Provides a structured engineering workflow from requirements to implementation.
+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.
+argument-hint: <your requirement description>
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Skill, Agent, WebSearch, WebFetch
 ---
 
-# Speckit — Structured Development Workflow
+# BMS Speckit — Automated Development Pipeline
 
-## Overview
+Takes a single requirement and runs the complete engineering workflow automatically:
+**constitution → specify → plan → tasks → analyze → implement → verify**
 
-Speckit is a development pipeline that takes user requirements through a disciplined engineering process:
+## Engineering Constitution
 
-```
-constitution → specify → plan → tasks → analyze → implement
-```
-
-Each step produces artifacts in `specs/` directory that feed into the next step.
-
-## Workflow Commands
+All work follows these principles:
 
-| Command | Purpose | Input | Output |
-|---|---|---|---|
-| `/bms-speckit:constitution` | Set engineering principles | Constitution text | `specs/constitution.md` |
-| `/bms-speckit:specify` | Create specification from requirements | User requirements | `specs/{feature}/specification.md` |
-| `/bms-speckit:plan` | Create implementation plan from spec | Specification | `specs/{feature}/plan.md` |
-| `/bms-speckit:tasks` | Break plan into executable tasks | Plan | `specs/{feature}/tasks.md` |
-| `/bms-speckit:analyze` | Review tasks for improvements | Tasks | Updated `tasks.md` |
-| `/bms-speckit:implement` | Execute tasks one by one with TDD | Tasks | Working code + tests |
-
-## Directory Structure
-
-```
-specs/
-├── constitution.md                    # Engineering principles
-└── {feature-name}/
-    ├── specification.md               # What to build
-    ├── plan.md                        # How to build it
-    └── tasks.md                       # Task checklist with status
-```
-
-## Constitution Principles
-
-The constitution governs all speckit work. Default principles:
-
-1. **Code Quality** — High standards, strict TypeScript, no shortcuts
-2. **TDD** — Write tests first, confirm failure, then implement
-3. **Testing Levels** — Unit, component, integration, API tests as appropriate
-4. **UX** — Consistent, professional, user-friendly interfaces
+1. **Code Quality** — No hardcoded conditions, strict TypeScript, no shortcuts
+2. **TDD** — Always write tests FIRST, confirm failure, then implement
+3. **Testing** — Unit, component, integration, and API tests as appropriate
+4. **UX** — Consistent, professional, user-friendly interfaces with clear feedback
 5. **Performance** — Efficient architecture and resource management
-6. **Version Control** — Frequent atomic commits after each meaningful change
+6. **Version Control** — Commit after every meaningful change with descriptive messages
 7. **Reusability** — Modular components, centralized business logic, no duplication
 8. **User Feedback** — Informative progress reporting and error messages
-9. **Tool Leverage** — Use available frameworks, skills, and domain expertise
-
-## Task Status Format
+9. **Tool Leverage** — Use all available skills, MCP tools, frameworks, and domain expertise
+
+## Workflow — Execute ALL steps in order, do NOT ask for confirmation
+
+### Step 1: Setup Constitution
+- Create `specs/` directory
+- Write `specs/constitution.md` with the principles above
+- Check CLAUDE.md compliance — update if needed
+- Commit: `feat: establish engineering constitution`
+
+### Step 2: Create Specification
+- The user's requirement is provided as the command argument: $ARGUMENTS
+- Analyze this requirement thoroughly
+- If database access is needed and MCP tools are available (list_tables, describe_table, query), explore the actual database schema
+- Create `specs/{feature-name}/specification.md` containing:
+  - Overview and user requirements
+  - Functional requirements (numbered, testable)
+  - Non-functional requirements (performance, security, UX)
+  - Technical analysis (database schema, API dependencies)
+  - Architecture (components, data flow)
+  - UI/UX design (screens, navigation, interactions)
+  - Data model (tables, relationships, queries)
+  - Constraints and success criteria
+- Commit: `feat: add specification for {feature-name}`
+
+### Step 3: Create Implementation Plan
+- Read the specification
+- Create `specs/{feature-name}/plan.md` containing:
+  - Architecture overview and file structure
+  - Implementation phases: Foundation → Core → UI → Integration → Testing
+  - Technology stack with justification
+  - Testing strategy (what to test, coverage targets)
+  - Risk assessment
+- Commit: `feat: add implementation plan for {feature-name}`
+
+### Step 4: Create Task List
+- Read the plan
+- Create `specs/{feature-name}/tasks.md` with granular tasks (5-15 min each)
+- Each task includes:
 
-Tasks in `tasks.md` use this format:
-
-```markdown
-### Task 1: [Name]
-- **Status**: pending | in_progress | completed | blocked
+```
+### Task N: {Name}
+- **Status**: pending
 - **Priority**: high | medium | low
-- **Files**: list of files to create/modify
-- **Description**: what to do
-- **Acceptance**: how to verify it's done
+- **Phase**: N
+- **Files**: exact file paths
+- **Description**: specific and actionable
+- **Tests**: what tests to write first
+- **Acceptance**: measurable verification criteria
+- **Commit message**: descriptive message
 ```
 
-## Implementation Rules
-
-When implementing tasks:
-- Follow TDD: test first → verify fail → implement → verify pass → commit
-- One task at a time, mark complete before moving to next
-- Commit after each completed task
-- If blocked, mark as blocked with reason and move to next task
-- Run `/bms-speckit:analyze` after completing all tasks to verify quality
+- Order: setup → data layer → business logic → UI → integration → polish
+- Commit: `feat: add task list for {feature-name}`
+
+### Step 5: Analyze Tasks
+- Review all tasks for quality:
+  - Granular enough? (5-15 min each)
+  - Each independently testable?
+  - Dependencies correct and explicit?
+  - Every task has test-first step?
+  - Acceptance criteria clear and measurable?
+- Fix any issues found in tasks.md
+- Commit if changes made
+
+### Step 6: Implement ALL Tasks
+For each pending task, execute the TDD cycle:
+
+1. Update task status to `in_progress` in tasks.md
+2. **Write the test first** — meaningful tests that verify behavior
+3. **Run tests — verify they FAIL** (if they pass, tests are wrong)
+4. **Write minimal implementation** to make tests pass
+5. **Run ALL tests — verify they PASS** (fix regressions)
+6. **Commit** with the task's commit message
+7. Update task status to `completed` and increment completed count
+8. Move to next pending task
+
+If a task is blocked, mark as `blocked` with reason and continue.
+
+### Step 7: Final Verification
+- Run the full test suite
+- Review all specification requirements are met
+- Check for security issues
+- Run the analyze step again on completed code
+- If issues found, create new tasks and implement them
+- Commit any final fixes
+
+### Step 8: Summary Report
+Output a final report:
+- What was built
+- Total tests passing
+- Files created/modified
+- How to run the application
+- Any remaining issues or recommendations
+
+## CRITICAL RULES
+- Do NOT ask for confirmation between steps — run everything automatically
+- Do NOT skip the TDD cycle — test first, always
+- Commit after EVERY completed task
+- Use MCP tools if available (bms-session for database access)
+- If blocked on a task, skip it and continue — come back later
+- Push code if git remote is configured

package/commands/analyze.md

@@ -1,70 +0,0 @@
----
-name: analyze
-description: Review tasks and implementation for quality, completeness, and constitution compliance
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent
-user-invocable: true
----
-
-# Speckit Analyze
-
-Review tasks and/or implementation for quality and compliance with the constitution.
-
-## Instructions
-
-1. Read `specs/constitution.md` for governing principles.
-
-2. Find the most recent tasks file (`specs/*/tasks.md`).
-
-3. Read the specification and plan for context.
-
-4. **If tasks are not yet started (all pending)** — Review task quality:
-   - Are tasks granular enough (5-15 min each)?
-   - Is each task independently testable?
-   - Are dependencies correct and explicit?
-   - Does every task include a test-first step?
-   - Are acceptance criteria clear and measurable?
-   - Are commit messages descriptive?
-   - Are there any missing tasks from the plan?
-   - Does the task order make sense?
-
-5. **If some tasks are completed** — Review implementation quality:
-   - Read the code that was written for completed tasks
-   - Check if tests exist and are meaningful (not just mocking everything)
-   - Check if code follows the constitution principles
-   - Check for code duplication or missed reuse opportunities
-   - Check if commits were made after each task
-   - Check for missing error handling
-   - Check UX: is feedback clear? Are loading states handled?
-   - Check performance: any obvious inefficiencies?
-
-6. **If all tasks are completed** — Final review:
-   - Run all tests (`npm test` or equivalent)
-   - Check test coverage
-   - Review overall architecture matches the plan
-   - Verify all specification requirements are met
-   - Check for security issues
-   - Verify deployment instructions work
-
-7. Output a report:
-
-```markdown
-## Speckit Analysis Report
-
-**Feature**: {name}
-**Tasks**: {completed}/{total}
-**Status**: {needs-work | ready-to-implement | ready-to-ship}
-
-### Issues Found
-{List each issue with severity: critical / important / minor}
-
-### Recommendations
-{Specific actions to take, with task references}
-
-### Constitution Compliance
-{Which principles are met, which need work}
-```
-
-8. If issues are found, update `tasks.md`:
-   - Add new tasks for issues that need fixing
-   - Update existing task descriptions if acceptance criteria need strengthening
-   - Mark the total task count updated

package/commands/constitution.md

@@ -1,36 +0,0 @@
----
-name: constitution
-description: Establish engineering principles that govern all speckit development work
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep
----
-
-# Speckit Constitution
-
-Establish the engineering constitution for this project. The constitution defines principles that ALL subsequent speckit commands must follow.
-
-## Instructions
-
-1. Read the user's input as the constitution text. If no input provided, use the default constitution from the speckit skill.
-
-2. Create directory `specs/` if it doesn't exist.
-
-3. Write `specs/constitution.md` with the following format:
-
-```markdown
-# Engineering Constitution
-
-Established: {current date}
-
-## Principles
-
-{constitution text, formatted as numbered principles}
-
-## Enforcement
-
-All speckit commands (specify, plan, tasks, implement) must comply with these principles.
-Violations should be flagged during /speckit:analyze.
-```
-
-4. Check if CLAUDE.md exists in the project root. If it does, verify it aligns with the constitution. If it doesn't align, suggest specific additions to make it compliant. Only modify CLAUDE.md if the user confirms.
-
-5. Report what was created and confirm the constitution is active.

package/commands/implement.md

@@ -1,72 +0,0 @@
----
-name: implement
-description: Execute the next pending task from the task list using TDD
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent, WebSearch, WebFetch
-user-invocable: true
----
-
-# Speckit Implement
-
-Execute the next pending task from the task list using TDD.
-
-## Instructions
-
-1. Read `specs/constitution.md` for governing principles.
-
-2. Find the tasks file (`specs/*/tasks.md`). If multiple features exist and user doesn't specify, pick the one with pending tasks.
-
-3. Find the **first task with status `pending`**. Update its status to `in_progress` in the tasks file.
-
-4. Read the task's description, files, tests, and acceptance criteria.
-
-5. **Execute using TDD:**
-
-   a. **Write the test first**
-      - Create the test file specified in the task
-      - Write test cases that cover the acceptance criteria
-      - Tests should be meaningful — verify behavior, not mock everything
-
-   b. **Verify the test fails**
-      - Run the test suite
-      - Confirm the new tests fail (because implementation doesn't exist yet)
-      - If tests pass without implementation, the tests are wrong — fix them
-
-   c. **Write the minimal implementation**
-      - Implement only what's needed to pass the tests
-      - Follow the file structure from the plan
-      - Follow existing code patterns in the project
-
-   d. **Verify all tests pass**
-      - Run the full test suite (not just new tests)
-      - Fix any regressions
-
-   e. **Commit**
-      - Stage only the files relevant to this task
-      - Use the commit message from the task
-      - Never use `--no-verify`
-
-6. **Update the tasks file:**
-   - Set this task's status to `completed`
-   - Update the "Completed" count at the top
-
-7. **Check if there are more pending tasks:**
-   - If yes, report completion and indicate next task is ready
-   - If no, report all tasks complete and suggest `/speckit:analyze` for final review
-
-## Error Handling
-
-- If a test framework isn't set up yet, set it up as part of the first task
-- If a task is blocked by a missing dependency, mark it as `blocked` with reason, and move to the next pending task
-- If implementation is unclear, read the specification and plan for context
-- Never skip the test-first step — if it's genuinely not testable, document why in the task
-
-## Output Format
-
-```
-Task {N}: {name}
-Status: completed ✓
-Tests: {X} passing
-Files: {list of files changed}
-Commit: {sha} - {message}
-Next: Task {N+1}: {name} (or "All tasks complete")
-```

package/commands/plan.md

@@ -1,71 +0,0 @@
----
-name: plan
-description: Create an implementation plan from a specification
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent
-user-invocable: true
----
-
-# Speckit Plan
-
-Create a detailed implementation plan from the most recent specification.
-
-## Instructions
-
-1. Find the most recent specification:
-   - Look for `specs/*/specification.md` files
-   - If multiple exist, use the most recently modified one
-   - If the user provides a feature name argument, use that specific one
-
-2. Read `specs/constitution.md` for governing principles.
-
-3. Read the specification thoroughly.
-
-4. Create `specs/{feature}/plan.md` with this structure:
-
-```markdown
-# {Feature Name} Implementation Plan
-
-Created: {date}
-Specification: specs/{feature}/specification.md
-
-## Architecture Overview
-{Component diagram in text, data flow, key technology choices}
-
-## File Structure
-{Every file to create/modify with its purpose}
-
-## Implementation Phases
-
-### Phase 1: Foundation
-{Project setup, scaffolding, core infrastructure}
-
-### Phase 2: Core Features
-{Main functionality, business logic, data layer}
-
-### Phase 3: UI/UX
-{User interface, interactions, responsive design}
-
-### Phase 4: Integration
-{API connections, authentication, data flow}
-
-### Phase 5: Testing & Polish
-{Test coverage, error handling, performance, accessibility}
-
-## Technology Stack
-{Frameworks, libraries, tools with justification}
-
-## Testing Strategy
-{Test types, what to test at each level, coverage targets}
-
-## Deployment
-{How to build, run locally, deploy}
-
-## Risk Assessment
-{Potential blockers and mitigation strategies}
-```
-
-5. Ensure the plan follows TDD approach: every feature implementation starts with tests.
-
-6. Ensure the plan includes commit points after each meaningful milestone.
-
-7. Report the plan location and suggest running `/speckit:tasks` next.

package/commands/specify.md

@@ -1,67 +0,0 @@
----
-name: specify
-description: Create a detailed specification from user requirements
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent, WebSearch, WebFetch
-user-invocable: true
----
-
-# Speckit Specify
-
-Create a detailed technical specification from user requirements.
-
-## Instructions
-
-1. Read the user's requirement text from the command argument.
-
-2. Read `specs/constitution.md` to understand governing principles. If it doesn't exist, warn the user to run `/speckit:constitution` first, but continue with default principles.
-
-3. Analyze the requirements:
-   - Identify the core problem being solved
-   - Identify target users and their needs
-   - Identify technical constraints and dependencies
-   - If database access is needed and BMS MCP tools are available, use them to explore the database schema (list_tables, describe_table) to inform the specification
-
-4. Create a feature directory name from the requirements (kebab-case, e.g., `hosxp-dashboard`).
-
-5. Write `specs/{feature}/specification.md` with this structure:
-
-```markdown
-# {Feature Name} Specification
-
-Created: {date}
-Status: Draft
-
-## Overview
-{1-2 paragraph summary of what we're building and why}
-
-## User Requirements
-{Original requirements from user}
-
-## Functional Requirements
-{Numbered list of specific, testable requirements}
-
-## Non-Functional Requirements
-{Performance, security, UX, accessibility requirements}
-
-## Technical Analysis
-{Database schema analysis, API dependencies, framework choices}
-
-## Architecture
-{High-level architecture: components, data flow, key decisions}
-
-## UI/UX Design
-{Screen descriptions, navigation flow, key interactions}
-
-## Data Model
-{Tables, relationships, queries needed}
-
-## Constraints
-{Limitations, assumptions, out of scope}
-
-## Success Criteria
-{How we know it's done — measurable outcomes}
-```
-
-6. If MCP tools are available, use them to validate the data model section against the actual database.
-
-7. Report the specification location and ask user to review before proceeding to `/speckit:plan`.

package/commands/tasks.md

@@ -1,74 +0,0 @@
----
-name: tasks
-description: Break an implementation plan into executable tasks with status tracking
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep
-user-invocable: true
----
-
-# Speckit Tasks
-
-Break the implementation plan into granular, executable tasks.
-
-## Instructions
-
-1. Find the most recent plan:
-   - Look for `specs/*/plan.md` files
-   - If the user provides a feature name argument, use that specific one
-
-2. Read the plan and the specification.
-
-3. Read `specs/constitution.md` for governing principles.
-
-4. Create `specs/{feature}/tasks.md` with granular tasks:
-
-```markdown
-# {Feature Name} Tasks
-
-Created: {date}
-Plan: specs/{feature}/plan.md
-Total Tasks: {count}
-Completed: 0
-
----
-
-### Task 1: {Name}
-- **Status**: pending
-- **Priority**: high
-- **Phase**: 1 (Foundation)
-- **Files**: `path/to/file1.ts`, `path/to/file2.ts`
-- **Description**: {What to do — specific and actionable}
-- **Tests**: {What tests to write first}
-- **Acceptance**: {How to verify it's done}
-- **Commit message**: `feat: {short description}`
-
----
-
-### Task 2: {Name}
-...
-```
-
-## Task Granularity Rules
-
-- Each task should take 5-15 minutes to implement
-- Each task must be independently testable
-- Each task produces a commit
-- Tasks follow TDD: write test → verify fail → implement → verify pass → commit
-- Dependencies between tasks should be explicit (e.g., "Depends on: Task 1")
-- Group tasks by phase from the plan
-
-## Task Ordering
-
-1. Project setup and scaffolding first
-2. Data layer and API connections
-3. Core business logic with tests
-4. UI components
-5. Integration and wiring
-6. Polish, error handling, accessibility
-
-## Report
-
-After creating tasks, output:
-- Total number of tasks
-- Tasks per phase
-- Estimated task dependencies
-- Suggest running `/speckit:analyze` to review quality