Notre avis
Génère des documents de cadrage spécifiques au projet dans .spec/steering/ pour fournir un contexte aux assistants IA.
Points forts
- Processus documenté en plusieurs étapes
- Types de documents variés (produit, tech, structure)
- Personnalisable via des templates et des documents custom
- Intégration facile avec les workflows IA via la commande /sdd-steering
Limites
- Nécessite que l'utilisateur fournisse des détails manuellement dans certains cas
- Les documents générés peuvent nécessiter des ajustements
- Limité au format Markdown
Lors de la configuration d'un nouveau projet ou pour aider un assistant IA à comprendre le contexte et les conventions du projet.
Lorsque le projet dispose déjà d'une documentation exhaustive et que l'assistance IA n'est pas utilisée.
Analyse de sécurité
SûrThe skill only instructs the AI to analyze project files and generate static Markdown documents in the .spec/steering/ directory. It does not execute any commands, access external resources, or handle sensitive data. There is no risk of destructive actions or data exfiltration.
Aucun point d'attention détecté
Exemples
Run /sdd-steering to generate product.md for this project based on my package.json.Create all steering documents for my project using /sdd-steering.Use /sdd-steering to create a custom-*.md for security guidelines.name: sdd-steering description: 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.
SDD Steering Document Generation
Generate project-specific steering documents that provide context and guidance for AI-assisted development.
What Are Steering Documents?
Steering documents are markdown files in .spec/steering/ that provide project-specific context to guide AI interactions. They describe YOUR project's unique characteristics.
Document Types
| Document | Purpose | Content |
|----------|---------|---------|
| product.md | Product context | Vision, users, features, goals |
| tech.md | Technology stack | Languages, frameworks, tools, architecture |
| structure.md | Project conventions | Directory structure, naming, patterns |
| custom-*.md | Custom guidance | Specialized rules for specific contexts |
Workflow
Step 1: Analyze Project
Gather information from:
- Project manifest - Dependencies and metadata (e.g.,
package.json,Cargo.toml,pyproject.toml,pom.xml,go.mod) - Directory structure - Folder organization
- Existing code patterns - Naming conventions, architecture
- Documentation - README, existing docs
- Build configuration - Build tools, scripts, CI/CD
Step 2: Generate Product Steering
Create .spec/steering/product.md:
# Product Overview
## Description
{Project description from manifest or analysis}
## Vision
{Long-term product vision}
## Target Users
- **Primary:** {Main user persona}
- **Secondary:** {Other user types}
## Core Features
1. {Feature 1} - {Brief description}
2. {Feature 2} - {Brief description}
## Key Value Propositions
- {Value 1}
- {Value 2}
## Success Metrics
- {Metric 1}: {Target}
- {Metric 2}: {Target}
Step 3: Generate Tech Steering
Create .spec/steering/tech.md:
# Technology Overview
## Stack
### Language
- **Primary:** {e.g., TypeScript, Python, Go, Rust, Java}
- **Version:** {e.g., 5.x, 3.11, 1.21}
- **Runtime:** {if applicable, e.g., Node.js, JVM, .NET}
### Frameworks
- {Framework 1}: {Purpose}
- {Framework 2}: {Purpose}
### Key Dependencies
| Package | Version | Purpose |
|---------|---------|---------|
| {dep1} | {version} | {why used} |
## Architecture
### Pattern
{e.g., Clean Architecture, MVC, Microservices, Hexagonal}
### Layers
┌─────────────────┐ │ Presentation │ Controllers, CLI, UI ├─────────────────┤ │ Application │ Services, Use Cases ├─────────────────┤ │ Domain │ Entities, Business Logic ├─────────────────┤ │ Infrastructure │ Database, External APIs └─────────────────┘
## Development Environment
### Prerequisites
- {Language runtime and version}
- {Package manager} (e.g., npm, pip, cargo, go mod, maven)
### Setup
```bash
# Clone and install dependencies
{package manager install command}
# Run development server
{dev server command}
Common Commands
| Command | Purpose |
|---------|---------|
| {install} | Install dependencies |
| {dev} | Development server |
| {build} | Production build |
| {test} | Run tests |
| {lint} | Code linting |
Quality Standards
- Test coverage: >= 80%
- Linting: {language-appropriate linter}
- Type checking: {if applicable}
### Step 4: Generate Structure Steering
Create `.spec/steering/structure.md`:
```markdown
# Project Structure
## Directory Layout
project-root/ ├── src/ # Source code │ ├── domain/ # Business logic │ ├── application/ # Use cases │ ├── infrastructure/ # External adapters │ └── {entry point} # Main entry point ├── tests/ # Test files ├── docs/ # Documentation └── {project manifest} # Dependencies/config
## Naming Conventions
### Files
| Type | Convention | Example |
|------|------------|---------|
| Components | {project convention} | `UserProfile.{ext}` |
| Services | {project convention} | `AuthService.{ext}` |
| Utilities | {project convention} | `format_date.{ext}` |
| Tests | {test convention} | `auth_test.{ext}` |
| Types/Interfaces | {project convention} | `user_types.{ext}` |
### Code
| Element | Convention | Example |
|---------|------------|---------|
| Classes/Types | PascalCase | `UserService` |
| Functions/Methods | {language convention} | `get_user_by_id` or `getUserById` |
| Constants | UPPER_SNAKE | `MAX_RETRY_COUNT` |
| Variables | {language convention} | `user_name` or `userName` |
| Interfaces | {project convention} | `UserRepository` or `IUserRepository` |
## Module Organization
### Import Order
1. Standard library / built-ins
2. External packages / dependencies
3. Internal modules (absolute paths)
4. Relative imports
5. Type/interface imports (if language separates them)
### Export Pattern
- Use barrel exports / index files where appropriate
- Named exports preferred over default (language-dependent)
- Public API exposed from domain layer
## Patterns
### Dependency Injection
{DI approach used, e.g., Inversify, manual}
### Error Handling
{Error handling pattern, e.g., Result types, exceptions}
### Logging
{Logging approach, e.g., structured logging}
Step 5: Create Directory
Ensure .spec/steering/ directory exists and save documents.
MCP Tool Integration
This skill generates documents manually. For automated analysis, the sdd-init MCP tool creates basic steering during project initialization.
Quality Checklist
- [ ] Product description is clear and specific
- [ ] Target users are well-defined
- [ ] Technology stack is accurately documented
- [ ] Directory structure matches actual project
- [ ] Naming conventions are consistent
- [ ] Development setup instructions are complete
- [ ] Key patterns are documented
Notes
- Steering documents are project-specific - they describe YOUR project
- Keep them updated as the project evolves
- Use custom steering for domain-specific rules
- Reference from AGENTS.md or CLAUDE.md in project root
Generateur de Documentation API
Documentation
Genere automatiquement de la documentation API OpenAPI/Swagger.
Rédacteur Technique
Documentation
Rédige de la documentation technique claire selon les meilleurs style guides.
Système de formulaires de documentation typés
Documentation
Utilisez la syntaxe `(doc ...)` pour ajouter des annotations typées, des descriptions, des tâches (todo) et d'autres métadonnées directement dans le code Scheme. Les annotations sont extractibles via des commandes comme lf-todo et lf-types, et s'intègrent au vérificateur de types, où les déclarations de type dans les doc prennent le pas sur l'inférence. Idéal pour documenter les fonctions, marquer des déprécations ou lister des améliorations localisées sans recourir à un système externe.