From sdd-mcp
Guides feature implementation in SDD workflow using TDD cycle (Red-Green-Refactor), SOLID principles, and security best practices. Invoke via /sdd-implement <feature-name>.
npx claudepluginhub yi-john-huang/sdd-mcpThis skill uses the workspace's default tool permissions.
Execute implementation following TDD methodology, SOLID principles, and security best practices.
Implements small features, bug fixes, and quick enhancements using TDD, SOLID principles, code quality reviews, and security checks. Invoke via /simple-task <description>.
Implements tasks using TDD test-first workflow in normal mode (from plans) or quick mode (direct instructions). Handles test generation, minimal coding, refactoring, security/performance checks, coverage, and reporting.
Enforces rigorous Test-Driven Development (TDD) via RED-GREEN-REFACTOR cycle. Requires failing tests before any production code when implementing features or fixing bugs.
Share bugs, ideas, or general feedback.
Execute implementation following TDD methodology, SOLID principles, and security best practices.
Before implementing:
sdd-status to verify).spec/specs/{feature}/tasks.md.spec/specs/{feature}/design.mdsdd-status MCP tool to verify all phases approvedFor each task:
┌─────────────────────────────────────────────────────────────┐
│ 1. RED: Write Failing Test │
│ - Define expected behavior │
│ - Run test, confirm it FAILS │
│ │
│ 2. GREEN: Write Minimal Code │
│ - Just enough to pass the test │
│ - No extra features │
│ - Run test, confirm it PASSES │
│ │
│ 3. REFACTOR: Improve Code │
│ - Clean up without changing behavior │
│ - Run tests, confirm still PASSING │
│ │
│ REPEAT for each test case │
└─────────────────────────────────────────────────────────────┘
// GOOD: One class, one job
class UserValidator {
validate(user: User): ValidationResult { ... }
}
class UserRepository {
save(user: User): Promise<void> { ... }
}
// BAD: Class doing too much
class UserManager {
validate(user: User) { ... }
save(user: User) { ... }
sendEmail(user: User) { ... }
generateReport() { ... }
}
// GOOD: Open for extension, closed for modification
interface PaymentProcessor {
process(amount: number): Promise<Result>;
}
class StripeProcessor implements PaymentProcessor { ... }
class PayPalProcessor implements PaymentProcessor { ... }
// BAD: Modifying existing code for new payment types
class PaymentService {
process(type: string, amount: number) {
if (type === 'stripe') { ... }
else if (type === 'paypal') { ... }
// Adding new type requires modifying this class
}
}
// GOOD: Subtypes are substitutable
class Bird {
move(): void { /* fly or walk */ }
}
class Sparrow extends Bird {
move(): void { this.fly(); }
}
class Penguin extends Bird {
move(): void { this.walk(); }
}
// BAD: Subtype breaks expected behavior
class Bird {
fly(): void { ... }
}
class Penguin extends Bird {
fly(): void { throw new Error("Can't fly!"); }
}
// GOOD: Specific interfaces
interface Readable {
read(): Data;
}
interface Writable {
write(data: Data): void;
}
class FileHandler implements Readable, Writable { ... }
class ReadOnlyFile implements Readable { ... }
// BAD: Fat interface forcing unnecessary implementation
interface FileOperations {
read(): Data;
write(data: Data): void;
delete(): void;
execute(): void;
}
// GOOD: Depend on abstractions
interface IUserRepository {
findById(id: string): Promise<User>;
}
class UserService {
constructor(private repo: IUserRepository) {}
}
// BAD: Depend on concrete implementations
class UserService {
private repo = new PostgresUserRepository();
}
Before marking implementation complete, verify:
npm audit, pip-audit, cargo audit, snyk)package-lock.json, Cargo.lock, poetry.lock, go.sum)// GOOD
const userEmail = user.email;
function calculateTotalPrice(items: Item[]): number { ... }
// BAD
const e = user.email;
function calc(i: any): any { ... }
// GOOD: Explain WHY, not WHAT
// Use retry because the external API has rate limits
const result = await retryWithBackoff(fetchData);
// BAD: Obvious comments
// Get the user
const user = getUser(id);
// GOOD: Specific, informative errors
class UserNotFoundError extends Error {
constructor(userId: string) {
super(`User with ID ${userId} not found`);
this.name = 'UserNotFoundError';
}
}
// BAD: Generic errors
throw new Error('Error');
After implementing each task:
sdd-quality-check MCP tool on new code| Tool | When to Use |
|---|---|
sdd-status | Check all phases approved before implementing |
sdd-spec-impl | Execute specific tasks with TDD |
sdd-quality-check | Validate code quality after implementation |
Apply these steering documents during implementation:
| Document | Purpose | Key Application |
|---|---|---|
.spec/steering/tdd-guideline.md | Test-Driven Development | Follow Red-Green-Refactor cycle for all code |
.spec/steering/principles.md | SOLID, DRY, KISS, YAGNI | Apply SOLID principles, keep code simple and focused |
.spec/steering/owasp-top10-check.md | Security checklist | Verify all OWASP Top 10 security requirements before completion |
Critical Implementation Rules:
| Anti-Pattern | Problem | Solution |
|---|---|---|
| God Class | Class does too much | Split by responsibility |
| Feature Envy | Method uses another class's data extensively | Move method to that class |
| Primitive Obsession | Using primitives for domain concepts | Create value objects |
| Magic Numbers | Unexplained numeric literals | Use named constants |
| Deep Nesting | Multiple levels of if/loops | Extract methods, early returns |
| Long Methods | Methods doing too much | Split into smaller methods |