tlc-spec-driven

Plans and implements features through adaptive Specify, Design, Tasks, and Execute phases with deterministic validation scripts.

3|1|Updated Mar 17, 2022
One-click install
npx skills add https://github.com/paulpessoa/menvo --skill tlc-spec-driven-paulpessoa
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tlc-spec-driven
Source: https://github.com/paulpessoa/menvo/tree/main/.agent/skills/tlc-spec-driven
Command: npx skills add https://github.com/paulpessoa/menvo --skill tlc-spec-driven-paulpessoa

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Feature work often drifts from requirements, ships without verification, or loses context between sessions. This Skill enforces a spec-driven workflow where requirements are written in testable EARS notation, tasks are atomic with Conventional Commits, and an independent Verifier confirms the implementation matches the spec before work is declared done. ## Core Features & Use Cases - Adaptive 4-Phase Workflow: Specify and Execute are always required; Design and Tasks auto-scale based on feature complexity, from one-liner specs to full architecture documents. - Deterministic Validation Gates: Python scripts validate spec closure, task granularity, Conventional Commits format, and completion state so structural rules are enforced by code rather than memory. - Independent Verification: A fresh Verifier sub-agent (author != verifier) runs a spec-anchored outcome check and a discrimination sensor that injects behavior-level faults to confirm tests actually catch regressions. - Project Memory & Lessons: A decision log (STATE.md), handoff snapshots for pause/resume, and a self-improving lessons layer that distills verification failures into reusable guidance. - Use Case: Ask the agent to specify and implement a new API endpoint; it writes EARS acceptance criteria, breaks work into atomic tasks with per-task gate checks, commits each task separately, and runs the Verifier before reporting completion. ## Quick Start Ask the agent to specify and implement a new feature, for example by saying "specify and implement a password reset endpoint with email verification".

Frequently Asked Questions about tlc-spec-driven

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement a feature with spec-driven development?

Start with the Specify phase to write testable requirements in EARS notation, then let the workflow auto-size Design and Tasks based on complexity. Execute implements one atomic task at a time with a gate check and Conventional Commit per task, ending with independent verification.

How does the Verifier validate an implementation against a spec?

The Verifier is a fresh sub-agent separate from the author that re-derives coverage from the spec using evidence-or-zero rules. It runs a spec-anchored outcome check plus a discrimination sensor that injects behavior-level faults to confirm tests kill them, then writes a PASS/FAIL validation report.

Does this workflow work with any programming language or framework?

Yes, the workflow is stack-agnostic and tool-agnostic. The shipped validation scripts are pure standard-library Python with zero dependencies, and the spec, tasks, and commit conventions apply to any codebase.

When should I not use spec-driven feature planning?

Do not use it for pure architecture decomposition analysis or standalone technical design documents. Small changes of three files or fewer collapse to a one-liner spec with inline implementation, so the full pipeline only activates for larger features.

How do I resume interrupted work across sessions?

Read the Handoff section of .specs/STATE.md, then reconcile it against git status and tasks.md since evidence wins over a stale snapshot. The pause procedure replaces only the Handoff section, preserving the Decisions log.