.claude/skills/sdd-steering-custom/SKILL.md
Create custom steering documents for specialized contexts. Use when you need domain-specific guidance for particular file types, modules, or workflows. Invoked via /sdd-steering-custom.
npx skillsauth add yi-john-huang/sdd-mcp sdd-steering-customInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Create specialized steering documents that provide context-specific guidance beyond the standard product/tech/structure documents.
Custom steering is useful for:
Custom steering documents can be loaded in three ways:
| Mode | Behavior | Use Case |
|------|----------|----------|
| ALWAYS | Loaded in every AI interaction | Core conventions, critical rules |
| CONDITIONAL | Loaded when file patterns match | Test-specific, API-specific rules |
| MANUAL | Referenced with @filename.md | Rarely needed, specialized contexts |
Ask yourself:
Is this guidance ALWAYS relevant?
├── YES → Use ALWAYS mode
│
└── NO → Is it relevant for specific file types?
├── YES → Use CONDITIONAL mode with patterns
│ Examples: *.test.ts, src/api/**/*
│
└── NO → Use MANUAL mode
Reference with @filename.md when needed
Save to .spec/steering/{filename}.md:
# {Topic Name}
## Purpose
{Why this steering document exists}
## Scope
{When this guidance applies}
## Guidelines
### Guideline 1: {Name}
{Detailed guidance}
**Do:**
- {Good practice}
**Don't:**
- {Anti-pattern}
### Guideline 2: {Name}
{Detailed guidance}
## Examples
### Good Example
```{language}
{Code showing good practice}
// DON'T: {explanation}
{Code showing anti-pattern}
Inclusion Mode: {ALWAYS | CONDITIONAL | MANUAL} File Patterns: {patterns for CONDITIONAL mode} Created: {date}
## Common Custom Steering Documents
### API Design Standards
```markdown
# API Design Standards
## Inclusion
Mode: CONDITIONAL
Patterns: src/api/**/*.ts, src/routes/**/*.ts
## Guidelines
### RESTful Conventions
- Use plural nouns for resources: `/users`, not `/user`
- Use HTTP methods correctly: GET (read), POST (create), PUT (update), DELETE (remove)
- Return appropriate status codes
### Request/Response Format
- Use JSON for request/response bodies
- Include `Content-Type: application/json` header
- Wrap responses in consistent envelope
# Test Patterns
## Inclusion
Mode: CONDITIONAL
Patterns: **/*.test.ts, **/*.spec.ts
## Guidelines
### Arrange-Act-Assert
Every test should follow:
1. **Arrange**: Set up test data and mocks
2. **Act**: Execute the code under test
3. **Assert**: Verify the results
### Naming Convention
`describe('{Class/Function}', () => {`
` it('should {expected behavior} when {condition}', () => {`
# Component Standards
## Inclusion
Mode: CONDITIONAL
Patterns: src/components/**/*.tsx
## Guidelines
### Component Structure
1. Imports (external, internal, types)
2. Type definitions
3. Component function
4. Helper functions
5. Exports
# Database Conventions
## Inclusion
Mode: CONDITIONAL
Patterns: src/db/**/*.ts, **/migrations/**/*
## Guidelines
### Table Naming
- Use snake_case: `user_accounts`
- Use plural: `orders`, not `order`
- Prefix with domain: `auth_sessions`
### Column Naming
- Use snake_case: `created_at`
- Foreign keys: `{table}_id`
- Booleans: `is_active`, `has_access`
Patterns use glob syntax:
| Pattern | Matches |
|---------|---------|
| *.test.ts | All test files in current dir |
| **/*.test.ts | All test files recursively |
| src/api/**/* | All files in api directory tree |
| *.{ts,tsx} | TypeScript and TSX files |
| !node_modules/** | Exclude node_modules |
Custom steering documents are managed manually. After creating:
.spec/steering/{name}.mdtools
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>.
development
Generate comprehensive tests following TDD methodology. Creates unit tests, integration tests, and edge case coverage. Works with existing test frameworks in the project. Invoked via /sdd-test-gen [file-path or function-name].
testing
Generate TDD task breakdown for SDD workflow. Use when breaking down design into implementable tasks with test-first approach. Invoked via /sdd-tasks <feature-name>.
testing
Create project-specific steering documents for SDD workflow. Use when setting up project context, documenting technology stack, or establishing project conventions. Invoked via /sdd-steering.