Steering files are the project-specific context that makes SDD skills work correctly for your project. They live inDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/jorgeferrando/sdd-skills/llms.txt
Use this file to discover all available pages before exploring further.
openspec/steering/ and are generated by /sdd-init. Skills like /sdd-apply are generic — they work with any language or framework — but to write correct code the AI needs to know your testing framework, architectural patterns, naming conventions, and commit format. Steering files provide this context. Without them, /sdd-apply refuses to start.
The 7 steering files
conventions.md — Rules that cause PR failures
conventions.md — Rules that cause PR failures
The most important steering file. It uses RFC 2119 severity levels (
MUST / MUST NOT / SHOULD / MAY) to define rules that, if broken, would fail a PR review. Loaded by /sdd-apply before every implementation and by /sdd-audit when checking code quality.project-rules.md — Rules that grow with the project
project-rules.md — Rules that grow with the project
Starts empty after
/sdd-init. Grows automatically during /sdd-apply sessions as the AI learns from corrections. Rules are recorded in RFC 2119 format with the reason and date they were established.product.md — What the project builds
product.md — What the project builds
Describes what the project is, who it is for, and where its boundaries are. Helps the AI understand whether a proposed change is in scope and how it fits the product’s purpose.
tech.md — Stack details
tech.md — Stack details
Documents the language, runtime, key dependencies, and the commands used to run the project in each environment. Skills read this to know which test runner to invoke and which tools are available.
structure.md — Directory layout and layers
structure.md — Directory layout and layers
Maps the directory structure to architectural layers and responsibilities. Prevents the AI from putting code in the wrong layer and makes it easy to understand where a new file should live.
environment.md — Available tools
environment.md — Available tools
Lists available MCP servers and CLI tools with their versions. Skills use this to decide which tools to call during exploration, verification, and archiving.
project-skill.md — Quick reference index
project-skill.md — Quick reference index
The entry point loaded first by all skills. Points to every other steering file and provides a summary of the stack and architecture so skills can orient quickly before deciding what else to read.
How project-rules.md grows
project-rules.md is the only steering file that changes automatically during normal workflow use. It grows whenever the AI learns a project-specific preference from a correction:
| Trigger | Behavior |
|---|---|
| User says “always use X” or “remember this” | Rule saved immediately to project-rules.md |
User overrides the AI’s choice during /sdd-apply | AI asks “save as rule?” before continuing |
| Same correction happens twice in the same project | Saved automatically without asking |
**MUST** use X — reason from correction context.
Updating steering
Steering files are plain markdown — you can edit them directly at any time. Skills pick up changes on the next invocation. For detecting drift after major refactors or convention changes, use the sync command:MEMORY.md file, then presents proposed additions, updates, and removals for your confirmation. Nothing is auto-applied — you review each proposed change.
project-rules.md also grows automatically during /sdd-apply sessions when the AI learns from corrections, so no manual intervention is needed for that file.
Specialists
Specialists are pre-built convention packs that add domain expertise to the workflow. They are.md files containing RFC 2119 rules, installed to openspec/steering/ and read automatically by /sdd-apply, /sdd-audit, and /sdd-verify. No new agents, no new phases — same workflow, more knowledge.
Available specialists
| Specialist | Severity | What it adds |
|---|---|---|
| accessibility | Important | WCAG 2.1 AA — semantic HTML, ARIA, keyboard navigation, contrast, screen reader support. For projects with user-facing UI. |
| anti-overengineering | Important | Rules against premature abstractions, unnecessary patterns, and speculative design. Applies to all projects. |
| async-node | Important | Node.js async/concurrency — async/await correctness, unhandled rejections, child_process safety, stream handling, and timeout discipline. |
| clean-arch | Important | Clean architecture — domain/application/infrastructure layer separation, dependency inversion, port/adapter isolation. For TypeScript projects. |
| llm | Important | LLM integration — prompt construction, response validation, context management, prompt injection prevention, and model selection. For projects calling Claude or other LLMs. |
| nodejs-patterns | Important | Node.js performance and functional design — event loop awareness, immutability, pure functions, no shared mutable state, stream backpressure. |
| observability | Important | Structured logging, log levels, correlation IDs, what to log and what never to log, and how to trace async operations. |
| performance | Important | N+1 prevention, pagination, async I/O, lazy loading, indexed queries. Not premature optimization — avoiding known traps. |
| readability | Important | Descriptive naming, clear structure, guard clauses, no abbreviations, no clever tricks. |
| result-pattern | Important | Result/Either monad — models expected errors as values, reserves try/catch for infrastructure boundaries. For TypeScript projects. |
| security | Critical | OWASP top 10 — injection, auth, secrets, input validation, access control. Classifies violations as Critical. |
| tdd | Critical | Enforces Red/Green/Refactor cycle, tests written before implementation, changes task ordering (test before code). |
| testing | Important | Proper test doubles (stub vs mock vs fake), no redundant tests, behavior-focused assertions. |
Installing a specialist
openspec/steering/. Skills pick them up automatically on the next invocation.
For a full overview of how specialists work and how to create a custom one, see Specialists.