Comparing SDD to Other Structured Development Tools
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 repo-local SDD workflow 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 skill and prompt 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.
Comparison: Liatrio SDD vs. Other Structured Development Tools
The table below compares Liatrio's SDD workflow 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 SDD Workflow | Kiro | SpecKit | Taskmaster |
|---|---|---|---|---|
| Setup & Installation | ✅ 4-phase workflow installed as an explicit-invocation agent skill (custom prompts also available) | ❌ 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 | ✅ Skill-first; prompt and slash-command installs remain available for compatible editors | ❌ 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 best with assistants that support agent skills; also supports custom prompts and 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 | ✅ Uses a guided four-phase 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 | ✅ Skill and prompt instructions 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 | ✅ Skill or prompt text can be adapted 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 | ✅ 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 | ✅ 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 | ✅ Minimal setup overhead with the recommended skill path; prompt installs remain available when needed | ❌ 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 | ✅ Markdown skill and prompt 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 |
Repo-Native Setup
The recommended entry point is the agent skill for skill-native assistants. Prompt files remain available for slash/custom command workflows, and manual copy-paste remains available for teams that want no installation at all.
The skill path is intentionally user-invoked rather than automatic: once called, it performs the same repository-state assessment and phase routing as the prompt workflow.
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 GitHub README quickstart for current setup details.
That same simplicity also makes SDD useful as a teaching tool: engineers can read the workflow instructions, understand the patterns they encode, and reuse those patterns when working with AI in other contexts.
The Bottom Line
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 SDD workflow aims 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 workflow is intentionally different. It exposes 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.