mini-spec
use **whenever designing, updating, or implementing the design, code, or docs** or **whenever reverse engineering a design from code**
When & Why to Use This Skill
The mini-spec skill is a comprehensive framework for managing the full software development lifecycle through a structured 3-level architecture: specs, design, and code. It enforces rigorous traceability and SOLID principles, ensuring that technical documentation, architectural designs (like CRC cards and sequence diagrams), and implementation remain perfectly synchronized while promoting minimal, idiomatic, and maintainable code.
Use Cases
- Architecting new features: Use the Spec and Design phases to create human-readable requirements and CRC cards before writing a single line of code.
- Reverse engineering legacy code: Analyze existing source files to reconstruct design documents, sequence diagrams, and technical specifications.
- Maintaining documentation-code parity: Utilize traceability comments and the Gaps Phase to identify and fix discrepancies between design artifacts and implementation.
- Code quality enforcement: Apply the Simplification Phase and SOLID principles to refactor complex logic into clean, modular, and testable components.
- Project progress tracking: Manage complex migrations or updates using the phase-based todo system to ensure no architectural requirements are missed.
| name | mini-spec |
|---|---|
| description | **Use proactively**. Use a central index to explore the project. Update it properly when changing it. Covers specs, design, and code |
Mini-spec
3-level architecture: specs → design → code.
specs/ # Human specs (language, environment required)
design/ # SOURCE OF TRUTH: crc-*, seq-*, ui-*, test-*, manifest-ui.md
docs/ # user-manual.md, developer-guide.md
src/ # Code with traceability comments
Task Tracking
Use todos (TodoWrite) to track progress through phases and tasks:
- Create a todo for each phase you'll work through
- Break implementation into per-file or per-component todos
- Mark phases complete as you finish them
- Use the Quality Checklist items as todos before finalizing
Core Principles
- use SOLID principles, comprehensive unit tests
- when adding code, verify whether it needs to be factored
- Code and specs as MINIMAL as possible
- Before using a callback, see if a collaborator reference would be simpler
- write idiomatic code for the language you use
- avoid holding locks in sections that have significant functionality
Cross-cutting Concerns
design.md Cross-cutting Concerns section: Patterns spanning components (auth, errors, logging, routing, theming).
Referenced from other design artifacts: Cards, sequences, and layouts can all say "see cross-cutting: auth"
Traceability
design.md Artifacts section: design files with code file checkboxes.
Code changes: Uncheck [x]→[ ], ask user: "Update design, specs, or defer?"
Update design: Read code, update design file, re-check box.
Workflow
Read specs first. Specs must indicate language/environment.
- Spec Phase
Create in
specs/: human readable, natural language descriptions
Upon completion, offer to update the design (Design Phase). Do not jump to Implementation.
- Design Phase
Create in
design/:
design.md: Intent + Artifacts (design files → code file checkboxes)crc-*: CRC cards (see format below)seq-*: sequence diagrams (≤150 chars wide)ui-*: ASCII layouts, reference CRC cardstest-*: test designs (see format below)manifest-ui.md: routes, theme, global components
Upon completion, offer to update the implementation (Implementation Phase). Do not jump to Gaps.
- Implementation Phase Add traceability comments:
// CRC: crc-Store.md | Seq: seq-crud.md
add(data): Item {
Mark implemented: [ ]→[x] in Artifacts.
Look out for language-specific "gotchas" like mixing functions an methods in Lua.
Upon completion, run the Simplification Phase.
- Simplification Phase
Invoke the
code-simplifieragent on the recently modified code. This refines code for clarity, consistency, and maintainability while preserving functionality.
Upon completion, proceed to Gaps Phase.
- Gaps Phase
design.md Gaps section tracks (use S1/D1/C1/O1 numbering):
- Spec→Design (Sn): Spec features without design artifacts
- Design→Code (Dn): Designed features without code
- Code→Design (Cn): Code without design artifacts
- Oversights (On): Missing tests, tech debt, enhancements, security concerns, etc.
Nest related items with checkboxes:
- [ ] O1: Test coverage gaps
- [ ] Feature A (5 scenarios)
- [ ] Feature B (3 scenarios)
Upon completion, offer to update Documentation (Documentation Phase).
- Documentation Phase, Optional -- offer to user after Gaps
Create
docs/user-manual.mdanddocs/developer-guide.mdwith traceability links.
CRC Card Format
# ClassName
**Source Spec:** feature.md
## Knows
- attribute: description
## Does
- behavior: description
## Collaborators
- OtherClass: why
## Sequences
- seq-scenario.md
Principles: Single Responsibility, minimal collaborations, PascalCase.
Test Case Format
# Test Design: ComponentName
**Source:** crc-ComponentName.md
## Test: name
**Purpose:** what this validates
**Input:** setup and data
**Expected:** verifiable outcome
**Refs:** crc-*.md, seq-*.md
Cover: happy path, errors, edge cases.
Quality Checklist
- CRC Cards: nouns/verbs covered, no god classes, Source Spec linked
- Sequences: participants from CRCs, ≤150 chars wide
- UI Specs: ASCII layouts, refs to CRCs and manifest-ui.md
- Traceability: design files in Artifacts, code files have checkboxes
- Tests: test-*.md for key behaviors