It also highlights something easy to miss: SDD keeps its method visible. The workflow is not + hidden behind a product layer, allowing teams to inspect the prompts and understand the + patterns that drive the workflow. This accessibility enables teams to improve their skills + with AI as they learn SDD.
@@ -39,8 +44,8 @@Structured processes often face criticism for introducing bureaucratic overhead. However, the cspell hook implementation proves that SDD structure is an investment, not a - cost. By mandating upfront clarity, it prevents ambiguity and rework—the true sources of - delay—ultimately increasing development velocity.
+ cost. By forcing the hardest thinking into the first two steps when correction is cheapest, it + prevents ambiguity and rework. These are the true sources of delay. Mandating upfront clarity ultimately increases development velocity.The specification clearly established Goals and Non-Goals, defining what's out of scope. This - protected the team from scope creep and unexpected requirements, concentrating effort - exclusively on agreed-upon value.
+The specification clearly established Goals and Non-Goals, defining what's out of scope. + That early clarity protected the team from scope creep and unexpected requirements, when it + was still cheap to make adjustments.
Git history shows implementation took under 6 minutes—from first commit (09:57:02) to final - commit (10:02:41). This remarkable speed was enabled by a clear plan breaking work into four - distinct tasks.
+ commit (10:02:41). That speed was enabled by Step 2 turning the approved spec into four + distinct tasks before implementation began.Explicitly Out of Scope:
SDD provides a robust framework that enhances clarity, guarantees verifiability, and gracefully accommodates change. The initial investment in structured planning and documentation delivers more predictable, successful outcomes with reduced rework and increased stakeholder confidence. + Because the workflow is exposed in readable prompts and artifacts, it also helps engineers learn + the patterns of effective AI-assisted development instead of treating them as hidden product + behavior.
Key Takeaway: The evidence from this real-world implementation demonstrates that SDD's structured approach is not overhead—it's an investment that pays dividends through - clarity, velocity, and quality assurance. + clarity, velocity, quality assurance, and a more teachable way of working with AI.
No. In SDD, these artifacts are process scaffolding for an implementation + loop, not living documentation that must stay perfectly synchronized forever. Their job is to help a + human and an AI align on the work, verify progress, and make the reasoning process explicit while + the feature is being built.
+ +Specs, tasks, proofs, and validation reports exist to guide the current implementation loop. + Once that loop is complete, the durable source of truth becomes the code and tests.
+Some teams keep artifacts in docs/specs/, some archive them, and some map them
+ to Jira, GitHub issues, or other systems. SDD stays intentionally unopinionated so teams can
+ manage context the way that fits their environment.
Even when they are not maintained forever, these artifacts still provide value as an audit + trail and a teaching surface that shows how the work was framed and verified.
+Feedback like "use a different test structure" or "refactor this code path" stays inside the + current implementation and review loop. The original artifacts already did their job by getting + the work to a reviewable state.
+Feedback like "this should use a different technology" or "the scope should be different" + signals that the earlier framing was off. That usually means going back upstream, clarifying the + direction, and starting a new spec for a new implementation loop.
+You can think of specs and proofs like the recipe notes and test batches used to bake a tray of + cookies. They help you get the current batch right, but once the batch is baked, the next major + change is usually a new batch, not an edit to the old dough.
+SDD1️⃣ I'll help you generate a specification... or
SDD3️⃣ Let me start implementing task 1.0.... This is expected behavior and
indicates the verification system is working correctly. The markers add minimal overhead
- (1-2 tokens) while providing immediate visual feedback.
+ (1-2 tokens) while providing immediate visual feedback. They also model a broader SDD
+ principle: effective AI workflows should make important operating logic explicit and easy to
+ inspect.
This verification technique was shared by Lada Kesseler at AI Native Dev Con Fall 2025 as a +
This verification technique was shared by Lada Kesseler at AI Native Dev Con Fall 2025 as a practical solution for detecting context rot in production AI workflows. The technique provides:
-For detailed research and technical information, see the For detailed research and technical information, see the context verification research documentation.
Other structured development tools like Kiro, SpecKit, and Taskmaster offer structured approaches - to AI-assisted development, but they require installation, configuration, and learning new - workflows. Here's why Liatrio's 4 transparent prompts are a better fit for day-to-day - development work.
+Kiro, SpecKit, and Taskmaster each add structure to AI-assisted development, but they do so + through very different operating models. This page compares Liatrio's four repo-local SDD + prompts with those tools, with a focus on setup, workflow fit, and day-to-day adoption cost.
+A second distinction matters just as much: SDD exposes its logic in plain markdown, so teams can + learn the patterns behind effective AI collaboration instead of depending on a product to hide + or mediate them.
How do Liatrio's prompts compare to other structured development tools? Here's - a side-by-side look at the key differences.
+The table below compares Liatrio's prompts with three other structured + development approaches. The emphasis is less on feature lists and more on the practical cost of + adopting each system inside an existing engineering workflow, including whether the workflow itself + is something engineers can inspect and learn from.
| Feature | Liatrio's SDD Prompts | -Kiro / SpecKit / Taskmaster | +Kiro | +SpecKit | +Taskmaster | |
|---|---|---|---|---|---|---|
| Setup & Installation | -✅ Just 4 markdown files—no installation | -❌ Kiro: Requires downloading IDE app. SpecKit: Requires installation and - configuration. Taskmaster: Requires installation and setup. | +✅ Four markdown files + added as prompts within your existing workflow | +❌ Requires installing Kiro, signing in, and + learning its product-specific workflow model + | +❌ Requires the Specify CLI, generated + agent command files, and adoption of a large multi-step workflow | +❌ MCP + or CLI setup, plus model/API configuration, project initialization, and a + PRD-to-task pipeline |
| Editor/IDE Dependency | -✅ Works with any editor (VS Code, Cursor, etc.) | -❌ Kiro: Requires switching to Kiro IDE. SpecKit/Taskmaster: Work within existing - editors but require specific setup. | +✅ Works in editors that support prompts or slash commands | +❌ Structured workflow assumes the Kiro IDE as the primary environment | +⚠️ Runs in existing editors through generated agent commands | +⚠️ Works in existing editors through CLI or MCP integration |
| AI Assistant Compatibility | -✅ Works with any AI assistant (Claude, GPT, Gemini, etc.) | -❌ Kiro: Built-in AI. SpecKit: Works with GitHub Copilot, Claude Code, Gemini CLI. - Taskmaster: Works with Claude, Cursor, etc. | +✅ Works with assistants that support custom prompts or slash commands | +⚠️ Uses Kiro's built-in agent experience, model options, and product-specific modes + | +⚠️ Works through supported agent integrations and slash commands | +⚠️ Works through CLI or MCP integrations plus model-provider and agent setup |
| Learning Curve | -✅ Just read markdown prompts—no new concepts | -❌ Kiro: Learn new IDE. SpecKit: Learn command system (`/speckit.specify`, - `/speckit.plan`, etc.). Taskmaster: Learn task management system. | +✅ Uses a guided four-prompt workflow layered onto your existing workflow | +❌ Requires learning Kiro's broader vocabulary and workflow model
+ (specs,
+ steering, hooks, powers,
+ autopilot, vibe vs spec, etc.)
+ |
+ ❌ Requires learning a large constitution → specify →
+ clarify → plan → tasks →
+ implement methodology
+ |
+ ❌ Requires learning Taskmaster's broader orchestration model: PRDs, task graphs, + subtasks, dependencies, statuses, and optional autopilot/TDD workflows |
| Transparency | -✅ Every prompt is readable markdown—no black boxes | -❌ Tool logic is hidden in codebases. Can't easily see or modify how they work. | +✅ Prompts are plain markdown, so the workflow logic is directly readable, editable, + and teachable | +⚠️ Some files are editable, but core behavior, modes, and workflow concepts live in + the product | +⚠️ Workflow files and templates are published on GitHub, but much of the method is + still experienced through its larger system | +⚠️ Open source, but much of the behavior lives in JS packages, configs, and task + state data |
| Flexibility | -✅ Edit prompts to fit your project/style/company guidelines | -❌ Limited customization. Must work within tool's structure and constraints. | +✅ Prompt text can be edited to match team or project conventions | +⚠️ Steering files, hooks, and modes are configurable within Kiro's product model + | +⚠️ Templates can be adapted, but the workflow, artifacts, and process vocabulary + stay highly prescriptive | +⚠️ Models, prompts, tasks, tags, and execution modes can be configured within its + orchestration system |
| File Structure | -✅ Simple docs/specs/ that doesn't pollute repo |
- ❌ Kiro: IDE-specific files. SpecKit: Creates .specify/ directory
- structure. Taskmaster: Task management files. |
+ ✅ Uses a repository-level docs/specs/ structure but can be easily
+ adapted
+ to any directory structure |
+ ⚠️ Stores project-specific files in .kiro alongside multiple product
+ concepts and configs |
+ ❌ Creates a .specify/ directory, agent-specific command files, and
+ multiple generated planning artifacts |
+ ❌ Stores PRDs, config, state, task graphs, and generated artifacts in
+ .taskmaster/
+ |
| Workflow Integration | -✅ Fits into your existing workflow—no context switching | -❌ Kiro: Requires switching IDEs. SpecKit: Requires using specific commands. - Taskmaster: Requires managing tasks through tool. | +✅ Adds structure without replacing repo-local development workflows | +❌ Best fit when teams are willing to adopt Kiro as the primary workspace and + operating model | +❌ Can run in an existing repo, but expects teams to adopt its full process and + artifact model | +❌ Adds a separate planning, execution, and tracking layer on top of normal + engineering work |
| Speed | -✅ Complete feature in minutes (example: <15 min) | -⚠️ Varies by tool, but requires learning and setup overhead | +✅ Minimal setup overhead once prompts are installed | +❌ Front-loaded overhead is high because teams must learn the product model before + moving quickly | +❌ Front-loaded overhead is high because the workflow generates and coordinates many + artifacts | +❌ Front-loaded overhead is high because useful adoption requires creating and + maintaining the task system |
| Cost | -✅ Free—just markdown files | -✅ All are open source, but require time investment to learn | +✅ Markdown files are free to use | +⚠️ Free tier available, but usage is managed through sign-in, credits, and paid + usage tiers | +✅ Open source | +⚠️ Open source, with limits on some commercial use cases |
While other tools require complex installation and configuration, the SDD workflow prompts can be - installed +
The SDD workflow prompts can be installed in any AI assistant in seconds using the slash-command-manager. This open-source tool from Liatrio - makes it - straightforward + makes it straightforward to add the prompts as slash commands in VS Code, Cursor, Claude Code, and many other AI tools - that - support - custom commands.
-No complex setup, no configuration files, no learning curve—just install the prompts and start
- using
- them immediately in your existing workflow. See the
+ Because the workflow is plain markdown, teams can adopt it without taking on a new IDE, a
+ generated artifact model, or a separate task-orchestration system. See the installation instructions in the README to get started. That same simplicity also makes SDD useful as a teaching tool: engineers can read the prompts,
+ understand the workflow patterns they encode, and reuse those patterns when working with AI in
+ other contexts.
For day-to-day development work in enterprise companies, Liatrio's 4 prompts provide the structure - and rigor you need without requiring new tools, installation, or learning curves. They're - transparent, flexible, and designed to fit into your existing workflow—not replace it. Perfect for - developers who want structured AI-assisted development without the overhead of switching tools or - learning new systems.
+For teams working in existing enterprise codebases, the main tradeoff is not whether a tool offers + structure, but how much new product or process it asks engineers to adopt. Liatrio's prompts aim to + provide structure in a repo-native form: readable markdown, editable conventions, and a workflow + that can sit on top of existing tools rather than replace them.
+This pattern extends beyond Kiro, SpecKit, and Taskmaster. Other spec-driven frameworks such as + Tessl and BMAD also add structure by introducing a larger system around the developer: more + tooling, more workflow machinery, and more framework-specific concepts to absorb. Liatrio's SDD + prompts are intentionally different. They expose the workflow logic directly in markdown, so teams + can inspect it, adapt it, and internalize better AI collaboration patterns instead of depending on + a mediated system.
- diff --git a/docs/developer-experience.html b/docs/developer-experience.html index c274203..ccf3406 100644 --- a/docs/developer-experience.html +++ b/docs/developer-experience.html @@ -29,15 +29,19 @@Using a real-world case study—implementing a pre-commit spell checker—we demonstrate the profound - impact Liatrio's workflow has on developer experience. We'll first explore the traditional - manual approach to establish a baseline, then reveal how AI assistance transforms the entire - development lifecycle from hours of toil into minutes of strategic oversight.
+ impact Liatrio's workflow has on developer experience. You can inspect the full cspell example + in Reference Materials. We'll first explore the + traditional manual approach to establish a baseline, then reveal how AI assistance transforms + the entire development lifecycle from hours of toil into minutes of strategic oversight. +Just as importantly, SDD keeps the workflow logic visible. The prompts, specs, tasks, proofs, + and validation artifacts make the method readable, so teams can learn how to guide AI well + instead of relying on hidden product behavior.
To appreciate the efficiency gains of AI-assisted workflows, we must first @@ -147,6 +151,8 @@
Because SDD exposes the workflow in readable prompts and artifacts, developers can study the + method itself and improve how they interact with AI over time.
+This case study demonstrates a fundamental transformation of developer @@ -318,22 +329,27 @@
Implementation time for standard features reduced from hours to minutes, enabling unprecedented development velocity and faster time-to-market for new capabilities.
Automated gates prevent errors and enforce standards by default, eliminating inconsistencies and reducing technical debt across the entire codebase.
Developers evolve from manual laborers bogged down by repetitive tasks to strategic overseers who direct high-level goals and validate results.
The prompts and artifacts make effective AI-assisted engineering visible, which helps + teams build shared habits and judgment instead of depending on hidden workflow logic.
+As organizations seek to maximize engineering effectiveness, AI-assisted, spec-driven workflows are poised to become the new standard. This approach doesn't just improve existing processes—it fundamentally reimagines what's possible when human expertise is amplified by intelligent - automation.
+ automation. The critical advantage of SDD is that it exposes this operating model in a form teams + can read, discuss, and adapt.Complete a feature in minutes, not days. Liatrio's Spec-Driven Development workflow is just 4 markdown prompts that help developers guide an AI assistant through - implementing their day-to-day work with structure, clarity, and evidence.
-These prompts are transparent (you can read and modify every one),
- tool-agnostic (works with any AI assistant), and lightweight
- (no installation, no dependencies). They create a simple file structure in
- docs/specs/ that doesn't pollute your repo.
These prompts are transparent and learnable: you can read + every prompt, understand the workflow logic it applies, and adapt the patterns to your own team + and projects. Instead of hiding the method inside a product, SDD exposes it in markdown.
+They are also tool-agnostic (works with any AI assistant) and
+ lightweight (no installation, no dependencies). They create a simple file
+ structure in docs/specs/ that doesn't pollute your repo.
+
View the prompts on GitHub: Built-in Scope Validation
Transform your flow input into a structured spec with clear boundaries
- -Break the spec into actionable tasks with demo criteria
- -Verify implementation meets all requirements with evidence
- -One person runs through these 4 prompts sequentially with an AI assistant. The - example described on this site took less than 15 minutes from start to finish.
+One person runs through these 4 prompts sequentially with an AI assistant. In + the cspell pre-commit hook example featured across this + site, the end-to-end workflow took less than 15 minutes from start to finish. The highest-leverage + work happens in Step 1 and Step 2: when the spec is clear and the task plan is concrete, + implementation and validation are far more likely to run smoothly without human rescue. Because the + prompts are readable, the workflow also doubles as a guide for learning how to scope work, guide + AI, and verify results more effectively.
Focus: Transform your flow input into a structured specification with - clear boundaries and functional requirements.
+Focus: Lock down scope, intent, and success criteria before any code is + written.
What It Does: The prompt validates scope (too large/too small/just - right), asks clarifying questions, and generates a specification document.
+ right), resolves ambiguous context, and generates a specification document with clear + boundaries.Output: A markdown spec file in
- docs/specs/[NN]-spec-[feature-name]/
docs/specs/[NN]-spec-[feature-name]/
+
Prompt: SDD-1-generate-spec.md
@@ -172,15 +114,17 @@Focus: Break the specification into actionable tasks with demo criteria - and proof artifacts.
+Focus: Turn the approved spec into an executable plan with demo + criteria and proof artifacts.
What It Does: Analyzes the spec, identifies relevant files, and creates - a task list with parent tasks (first) and sub-tasks (after confirmation).
+ a task list with parent tasks (first) and sub-tasks (after confirmation) so drift is + caught before implementation starts.Output: A task list markdown file with demo criteria and proof artifact requirements
+ target="_blank" rel="noopener noreferrer">SDD-2-generate-task-list-from-spec.md +- The upfront investment in clarity de-risks the entire development lifecycle by preventing the two - most common causes of project failure: ambiguous requirements and unchecked scope creep. + The highest-leverage work happens in the first two steps: if you nail the spec and task breakdown, + the later steps have a much better chance of succeeding without rework, course correction, or human + intervention.
How does this compare to other structured development tools? See our comparison against Kiro, SpecKit, and Taskmaster to understand why Liatrio's prompts fit better into the typical workflow of software developers doing - day-to-day work.
+ day-to-day work, and why exposing the workflow logic matters just as much as lightweight + adoption. +SDD is intentionally focused on the implementation loop. In many enterprise + teams, research, prioritization, and architecture decisions already happen upstream in product, + design, or ticketing systems. SDD starts when an engineer has a piece of work ready to execute and + helps carry it through implementation and into review.
+ +This is where requirements are clarified, options are considered, and constraints are + understood. In many teams this already lives in Jira, GitHub issues, design docs, or + product conversations before SDD begins.
+This is the four-step workflow. Specs, tasks, proofs, and validation artifacts help the human + and the AI align on the work, verify progress, and make the reasoning process visible while + the feature is being built.
+The PR is reviewed and feedback is incorporated. Implementation feedback can be handled in the + current loop, but directional feedback usually means starting a new spec and a new + implementation run.
+Specs, tasks, proofs, and validation reports are process artifacts, not living documentation. + They exist to guide the implementation loop, help the human verify the AI's understanding, and + make the workflow teachable while the work is in flight.
+After that loop completes, the code and tests become the durable source of truth. Some teams keep
+ these artifacts in docs/specs/, some archive them elsewhere, and some align them to
+ external systems. SDD intentionally leaves that lifecycle flexible so teams can manage context in
+ the way that fits their environment.
By consistently using these four prompts, developers transform small feature work from reactive coding into predictable, evidence-based implementation. Liatrio's Spec-Driven Development workflow creates a self-documenting, auditable process that systematically drives up quality, reduces ambiguity, and ensures every feature delivered is a feature validated—all in minutes, not days.
+The important point is that this process remains visible to the team. Engineers are not only using + AI to move faster; they are learning a repeatable way to frame requirements, direct execution, and + validate output.
The linkage from Git commit, to task list, to proof artifact forms an unbreakable audit trail from a specific line of code back to the requirement it satisfies. This traceability is non-negotiable and transforms development into a transparent, verifiable process.
+Because the workflow is documented in prompts and artifacts rather than hidden behind product logic, + the audit trail also becomes a teaching surface teams can inspect to understand how effective + AI-assisted delivery actually works.
Every step generates artifacts that serve as living documentation, creating a complete - project history without additional overhead.
+Every step generates a working record of the implementation loop, creating traceability and + shared context without requiring a separate documentation effort.
The SDD workflow creates a structured directory layout in docs/specs/ that provides a complete audit trail from requirements to implementation:
One common way to run SDD is to keep implementation artifacts in
+ docs/specs/ so requirements, tasks, proofs, and validation stay connected in one
+ place while the work is active.
+
docs/specs
+
+
+
+
+ docs/specs
├── 01-spec-feature-name
│ ├── 01-proofs
│ │ ├── 01-task-01-proofs.md
@@ -404,38 +412,68 @@ Directory Structure
├── 03-spec-third-feature.md
├── 03-tasks-third-feature.md
└── 03-validation-third-feature.md
-
+
+
-
-
- File Naming Convention
-
- [NN]-spec-[feature-name]/: Main directory for each feature specification
-
- [NN]: Zero-padded 2-digit number (01, 02, 03, etc.)spec-[feature-name]: Descriptive feature name
- [NN]-spec-[feature-name].md: The main specification document[NN]-tasks-[feature-name].md: Task breakdown with parent/sub-tasks[NN]-questions-1-[feature-name].md: Clarifying questions and answers[NN]-validation-[feature-name].md: Validation report and coverage matrix[NN]-proofs/: Subdirectory containing proof artifacts
-
- [NN]-task-[TT]-proofs.md: Proof artifacts for each parent task
-
+
+
+ File Naming Convention
+
+ [NN]-spec-[feature-name]/: Main directory for each
+ feature specification
+
+ [NN]: Zero-padded 2-digit number (01, 02, 03, etc.)spec-[feature-name]: Descriptive feature name
+ [NN]-spec-[feature-name].md: The main specification
+ document[NN]-tasks-[feature-name].md: Task breakdown with
+ parent/sub-tasks[NN]-questions-1-[feature-name].md: Clarifying
+ questions and answers[NN]-validation-[feature-name].md: Validation report
+ and coverage matrix[NN]-proofs/: Subdirectory containing proof artifacts
+
+ [NN]-task-[TT]-proofs.md: Proof artifacts for
+ each parent task
+
+
+
+ Workflow Progression
+
+ - Specification Phase
Creates
+ [NN]-spec-[feature-name].md and
+ [NN]-questions-1-[feature-name].md
+
+ - Task Planning Phase
Creates
+ [NN]-tasks-[feature-name].md
+
+ - Implementation Phase
Creates
+ [NN]-proofs/[NN]-task-[TT]-proofs.md files as tasks are completed
+
+ - Validation Phase
Creates
+ [NN]-validation-[feature-name].md with final validation report
+
+
+ This shows one way to store a complete Loop-2 implementation trail in-repo. The exact
+ retention model is intentionally flexible, and teams can archive or externalize these
+ artifacts once the implementation loop is complete.
+
-
- Workflow Progression
-
- - Specification Phase: Creates
[NN]-spec-[feature-name].md and [NN]-questions-1-[feature-name].md
- - Task Planning Phase: Creates
[NN]-tasks-[feature-name].md
- - Implementation Phase: Creates
[NN]-proofs/[NN]-task-[TT]-proofs.md files as tasks are completed
- - Validation Phase: Creates
[NN]-validation-[feature-name].md with final validation report
-
- This structure provides a complete audit trail from requirements to implementation, with each artifact serving as evidence in the validation process.
+
+
+
diff --git a/docs/reference-materials.html b/docs/reference-materials.html
index ce1aeed..eb2e3d7 100644
--- a/docs/reference-materials.html
+++ b/docs/reference-materials.html
@@ -20,9 +20,19 @@
Reference Materials
- Complete documentation and proof artifacts from a real Spec-Driven Development workflow
+ Complete documentation, workflow logic, and proof artifacts from a real
+ Spec-Driven Development run
- These reference materials demonstrate a complete Spec-Driven Development workflow in action. They document the implementation of a cspell pre-commit hook feature, showing the full SDD process from initial conversation through specification, task breakdown, implementation proofs, and validation.
+ These reference materials demonstrate a complete Spec-Driven Development workflow in action. They
+ document the implementation of a cspell pre-commit hook feature, showing the full SDD process
+ from initial conversation through specification, task breakdown, implementation proofs, and
+ validation.
+ Taken together, they are more than evidence that the workflow worked. They also expose the
+ internal logic of the method so engineers can study how SDD structures intent, guides AI, and
+ verifies outcomes.
+ This page preserves one complete run for study and demonstration. Teams may keep, archive,
+ externalize, or discard these artifacts differently depending on how they manage planning,
+ ticketing, and AI context in their own environment.
@@ -40,7 +50,8 @@ Core Documentation
AI Conversation
- Complete AI-assisted development conversation and decision making process
+ Complete AI-assisted development conversation showing how intent, constraints, and decisions
+ were shaped
View Documentation
Technical specification for the cspell pre-commit hook implementation
+Technical specification showing how requirements, boundaries, and success criteria were made + explicit
View SpecificationDetailed task breakdown and implementation roadmap
+Detailed task breakdown showing how the spec was converted into an executable implementation + plan
View TasksThese artifacts show how SDD turns implementation into something visible. Each proof document is + both evidence of completion and an example of how to make AI-driven work verifiable.
+