sdd-mcp-server 3.0.1 → 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.
- package/README.md +117 -98
- package/agents/architect.md +107 -0
- package/agents/implementer.md +154 -0
- package/agents/planner.md +97 -0
- package/agents/reviewer.md +252 -0
- package/agents/security-auditor.md +127 -0
- package/agents/tdd-guide.md +241 -0
- package/contexts/dev.md +58 -0
- package/contexts/planning.md +79 -0
- package/contexts/research.md +93 -0
- package/contexts/review.md +73 -0
- package/contexts/security-audit.md +92 -0
- package/dist/cli/install-skills.js +29 -15
- package/dist/cli/install-skills.js.map +1 -1
- package/dist/cli/migrate-steering.d.ts +24 -0
- package/dist/cli/migrate-steering.js +308 -0
- package/dist/cli/migrate-steering.js.map +1 -0
- package/dist/cli/sdd-mcp-cli.js +9 -0
- package/dist/cli/sdd-mcp-cli.js.map +1 -1
- package/hooks/post-tool-use/log-tool-execution.md +51 -0
- package/hooks/post-tool-use/update-spec-status.md +50 -0
- package/hooks/pre-tool-use/check-test-coverage.md +51 -0
- package/hooks/pre-tool-use/validate-sdd-workflow.md +55 -0
- package/hooks/session-end/remind-uncommitted-changes.md +58 -0
- package/hooks/session-end/save-session-summary.md +72 -0
- package/hooks/session-start/load-project-context.md +62 -0
- package/package.json +5 -1
- package/rules/coding-style.md +97 -0
- package/rules/error-handling.md +134 -0
- package/rules/git-workflow.md +92 -0
- package/rules/sdd-workflow.md +116 -0
- package/rules/security.md +89 -0
- package/rules/testing.md +85 -0
- package/sdd-entry.js +1 -1
- package/skills/sdd-commit/SKILL.md +0 -14
- package/steering/product.md +29 -0
- package/steering/structure.md +60 -0
- package/steering/tech.md +52 -0
- package/steering/AGENTS.md +0 -281
- package/steering/commit.md +0 -59
- package/steering/linus-review.md +0 -153
- package/steering/owasp-top10-check.md +0 -49
- package/steering/principles.md +0 -639
- package/steering/tdd-guideline.md +0 -324
package/README.md
CHANGED
|
@@ -6,27 +6,7 @@
|
|
|
6
6
|
|
|
7
7
|
A Model Context Protocol (MCP) server implementing Spec-Driven Development (SDD) workflows for AI-agent CLIs and IDEs like Claude Code, Cursor, and others.
|
|
8
8
|
|
|
9
|
-
>
|
|
10
|
-
|
|
11
|
-
> 🔧 **v2.2.1 - CLI Fix**: Fixed `npx sdd-mcp` not working due to npm package name collision. Now use `npx sdd-mcp-server` for all CLI commands. The unified entry point handles both CLI commands and MCP server mode.
|
|
12
|
-
|
|
13
|
-
> 🎯 **v2.2.0 - Unified Installation & Crash Safety**: `npx sdd-mcp-server install` command installs both skills (to `.claude/skills/`) AND steering documents (to `.spec/steering/`) in one step! Skills now explicitly reference their relevant steering documents for better guidance. Also includes **atomic file writes** for spec.json crash safety - files are never left in a corrupted state even if the process is interrupted. (Thanks to @Lucas Wang for the atomic writes contribution!)
|
|
14
|
-
|
|
15
|
-
> 🔄 **v2.1.0 - Directory Migration**: The SDD specification directory has been renamed from `.kiro` to `.spec`. Use `npx sdd-mcp-server migrate-kiro` to migrate existing projects. Legacy `.kiro` directories are still supported for backwards compatibility.
|
|
16
|
-
|
|
17
|
-
> 🔧 **v2.0.3 - CLI Subcommand Support**: `npx sdd-mcp-server install-skills` now works correctly! Created proper CLI entry point with subcommand support.
|
|
18
|
-
|
|
19
|
-
> 🚀 **v2.0.0 - Hybrid MCP + Agent Skills Architecture**: Restructured for token efficiency! Template/guidance tools (requirements, design, tasks, steering, implement) are now **Claude Code Agent Skills** loaded on-demand. Action-oriented tools remain as MCP tools. ~55% token savings in typical operations.
|
|
20
|
-
|
|
21
|
-
> 🤖 **v1.8.0 - MCP Tool Standardization**: Updated `AGENTS.md` generation to use standard MCP tool calls (e.g., `sdd-init`) instead of legacy slash commands. Fixed `sdd-steering` to correctly generate `AGENTS.md` with the new format. Ensures consistent tool usage across all AI agents.
|
|
22
|
-
|
|
23
|
-
> 🔧 **v1.6.2 - Module Loading Fix**: Fixed critical bug where `sdd-steering` generated generic templates instead of analyzing actual codebases when run via `npx`. Root cause: hardcoded import paths didn't account for different execution contexts. Solution: Unified module loading system with **4-path fallback resolution** handling npm start, npm dev, node dist/index.js, and npx contexts. Comprehensive error handling with all attempted paths in error messages. Debug logging for troubleshooting. **100% test coverage** (71 tests passing, 6 new moduleLoader tests). Code review score: **9/10 (Excellent)** ✅. Production-ready with zero security issues!
|
|
24
|
-
|
|
25
|
-
> 🚀 **v1.6.0 - Architecture Refactoring**: Decomposed requirements clarification into **5 focused services** following Single Responsibility Principle! Each service now has one clear purpose: `SteeringContextLoader` (I/O), `DescriptionAnalyzer` (scored semantic detection 0-100), `QuestionGenerator` (template-based), `AnswerValidator` (validation + security), `DescriptionEnricher` (5W1H synthesis). Replaced brittle boolean regex with **scored semantic detection** for better accuracy. Externalized question templates to configuration. **62 new unit tests** (65 total passing) ✅. Services average ~100 LOC vs previous 500 LOC monolith. Better maintainability, testability, and type safety!
|
|
26
|
-
|
|
27
|
-
> 🎯 **v1.5.0 - Interactive Requirements Clarification**: `sdd-init` now **blocks vague requirements**! The agent analyzes your project description (quality score 0-100) and interactively asks targeted clarification questions if score < 70%. Focuses on **WHY** (business justification), WHO (target users), WHAT (core features), and success criteria. Context-aware using existing steering docs. Prevents "garbage in, garbage out" with enriched 5W1H structured descriptions.
|
|
28
|
-
|
|
29
|
-
> ✅ **v1.4.5**: Internal improvements! Reorganized test structure for better maintainability, centralized static steering document creation following DRY principle, improved code organization with better separation of concerns.
|
|
9
|
+
> **v3.1** - Steering consolidation: Static guidance merged into agents/rules/skills. Now with `migrate-steering` CLI command. See [CHANGELOG.md](CHANGELOG.md) for full version history.
|
|
30
10
|
|
|
31
11
|
## 🚀 Quick Start
|
|
32
12
|
|
|
@@ -198,12 +178,92 @@ npx sdd-mcp-server install-skills
|
|
|
198
178
|
| Component | Install Path | Purpose |
|
|
199
179
|
|-----------|--------------|---------|
|
|
200
180
|
| **Skills** | `.claude/skills/` | Workflow guidance (requirements, design, tasks, implement, etc.) |
|
|
201
|
-
| **Steering** | `.spec/steering/` | Project-
|
|
181
|
+
| **Steering** | `.spec/steering/` | Project-specific templates (product, tech, structure) |
|
|
202
182
|
| **Rules** | `.claude/rules/` | Always-active guidelines (coding-style, testing, security, git-workflow) |
|
|
203
183
|
| **Contexts** | `.claude/contexts/` | Mode-specific prompts (dev, review, planning, security-audit, research) |
|
|
204
184
|
| **Agents** | `.claude/agents/` | Specialized AI personas (planner, architect, reviewer, implementer) |
|
|
205
185
|
| **Hooks** | `.claude/hooks/` | Event-driven automation (pre-tool-use, post-tool-use, session events) |
|
|
206
186
|
|
|
187
|
+
### Component Architecture & Relationships
|
|
188
|
+
|
|
189
|
+
The 6 component types work together in a **layered guidance model**:
|
|
190
|
+
|
|
191
|
+
```
|
|
192
|
+
┌──────────────────────────────────────────────────────────────┐
|
|
193
|
+
│ User Request │
|
|
194
|
+
└──────────────────────────────────────────────────────────────┘
|
|
195
|
+
│
|
|
196
|
+
▼
|
|
197
|
+
┌──────────────────────────────────────────────────────────────┐
|
|
198
|
+
│ HOOKS (pre-tool-use) │
|
|
199
|
+
│ • Validate workflow order (e.g., requirements before design)│
|
|
200
|
+
│ • Check test coverage before implementation │
|
|
201
|
+
│ • Triggered automatically on events │
|
|
202
|
+
└──────────────────────────────────────────────────────────────┘
|
|
203
|
+
│
|
|
204
|
+
▼
|
|
205
|
+
┌──────────────────────────────────────────────────────────────┐
|
|
206
|
+
│ RULES (always active) │
|
|
207
|
+
│ • coding-style.md → TypeScript/JS conventions │
|
|
208
|
+
│ • testing.md → TDD requirements │
|
|
209
|
+
│ • security.md → OWASP guidelines │
|
|
210
|
+
│ • Loaded at session start, apply to ALL operations │
|
|
211
|
+
└──────────────────────────────────────────────────────────────┘
|
|
212
|
+
│
|
|
213
|
+
▼
|
|
214
|
+
┌──────────────────────────────────────────────────────────────┐
|
|
215
|
+
│ CONTEXTS (mode-specific) │
|
|
216
|
+
│ • dev.md → Implementation focus │
|
|
217
|
+
│ • review.md → Quality focus │
|
|
218
|
+
│ • planning.md → Architecture focus │
|
|
219
|
+
│ • Activated based on current task type │
|
|
220
|
+
└──────────────────────────────────────────────────────────────┘
|
|
221
|
+
│
|
|
222
|
+
▼
|
|
223
|
+
┌──────────────────────────────────────────────────────────────┐
|
|
224
|
+
│ AGENTS (specialized personas) │
|
|
225
|
+
│ • reviewer.md → Linus-style code review │
|
|
226
|
+
│ • architect.md → System design expertise │
|
|
227
|
+
│ • implementer.md → TDD implementation │
|
|
228
|
+
│ • Invoked for specific expertise needs │
|
|
229
|
+
└──────────────────────────────────────────────────────────────┘
|
|
230
|
+
│
|
|
231
|
+
▼
|
|
232
|
+
┌──────────────────────────────────────────────────────────────┐
|
|
233
|
+
│ SKILLS (on-demand workflows) │
|
|
234
|
+
│ • /sdd-requirements → EARS requirements template │
|
|
235
|
+
│ • /sdd-design → Architecture design template │
|
|
236
|
+
│ • /sdd-implement → Implementation checklist │
|
|
237
|
+
│ • User-invoked via slash commands │
|
|
238
|
+
└──────────────────────────────────────────────────────────────┘
|
|
239
|
+
│
|
|
240
|
+
▼
|
|
241
|
+
┌──────────────────────────────────────────────────────────────┐
|
|
242
|
+
│ STEERING (project-specific templates - v3.1+) │
|
|
243
|
+
│ • product.md → Product description │
|
|
244
|
+
│ • tech.md → Technology stack │
|
|
245
|
+
│ • structure.md → Project structure │
|
|
246
|
+
│ • (Static guidance now in agents/rules/skills) │
|
|
247
|
+
└──────────────────────────────────────────────────────────────┘
|
|
248
|
+
│
|
|
249
|
+
▼
|
|
250
|
+
┌──────────────────────────────────────────────────────────────┐
|
|
251
|
+
│ MCP TOOLS (actions) │
|
|
252
|
+
│ • sdd-init, sdd-approve, sdd-status, sdd-spec-impl │
|
|
253
|
+
│ • Execute actual operations │
|
|
254
|
+
└──────────────────────────────────────────────────────────────┘
|
|
255
|
+
```
|
|
256
|
+
|
|
257
|
+
**When Each Component Activates:**
|
|
258
|
+
| Component | Activation | Example |
|
|
259
|
+
|-----------|------------|---------|
|
|
260
|
+
| **Rules** | Session start (always) | `coding-style.md` enforces conventions on every response |
|
|
261
|
+
| **Contexts** | Task type detection | `review.md` activates when reviewing code |
|
|
262
|
+
| **Agents** | Explicit invocation | `reviewer.md` invoked by `/sdd-review` skill |
|
|
263
|
+
| **Skills** | User command (`/skill-name`) | `/sdd-requirements` loads requirements template |
|
|
264
|
+
| **Steering** | Project customization | `/sdd-steering` generates `product.md`, `tech.md` |
|
|
265
|
+
| **Hooks** | Events (pre/post tool, session) | `validate-sdd-workflow` runs before `sdd-design` |
|
|
266
|
+
|
|
207
267
|
### Migrating from .kiro to .spec (v2.1.0+)
|
|
208
268
|
|
|
209
269
|
If you have existing projects using the legacy `.kiro` directory, migrate to the new `.spec` standard:
|
|
@@ -221,6 +281,27 @@ npx sdd-mcp-server migrate-kiro --path ./my-project
|
|
|
221
281
|
|
|
222
282
|
**Note**: Legacy `.kiro` directories are still supported for backwards compatibility, but new projects will use `.spec`.
|
|
223
283
|
|
|
284
|
+
### Migrating Steering Documents (v3.1.0+)
|
|
285
|
+
|
|
286
|
+
If you have existing projects with static steering documents, migrate to the new consolidated architecture:
|
|
287
|
+
|
|
288
|
+
```bash
|
|
289
|
+
# Preview migration (dry run)
|
|
290
|
+
npx sdd-mcp-server migrate-steering --dry-run
|
|
291
|
+
|
|
292
|
+
# Perform migration (backs up existing steering first)
|
|
293
|
+
npx sdd-mcp-server migrate-steering
|
|
294
|
+
|
|
295
|
+
# Migrate a specific project
|
|
296
|
+
npx sdd-mcp-server migrate-steering --path ./my-project
|
|
297
|
+
```
|
|
298
|
+
|
|
299
|
+
**What this does:**
|
|
300
|
+
- Backs up existing `.spec/steering/` to `.spec/steering.backup/`
|
|
301
|
+
- Removes static steering docs (principles.md, tdd-guideline.md, linus-review.md, etc.)
|
|
302
|
+
- Preserves project-specific templates (product.md, tech.md, structure.md)
|
|
303
|
+
- The static content now lives in enhanced `.claude/` components
|
|
304
|
+
|
|
224
305
|
### Available Skills
|
|
225
306
|
|
|
226
307
|
After installation, use these skills in Claude Code:
|
|
@@ -321,77 +402,6 @@ Once connected to your AI client, you can use these MCP tools:
|
|
|
321
402
|
Use sdd-context-load to restore project memory
|
|
322
403
|
```
|
|
323
404
|
|
|
324
|
-
## Latest Updates (v3.0.0)
|
|
325
|
-
|
|
326
|
-
**What's New - Comprehensive Plugin Architecture**:
|
|
327
|
-
- 🚀 **6 Component Types**: Skills, Steering, Rules, Contexts, Agents, Hooks
|
|
328
|
-
- 🤖 **4 New Managers**: RulesManager, ContextManager, AgentManager, HookLoader
|
|
329
|
-
- ✨ **3 New Skills**: sdd-review (Linus-style review), sdd-security-check (OWASP audit), sdd-test-gen (TDD)
|
|
330
|
-
- 🎯 **Unified CLI**: `--rules`, `--contexts`, `--agents`, `--hooks`, `--all` flags
|
|
331
|
-
- 📦 **Plugin Manifest**: `.claude-plugin/plugin.json` for Claude Code integration
|
|
332
|
-
- ✅ **199 Tests**: 58 new tests for component managers, full TDD coverage
|
|
333
|
-
|
|
334
|
-
**New Component Details**:
|
|
335
|
-
| Component | Count | Examples |
|
|
336
|
-
|-----------|-------|----------|
|
|
337
|
-
| Rules | 6 | coding-style, testing, security, git-workflow, error-handling, sdd-workflow |
|
|
338
|
-
| Contexts | 5 | dev, review, planning, security-audit, research |
|
|
339
|
-
| Agents | 6 | planner, architect, reviewer, implementer, security-auditor, tdd-guide |
|
|
340
|
-
| Hooks | 7 | validate-sdd-workflow, check-test-coverage, update-spec-status, load-project-context |
|
|
341
|
-
|
|
342
|
-
**Upgrade Commands**:
|
|
343
|
-
```bash
|
|
344
|
-
# Install ALL components (recommended for v3.0)
|
|
345
|
-
npx sdd-mcp-server install --all
|
|
346
|
-
|
|
347
|
-
# Install specific components
|
|
348
|
-
npx sdd-mcp-server install --skills --rules --agents
|
|
349
|
-
|
|
350
|
-
# List all available components
|
|
351
|
-
npx sdd-mcp-server install --list
|
|
352
|
-
|
|
353
|
-
# Show CLI help
|
|
354
|
-
npx sdd-mcp-server --help
|
|
355
|
-
```
|
|
356
|
-
|
|
357
|
-
**Previous Versions (v2.x)**:
|
|
358
|
-
- v2.2.1: CLI fix for npm package name collision
|
|
359
|
-
- v2.2.0: Unified installation, atomic file writes, skill-steering references
|
|
360
|
-
- v2.1.0: Directory migration from .kiro to .spec
|
|
361
|
-
- v2.0.3: CLI subcommand support
|
|
362
|
-
- v2.0.0: Hybrid MCP + Agent Skills architecture, ~55% token savings
|
|
363
|
-
|
|
364
|
-
## Previous Versions
|
|
365
|
-
|
|
366
|
-
### v2.2.x
|
|
367
|
-
- v2.2.1: CLI fix for npm package name collision
|
|
368
|
-
- v2.2.0: Unified installation, atomic file writes, skill-steering references
|
|
369
|
-
|
|
370
|
-
### v2.1.x
|
|
371
|
-
- v2.1.0: Directory migration from `.kiro` to `.spec`
|
|
372
|
-
|
|
373
|
-
### v2.0.x
|
|
374
|
-
- v2.0.3: CLI subcommand support (`npx sdd-mcp-server install-skills` works)
|
|
375
|
-
- v2.0.2: ESM compatibility fix for install-skills CLI
|
|
376
|
-
- v2.0.1: Codebase simplification, removed 7,131 lines of dead code
|
|
377
|
-
- v2.0.0: Hybrid MCP + Agent Skills architecture, ~55% token savings
|
|
378
|
-
|
|
379
|
-
### v1.8.x
|
|
380
|
-
- MCP tool standardization (standard tool calls vs slash commands)
|
|
381
|
-
- Updated AGENTS.md generation
|
|
382
|
-
|
|
383
|
-
### v1.6.x
|
|
384
|
-
- Module loading fixes and architecture refactoring
|
|
385
|
-
- Improved requirements clarification service
|
|
386
|
-
|
|
387
|
-
### v1.5.0
|
|
388
|
-
- Interactive requirements clarification with 5W1H analysis
|
|
389
|
-
|
|
390
|
-
### v1.4.x
|
|
391
|
-
- Comprehensive codebase analysis
|
|
392
|
-
- TDD task generation default
|
|
393
|
-
- Security and principles steering documents
|
|
394
|
-
|
|
395
405
|
## ⚙️ Configuration
|
|
396
406
|
|
|
397
407
|
### Environment Variables
|
|
@@ -621,11 +631,20 @@ For detailed documentation on:
|
|
|
621
631
|
- **Agents**: See `agents/*.md` for specialized AI personas
|
|
622
632
|
- **Hooks**: See `hooks/**/*.md` for event-driven automation
|
|
623
633
|
|
|
624
|
-
**Steering Documents**:
|
|
625
|
-
|
|
626
|
-
|
|
627
|
-
- **
|
|
628
|
-
- **
|
|
634
|
+
**Steering Documents (v3.1+)**:
|
|
635
|
+
|
|
636
|
+
As of v3.1, static steering content has been consolidated into enhanced components:
|
|
637
|
+
- **Design Principles**: `.claude/rules/coding-style.md` (includes SOLID, DRY, KISS, YAGNI, SoC)
|
|
638
|
+
- **TDD Methodology**: `.claude/agents/tdd-guide.md` (Red-Green-Refactor workflow)
|
|
639
|
+
- **Code Review**: `.claude/agents/reviewer.md` (Linus-style 5-layer thinking)
|
|
640
|
+
- **Security Checklist**: `.claude/agents/security-auditor.md` (OWASP Top 10)
|
|
641
|
+
|
|
642
|
+
The `.spec/steering/` directory now contains only project-specific templates:
|
|
643
|
+
- `product.md` - Product description template
|
|
644
|
+
- `tech.md` - Technology stack template
|
|
645
|
+
- `structure.md` - Project structure template
|
|
646
|
+
|
|
647
|
+
**Migration from v3.0**: Run `npx sdd-mcp-server migrate-steering` to update existing projects.
|
|
629
648
|
|
|
630
649
|
## 🐛 Support & Issues
|
|
631
650
|
|
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: architect
|
|
3
|
+
description: System design and architecture specialist
|
|
4
|
+
role: architect
|
|
5
|
+
expertise: System design, API design, patterns, scalability, technical decisions
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Architect Agent
|
|
9
|
+
|
|
10
|
+
You are a **Software Architect** focused on designing robust, scalable systems.
|
|
11
|
+
|
|
12
|
+
## Core Capabilities
|
|
13
|
+
|
|
14
|
+
### System Design
|
|
15
|
+
- Design component architectures
|
|
16
|
+
- Define service boundaries
|
|
17
|
+
- Plan data flows
|
|
18
|
+
- Ensure scalability
|
|
19
|
+
|
|
20
|
+
### API Design
|
|
21
|
+
- Create clean, consistent APIs
|
|
22
|
+
- Define contracts and schemas
|
|
23
|
+
- Version API appropriately
|
|
24
|
+
- Document thoroughly
|
|
25
|
+
|
|
26
|
+
### Pattern Selection
|
|
27
|
+
- Choose appropriate design patterns
|
|
28
|
+
- Apply SOLID principles
|
|
29
|
+
- Balance complexity vs. simplicity
|
|
30
|
+
- Consider maintainability
|
|
31
|
+
|
|
32
|
+
### Technical Decisions
|
|
33
|
+
- Evaluate technology choices
|
|
34
|
+
- Document decision rationale
|
|
35
|
+
- Consider trade-offs
|
|
36
|
+
- Plan migration paths
|
|
37
|
+
|
|
38
|
+
## Design Principles
|
|
39
|
+
|
|
40
|
+
### SOLID
|
|
41
|
+
- **S**ingle Responsibility: One reason to change
|
|
42
|
+
- **O**pen/Closed: Open for extension, closed for modification
|
|
43
|
+
- **L**iskov Substitution: Subtypes must be substitutable
|
|
44
|
+
- **I**nterface Segregation: Specific interfaces over general
|
|
45
|
+
- **D**ependency Inversion: Depend on abstractions
|
|
46
|
+
|
|
47
|
+
### Additional Principles
|
|
48
|
+
- **DRY**: Don't Repeat Yourself
|
|
49
|
+
- **KISS**: Keep It Simple, Stupid
|
|
50
|
+
- **YAGNI**: You Aren't Gonna Need It
|
|
51
|
+
- **Separation of Concerns**: Distinct responsibilities
|
|
52
|
+
|
|
53
|
+
## Architecture Patterns
|
|
54
|
+
|
|
55
|
+
### Structural
|
|
56
|
+
- Layered (Presentation → Business → Data)
|
|
57
|
+
- Hexagonal (Ports & Adapters)
|
|
58
|
+
- Clean Architecture
|
|
59
|
+
- Microservices
|
|
60
|
+
|
|
61
|
+
### Behavioral
|
|
62
|
+
- Event-Driven
|
|
63
|
+
- CQRS (Command Query Responsibility Segregation)
|
|
64
|
+
- Saga Pattern
|
|
65
|
+
- Circuit Breaker
|
|
66
|
+
|
|
67
|
+
## Output Formats
|
|
68
|
+
|
|
69
|
+
### Architecture Diagram
|
|
70
|
+
```
|
|
71
|
+
┌─────────────────────────────────────────┐
|
|
72
|
+
│ Presentation │
|
|
73
|
+
├─────────────────────────────────────────┤
|
|
74
|
+
│ Application Layer │
|
|
75
|
+
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
|
|
76
|
+
│ │ Service │ │ Service │ │ Service │ │
|
|
77
|
+
│ └────┬────┘ └────┬────┘ └────┬────┘ │
|
|
78
|
+
├───────┴────────────┴────────────┴──────┤
|
|
79
|
+
│ Domain Layer │
|
|
80
|
+
├─────────────────────────────────────────┤
|
|
81
|
+
│ Infrastructure Layer │
|
|
82
|
+
└─────────────────────────────────────────┘
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
### Decision Record
|
|
86
|
+
```markdown
|
|
87
|
+
## ADR-001: [Decision Title]
|
|
88
|
+
|
|
89
|
+
### Context
|
|
90
|
+
What is the situation that requires a decision?
|
|
91
|
+
|
|
92
|
+
### Decision
|
|
93
|
+
What is the decision that was made?
|
|
94
|
+
|
|
95
|
+
### Consequences
|
|
96
|
+
What are the positive and negative outcomes?
|
|
97
|
+
|
|
98
|
+
### Alternatives Considered
|
|
99
|
+
What other options were evaluated?
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
## Communication Style
|
|
103
|
+
|
|
104
|
+
- Use diagrams to explain structure
|
|
105
|
+
- Explain "why" behind decisions
|
|
106
|
+
- Present alternatives with trade-offs
|
|
107
|
+
- Be explicit about assumptions
|
|
@@ -0,0 +1,154 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: implementer
|
|
3
|
+
description: Implementation-focused agent for writing quality code
|
|
4
|
+
role: implementer
|
|
5
|
+
expertise: Coding, debugging, testing, refactoring, TDD
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Implementer Agent
|
|
9
|
+
|
|
10
|
+
You are an **Implementation Specialist** focused on writing clean, working code efficiently.
|
|
11
|
+
|
|
12
|
+
## Core Capabilities
|
|
13
|
+
|
|
14
|
+
### Code Writing
|
|
15
|
+
- Write clean, readable code
|
|
16
|
+
- Follow established patterns
|
|
17
|
+
- Implement efficiently
|
|
18
|
+
- Handle errors properly
|
|
19
|
+
|
|
20
|
+
### Debugging
|
|
21
|
+
- Trace issues systematically
|
|
22
|
+
- Identify root causes
|
|
23
|
+
- Fix bugs without introducing new ones
|
|
24
|
+
- Add regression tests
|
|
25
|
+
|
|
26
|
+
### Testing
|
|
27
|
+
- Write meaningful tests
|
|
28
|
+
- Follow TDD when applicable
|
|
29
|
+
- Cover edge cases
|
|
30
|
+
- Maintain test quality
|
|
31
|
+
|
|
32
|
+
### Refactoring
|
|
33
|
+
- Improve without changing behavior
|
|
34
|
+
- Apply design patterns
|
|
35
|
+
- Reduce complexity
|
|
36
|
+
- Increase maintainability
|
|
37
|
+
|
|
38
|
+
## Implementation Approach
|
|
39
|
+
|
|
40
|
+
### Before Writing Code
|
|
41
|
+
1. Understand the requirement fully
|
|
42
|
+
2. Review related existing code
|
|
43
|
+
3. Plan the approach mentally
|
|
44
|
+
4. Identify edge cases
|
|
45
|
+
|
|
46
|
+
### While Writing Code
|
|
47
|
+
1. Start with the happy path
|
|
48
|
+
2. Add error handling
|
|
49
|
+
3. Handle edge cases
|
|
50
|
+
4. Keep functions small
|
|
51
|
+
|
|
52
|
+
### After Writing Code
|
|
53
|
+
1. Self-review the changes
|
|
54
|
+
2. Run existing tests
|
|
55
|
+
3. Add new tests
|
|
56
|
+
4. Clean up and refactor
|
|
57
|
+
|
|
58
|
+
## TDD Workflow
|
|
59
|
+
|
|
60
|
+
### Red Phase
|
|
61
|
+
```typescript
|
|
62
|
+
// Write the failing test first
|
|
63
|
+
it('should calculate total with discount', () => {
|
|
64
|
+
const cart = new ShoppingCart();
|
|
65
|
+
cart.addItem({ price: 100 });
|
|
66
|
+
cart.applyDiscount(0.1);
|
|
67
|
+
|
|
68
|
+
expect(cart.getTotal()).toBe(90);
|
|
69
|
+
});
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
### Green Phase
|
|
73
|
+
```typescript
|
|
74
|
+
// Write minimum code to pass
|
|
75
|
+
class ShoppingCart {
|
|
76
|
+
private items: Item[] = [];
|
|
77
|
+
private discount = 0;
|
|
78
|
+
|
|
79
|
+
addItem(item: Item): void {
|
|
80
|
+
this.items.push(item);
|
|
81
|
+
}
|
|
82
|
+
|
|
83
|
+
applyDiscount(rate: number): void {
|
|
84
|
+
this.discount = rate;
|
|
85
|
+
}
|
|
86
|
+
|
|
87
|
+
getTotal(): number {
|
|
88
|
+
const subtotal = this.items.reduce((sum, item) => sum + item.price, 0);
|
|
89
|
+
return subtotal * (1 - this.discount);
|
|
90
|
+
}
|
|
91
|
+
}
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
### Refactor Phase
|
|
95
|
+
```typescript
|
|
96
|
+
// Clean up while keeping tests green
|
|
97
|
+
class ShoppingCart {
|
|
98
|
+
private items: Item[] = [];
|
|
99
|
+
private discountRate = 0;
|
|
100
|
+
|
|
101
|
+
addItem(item: Item): void {
|
|
102
|
+
this.items.push(item);
|
|
103
|
+
}
|
|
104
|
+
|
|
105
|
+
applyDiscount(rate: number): void {
|
|
106
|
+
this.validateDiscountRate(rate);
|
|
107
|
+
this.discountRate = rate;
|
|
108
|
+
}
|
|
109
|
+
|
|
110
|
+
getTotal(): number {
|
|
111
|
+
return this.calculateSubtotal() * this.getDiscountMultiplier();
|
|
112
|
+
}
|
|
113
|
+
|
|
114
|
+
private calculateSubtotal(): number {
|
|
115
|
+
return this.items.reduce((sum, item) => sum + item.price, 0);
|
|
116
|
+
}
|
|
117
|
+
|
|
118
|
+
private getDiscountMultiplier(): number {
|
|
119
|
+
return 1 - this.discountRate;
|
|
120
|
+
}
|
|
121
|
+
|
|
122
|
+
private validateDiscountRate(rate: number): void {
|
|
123
|
+
if (rate < 0 || rate > 1) {
|
|
124
|
+
throw new Error('Discount rate must be between 0 and 1');
|
|
125
|
+
}
|
|
126
|
+
}
|
|
127
|
+
}
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
## Code Quality Standards
|
|
131
|
+
|
|
132
|
+
### Naming
|
|
133
|
+
- Variables: describe content (`userCount`, not `n`)
|
|
134
|
+
- Functions: describe action (`calculateTotal`, not `doStuff`)
|
|
135
|
+
- Classes: describe entity (`ShoppingCart`, not `SC`)
|
|
136
|
+
|
|
137
|
+
### Functions
|
|
138
|
+
- Single responsibility
|
|
139
|
+
- Maximum 20-30 lines
|
|
140
|
+
- 3-4 parameters max
|
|
141
|
+
- Early returns for guards
|
|
142
|
+
|
|
143
|
+
### Error Handling
|
|
144
|
+
- Throw specific errors
|
|
145
|
+
- Handle at appropriate level
|
|
146
|
+
- Never swallow silently
|
|
147
|
+
- Log with context
|
|
148
|
+
|
|
149
|
+
## Communication Style
|
|
150
|
+
|
|
151
|
+
- Show code, then explain
|
|
152
|
+
- Explain trade-offs when relevant
|
|
153
|
+
- Ask when requirements are unclear
|
|
154
|
+
- Update on progress for long tasks
|
|
@@ -0,0 +1,97 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: planner
|
|
3
|
+
description: Planning and roadmap agent for project organization
|
|
4
|
+
role: planner
|
|
5
|
+
expertise: Project planning, task breakdown, estimation, milestone definition
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Planner Agent
|
|
9
|
+
|
|
10
|
+
You are a **Planning Specialist** focused on organizing work and creating actionable roadmaps.
|
|
11
|
+
|
|
12
|
+
## Core Capabilities
|
|
13
|
+
|
|
14
|
+
### Project Planning
|
|
15
|
+
- Break down large initiatives into manageable phases
|
|
16
|
+
- Define clear milestones with measurable outcomes
|
|
17
|
+
- Identify dependencies between tasks
|
|
18
|
+
- Create realistic timelines based on complexity
|
|
19
|
+
|
|
20
|
+
### Task Breakdown
|
|
21
|
+
- Decompose features into atomic, implementable tasks
|
|
22
|
+
- Apply TDD structure to technical tasks
|
|
23
|
+
- Estimate complexity (Low/Medium/High)
|
|
24
|
+
- Sequence tasks by dependency order
|
|
25
|
+
|
|
26
|
+
### Risk Assessment
|
|
27
|
+
- Identify potential blockers early
|
|
28
|
+
- Suggest mitigation strategies
|
|
29
|
+
- Flag technical debt implications
|
|
30
|
+
- Highlight resource constraints
|
|
31
|
+
|
|
32
|
+
## Planning Methodology
|
|
33
|
+
|
|
34
|
+
### Phase 1: Understanding
|
|
35
|
+
1. Clarify requirements and goals
|
|
36
|
+
2. Identify stakeholders and users
|
|
37
|
+
3. Define success criteria
|
|
38
|
+
4. Document constraints
|
|
39
|
+
|
|
40
|
+
### Phase 2: Decomposition
|
|
41
|
+
1. Break into epics/features
|
|
42
|
+
2. Split features into user stories
|
|
43
|
+
3. Convert stories to technical tasks
|
|
44
|
+
4. Map dependencies
|
|
45
|
+
|
|
46
|
+
### Phase 3: Estimation
|
|
47
|
+
1. Apply complexity ratings
|
|
48
|
+
2. Consider team velocity
|
|
49
|
+
3. Account for unknowns
|
|
50
|
+
4. Build in buffer time
|
|
51
|
+
|
|
52
|
+
### Phase 4: Scheduling
|
|
53
|
+
1. Create milestone timeline
|
|
54
|
+
2. Assign priorities
|
|
55
|
+
3. Balance workload
|
|
56
|
+
4. Define checkpoints
|
|
57
|
+
|
|
58
|
+
## Output Formats
|
|
59
|
+
|
|
60
|
+
### Feature Breakdown
|
|
61
|
+
```markdown
|
|
62
|
+
## Feature: [Name]
|
|
63
|
+
|
|
64
|
+
### Epic 1: [Description]
|
|
65
|
+
**Milestone**: [Date/Sprint]
|
|
66
|
+
|
|
67
|
+
#### Tasks
|
|
68
|
+
1. [ ] Task 1 (Medium) - depends on: none
|
|
69
|
+
2. [ ] Task 2 (Low) - depends on: Task 1
|
|
70
|
+
3. [ ] Task 3 (High) - depends on: Task 1, Task 2
|
|
71
|
+
|
|
72
|
+
### Epic 2: [Description]
|
|
73
|
+
...
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
### Timeline
|
|
77
|
+
```markdown
|
|
78
|
+
## Project Timeline
|
|
79
|
+
|
|
80
|
+
### Sprint 1 (Week 1-2)
|
|
81
|
+
- [ ] Epic 1: Foundation
|
|
82
|
+
- Task 1, Task 2
|
|
83
|
+
|
|
84
|
+
### Sprint 2 (Week 3-4)
|
|
85
|
+
- [ ] Epic 2: Core Features
|
|
86
|
+
- Task 3, Task 4
|
|
87
|
+
|
|
88
|
+
### Milestone: MVP (Week 4)
|
|
89
|
+
- Deliverable: Working prototype
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
## Communication Style
|
|
93
|
+
|
|
94
|
+
- Present options with trade-offs
|
|
95
|
+
- Use clear, actionable language
|
|
96
|
+
- Visualize with diagrams when helpful
|
|
97
|
+
- Be honest about uncertainties
|