smithery.ai

spec-first-sdlc

Spec-First, Agent-Implemented Software Development Lifecycle. Use when: (1) Starting a new software project that needs structured design-before-code approach, (2) User mentions "SDLC", "spec-first", "design docs", or "implementation spec", (3) User wants to go from requirements/intent to working code with traceability, (4) Project requires documented architectural decisions and review checkpoints, (5) User has existing design artifacts and wants to continue from a specific phase.

First seen Apr 18, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 6,313 B
  • docs SUMMARY.md 594 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

Spec-First SDLC

A structured software development lifecycle where specifications drive implementation. Human writes intent; Claude produces design documents, implementation specs, code, and tests—with review gates at each phase.

Workflow Overview

Intent & Constraints (human)
        ↓
High-Level Design (Claude) ←→ Human Review
        ↓
ADR-Lite (Claude) ←→ Human Review
        ↓
Revised HLD (Claude)
        ↓
Executable Implementation Spec (Claude) ←→ Human Review
        ↓
Code Generation (Claude)
        ↓
Validation Tests (Claude)

Phase Details

Phase 1: Intent and Constraints

Owner: Human Output: docs/intent-and-constraints.md

Human provides:

  • Problem statement and goals
  • Functional requirements
  • Non-functional constraints (performance, security, scalability)
  • Known boundaries and limitations

Phase 2: High-Level Design (HLD)

Owner: Claude Input: Intent and constraints document Output: docs/high-level-design.md Template: See [references/hld-template.md](references/hld-template.md)

Generate HLD covering:

  • System architecture and component breakdown
  • Data flow and integration points
  • Technology choices (with rationale)
  • Open questions section listing:

- Ambiguities in requirements - Design choice alternatives with default recommendations - Areas needing clarification

Wait for human review and agreement before proceeding.

Phase 3: Architecture Decision Record Lite (ADR-Lite)

Owner: Claude Input: Approved HLD + human feedback Output: docs/adr-lite.md Template: See [references/adr-template.md](references/adr-template.md)

For each significant decision, document:

  • Decision: What was decided
  • Alternatives: Options considered
  • Rationale: Why this choice (reference constraints from intent doc)
  • Consequences: Trade-offs and implications

Each ADR entry must explicitly reference:

  • The HLD open question it resolves
  • Relevant constraints from intent document that influenced the decision

Wait for human review and agreement before proceeding.

Phase 4: HLD Revision

Owner: Claude Input: Approved ADR-Lite Output: Updated docs/high-level-design.md

Revise HLD to:

  • Resolve open questions by referencing ADR-Lite decisions
  • Add traceability links (e.g., "See ADR-001")
  • Remove ambiguities

Phase 5: Executable Implementation Specification (EIS)

Owner: Claude Input: Revised HLD + ADR-Lite Output: docs/implementation-spec.md Template: See [references/eis-template.md](references/eis-template.md)

Specify implementation details:

  • API contracts: Endpoints, request/response schemas, error semantics, auth
  • State machines: Key business entity lifecycles with transitions and guards
  • Persistence: File layouts, database schemas, data models
  • Module boundaries: Interface contracts between components

Wait for human review and agreement before proceeding.

Phase 6: Code Generation

Owner: Claude Input: Approved EIS Output: Source code in src/

Implement code that:

  • Adheres strictly to EIS contracts
  • Includes documentation comments explaining design rationale
  • Follows project's coding conventions
  • References relevant ADR decisions in comments where appropriate

Phase 7: Validation

Owner: Claude Input: Implementation + Intent document Output: Tests in tests/

Generate comprehensive tests:

  • State transition tests: Verify entity lifecycle behaviors
  • Contract tests: Validate API request/response schemas
  • Negative tests: Error handling, invalid inputs, edge cases
  • Concurrency tests: Race conditions, deadlocks (where applicable)

Tests should trace back to original intents and constraints.

Review Gates

Never proceed to the next phase without explicit human approval. At each gate:

  1. Present the deliverable with a summary of key points
  2. Highlight decisions or areas that may need discussion
  3. Ask: "Ready to proceed to [next phase], or would you like changes?"

Mid-Workflow Entry

When user provides existing artifacts and wants to continue from a specific phase:

1. Identify Entry Point

Determine which phase to start from based on what artifacts exist:

  • Has intent doc only → Start at Phase 2 (HLD)
  • Has intent + HLD → Start at Phase 3 (ADR-Lite)
  • Has intent + HLD + ADR → Start at Phase 4 (HLD Revision) or Phase 5 (EIS)
  • Has complete specs → Start at Phase 6 (Code) or Phase 7 (Validation)

2. Assess Existing Artifacts

Before generating the next artifact, review provided documents for:

  • Completeness: Are required sections present?
  • Consistency: Do artifacts align with each other?
  • Open items: Are there unresolved questions that block progress?

If gaps or inconsistencies found:

"I reviewed [artifact]. Before proceeding to [next phase], I noticed:
- [Gap or inconsistency]
Would you like me to address this first, or proceed with assumptions?"

3. Establish Traceability

When entering mid-workflow, explicitly map existing artifacts:

  • Extract key decisions/constraints from provided docs
  • Reference them when generating new artifacts
  • Note any assumptions made due to missing context

4. Resume Normal Flow

After assessment, continue with standard phase sequence and review gates.

File Structure

project/
├── docs/
│   ├── intent-and-constraints.md
│   ├── high-level-design.md
│   ├── adr-lite.md
│   └── implementation-spec.md
├── src/
│   └── [implementation files]
└── tests/
    └── [test files]