A while back I published an article about my AI-coding practices. The comments introduced me to the SDD (Spec-Driven Development) methodology — and that sparked an idea.
What if I built a tool that manages and automates the entire development process — one based on specs and controlled code generation, with no context loss between sessions?
I dove in. Almost no sleep for several days. Yesterday I shipped the MVP.
Meet Skaro.
How It Works
Skaro structures development as a sequential pipeline:
- Constitution — tech stack, code standards, test requirements, security policies, LLM rules
- Architecture — project overview, components, data storage, interactions, infrastructure, integrations, trade-offs
- Dev Plan — milestones and tasks
- Tasks — each task has its own pipeline: spec → clarification → plan → implementation → tests
- Review — repository-wide check against all pipeline stages, LLM chat for fixing issues
All artifacts (specs, plans, LLM Q&A) are stored in .skaro/ alongside the code and committed to the repo. Context is never lost between sessions.
Roles
Each role can be assigned its own model — some models excel at coding, others at planning and architecture reasoning. Personally, I use Anthropic Opus 4.6 for all roles.
| Role | Responsibility |
|---|---|
| Architect | Architecture generation & review, ADR |
| Coder | Stage-by-stage task implementation |
| Reviewer | Repository check, error fixing |
The dashboard shows project statistics: token consumption broken down by role and task, file stats, and pipeline progress.
1. Installation
Requires Python 3.11+.
Windows (PowerShell):
irm https://raw.githubusercontent.com/skarodev/skaro/main/install.ps1 | iex
Linux / macOS:
curl -fsSL https://raw.githubusercontent.com/skarodev/skaro/main/install.sh | sh
The script creates an isolated venv in ~/.skaro/ and installs the CLI. Re-running it detects the existing venv and upgrades in place.
Alternatively — via pipx or uv:
pipx install skaro
# or
uv tool install skaro
Verify the installation:
skaro --version
2. Project Initialization
cd my-project
skaro init
skaro ui
skaro init handles two scenarios:
-
New project — creates a
.skaro/directory with empty constitution, architecture, and config templates - Existing repo — Skaro analyzes the codebase and auto-generates the constitution and architecture from the found code; you only need to create the plan and tasks
skaro ui launches the web dashboard at http://localhost:4700.
Multiple projects can run simultaneously — each additional one opens on port 4700+1.
Check the current project state from the terminal:
skaro status
3. LLM Configuration
Providers and models are configured via the UI — separately for each role (architect, coder, reviewer).
Supported providers:
| Provider | API Key Required | Default Model |
|---|---|---|
| Anthropic | yes | claude-sonnet-4-6 |
| OpenAI | yes | gpt-5.2 |
| Groq | yes | llama-3.3-70b-versatile |
| Ollama | no | qwen3:32b |
Keys are stored locally and only sent to the selected provider.
More in documentation: https://docs.skaro.dev/providers/supported-providers
4. Constitution
The Constitution is a document that defines project rules for the LLM: tech stack, code standards, test requirements, security policies.
Fill it in manually with the built-in MD editor or pick a ready-made preset.
Available presets: React, Next.js, SvelteKit, Vue, Angular, FastAPI, Django, NestJS, Express, Flutter, React Native, Kotlin Multiplatform.
Example constitution block:
## LLM Rules
- No stubs without an explicit TODO and justification
- No code duplication: prefer reuse and clear abstractions
- No hidden assumptions — ask when uncertain
- Always generate AI_NOTES.md from the template
5. Architecture
Architecture is the key document for the LLM. It starts with an Overview: what is being built and what problem it solves. Without this context the model doesn't understand the project's goals. It then describes components and their responsibilities, data stores, interaction protocols, infrastructure, external integrations, and known trade-offs.
New: Architecture can now be generated with an LLM. The Architect role analyzes your filled-in overview and proposes a full architecture for your review and approval.
Once approved, the architecture is locked and becomes the context for all subsequent tasks.
5.1 ADR
After the architecture is approved, Skaro offers to generate ADR (Architecture Decision Records) — documents that capture key architectural decisions: what was decided, what alternatives were considered, and why they were rejected. ADRs are stored in the repo and serve as historical context for the whole team.
6. Dev Plan
The dev plan is structured around milestones. Each milestone contains a list of tasks with dependencies and statuses.
Tasks can be generated from the architecture via LLM or added manually. The plan template lives in .skaro/devplan.md and is directly editable.
7. Tasks
7.1 Generating Tasks from the Dev Plan
Tasks are generated from the plan in one action. Each task gets its own directory at .skaro/milestones/<milestone>/<task>/.
7.2 Task Specification
The spec describes the task from a template: context, user scenarios, functional and non-functional requirements, explicit constraints, acceptance criteria.
A clear spec is the foundation of quality implementation. The more precisely it's described, the fewer gaps there are.
7.3 LLM Q&A
After reading the spec, the LLM Architect asks clarifying questions. Answers are saved as task artifacts and included in the generation context.
7.4 Implementation Plan & Stage Breakdown
Based on the spec and Q&A answers, the Coder role builds a step-by-step implementation plan. Each stage is an atomic set of changes that can be implemented and verified independently.
7.5 Stage-by-Stage Implementation
The Coder role implements the task stage by stage. Each stage produces a list of files with their contents.
7.6 File Confirmation
Before writing to disk, a full diff is available for each new or modified file. The developer explicitly confirms saving — no automatic overwriting.
7.7 Git
The built-in Git section shows a list of changed files with their statuses. For each file you can view the diff, select files for staging, write a commit message, push changes, or create a new branch — all from the dashboard UI.
7.8 Tests
The test phase performs a structural check of the task: are all files from the plan present on disk, are there test files in the project, is the spec filled in, are all implementation stages complete. You can also configure arbitrary verification commands in verify.yaml — they'll be executed automatically.
The LLM proposes corrected files:
🤖 Autopilot
Put a task on autopilot and go grab a coffee ☕
When autopilot is running:
- Asks clarifying questions and answers them itself — no interruptions needed
- Forms an execution plan — breaks the task into atomic stages
- Sequentially implements each stage — from spec to working code
-
Adds new files to
git stageautomatically - Runs tests — missing tests are silently skipped
Every stage is saved as it completes, so you can return to any step later and continue from there.
8. Review
8.1 Repository Check
Review performs a project-wide check: is the constitution approved, is the architecture confirmed, are all tasks implemented and tested, are there any open milestones. Global verification commands from the config are also run.
8.2 LLM Chat for Fixing Issues
After the review a chat session opens. Before sending, you can select a scope — specific tasks or milestones for the LLM to take as context. Describe the problem, the LLM proposes fixes using the same diff-view and file-confirmation mechanism.
Get Started
Skaro is licensed under AGPL-3.0 — the core stays open and free.
A first real project built entirely in Skaro: Tic-Tac-Toe.
I'd love feedback and any criticism — drop it in the comments or reach out via the links below.
Links:
Top comments (0)