sdd-mcp-server 3.0.2 → 3.1.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 (42) hide show
  1. package/README.md +117 -98
  2. package/agents/architect.md +107 -0
  3. package/agents/implementer.md +154 -0
  4. package/agents/planner.md +97 -0
  5. package/agents/reviewer.md +252 -0
  6. package/agents/security-auditor.md +127 -0
  7. package/agents/tdd-guide.md +241 -0
  8. package/contexts/dev.md +58 -0
  9. package/contexts/planning.md +79 -0
  10. package/contexts/research.md +93 -0
  11. package/contexts/review.md +73 -0
  12. package/contexts/security-audit.md +92 -0
  13. package/dist/cli/migrate-steering.d.ts +24 -0
  14. package/dist/cli/migrate-steering.js +308 -0
  15. package/dist/cli/migrate-steering.js.map +1 -0
  16. package/dist/cli/sdd-mcp-cli.js +9 -0
  17. package/dist/cli/sdd-mcp-cli.js.map +1 -1
  18. package/hooks/post-tool-use/log-tool-execution.md +51 -0
  19. package/hooks/post-tool-use/update-spec-status.md +50 -0
  20. package/hooks/pre-tool-use/check-test-coverage.md +51 -0
  21. package/hooks/pre-tool-use/validate-sdd-workflow.md +55 -0
  22. package/hooks/session-end/remind-uncommitted-changes.md +58 -0
  23. package/hooks/session-end/save-session-summary.md +72 -0
  24. package/hooks/session-start/load-project-context.md +62 -0
  25. package/package.json +5 -1
  26. package/rules/coding-style.md +97 -0
  27. package/rules/error-handling.md +134 -0
  28. package/rules/git-workflow.md +92 -0
  29. package/rules/sdd-workflow.md +116 -0
  30. package/rules/security.md +89 -0
  31. package/rules/testing.md +85 -0
  32. package/sdd-entry.js +1 -1
  33. package/skills/sdd-commit/SKILL.md +0 -14
  34. package/steering/product.md +29 -0
  35. package/steering/structure.md +60 -0
  36. package/steering/tech.md +52 -0
  37. package/steering/AGENTS.md +0 -281
  38. package/steering/commit.md +0 -59
  39. package/steering/linus-review.md +0 -153
  40. package/steering/owasp-top10-check.md +0 -49
  41. package/steering/principles.md +0 -639
  42. package/steering/tdd-guideline.md +0 -324
package/rules/git-workflow.md ADDED
@@ -0,0 +1,92 @@
1
+ ---
2
+ name: git-workflow
3
+ description: Git commit and branching conventions
4
+ priority: 80
5
+ alwaysActive: true
6
+ ---
7
+
8
+ # Git Workflow Rules
9
+
10
+ ## Commit Messages
11
+
12
+ ### Format
13
+ ```
14
+ <type>(<scope>): <subject>
15
+
16
+ <body>
17
+
18
+ <footer>
19
+ ```
20
+
21
+ ### Types
22
+ - **feat**: New feature
23
+ - **fix**: Bug fix
24
+ - **docs**: Documentation only changes
25
+ - **style**: Code style changes (formatting, semicolons)
26
+ - **refactor**: Code change that neither fixes a bug nor adds a feature
27
+ - **perf**: Performance improvement
28
+ - **test**: Adding or updating tests
29
+ - **chore**: Build process or auxiliary tool changes
30
+
31
+ ### Subject Line
32
+ - Use imperative mood ("add" not "added")
33
+ - No period at the end
34
+ - Maximum 50 characters
35
+ - Capitalize first letter
36
+
37
+ ### Body
38
+ - Explain "what" and "why", not "how"
39
+ - Wrap at 72 characters
40
+ - Separate from subject with blank line
41
+
42
+ ### Examples
43
+ ```
44
+ feat(auth): add JWT token refresh endpoint
45
+
46
+ Implement automatic token refresh to improve user experience.
47
+ Tokens are refreshed 5 minutes before expiration.
48
+
49
+ Closes #123
50
+ ```
51
+
52
+ ```
53
+ fix(api): handle null response from external service
54
+
55
+ The external payment API occasionally returns null instead of
56
+ an error object. This caused unhandled exceptions in production.
57
+
58
+ Fixes #456
59
+ ```
60
+
61
+ ## Branching Strategy
62
+
63
+ ### Branch Types
64
+ - **main/master**: Production-ready code
65
+ - **develop**: Integration branch for features
66
+ - **feature/**: New features (`feature/add-user-auth`)
67
+ - **fix/**: Bug fixes (`fix/login-validation`)
68
+ - **refactor/**: Code refactoring (`refactor/better-architecture`)
69
+
70
+ ### Branch Naming
71
+ - Use lowercase with hyphens
72
+ - Include ticket number if applicable
73
+ - Keep names descriptive but concise
74
+
75
+ ## Pull Requests
76
+
77
+ ### Before Creating PR
78
+ - Rebase on latest target branch
79
+ - Run all tests locally
80
+ - Update documentation if needed
81
+ - Self-review your changes
82
+
83
+ ### PR Description
84
+ - Reference related issues
85
+ - Describe what changed and why
86
+ - Include testing instructions
87
+ - Add screenshots for UI changes
88
+
89
+ ### Review Process
90
+ - Address all review comments
91
+ - Don't force-push after review started
92
+ - Squash commits when merging (if team policy)
package/rules/sdd-workflow.md ADDED
@@ -0,0 +1,116 @@
1
+ ---
2
+ name: sdd-workflow
3
+ description: Spec-Driven Development process rules
4
+ priority: 85
5
+ alwaysActive: true
6
+ ---
7
+
8
+ # SDD Workflow Rules
9
+
10
+ ## Spec-Driven Development Process
11
+
12
+ ### Phase Order
13
+ Follow the SDD phases in strict order:
14
+
15
+ 1. **Initialize** (`sdd-init`)
16
+ - Define feature name and description
17
+ - Answer clarification questions
18
+ - Create spec directory structure
19
+
20
+ 2. **Requirements** (`sdd-requirements`)
21
+ - Generate EARS-formatted requirements
22
+ - Define acceptance criteria
23
+ - Identify constraints and assumptions
24
+
25
+ 3. **Design** (`sdd-design`)
26
+ - Create technical design specifications
27
+ - Define component architecture
28
+ - Document interfaces and data flows
29
+
30
+ 4. **Tasks** (`sdd-tasks`)
31
+ - Break down into implementable tasks
32
+ - Apply TDD methodology
33
+ - Estimate complexity
34
+
35
+ 5. **Implement** (`sdd-implement`)
36
+ - Follow TDD (Red-Green-Refactor)
37
+ - Reference steering documents
38
+ - Update spec status
39
+
40
+ ## EARS Requirements Format
41
+
42
+ Use Easy Approach to Requirements Syntax:
43
+
44
+ | Pattern | Template | Use Case |
45
+ |---------|----------|----------|
46
+ | Ubiquitous | The `<system>` SHALL `<action>` | Always true |
47
+ | Event-Driven | WHEN `<trigger>` THEN the `<system>` SHALL `<action>` | Response to event |
48
+ | State-Driven | WHILE `<state>` THE `<system>` SHALL `<action>` | During state |
49
+ | Optional | WHERE `<feature>` THE `<system>` SHALL `<action>` | Configurable |
50
+ | Unwanted | IF `<condition>` THEN the `<system>` SHALL `<action>` | Exception |
51
+
52
+ ### Example
53
+ ```markdown
54
+ ## FR-1: User Authentication
55
+ WHEN a user submits valid credentials
56
+ THEN the system SHALL authenticate the user and return a session token
57
+
58
+ **Acceptance Criteria:**
59
+ 1. Token expires after 24 hours of inactivity
60
+ 2. Invalid credentials return 401 error
61
+ 3. Rate limiting prevents brute force attempts
62
+ ```
63
+
64
+ ## Steering Documents
65
+
66
+ ### Always Reference
67
+ - `.spec/steering/tdd-guideline.md` - TDD methodology
68
+ - `.spec/steering/principles.md` - SOLID, DRY, KISS, YAGNI
69
+ - `.spec/steering/linus-review.md` - Code review standards
70
+
71
+ ### When to Reference
72
+ - Before writing any code, review relevant steering docs
73
+ - During code review, verify compliance
74
+ - When refactoring, ensure principles are maintained
75
+
76
+ ## Approval Gates
77
+
78
+ ### Requirements Approval
79
+ Before proceeding to design:
80
+ - [ ] All requirements use EARS format
81
+ - [ ] Each requirement is testable
82
+ - [ ] Acceptance criteria are specific
83
+ - [ ] Constraints are documented
84
+
85
+ ### Design Approval
86
+ Before proceeding to tasks:
87
+ - [ ] Architecture diagram included
88
+ - [ ] Interfaces defined
89
+ - [ ] Dependencies identified
90
+ - [ ] Security considerations addressed
91
+
92
+ ### Tasks Approval
93
+ Before proceeding to implementation:
94
+ - [ ] Tasks follow TDD structure
95
+ - [ ] Complexity estimated
96
+ - [ ] Dependencies mapped
97
+ - [ ] Steering doc references included
98
+
99
+ ## Spec File Locations
100
+
101
+ ```
102
+ .spec/
103
+ ├── steering/ # Project-wide rules
104
+ │ ├── product.md
105
+ │ ├── tech.md
106
+ │ ├── structure.md
107
+ │ ├── tdd-guideline.md
108
+ │ ├── principles.md
109
+ │ └── linus-review.md
110
+ └── specs/ # Feature specifications
111
+ └── {feature-name}/
112
+ ├── spec.json
113
+ ├── requirements.md
114
+ ├── design.md
115
+ └── tasks.md
116
+ ```
package/rules/security.md ADDED
@@ -0,0 +1,89 @@
1
+ ---
2
+ name: security
3
+ description: Security best practices aligned with OWASP Top 10
4
+ priority: 99
5
+ alwaysActive: true
6
+ ---
7
+
8
+ # Security Rules
9
+
10
+ ## OWASP Top 10 Alignment
11
+
12
+ ### A01: Broken Access Control
13
+ - Implement proper authentication checks before sensitive operations
14
+ - Use principle of least privilege for permissions
15
+ - Validate user authorization for every request
16
+ - Never expose internal IDs directly to users
17
+
18
+ ### A02: Cryptographic Failures
19
+ - Never store passwords in plain text - use bcrypt or similar
20
+ - Use HTTPS for all external communications
21
+ - Don't hardcode secrets in source code
22
+ - Use secure random number generators for tokens
23
+
24
+ ### A03: Injection
25
+ - Always use parameterized queries for database operations
26
+ - Validate and sanitize all user inputs
27
+ - Escape output data appropriately for context (HTML, SQL, etc.)
28
+ - Never use `eval()` or similar dynamic code execution
29
+
30
+ ### A04: Insecure Design
31
+ - Apply defense in depth - multiple layers of security
32
+ - Implement rate limiting for APIs
33
+ - Design with security in mind from the start
34
+ - Use secure defaults
35
+
36
+ ### A05: Security Misconfiguration
37
+ - Disable unnecessary features and services
38
+ - Keep dependencies updated
39
+ - Remove default credentials
40
+ - Configure proper error handling (no stack traces in production)
41
+
42
+ ### A06: Vulnerable Components
43
+ - Regularly audit and update dependencies
44
+ - Use `npm audit` or similar tools
45
+ - Pin dependency versions in production
46
+ - Monitor security advisories
47
+
48
+ ### A07: Authentication Failures
49
+ - Implement strong password policies
50
+ - Use multi-factor authentication where possible
51
+ - Protect against brute force attacks
52
+ - Secure session management
53
+
54
+ ### A08: Data Integrity Failures
55
+ - Validate data integrity with checksums
56
+ - Use code signing for releases
57
+ - Verify software updates are from trusted sources
58
+
59
+ ### A09: Logging Failures
60
+ - Log security-relevant events
61
+ - Never log sensitive data (passwords, tokens, PII)
62
+ - Ensure logs are tamper-proof
63
+ - Monitor logs for suspicious activity
64
+
65
+ ### A10: Server-Side Request Forgery (SSRF)
66
+ - Validate and sanitize URLs before making requests
67
+ - Use allowlists for external services
68
+ - Don't expose internal services to user-controlled URLs
69
+
70
+ ## Code Security Practices
71
+
72
+ ### Input Validation
73
+ ```typescript
74
+ // Always validate user input
75
+ function processUserInput(input: unknown): ValidatedInput {
76
+ if (typeof input !== 'string') {
77
+ throw new ValidationError('Input must be a string');
78
+ }
79
+ if (input.length > MAX_INPUT_LENGTH) {
80
+ throw new ValidationError('Input too long');
81
+ }
82
+ return sanitize(input);
83
+ }
84
+ ```
85
+
86
+ ### Error Handling
87
+ - Never expose internal errors to users
88
+ - Log errors with context for debugging
89
+ - Return generic error messages to clients
package/rules/testing.md ADDED
@@ -0,0 +1,85 @@
1
+ ---
2
+ name: testing
3
+ description: Testing requirements and best practices
4
+ priority: 95
5
+ alwaysActive: true
6
+ ---
7
+
8
+ # Testing Rules
9
+
10
+ ## Test-Driven Development (TDD)
11
+
12
+ Follow the Red-Green-Refactor cycle:
13
+ 1. **RED**: Write a failing test that defines expected behavior
14
+ 2. **GREEN**: Write minimum code to make the test pass
15
+ 3. **REFACTOR**: Clean up code while keeping tests green
16
+
17
+ ## Test Organization
18
+
19
+ ### File Structure
20
+ - Test files should mirror source structure
21
+ - Name test files as `{source-file}.test.ts`
22
+ - Group tests in `__tests__` directories or alongside source files
23
+
24
+ ### Test Structure
25
+ ```typescript
26
+ describe('ComponentName', () => {
27
+ describe('methodName', () => {
28
+ it('should describe expected behavior', () => {
29
+ // Arrange - Set up test data
30
+ // Act - Execute the code
31
+ // Assert - Verify results
32
+ });
33
+ });
34
+ });
35
+ ```
36
+
37
+ ## Test Quality
38
+
39
+ ### Test Naming
40
+ - Use descriptive names that explain the scenario
41
+ - Pattern: `should {expected behavior} when {condition}`
42
+ - Examples:
43
+ - `should return empty array when directory is empty`
44
+ - `should throw error for invalid input`
45
+
46
+ ### Test Independence
47
+ - Each test should be independent and isolated
48
+ - Use `beforeEach` to reset state between tests
49
+ - Never rely on test execution order
50
+
51
+ ### Assertions
52
+ - One logical assertion per test (can have multiple `expect` calls)
53
+ - Test behavior, not implementation
54
+ - Include both positive and negative test cases
55
+
56
+ ## Coverage Requirements
57
+
58
+ ### Minimum Coverage
59
+ - Aim for 80% code coverage for new code
60
+ - Critical paths require 100% coverage
61
+ - Cover edge cases and error conditions
62
+
63
+ ### What to Test
64
+ - Public API methods
65
+ - Edge cases and boundary conditions
66
+ - Error handling paths
67
+ - Integration points
68
+
69
+ ### What Not to Test
70
+ - Third-party library internals
71
+ - Simple getters/setters without logic
72
+ - Framework-generated code
73
+
74
+ ## Mocking
75
+
76
+ ### When to Mock
77
+ - External services and APIs
78
+ - File system operations
79
+ - Network requests
80
+ - Time-dependent code
81
+
82
+ ### Mock Best Practices
83
+ - Mock at the boundary, not internal implementation
84
+ - Verify mock interactions when relevant
85
+ - Reset mocks in `beforeEach`
package/sdd-entry.js CHANGED
@@ -12,7 +12,7 @@
12
12
  * npx sdd-mcp-server # MCP: Start MCP server
13
13
  */
14
14
 
15
- const CLI_COMMANDS = ['install', 'install-skills', 'migrate-kiro'];
15
+ const CLI_COMMANDS = ['install', 'install-skills', 'migrate-kiro', 'migrate-steering'];
16
16
  const args = process.argv.slice(2);
17
17
  const command = args[0];
18
18
 
package/skills/sdd-commit/SKILL.md CHANGED
@@ -271,20 +271,6 @@ git rebase origin/main
271
271
  git push origin feature/AUTH-123-jwt-auth
272
272
  ```
273
273
 
274
- ## Steering Document References
275
-
276
- Apply these steering documents for commits and PRs:
277
-
278
- | Document | Purpose | Key Application |
279
- |----------|---------|-----------------|
280
- | `.spec/steering/commit.md` | Commit message conventions | Follow type prefixes, scope, and format guidelines |
281
-
282
- **Key Commit Rules:**
283
- 1. Use type prefixes: `feat`, `fix`, `docs`, `refactor`, `test`, etc.
284
- 2. Keep subject line under 72 characters
285
- 3. Use imperative mood ("add" not "added")
286
- 4. Reference issues in footer
287
-
288
274
  ## Quality Checklist
289
275
 
290
276
  - [ ] Commit message follows format
package/steering/product.md ADDED
@@ -0,0 +1,29 @@
1
+ # Product Overview
2
+
3
+ ## Product Description
4
+ <!-- Describe your product/project in 1-2 sentences -->
5
+
6
+ **Project**: <!-- project name -->
7
+ **Version**: <!-- current version -->
8
+ **Type**: <!-- Web App, CLI Tool, Library, API, etc. -->
9
+
10
+ ## Core Features
11
+ <!-- List the main features of your product -->
12
+ - Feature 1
13
+ - Feature 2
14
+ - Feature 3
15
+
16
+ ## Target Use Case
17
+ <!-- Describe the primary use case this product solves -->
18
+
19
+ ## Key Value Proposition
20
+ <!-- What makes this product valuable? What problems does it solve? -->
21
+
22
+ ## Target Users
23
+ <!-- Who are the primary users of this product? -->
24
+
25
+ ## Success Metrics
26
+ <!-- How do you measure success for this product? -->
27
+
28
+ ## Technical Advantages
29
+ <!-- What technical benefits does this architecture provide? -->
package/steering/structure.md ADDED
@@ -0,0 +1,60 @@
1
+ # Project Structure
2
+
3
+ ## Directory Organization
4
+ ```
5
+ ├── src/ # Source code
6
+ │ ├── components/ # UI components (if applicable)
7
+ │ ├── services/ # Business logic services
8
+ │ ├── models/ # Data models
9
+ │ ├── utils/ # Utility functions
10
+ │ └── index.ts # Entry point
11
+ ├── tests/ # Test files
12
+ │ ├── unit/ # Unit tests
13
+ │ └── integration/ # Integration tests
14
+ ├── dist/ # Build output
15
+ ├── docs/ # Documentation
16
+ ├── .spec/ # SDD workflow files
17
+ │ ├── steering/ # Project steering documents
18
+ │ └── specs/ # Feature specifications
19
+ ├── package.json # Project configuration
20
+ ├── tsconfig.json # TypeScript configuration (if applicable)
21
+ └── README.md # Project documentation
22
+ ```
23
+
24
+ ## Key Directories
25
+ - **src/**: Main source code directory
26
+ - **tests/**: Test files organized by type
27
+ - **dist/**: Compiled/built output for production
28
+ - **docs/**: Project documentation
29
+
30
+ ## Code Organization Patterns
31
+ <!-- Describe how code is organized -->
32
+ - Pattern 1
33
+ - Pattern 2
34
+
35
+ ## File Naming Conventions
36
+ <!-- Define naming conventions for different file types -->
37
+ - **Source files**: <!-- e.g., kebab-case.ts -->
38
+ - **Test files**: <!-- e.g., *.test.ts or *.spec.ts -->
39
+ - **Configuration**: <!-- e.g., .json or .config.js -->
40
+ - **Constants**: UPPER_SNAKE_CASE
41
+ - **Functions/Variables**: camelCase
42
+ - **Classes/Types**: PascalCase
43
+
44
+ ## Module Organization
45
+ <!-- Describe how modules are organized -->
46
+
47
+ ## Architectural Principles
48
+ - **Separation of Concerns**: Each module handles a specific responsibility
49
+ - **Type Safety**: Use strong typing where applicable
50
+ - **Dependency Inversion**: Depend on abstractions, not concrete implementations
51
+
52
+ ## Testing Structure
53
+ - **Unit tests**: Test individual functions/components in isolation
54
+ - **Integration tests**: Test interactions between modules
55
+ - **E2E tests**: Test complete user workflows
56
+
57
+ ## Build Output
58
+ - **Command**: <!-- e.g., npm run build -->
59
+ - **Output directory**: <!-- e.g., dist/ -->
60
+ - **Artifacts**: <!-- What gets generated -->
package/steering/tech.md ADDED
@@ -0,0 +1,52 @@
1
+ # Technology Stack
2
+
3
+ ## Architecture
4
+ **Type**: <!-- MVC, DDD, Clean Architecture, Microservices, etc. -->
5
+ **Language**: <!-- Primary language -->
6
+ **Module System**: <!-- CommonJS, ES Module, etc. -->
7
+ **Framework**: <!-- Main framework if any -->
8
+ **Build Tool**: <!-- Webpack, Vite, TypeScript Compiler, etc. -->
9
+
10
+ ## Core Technologies
11
+ <!-- List main technologies used -->
12
+ - **Runtime**: <!-- Node.js, Python, Go, etc. -->
13
+ - **Language**: <!-- TypeScript, JavaScript, Python, etc. -->
14
+ - **Framework**: <!-- Express, FastAPI, Spring Boot, etc. -->
15
+ - **Testing**: <!-- Jest, pytest, JUnit, etc. -->
16
+
17
+ ## Development Environment
18
+ - **Runtime Version**: <!-- e.g., Node.js >=18.0.0 -->
19
+ - **Package Manager**: <!-- npm, yarn, pip, etc. -->
20
+ - **Testing Framework**: <!-- Jest, pytest, etc. -->
21
+
22
+ ## Dependencies
23
+ ### Production Dependencies
24
+ <!-- List key production dependencies -->
25
+
26
+ ### Development Dependencies
27
+ <!-- List key development dependencies -->
28
+
29
+ ## Development Commands
30
+ ```bash
31
+ # Start development server
32
+ npm run dev
33
+
34
+ # Build for production
35
+ npm run build
36
+
37
+ # Run tests
38
+ npm run test
39
+
40
+ # Lint code
41
+ npm run lint
42
+ ```
43
+
44
+ ## Quality Assurance
45
+ - **Linting**: <!-- ESLint, Pylint, etc. -->
46
+ - **Type Checking**: <!-- TypeScript, mypy, etc. -->
47
+ - **Testing**: <!-- Coverage requirements, test types -->
48
+
49
+ ## Deployment Configuration
50
+ - **Containerization**: <!-- Docker, Kubernetes, etc. -->
51
+ - **Build Process**: <!-- How to build for production -->
52
+ - **CI/CD**: <!-- GitHub Actions, GitLab CI, etc. -->