tlc-spec-driven

name	tlc-spec-driven
description	Project and feature planning with 4 adaptive phases - Specify, Design, Tasks, Execute. Auto-sizes depth by complexity. Creates atomic tasks with verification criteria, atomic git commits, requirement traceability, and persistent memory across sessions. Stack-agnostic. Use when (1) Starting new projects (initialize vision, goals, roadmap), (2) Working with existing codebases (map stack, architecture, conventions), (3) Planning features (requirements, design, task breakdown), (4) Implementing with verification and atomic commits, (5) Quick ad-hoc tasks (bug fixes, config changes), (6) Tracking decisions/blockers/deferred ideas across sessions, (7) Pausing/resuming work. Triggers on "initialize project", "map codebase", "specify feature", "discuss feature", "design", "tasks", "implement", "validate", "verify work", "UAT", "quick fix", "quick task", "pause work", "resume work". Do NOT use for architecture decomposition analysis (use architecture skills) or technical design docs (use create-technical-design-doc).
license	CC-BY-4.0
metadata	{"author":"Felipe Rodrigues - github.com/felipfr","version":"2.0.0"}

Tech Lead's Club - Spec-Driven Development

Base workflow by Felipe Rodrigues (tlc-spec-driven, CC-BY-4.0), adapted by cast-skills with two changes woven into the flow below: project-context loading before every cycle, and immutable phase-1 TDD inside Execute. Changes are marked [cast-skills]. See ATTRIBUTION.md.

Plan and implement projects with precision. Granular tasks. Clear dependencies. Right tools. Zero ceremony.

┌──────────┐   ┌──────────┐   ┌─────────┐   ┌─────────┐
│ SPECIFY  │ → │  DESIGN  │ → │  TASKS  │ → │ EXECUTE │
└──────────┘   └──────────┘   └─────────┘   └─────────┘
   required      optional*      optional*     required

* Agent auto-skips when scope doesn't need it

Auto-Sizing: The Core Principle

The complexity determines the depth, not a fixed pipeline. Before starting any feature, assess its scope and apply only what's needed:

Scope	What	Specify	Design	Tasks	Execute
Small	≤3 files, one sentence	Quick mode — skip pipeline entirely	-	-	-
Medium	Clear feature, <10 tasks	Spec (brief)	Skip — design inline	Skip — tasks implicit	Implement + verify
Large	Multi-component feature	Full spec + requirement IDs	Architecture + components	Full breakdown + dependencies	Implement + verify per task
Complex	Ambiguity, new domain	Full spec + discuss gray areas	Research + architecture	Breakdown + parallel plan	Implement + interactive UAT

Rules:

• Specify and Execute are always required — you always need to know WHAT and DO it
• Design is skipped when the change is straightforward (no architectural decisions, no new patterns)
• Tasks is skipped when there are ≤3 obvious steps (they become implicit in Execute)
• Discuss is triggered within Specify only when the agent detects ambiguous gray areas that need user input
• Interactive UAT is triggered within Execute only for user-facing features with complex behavior
• Quick mode is the express lane — for bug fixes, config changes, and small tweaks
• [cast-skills] Execute is test-first and the tests are immutable — phase 1 writes the tests as the frozen contract derived from the spec; phase 2 makes the implementation conform. You never edit a test to make code pass. A test that feels wrong is a spec change: stop, fix the spec, revise the test deliberately. See tdd-immutable.md. This applies in every scope, including quick mode.

Safety valve: Even when Tasks is skipped, Execute ALWAYS starts by listing atomic steps inline (see implement.md). If that listing reveals >5 steps or complex dependencies, STOP and create a formal tasks.md — the Tasks phase was wrongly skipped.

Project Structure

.specs/
├── project/
│   ├── PROJECT.md      # Vision & goals
│   ├── ROADMAP.md      # Features & milestones
│   └── STATE.md        # Memory: decisions, blockers, lessons, todos, deferred ideas
├── codebase/           # Brownfield analysis (existing projects)
│   ├── STACK.md
│   ├── ARCHITECTURE.md
│   ├── CONVENTIONS.md
│   ├── STRUCTURE.md
│   ├── TESTING.md
│   ├── INTEGRATIONS.md
│   └── CONCERNS.md
├── features/           # Feature specifications
│   └── [feature]/
│       ├── spec.md     # Requirements with traceable IDs
│       ├── context.md  # User decisions for gray areas (only when discuss is triggered)
│       ├── design.md   # Architecture & components (only for Large/Complex)
│       └── tasks.md    # Atomic tasks with verification (only for Large/Complex)
└── quick/              # Ad-hoc tasks (quick mode)
    └── NNN-slug/
        ├── TASK.md
        └── SUMMARY.md

Workflow

[cast-skills] Step 0 — load project context (every feature, fix, or quick task): Before Specify (or before Implement in quick mode), read skills/project-context/SKILL.md for domain, stack, conventions, and the module map; then read the affected <module>/SKILL.md for its business rules, relationships, and gotchas. This replaces re-deriving the codebase from scratch each session. If these skills don't exist yet, run creating-project-skills first.

New project:

1. Initialize project → PROJECT.md + ROADMAP.md
2. For each feature → load project context → Specify → (Design) → (Tasks) → Execute (depth auto-sized)

Existing codebase:

1. Map codebase → 7 brownfield docs
2. Initialize project → PROJECT.md + ROADMAP.md
3. For each feature → load project context → same adaptive workflow

Quick mode: Load context → Describe → Implement → Verify → Commit (for ≤3 files, one-sentence scope)

Context Loading Strategy

Base load (~15k tokens):

• [cast-skills] skills/project-context/SKILL.md (domain, stack, conventions, module map)
• PROJECT.md (if exists)
• ROADMAP.md (when planning/working on features)
• STATE.md (persistent memory)

On-demand load:

• [cast-skills] <affected-module>/SKILL.md (business rules, relationships, gotchas — load the module you're touching, never all modules at once)
• Codebase docs (when working in existing project)
• CONCERNS.md (when planning features that touch flagged areas, estimating risk, or modifying fragile components)
• TESTING.md (when creating tasks or executing — drives test type assignment and gate checks)
• spec.md (when working on specific feature)
• context.md (when designing or implementing from user decisions)
• design.md (when implementing from design)
• tasks.md (when executing tasks)

Never load simultaneously:

• Multiple feature specs
• Multiple architecture docs
• Archived documents

Target: <40k tokens total context Reserve: 160k+ tokens for work, reasoning, outputs Monitoring: Display status when >40k (see context-limits.md)

Sub-Agent Delegation

Use sub-agents (the Task tool or equivalent) to keep the main context window lean and enable parallel execution. The orchestrating agent plans and coordinates; sub-agents do the heavy lifting.

When to delegate to a sub-agent:

Activity	Delegate?	Why
Research (design phase, brownfield mapping)	Yes	Research output is large; only the summary matters to the main context
Implementing a task	Yes	File reads, edits, test output consume context; only the result matters
Parallel [P] tasks	Yes (one per task)	The only way to actually run tasks in parallel
Sequential tasks with no [P]	Yes	Keeps implementation artifacts out of the main context
Planning, task creation, validation reports	No	These require the full accumulated context to be coherent
Quick mode tasks	No	Too small to justify the overhead

Context each sub-agent receives:

The orchestrating agent MUST provide each sub-agent with:

• The specific task definition from tasks.md (What, Where, Depends on, Reuses, Done when, Tests, Gate)
• Relevant coding principles and conventions (coding-principles.md, CONVENTIONS.md)
• TESTING.md, if it exists (for gate check commands and test patterns)
• Any spec/design context the task references

The sub-agent does NOT receive: other tasks' definitions, accumulated chat history, validation reports from other tasks, or STATE.md (unless the task explicitly references a decision/blocker).

What sub-agents return:

Each sub-agent reports back:

• Status: Complete | Blocked | Partial
• Files changed: [list]
• Gate check result: [pass/fail + test counts]
• SPEC_DEVIATION markers (if any)
• Issues encountered (if any)

The orchestrating agent uses this to update tasks.md status, traceability, and decide next steps.

Commands

Project-level:

Trigger Pattern	Reference
Initialize project, setup project	project-init.md
Create roadmap, plan features	roadmap.md
Map codebase, analyze existing code	brownfield-mapping.md
Document concerns, find tech debt, what's risky	concerns.md
Record decision, log blocker, add todo	state-management.md
Pause work, end session	session-handoff.md
Resume work, continue	session-handoff.md

Feature-level (auto-sized):

Trigger Pattern	Reference
Specify feature, define requirements	specify.md
Discuss feature, capture context, how should this work	discuss.md
Design feature, architecture	design.md
Break into tasks, create tasks	tasks.md
Implement task, build, execute	implement.md
Validate, verify, test, UAT, walk me through it	validate.md
Quick fix, quick task, small change, bug fix	quick-mode.md

Skill Integrations

This skill coexists with other skills. Before specific tasks, check if complementary skills are installed and prefer them when available.

Diagrams → mermaid-studio

Whenever the workflow requires creating or updating a diagram (architecture overviews, data flows, component diagrams, sequence diagrams, etc.), always check if the mermaid-studio skill is installed in the user's environment before proceeding. If it is installed, delegate all diagram creation and rendering to it. If it is not installed, proceed with inline mermaid code blocks as usual and recommend the user install mermaid-studio for richer diagram capabilities (rendering to SVG/PNG, validation, theming, etc.). Display this recommendation at most once per session.

Code Exploration → codenavi

Whenever the workflow requires exploring or discovering things in an existing repository (brownfield mapping, code reuse analysis, pattern identification, dependency tracing, etc.), always check if the codenavi skill is installed in the user's environment before proceeding. If it is installed, delegate code exploration and navigation tasks to it. If it is not installed, fall back to the built-in code analysis tools (see code-analysis.md) and recommend the user install codenavi for more effective codebase exploration. Display this recommendation at most once per session.

Knowledge Verification Chain

When researching, designing, or making any technical decision, follow this chain in strict order. Never skip steps.

Step 1: Codebase → check existing code, conventions, and patterns already in use
Step 2: Project docs → README, docs/, inline comments, .specs/codebase/
Step 3: Context7 MCP → resolve library ID, then query for current API/patterns
Step 4: Web search → official docs, reputable sources, community patterns
Step 5: Flag as uncertain → "I'm not certain about X — here's my reasoning, but verify"

Rules:

• Never skip to Step 5 if Steps 1-4 are available
• Step 5 is ALWAYS flagged as uncertain — never presented as fact
• NEVER assume or fabricate. If you cannot find an answer, say "I don't know" or "I couldn't find documentation for this". Inventing APIs, patterns, or behaviors causes cascading failures across design → tasks → implementation. Uncertainty is always preferable to fabrication.

Output Behavior

Model guidance: After completing lightweight tasks (validation, state updates, session handoff), naturally mention once that such tasks work well with faster/cheaper models. Track in STATE.md under Preferences to avoid repeating. For heavy tasks (brownfield mapping, complex design), briefly note the reasoning requirements before starting.

Be conversational, not robotic. Don't interrupt workflow—add as a natural closing note. Skip if user seems experienced or has already acknowledged the tip.

Code Analysis

Use available tools with graceful degradation. See code-analysis.md.

---

cast-skills Generation Templates

[cast-skills] The runtime behavior (context loading + immutable TDD) is woven into the workflow above. The files below are meta — they are read by creating-project-skills to generate a project's skill tree, not consumed during a normal Specify → Execute cycle.

Template	Generates
project-context-template.md	skills/project-context/SKILL.md — domain, stack, conventions, module map
module-template.md	<module>/SKILL.md — business rules, relationships, gotchas
sdd-skill-template.md	the project-adapted header that overwrites this SKILL.md's frontmatter (project name, framework, trigger phrases)
tdd-immutable.md	the immutable-TDD contract, copied verbatim into the generated workflow

Distributed by cast-skills (MIT). Original tlc-spec-driven files remain CC-BY-4.0 — see ATTRIBUTION.md.