A 4-phase planning tool that breaks projects into atomic, verifiable tasks with persistent state management.

Install

mkdir -p .claude/skills/tlc-spec-driven && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/8440" && unzip -o skill.zip -d .claude/skills/tlc-spec-driven && rm skill.zip

Installs to .claude/skills/tlc-spec-driven

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

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).
1023 chars✓ has a “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Intermediate

Key capabilities

  • Define project specifications with requirement traceability
  • Break down features into atomic tasks with verification criteria
  • Maintain persistent project memory and decision logs
  • Execute implementation with atomic git commits
  • Validate outcomes using an independent verifier sub-agent
  • Distill verification failures into reusable project-local lessons

How it works

The skill follows a four-phase adaptive pipeline of Specify, Design, Tasks, and Execute. It auto-sizes the depth of these phases based on the complexity of the requested feature.

Inputs & outputs

You give it
Feature requirements or project goals
You get back
Implemented code with verification reports and decision logs

When to use tlc-spec-driven

  • Initializing a new repository
  • Breaking down complex features into actionable tasks
  • Tracking project decisions and blockers
  • Mapping existing codebase architecture

About this skill

Tech Lead's Club - Spec-Driven Development

Plan and implement features 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

Critical Rules (read before acting)

Loading this skill's files. Reference files live under references/ in this skill's own directory (where this SKILL.md resides). Resolve them relative to the skill directory - never the workspace root - and load them through the active skill by name; never assume a fixed install path. When a step tells you to read a reference, read it completely (to EOF) before acting - never act on a partial/truncated read.

Running this skill's scripts. Every scripts/*.py shipped with this skill lives under that same skill directory. Resolve the skill directory first, then invoke python3 <skill-dir>/scripts/<name>.py .... Never run python3 scripts/... from the consuming project root - that looks for a project-local scripts/ tree that is not this skill. Project data under .specs/ is still read/written relative to the project root (pass --root when the cwd is elsewhere). Below, <skill-dir> means the directory that contains this SKILL.md.

Execution contract - every task, non-negotiable (holds even if you do not open the reference files):

  1. Tests derive from the spec's acceptance criteria and assert spec-defined outcomes - they never mirror the implementation.
  2. The gate must pass (tests pass) before a task is done - the test runner decides, not self-assessment.
  3. One atomic commit per task. Mark the task complete in tasks.md (and update spec traceability when used) before that commit, and include those updates in the same commit. Never batch tasks; never weaken, skip, or delete tests to make them pass.
  4. After the LAST task, a fresh Verifier always runs automatically (author ≠ verifier) - spec-anchored outcome check + discrimination sensor. It is never optional and never prompted. See Sub-Agent Delegation.
  5. Blast radius: approving a spec or tasks authorizes local implementation and local commits only. git push, force-push, deploy, production DB changes, and other remote / externally visible / destructive operations require an explicit go-ahead for that action.

Deterministic gates run before human review - not from memory. The structural gates for the spec and tasks are enforced by scripts in this skill's scripts/ directory, so they cannot silently drift when the model forgets a step:

  • Before confirming a spec: python3 <skill-dir>/scripts/validate_spec.py <spec-path-or-feature> (closure gate: EARS-shaped ACs, filled assumptions, well-formed requirement IDs, required sections).
  • Before presenting tasks for approval: python3 <skill-dir>/scripts/validate_tasks.py <tasks-path-or-feature> (granularity smell, diagram-vs-Depends on parity within a phase, no forward-phase dependency, every task carries Tests + Gate).
  • On each commit: python3 <skill-dir>/scripts/check_commit.py --message "<msg>" (Conventional Commits). Optionally wire it as a git commit-msg guard (git only, no agent dependency) - see implement.md.
  • Before declaring a feature done: python3 <skill-dir>/scripts/validate_state.py <feature> (completion gate: the Verifier's validation.md exists, its verdict is filled to PASS, and it cites file:line evidence - a missing, FAIL, placeholder, or evidence-free report fails). The closing step of Execute runs this automatically, the same way the lessons layer runs at distillation; it is not a manual step.

A non-zero exit means STOP and fix before proceeding. Skip a script only when no code-execution tool is available; then perform the same checks by reading the artifact.

Before Execute: read implement.md completely and run <skill-dir>/scripts/validate_tasks.py; if a formal tasks.md packs into more than one task-budgeted batch (> ~8 tasks), present the sub-agent offer first (see Sub-Agent Delegation).

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:

ScopeWhatSpecifyDesignTasksExecute
Small≤3 files, one sentenceOne-liner spec (inline)SkipSkipImplement + verify inline
MediumClear feature, <10 tasksSpec (brief)Skip - design inlineSkip - tasks implicitImplement + verify
LargeMulti-component featureFull spec + requirement IDsArchitecture + componentsFull breakdown + dependenciesImplement + verify per task
ComplexAmbiguity, new domainFull spec + discuss gray areasResearch + architectureBreakdown + phase planImplement + 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 when the agent detects ambiguous gray areas that need user input, or when the feature has any implicit-requirement dimension present (persistence/state, external calls, auth, payments, concurrency, state transitions)
  • Interactive UAT is triggered within Execute only for user-facing features with complex behavior

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.

.specs Structure

.specs/
├── STATE.md            # Project memory: Decisions log (AD-NNN) + Handoff snapshot
├── LESSONS.md          # Self-improving lessons playbook (rendered by scripts/lessons.py - do not hand-edit)
├── lessons.json        # Canonical lessons state (machine-owned)
└── 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)
        └── validation.md   # Verifier report: PASS/FAIL, per-AC evidence, sensor result, diff range

Create artifacts lazily. Write each file only when its phase actually produces content - never scaffold empty context.md, design.md, or tasks.md up front. An empty file signals a phase happened when it did not; absence is the correct state for a skipped phase. The deterministic validators (scripts/validate_spec.py, scripts/validate_tasks.py, scripts/check_commit.py, scripts/validate_state.py) ship inside this skill's own scripts/ directory, alongside lessons.py.

Workflow

New feature:

  1. Specify → (Design) → (Tasks) → Execute (depth auto-sized)

Resume work:

  1. Read .specs/STATE.md (Handoff + Decisions).
  2. Reconcile Handoff against git (branch, status --porcelain, recent commits) and tasks.md - evidence wins over a stale snapshot. Full procedure: memory.md.
  3. Propose the reconciled next step before writing code.

Context Loading Strategy

On-demand load (only what the current task needs):

  • .specs/STATE.md - Decisions section (read at Design, re-read on resume); Handoff section (read on resume only)
  • confirmed lessons - load at Specify and Design via python3 <skill-dir>/scripts/lessons.py list --status confirmed (lessons.md); confirmed only, never candidates
  • spec.md (when working on a 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

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

Sub-Agent Delegation

Trigger: count total tasks. If the feature packs into more than one task-budgeted batch (> ~8 tasks) → offer sub-agents; if it fits a single batch (≤ ~8 tasks) → execute inline.

Offer-then-confirm - never auto-spawn. The user must accept before any sub-agent is dispatched.

One worker per task-budgeted batch (~7 tasks, whole phases): Phases stay the semantic/dependency unit; a batch is the execution unit - one or more consecutive whole phases packed to ~7 tasks. Walk phases in order, accumulate whole phases into the current batch until it reaches the budget, then start the next - **nev


Content truncated.

When not to use it

  • Architecture decomposition analysis
  • Creating technical design documents

Prerequisites

Access to .specs/ directory for state and feature files

Limitations

  • Requires manual intervention for sub-agent dispatching
  • Bounded to 3 iterations for fix-and-verify loops
  • Context limit of 40k tokens for active files

How it compares

Unlike manual planning, this skill enforces an automated, spec-anchored verification gate where the author and verifier are distinct agents.

Compared to similar skills

tlc-spec-driven side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
tlc-spec-driven (this skill)74moNo flagsIntermediate
trello412moReviewBeginner
executing-plans63moNo flagsIntermediate
github-project-management46moReviewAdvanced

Try saying

Example prompts that trigger this skill in your AI assistant.

More by tech-leads-club

View all by tech-leads-club

accessibility

tech-leads-club

Audit and improve web accessibility following WCAG 2.1 guidelines. Use when asked to "improve accessibility", "a11y audit", "WCAG compliance", "screen reader support", "keyboard navigation", or "make accessible".

42174

perf-lighthouse

tech-leads-club

Run Lighthouse audits locally via CLI or Node API, parse and interpret reports, set performance budgets. Use when measuring site performance, understanding Lighthouse scores, setting up budgets, or integrating audits into CI. Triggers on: lighthouse, run lighthouse, lighthouse score, performance audit, performance budget.

1361

subagent-creator

tech-leads-club

Guide for creating AI subagents with isolated context for complex multi-step workflows. Use when users want to create a subagent, specialized agent, verifier, debugger, or orchestrator that requires isolated context and deep specialization. Works with any agent that supports subagent delegation. Triggers on "create subagent", "new agent", "specialized assistant", "create verifier".

828

aws-advisor

tech-leads-club

Expert AWS Cloud Advisor for architecture design, security review, and implementation guidance. Leverages AWS MCP tools for accurate, documentation-backed answers. Use when user asks about AWS architecture, security, service selection, migrations, troubleshooting, or learning AWS. Triggers on AWS, Lambda, S3, EC2, ECS, EKS, DynamoDB, RDS, CloudFormation, CDK, Terraform, Serverless, SAM, IAM, VPC, API Gateway, or any AWS service.

529

cursor-subagent-creator

tech-leads-club

Creates Cursor-specific AI subagents with isolated context for complex multi-step workflows. Use when creating subagents for Cursor editor specifically, following Cursor's patterns and directories (.cursor/agents/). Triggers on "cursor subagent", "cursor agent".

538

domain-analysis

tech-leads-club

Identifies subdomains and suggests bounded contexts in any codebase following DDD Strategic Design. Use when analyzing domain boundaries, identifying business subdomains, assessing domain cohesion, mapping bounded contexts, or when the user asks about DDD strategic design, domain analysis, or subdomain classification.

39

Search skills

Search the agent skills registry