sdd-mcp-server 3.5.0 → 4.0.0

package/skills/simple-task/SKILL.md

@@ -1,152 +1,31 @@
 ---
 name: simple-task
-description: Implement simple features with best practices. Use when adding small features, bug fixes, or quick enhancements without the full SDD workflow. Invoked via /simple-task <description>.
+description: Implement a small focused change test-first without starting the full SDD workflow.
+disable-model-invocation: true
 ---
 
-# Simple Task Implementation
+# Simple Task
 
-Implement small features, bug fixes, or quick enhancements while following best practices from the project's steering documents.
+Work inline in the current turn; do not create a serial implementation specialist.
 
-## When to Use
+Use this route for a bounded bug fix, refactor, or enhancement with clear acceptance behavior. Switch to formal SDD when requirements, architecture, approval gates, or several dependent components need design.
 
-Use `/simple-task` for:
-- Small feature additions (e.g., "add logout button")
-- Bug fixes
-- Minor enhancements
-- Quick refactoring
+## Required Workflow
 
-Use **full SDD workflow** for:
-- Complex features requiring multiple components
-- New modules or subsystems
-- Features needing formal requirements/design review
+1. Confirm the requested behavior and inspect existing patterns. Do not infer extra scope.
+2. Locate the narrowest affected code and focused test.
+3. **RED:** write or adjust a focused failing test for observable behavior; run it and confirm the intended failure.
+4. **GREEN:** implement the smallest complete fix; run the focused test.
+5. **REFACTOR:** simplify while preserving behavior; rerun the focused test.
+6. Check boundaries, error propagation, compatibility, authorization, input validation, injection, secret handling, and sensitive logs where relevant.
+7. Review all affected callers and artifacts. Never discard unrelated work or claim unobserved checks.
 
-## Workflow
-
-### Step 1: Understand the Task
-
-1. Clarify what needs to be done
-2. Identify affected files/components
-3. Estimate scope (if larger than expected, suggest full SDD workflow)
-
-### Step 2: Apply TDD (Test-Driven Development)
-
-**Reference:** `.spec/steering/tdd-guideline.md`
-
-Follow the Red-Green-Refactor cycle:
-
-```
-1. RED    → Write a failing test first
-2. GREEN  → Write minimal code to pass
-3. REFACTOR → Clean up while tests pass
-```
-
-**Quick TDD Checklist:**
-- [ ] Write test before implementation
-- [ ] Test describes expected behavior
-- [ ] Minimal code to make test pass
-- [ ] Refactor without breaking tests
-
-### Step 3: Apply Design Principles
-
-**Reference:** `.spec/steering/principles.md`
-
-**SOLID Quick Reference:**
-- **S**ingle Responsibility: Each function/class does one thing
-- **O**pen/Closed: Extend behavior without modifying existing code
-- **L**iskov Substitution: Subtypes must be substitutable
-- **I**nterface Segregation: Small, focused interfaces
-- **D**ependency Inversion: Depend on abstractions
-
-**Other Principles:**
-- **DRY**: Don't repeat yourself - extract common logic
-- **KISS**: Keep it simple - avoid unnecessary complexity
-- **YAGNI**: You aren't gonna need it - only implement what's required
-
-### Step 4: Code Quality Review
-
-**Reference:** `.spec/steering/linus-review.md`
-
-Before finalizing, ask:
-1. **Taste**: Is the solution elegant? Can special cases be eliminated?
-2. **Simplicity**: Can it be simpler? Fewer lines? Less nesting?
-3. **Data Structures**: Is the right data structure used?
-4. **Breaking Changes**: Does this break existing functionality?
-
-**Quality Checklist:**
-- [ ] Functions are short and focused
-- [ ] No more than 3 levels of indentation
-- [ ] Clear, descriptive naming
-- [ ] No unnecessary complexity
-
-### Step 5: Security Check
-
-**Reference:** `.spec/steering/owasp-top10-check.md`
-
-**Quick Security Checklist:**
-- [ ] Input validation (sanitize user inputs)
-- [ ] No SQL/command injection (use parameterized queries)
-- [ ] Access control enforced
-- [ ] No secrets in code (use env vars)
-- [ ] Proper error handling (no stack traces to users)
-
-### Step 6: Implement and Test
-
-1. Write the failing test (RED)
-2. Implement minimal solution (GREEN)
-3. Run tests to confirm pass
-4. Refactor if needed
-5. Run full test suite
-6. Verify no lint/type errors
-
-## Reference Documents
-
-These steering documents provide detailed guidance:
-
-| Document | Content |
-|----------|---------|
-| `tdd-guideline.md` | TDD methodology, test pyramid, Red-Green-Refactor |
-| `principles.md` | SOLID, DRY, KISS, YAGNI, Separation of Concerns |
-| `linus-review.md` | Code quality, "good taste", simplicity standards |
-| `owasp-top10-check.md` | Security checklist (OWASP Top 10) |
+If the work genuinely decomposes into at least two independent slices, they may run concurrently; otherwise keep it in the parent.
 
 ## Output
 
-After implementing, provide:
-
-```markdown
-## Implementation Summary
-
-**Task:** {what was implemented}
-
-**Changes:**
-- {file1}: {what changed}
-- {file2}: {what changed}
-
-**Tests Added:**
-- {test description}
-
-**Principles Applied:**
-- TDD: {how TDD was followed}
-- Design: {which principles were applied}
-- Security: {security considerations}
-
-**Ready for:** {commit / further review / testing}
-```
-
-## Example
-
-```
-User: /simple-task add a logout button to the navbar
-
-Claude:
-1. Understand: Add logout button that clears session and redirects to login
-2. TDD: Write test for logout functionality first
-3. Principles: Single responsibility - logout logic in AuthService
-4. Security: Ensure session is properly invalidated
-5. Implement: Button component + logout handler
-6. Test: Verify all tests pass
-```
+Report changed paths, behavior protected, failing and passing focused test evidence, security considerations, and unresolved blockers.
 
-## Specialist Delegation
+## Optional Reference
 
-When the host supports subagents, delegate the implementation to the `implementer` role with a compact handoff containing only the requested change, affected files, constraints, and focused verification. Wait for the specialist and then integrate its result into the current workflow. If specialist delegation is unavailable, state the fallback and continue in the current agent.
+Read [REFERENCE.md](REFERENCE.md) only for scope examples, TDD reminders, or the completion checklist.

package/templates/CLAUDE.md

@@ -1,43 +1,31 @@
-# CLAUDE.md — Spec-Driven Development (SDD)
+# CLAUDE.md — Spec-Driven Development
 
-This project uses the SDD workflow powered by `sdd-mcp-server`.
+This project uses `sdd-mcp-server` with manual-only skills and the canonical v4 MCP runtime.
 
-## Two Development Paths
+## Development paths
 
-### Path A: Simple Task (`/simple-task`)
-For small features, bug fixes, and quick enhancements.
+### Simple task
 
-### Path B: Full SDD Workflow
-For complex features requiring formal specification.
+Invoke `/simple-task` for a small feature, bug fix, or focused enhancement.
 
-```
-sdd-init → /sdd-requirements → /sdd-design → /sdd-tasks → /sdd-implement
+### Formal SDD
+
+For work requiring approved requirements, design, and TDD tasks:
+
+```text
+sdd-init → /sdd-requirements → sdd-approve → /sdd-design → sdd-approve → /sdd-tasks → optional test review → sdd-approve → /sdd-implement
 ```
 
-Each phase requires human approval before proceeding.
+Use the installed `sdd-*` MCP tools for state changes and compact context by default. Feature-scoped calls use `featureName`, not `projectId`.
 
-## Installed Components
+For continuation, call `sdd-context-load` with `featureName`; retain the returned `fingerprint` and send it as `ifNoneMatch` on the next identical request. A `not-modified` result means the prior payload remains current and must not be requested or repeated again.
 
-The installer appends only the components selected for this target and their effective paths.
+## Model execution
 
-## MCP Tools
+Claude applies the routed model to the current skill turn: Opus for requirements, design, review, and security; Sonnet for implementation and TDD. Execute in this turn and do not spawn a second specialist merely to switch models. Commit work remains in the current turn.
 
-| Tool | Description |
-|------|-------------|
-| `sdd-init` | Initialize new SDD spec |
-| `sdd-status` | Check workflow progress |
-| `sdd-approve` | Approve workflow phases |
-| `sdd-quality-check` | Code quality analysis |
-| `sdd-context-load` | Load project context |
-| `sdd-validate-design` | Design quality validation |
-| `sdd-validate-gap` | Implementation gap analysis |
-| `sdd-spec-impl` | Execute tasks with TDD |
+## Installed components
 
-## Workflow
+The installer appends only selected components and their effective paths. Detailed rules and references load on demand; path-scoped rule bodies are not imported into this root file.
 
-1. **Setup**: `npx sdd-mcp-server install --profile full --target claude-code` (already done)
-2. **Steering** (optional): `/sdd-steering` to generate project-specific docs
-3. **Specify**: `sdd-init` → `/sdd-requirements` → `/sdd-design` → `/sdd-tasks` (approve each phase)
-4. **Implement**: `/sdd-implement` or `sdd-spec-impl`
-5. **Review**: `sdd-quality-check`
-6. **Commit**: `/sdd-commit`
+To update untouched generated guidance automatically, rerun the installer. User-modified managed files are preserved. A legacy refresh uses `--refresh-generated` and stores reversible backups under `.sdd-mcp/backups/<timestamp>/claude-code/`.

package/rules/git-workflow.md

@@ -1,92 +0,0 @@
----
-name: git-workflow
-description: Git commit and branching conventions
-priority: 80
-alwaysActive: true
----
-
-# Git Workflow Rules
-
-## Commit Messages
-
-### Format
-```
-<type>(<scope>): <subject>
-
-<body>
-
-<footer>
-```
-
-### Types
-- **feat**: New feature
-- **fix**: Bug fix
-- **docs**: Documentation only changes
-- **style**: Code style changes (formatting, semicolons)
-- **refactor**: Code change that neither fixes a bug nor adds a feature
-- **perf**: Performance improvement
-- **test**: Adding or updating tests
-- **chore**: Build process or auxiliary tool changes
-
-### Subject Line
-- Use imperative mood ("add" not "added")
-- No period at the end
-- Maximum 50 characters
-- Capitalize first letter
-
-### Body
-- Explain "what" and "why", not "how"
-- Wrap at 72 characters
-- Separate from subject with blank line
-
-### Examples
-```
-feat(auth): add JWT token refresh endpoint
-
-Implement automatic token refresh to improve user experience.
-Tokens are refreshed 5 minutes before expiration.
-
-Closes #123
-```
-
-```
-fix(api): handle null response from external service
-
-The external payment API occasionally returns null instead of
-an error object. This caused unhandled exceptions in production.
-
-Fixes #456
-```
-
-## Branching Strategy
-
-### Branch Types
-- **main/master**: Production-ready code
-- **develop**: Integration branch for features
-- **feature/**: New features (`feature/add-user-auth`)
-- **fix/**: Bug fixes (`fix/login-validation`)
-- **refactor/**: Code refactoring (`refactor/better-architecture`)
-
-### Branch Naming
-- Use lowercase with hyphens
-- Include ticket number if applicable
-- Keep names descriptive but concise
-
-## Pull Requests
-
-### Before Creating PR
-- Rebase on latest target branch
-- Run all tests locally
-- Update documentation if needed
-- Self-review your changes
-
-### PR Description
-- Reference related issues
-- Describe what changed and why
-- Include testing instructions
-- Add screenshots for UI changes
-
-### Review Process
-- Address all review comments
-- Don't force-push after review started
-- Squash commits when merging (if team policy)

package/rules/sdd-workflow.md

@@ -1,116 +0,0 @@
----
-name: sdd-workflow
-description: Spec-Driven Development process rules
-priority: 85
-alwaysActive: true
----
-
-# SDD Workflow Rules
-
-## Spec-Driven Development Process
-
-### Phase Order
-Follow the SDD phases in strict order:
-
-1. **Initialize** (`sdd-init`)
-   - Define feature name and description
-   - Answer clarification questions
-   - Create spec directory structure
-
-2. **Requirements** (`sdd-requirements`)
-   - Generate EARS-formatted requirements
-   - Define acceptance criteria
-   - Identify constraints and assumptions
-
-3. **Design** (`sdd-design`)
-   - Create technical design specifications
-   - Define component architecture
-   - Document interfaces and data flows
-
-4. **Tasks** (`sdd-tasks`)
-   - Break down into implementable tasks
-   - Apply TDD methodology
-   - Estimate complexity
-
-5. **Implement** (`sdd-implement`)
-   - Follow TDD (Red-Green-Refactor)
-   - Reference steering documents
-   - Update spec status
-
-## EARS Requirements Format
-
-Use Easy Approach to Requirements Syntax:
-
-| Pattern | Template | Use Case |
-|---------|----------|----------|
-| Ubiquitous | The `<system>` SHALL `<action>` | Always true |
-| Event-Driven | WHEN `<trigger>` THEN the `<system>` SHALL `<action>` | Response to event |
-| State-Driven | WHILE `<state>` THE `<system>` SHALL `<action>` | During state |
-| Optional | WHERE `<feature>` THE `<system>` SHALL `<action>` | Configurable |
-| Unwanted | IF `<condition>` THEN the `<system>` SHALL `<action>` | Exception |
-
-### Example
-```markdown
-## FR-1: User Authentication
-WHEN a user submits valid credentials
-THEN the system SHALL authenticate the user and return a session token
-
-**Acceptance Criteria:**
-1. Token expires after 24 hours of inactivity
-2. Invalid credentials return 401 error
-3. Rate limiting prevents brute force attempts
-```
-
-## Steering Documents
-
-### Always Reference
-- `.spec/steering/tdd-guideline.md` - TDD methodology
-- `.spec/steering/principles.md` - SOLID, DRY, KISS, YAGNI
-- `.spec/steering/linus-review.md` - Code review standards
-
-### When to Reference
-- Before writing any code, review relevant steering docs
-- During code review, verify compliance
-- When refactoring, ensure principles are maintained
-
-## Approval Gates
-
-### Requirements Approval
-Before proceeding to design:
-- [ ] All requirements use EARS format
-- [ ] Each requirement is testable
-- [ ] Acceptance criteria are specific
-- [ ] Constraints are documented
-
-### Design Approval
-Before proceeding to tasks:
-- [ ] Architecture diagram included
-- [ ] Interfaces defined
-- [ ] Dependencies identified
-- [ ] Security considerations addressed
-
-### Tasks Approval
-Before proceeding to implementation:
-- [ ] Tasks follow TDD structure
-- [ ] Complexity estimated
-- [ ] Dependencies mapped
-- [ ] Steering doc references included
-
-## Spec File Locations
-
-```
-.spec/
-├── steering/          # Project-wide rules
-│   ├── product.md
-│   ├── tech.md
-│   ├── structure.md
-│   ├── tdd-guideline.md
-│   ├── principles.md
-│   └── linus-review.md
-└── specs/             # Feature specifications
-    └── {feature-name}/
-        ├── spec.json
-        ├── requirements.md
-        ├── design.md
-        └── tasks.md
-```