sdd-mcp-server 3.5.0 → 4.0.0

package/skills/sdd-review/SKILL.md

@@ -1,195 +1,31 @@
 ---
 name: sdd-review
-description: Perform thorough Linus-style code review focusing on correctness, maintainability, and adherence to project conventions. Use after completing implementation to ensure code quality. Invoked via /sdd-review [file-path or PR-number].
+description: Review a focused change for correctness, regressions, security, and maintainability.
+disable-model-invocation: true
 ---
 
-# SDD Code Review
+# Code Review
 
-Perform comprehensive code reviews in the style of Linus Torvalds - direct, thorough, and focused on what matters: correctness, simplicity, and long-term maintainability.
+## Required Review
 
-## Review Philosophy
+1. Establish the exact diff or artifact scope. Read related requirements, design, tests, and local conventions.
+2. Verify behavior and error paths from code and focused test evidence; do not infer correctness from style.
+3. Review data flow, state transitions, concurrency, resource ownership, compatibility, and boundary conditions.
+4. Check authorization, validation, injection, secret handling, sensitive logging, and dependency risk where applicable.
+5. Remove false positives and preference-only remarks. Cite each finding with a path and line, triggering scenario, impact, and concrete remediation.
+6. Rank findings: **critical** (security/data loss), **important** (incorrect behavior/regression), then **minor** (maintainability with real cost).
+7. State verification evidence and residual risk. If no findings remain, say so explicitly.
 
-> "Talk is cheap. Show me the code."
-> — Linus Torvalds
-
-This review focuses on:
-1. **Correctness** - Does it actually work? Does it handle edge cases?
-2. **Simplicity** - Is it more complex than necessary?
-3. **Maintainability** - Will future developers understand this?
-4. **Convention Adherence** - Does it follow project patterns?
-
-## Workflow
-
-### Step 1: Identify Review Scope
-
-Determine what to review:
-- **Single file**: `/sdd-review src/services/UserService.ts`
-- **Directory**: `/sdd-review src/services/`
-- **Git diff**: `/sdd-review HEAD~3..HEAD`
-- **PR/MR**: `/sdd-review PR-123` or `/sdd-review MR-45`
-
-### Step 2: Load Project Context
-
-Before reviewing:
-1. Read project steering documents from `.spec/steering/`
-2. Understand existing patterns in the codebase
-3. Check if there's a related spec in `.spec/specs/`
-
-### Step 3: Perform Review
-
-#### Code Correctness Checks
-
-```markdown
-## Correctness Issues
-
-### Critical
-- [ ] Logic errors that will cause bugs
-- [ ] Race conditions or threading issues
-- [ ] Resource leaks (files, connections, memory)
-- [ ] Unhandled error conditions
-
-### Important
-- [ ] Edge cases not handled
-- [ ] Assumptions that may not hold
-- [ ] Off-by-one errors
-- [ ] Type mismatches or unsafe casts
-```
+Do not edit code unless asked. Never claim a test or security check ran when it did not.
 
 ## Specialist Delegation
 
-When the host supports subagents, delegate the focused review to the `reviewer` role with a compact handoff containing only the diff or scope, approved requirements, project conventions, and verification evidence. 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.
-
-#### Simplicity Assessment
-
-Ask these questions:
-- Could this be done with less code?
-- Is there a standard library function for this?
-- Is this abstraction earning its keep?
-- Would a junior developer understand this in 6 months?
-
-#### Pattern Violations
-
-Check against project conventions:
-```markdown
-## Pattern Violations
-
-### Naming
-- [ ] Variables don't follow naming convention
-- [ ] Functions named for implementation, not purpose
-
-### Structure
-- [ ] Logic in wrong layer (controller doing business logic)
-- [ ] Missing separation of concerns
-- [ ] Circular dependencies introduced
-
-### Error Handling
-- [ ] Swallowed exceptions
-- [ ] Generic error messages
-- [ ] Missing error propagation
-```
-
-### Step 4: Provide Feedback
-
-Structure feedback with clear categories:
-
-```markdown
-# Code Review: {file/PR description}
-
-## Summary
-Brief overall assessment (1-2 sentences)
-
-## 🚨 Must Fix (Blocking)
-Issues that must be resolved before merge:
-1. **Line 42**: Memory leak - connection never closed
-   ```diff
-   - const conn = await getConnection();
-   + const conn = await getConnection();
-   + try { ... } finally { conn.close(); }
-   ```
-
-## ⚠️ Should Fix (Non-blocking)
-Issues that should be addressed but won't block:
-1. **Line 78**: Magic number should be a named constant
-2. **Line 103**: Consider extracting this to a helper function
-
-## 💡 Suggestions (Optional)
-Improvements that would be nice but are truly optional:
-1. **Line 156**: This could be simplified with `Array.flatMap()`
-
-## ✅ What's Good
-Acknowledge good patterns to reinforce them:
-1. Good use of dependency injection
-2. Clear separation of concerns
-3. Comprehensive error handling in auth module
-```
-
-### Step 5: Verify Tests
-
-For any code changes:
-1. Check if tests exist for modified code
-2. Verify edge cases are tested
-3. Run existing tests to ensure no regressions
-
-```bash
-# Run tests for affected files
-npm test -- --findRelatedTests {changed-files}
-```
-
-## Review Severity Levels
-
-| Level | Meaning | Action Required |
-|-------|---------|-----------------|
-| 🚨 **Critical** | Bug, security issue, data loss risk | Must fix before merge |
-| ⚠️ **Warning** | Code smell, potential issue | Should fix, discuss if disagree |
-| 💡 **Info** | Suggestion, style preference | Optional, author's choice |
-
-## Common Issues to Watch For
-
-### TypeScript/JavaScript Specific
-- `any` type usage without justification
-- Missing null/undefined checks
-- Promises not awaited
-- Event listener memory leaks
-- Mutable shared state
-
-### General
-- Functions doing too much
-- Deep nesting (> 3 levels)
-- Boolean parameters (use options object)
-- Comments explaining *what* instead of *why*
-- Dead code or unused imports
-
-## Integration with SDD Workflow
-
-When reviewing implementation:
-1. Compare against requirements in `.spec/specs/{feature}/requirements.md`
-2. Verify design patterns from `.spec/specs/{feature}/design.md`
-3. Check task completion against `.spec/specs/{feature}/tasks.md`
-
-## Example Review
-
-```markdown
-# Code Review: UserAuthService.ts
-
-## Summary
-Good overall structure but has a critical security issue and some error handling gaps.
+Target renderers provide the `reviewer` route. When a native advisor is required, dispatch exactly one compact handoff with `specialistDepth: 1`; include only the diff/scope, approved contracts, conventions, and verification evidence. The specialist must not delegate again. Keep the handoff and returned summary at or below 2,048 estimated tokens. If the advisor or routed model is unavailable, record one fallback and continue in the parent without retrying or selecting a generic child. Where a native per-turn model override applies, execute in this turn.
 
-## 🚨 Must Fix
-1. **Line 67**: Password stored in plain text in error log
-   ```typescript
-   // BAD: Leaks credentials
-   logger.error(`Login failed for ${email} with password ${password}`);
+## Output
 
-   // GOOD: Never log credentials
-   logger.error(`Login failed for ${email}`);
-   ```
+Return findings first, ordered by severity, then assumptions, verification evidence, and unresolved blockers. Do not echo the reviewed artifact.
 
-## ⚠️ Should Fix
-1. **Line 89**: Catch block swallows all errors
-2. **Line 112-130**: This block should be extracted to a private method
+## Optional Reference
 
-## ✅ What's Good
-- Clean separation between auth logic and data access
-- Good use of TypeScript discriminated unions for auth result
-- Comprehensive input validation
-```
+Read [REFERENCE.md](REFERENCE.md) only for language-specific review prompts, severity examples, or the extended checklist.

package/skills/sdd-security-check/REFERENCE.md

@@ -0,0 +1,19 @@
+# Security Audit Reference
+
+Read only for the branch being audited.
+
+## OWASP Prompts
+
+- Access control: object ownership, function-level checks, tenant isolation, deny-by-default paths.
+- Cryptography: approved primitives, key lifecycle, transport/storage protection, password hashing.
+- Injection: query parameters, process arguments, templates, headers, paths, deserialization.
+- Design: abuse cases, rate limits, replay/idempotency, resource exhaustion.
+- Configuration: debug/default settings, CORS, headers, unnecessary capabilities.
+- Components/integrity: vulnerable dependencies, lockfiles, update/build provenance.
+- Authentication: session fixation, credential recovery, MFA/rate-limit requirements.
+- Logging: security events without credentials, tokens, personal or regulated data.
+- SSRF: URL parsing, redirects, DNS rebinding, private-address blocking, allowlists.
+
+## Finding Checklist
+
+A finding names the threat actor, preconditions, source-to-sink path, affected asset, impact, severity rationale, location, remediation, and regression test. Redact secrets. Separate confirmed vulnerabilities from hardening opportunities and tool warnings. If a control is outside scope, record it as unverified rather than absent.

package/skills/sdd-security-check/SKILL.md

@@ -1,197 +1,31 @@
 ---
 name: sdd-security-check
-description: Perform OWASP-aligned security audit of code. Checks for common vulnerabilities including injection, authentication flaws, sensitive data exposure, and more. Invoked via /sdd-security-check [file-path or scope].
+description: Audit a focused scope for exploitable security flaws and prioritized remediation.
+disable-model-invocation: true
 ---
 
-# SDD Security Check
+# Security Audit
 
-Perform comprehensive security audits aligned with OWASP Top 10 and security best practices. Identify vulnerabilities before they reach production.
+## Required Audit
 
-## Security Philosophy
+1. Define trust boundaries, assets, actors, entry points, data sensitivity, and the exact review scope.
+2. Trace untrusted input through validation, authorization, storage, commands, queries, templates, URLs, and output.
+3. Check relevant OWASP risks: access control, cryptography, injection, insecure design, misconfiguration, vulnerable components, authentication, integrity, logging, and SSRF.
+4. Search for embedded secrets and unsafe sensitive-data logging. Never print a discovered secret; redact it and identify only its location/type.
+5. Inspect dependency and automated scan results only when the project provides safe focused commands; distinguish tool evidence from manual review.
+6. For each finding, prove the path to impact, assign severity, cite location, and give a minimal remediation plus a regression test.
+7. Compare implementation with security requirements and design controls. Record coverage gaps and residual risk.
 
-Security is not a feature—it's a requirement. Every code change should be reviewed through a security lens.
+Do not make destructive probes, contact external systems, or claim exploitability without evidence.
 
-## OWASP Top 10 Checks (2021)
-
-### A01: Broken Access Control
-
-Check for:
-- Missing authorization checks on endpoints
-- Insecure Direct Object References (IDOR)
-- Missing function-level access control
-- CORS misconfiguration
-- JWT validation bypass
-
-**Pattern**: Ensure every endpoint has explicit authorization checks.
-
-### A02: Cryptographic Failures
-
-Check for:
-- Sensitive data transmitted without TLS
-- Weak or deprecated algorithms (MD5, SHA1, DES)
-- Hardcoded secrets or API keys
-- Insufficient key length
-- Missing encryption at rest
-
-**Pattern**: Use strong algorithms (bcrypt for passwords, AES-256 for data).
-
-### A03: Injection
-
-Check for:
-- SQL injection (use parameterized queries)
-- NoSQL injection (validate/sanitize inputs)
-- Command injection (use execFile with array args, not string interpolation)
-- LDAP injection
-- Template injection
-
-**Pattern**: Never interpolate user input into queries or commands.
-
-### A04: Insecure Design
-
-Check for:
-- Missing rate limiting
-- No brute force protection
-- Predictable resource IDs
-- Missing threat modeling
-
-### A05: Security Misconfiguration
-
-Check for:
-- Debug mode in production
-- Default credentials
-- Unnecessary features enabled
-- Missing security headers
-- Verbose error messages in production
-
-**Required Headers**: CSP, X-Frame-Options, X-Content-Type-Options, HSTS
-
-### A06: Vulnerable Components
-
-- Check dependencies with `npm audit`
-- Review for known CVEs
-- Verify component versions
-
-### A07: Authentication Failures
-
-Check for:
-- Weak password requirements
-- Missing MFA where required
-- Session fixation vulnerabilities
-- Credential stuffing exposure
-- Insecure password recovery
-
-**Session Config**: secure=true, httpOnly=true, sameSite='strict'
-
-### A08: Software and Data Integrity Failures
-
-Check for:
-- Missing integrity verification on downloads
-- Insecure CI/CD pipeline
-- Unsigned code or packages
-- Auto-update without verification
-
-### A09: Security Logging and Monitoring Failures
-
-Check for:
-- No logging of security events
-- Sensitive data in logs (never log passwords!)
-- Missing audit trail
-- Logs not protected from tampering
-
-**Required Events**: Auth attempts, auth failures, admin actions, data access anomalies
-
-### A10: Server-Side Request Forgery (SSRF)
-
-Check for:
-- User-controlled URLs in server requests
-- Missing URL validation
-- Internal network access possible
-
-**Pattern**: Use URL allowlists for server-side requests.
-
-## Security Check Workflow
-
-### Step 1: Define Scope
-
-```
-/sdd-security-check src/api/        # Check API layer
-/sdd-security-check src/auth/       # Focus on authentication
-/sdd-security-check HEAD~5..HEAD    # Check recent changes
-```
-
-### Step 2: Automated Scans
-
-Run these checks:
-```bash
-# Dependency vulnerabilities
-npm audit
-
-# Secret detection
-npx gitleaks detect
-
-# SAST scan if configured
-npx semgrep --config=p/security-audit
-```
-
-### Step 3: Manual Review
-
-For each file, check:
-1. Input validation
-2. Output encoding
-3. Authentication/Authorization
-4. Data handling
-5. Error handling
-6. Logging practices
-
-### Step 4: Generate Report
-
-```markdown
-# Security Audit Report: {scope}
-
-## Summary
-- 🔴 Critical: {count}
-- 🟠 High: {count}
-- 🟡 Medium: {count}
-- 🟢 Low: {count}
-
-## Critical Findings
-
-### SEC-001: {Finding Title}
-**Location**: {file:line}
-**Risk**: Critical
-**OWASP**: {category}
-
-**Issue**: {description}
-**Recommendation**: {fix}
-
-## Remediation Priority
-1. Critical findings - Fix immediately
-2. High findings - Fix before deployment
-3. Medium findings - Fix this sprint
-4. Low findings - Track and schedule
-```
-
-## Quick Security Checklist
+## Specialist Delegation
 
-Before any deployment:
-- [ ] No hardcoded secrets in code
-- [ ] All inputs validated and sanitized
-- [ ] All outputs properly encoded
-- [ ] Authentication on all protected routes
-- [ ] Authorization checks at function level
-- [ ] Security headers configured
-- [ ] Dependencies scanned for vulnerabilities
-- [ ] Error messages don't leak sensitive info
-- [ ] Security events are logged
-- [ ] Rate limiting in place
+Target renderers provide the `security-auditor` route. When a native advisor is required, dispatch exactly one compact handoff with `specialistDepth: 1`; include only threat context, relevant diff, security requirements, and scan evidence. The specialist must not delegate again. Keep the handoff and returned summary at or below 2,048 estimated tokens. If the advisor or routed model is unavailable, record one fallback and continue in the parent without retrying or selecting a generic child. Where a native per-turn model override applies, execute in this turn.
 
-## Integration with SDD Workflow
+## Output
 
-When checking implementation against spec:
-1. Verify security NFRs from requirements.md are met
-2. Check security considerations from design.md are implemented
-3. Ensure security-related tasks in tasks.md are complete
+Return findings ordered critical/high/medium/low, each with evidence, impact, remediation, and verification. Then list checked areas, unresolved blockers, and residual risk.
 
-## Specialist Delegation
+## Optional Reference
 
-When the host supports subagents, delegate the audit to the `security-auditor` role with a compact handoff containing only the review scope, threat context, security requirements, and relevant diff. 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 OWASP prompts, severity guidance, or the report checklist.

package/skills/sdd-steering/REFERENCE.md

@@ -0,0 +1,25 @@
+# Steering Reference
+
+Read only when creating a missing section.
+
+## Product
+
+Record verified purpose, primary users, core capabilities, explicit boundaries, and success measures. Avoid roadmap promises and marketing prose.
+
+## Technology
+
+Record runtime/language versions, package manager, frameworks, important dependencies, architecture boundaries, persistence/integration choices, and commands proven by manifests or configuration. Label inferred architecture as such.
+
+## Structure
+
+Record responsibilities of top-level directories, source/test locations, naming and import conventions observed repeatedly, public boundaries, generated artifacts, and placement rules for new work.
+
+## Validation Checklist
+
+- each fact cites a repository source or is labeled unknown;
+- commands and paths exist and use current names;
+- existing user guidance remains intact unless directly updated;
+- no credential, endpoint secret, personal data, or machine-specific value appears;
+- guidance describes this project rather than generic best practices;
+- conflicts between documentation and code are reported instead of silently resolved;
+- update mode changes only sections supported by new evidence.