Maintains consistency when creating, modifying, reading, reviewing, or working with specifications. Use when user mentions SPEC.md, requirements, or any specification documents to ensure consistent handling. Provides specification knowledge—quality criteria, editing methods, and three-layer framework (Intent/Design/Consistency).
Maintains specification quality by applying intent, design, and consistency layers to create complete, implementable specs.
/plugin marketplace add elct9620/claude-spec-plugin/plugin install elct9620-spec@elct9620/claude-spec-pluginThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Expertise for working with software specifications.
A specification is a complete record of design decisions. It tells implementers (human or machine) what to build so they can focus on how.
Core principle: Constrain design, open implementation.
Complete specifications address three layers:
| Layer | Purpose | Key Question |
|---|---|---|
| Intent | Why this exists | What problem for whom? |
| Design | What to build | What boundaries, interfaces, behaviors? |
| Consistency | How to stay unified | What patterns for similar problems? |
Provides context for judgment calls:
| Element | Role | Core |
|---|---|---|
| Purpose | What problem the system solves | ✓ |
| Users | Who uses it, what they accomplish | ✓ |
| Impacts | What behavior changes indicate success (drives priority) | |
| Success criteria | What defines "done" and "working" | |
| Non-goals | What is explicitly out of scope |
Without intent, implementers make technically correct but misaligned decisions.
Defines observable behaviors and boundaries:
| Element | Role | Format | Core |
|---|---|---|---|
| System boundary | What's inside vs outside | - | |
| User journeys | Task flows achieving impacts | Context → Action → Outcome | |
| Interfaces | Contracts between internal modules | - | |
| Presenter | How system presents to users | UI: colors, layout / CLI: output format / API: response structure | |
| Behaviors | Outcomes for each state × operation | State + Operation → Result | ✓ |
| Error scenarios | How failures are handled | - | ✓ |
Establishes patterns for uniform implementation (all items enhance quality, none required for minimal spec):
| Concept | Role | Example |
|---|---|---|
| Context | Shared understanding | "This is event-driven" |
| Pattern | Recurring situation → approach | "State changes via events" |
| Form | Expected structure | "Events have type, payload", "Primary: #FF0000", "Errors to stderr" |
| Contract | Interaction agreement | "Handlers must be idempotent" |
Weave these into relevant sections rather than listing separately.
For projects requiring code-level consistency across multiple contributors or extended development periods.
| Category | Purpose | Examples |
|---|---|---|
| Architecture | Module boundaries and dependencies | Clean Architecture, Hexagonal, Layered |
| Design Patterns | Reusable solutions | Repository, Factory, Strategy |
| Testing Style | Test structure and conventions | Given-When-Then, Arrange-Act-Assert |
| Code Organization | Directory structure and naming | Feature-based, layer-based, naming conventions |
When to include:
When to skip:
Rate each item Y (yes) or N (no).
Intent Layer
| # | Criterion | Required | Y/N |
|---|---|---|---|
| 1 | Purpose stated in one sentence? | ✓ | |
| 2 | Target users identified? | ✓ | |
| 3 | Impacts (behavior changes) identified? | ||
| 4 | Success criteria measurable or verifiable? |
Design Layer
| # | Criterion | Required | Y/N |
|---|---|---|---|
| 5 | Each documented feature has defined behavior? | ✓ | |
| 6 | Error scenarios cover all documented features? | ✓ | |
| 7 | Interaction points (internal and external) have explicit contracts? | ||
| 8 | Implementer can build without clarifying questions? | ✓ |
Consistency Layer
| # | Criterion | Required | Y/N |
|---|---|---|---|
| 9 | Recurring situations have named patterns? | ||
| 10 | Two implementers would produce compatible results? |
Passing Criteria:
| Question | Design Decision (specify) | Implementation Detail (open) |
|---|---|---|
| User-visible? | Error messages, CLI output | Log format, variable names |
| Affects modules? | Interface signatures | Internal functions |
| Needs consistency? | Error handling pattern | Algorithm choice |
| Could misalign? | Business rules | Performance optimization |
Test: "If implemented differently, would users notice or would modules conflict?"
Warning signs of over-specification: internal implementation details, algorithm choices (unless user-visible)
Warning signs of under-specification: vague terms ("appropriate", "reasonable"), undefined behavior for reachable states
| Problem | Symptom | Cause | Fix |
|---|---|---|---|
| Missing intent | Technical tasks instead of user value | No purpose/users defined | Add intent layer |
| Undefined scenarios | Inconsistent edge case behavior | Incomplete state coverage | Enumerate all combinations |
| Over-specification | Implementer constrained unnecessarily | Implementation details included | Keep only observable behaviors |
| Inconsistent patterns | Similar problems solved differently | No shared conventions | Extract and reference patterns |
| Vague language | Ambiguous interpretation | "Handle appropriately" | Use specific values or criteria |
| Hidden assumptions | Works only in specific context | Unstated prerequisites | Make all assumptions explicit |
Apply to both writing new specifications and improving existing ones. When improving, identify current phase and proceed from there.
| Phase | Focus | Output | Confirm |
|---|---|---|---|
| 1. Intent | Why and for whom | Purpose, Users, Impacts | Rubric #1-2 Y |
| 2. Scope | What's included | Feature list, User journeys (Context → Action → Outcome) | List complete |
| 3. Behavior | How it works | Feature behaviors, Error scenarios | Rubric #5-6, #8 Y |
| 4. Refinement | Quality | Patterns, Contracts | Rubric #7, #9-10 as needed |
Rules:
Assess against three layers:
Key questions:
Flag: missing layers, vague language, implementation details that should be open, design decisions that should be specified.
Default: Keep everything in SPEC.md.
Use this decision table to determine when to extract content:
| Decides | Expands | External | → Action |
|---|---|---|---|
| Y | - | - | Keep in SPEC.md |
| N | N | - | Keep in SPEC.md |
| N | Y | N | May extract (summary + link) |
| N | Y | Y | Extract (link only) |
Conditions:
Examples:
| Content | Decides | Expands | External | → Action |
|---|---|---|---|---|
| Feature behavior | Y | - | - | Keep |
| Decision table | Y | - | - | Keep |
| Error handling rules | Y | - | - | Keep |
| API endpoints (3-5) | N | N | - | Keep |
| Full DB schema (50+ fields) | N | Y | N | May extract |
| Complete test cases | N | Y | N | May extract |
| Figma design | N | Y | Y | Extract |
When extracting:
See [Schema](docs/schema.md) for field definitions| Type | Location |
|---|---|
| Data structures | docs/schema.md |
| Visual design | docs/design.md or external |
| Test cases | docs/tests.md |
When updating specifications:
Writing tip: Use tables (like this decision table) to define boundaries and rules. Tables make conditions explicit and reduce ambiguity.
Do not leave gaps. Instead:
Mark explicitly what is decided vs pending:
## Technical Stack
Decided:
- Runtime: Node.js >= 20
To be decided:
- Database: PostgreSQL or SQLite
(depends on deployment target)
Surface the conflict explicitly and request resolution rather than making assumptions.
This skill should be used when the user asks about libraries, frameworks, API references, or needs code examples. Activates for setup questions, code generation involving libraries, or mentions of specific frameworks like React, Vue, Next.js, Prisma, Supabase, etc.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.