DEV Community: Andrey

Skaro 2.0: Not Another AI Coding Tool, but a Workspace for Building Software With AI

Andrey — Mon, 13 Apr 2026 13:24:36 +0000

I wrote about Skaro before, but since then the project has changed quite a lot.

Version 2.0 is not a cosmetic update. It is a deeper rethink of how the product should work and what kind of collaboration model it should support.

So instead of posting a simple changelog, I want to explain what Skaro actually is, why I keep building it, and where I want to take it next.

The question I get the most

Whenever I show a new AI tool for software development, I get the same question almost immediately:

How is this different from Cursor, Codex, Claude Code, and why build something else at all?

That is a fair question. But I think the problem is in the framing.

Most people try to place Skaro into an existing category: editor, coding agent, code generator, or just another UI around an LLM.

That is not how I think about it.

Skaro was never meant to be just another utility that helps write code faster. And it was not meant to be just a chat where you occasionally paste pieces of a project.

The idea is different.

What Skaro is

In short, Skaro is a collaborator and a workspace for building software projects together with AI.

Not in the sense of replacing the developer.

Not in the sense of asking the model to do everything on its own.

But in the sense of real collaboration, where the human and the AI have different roles, and those roles are separated in a natural way.

The human leads the project. The human owns the intent, the key decisions, the architecture, the constraints, and the meaning behind the work.

The AI acts as engineering leverage. It helps discuss ideas, shape documents, break work into stages, define tasks, implement changes, return to context, and push things toward completion.

That is the model that makes sense to me.

^{There is a typo in the generated image :)}

Why I felt this tool needed to exist

Once you start building software with AI seriously, one problem shows up very quickly.

Human + AI collaboration produces a large amount of decisions, assumptions, agreements, intermediate conclusions, corrections, and context. You cannot keep all of that in your head. And you cannot scatter it across random chats either.

At some point, a project starts to fall apart not because there is not enough code, but because the thread gets lost:

why a certain decision was made
what the architecture depends on
what was already agreed on
how one task relates to another
which constraints were already established

That is why I think an AI-assisted project needs external memory.

Not a detached knowledge base somewhere on the side, but a working structure that lives close to the project itself and stays visible during everyday work.

Why artifacts are at the center of Skaro

That is what artifacts are for in Skaro.

Artifacts are not documents for the sake of documents. And they are not bureaucracy layered on top of development.

They are the recorded output of what was already discussed, designed, and agreed on: architecture, plans, milestones, tasks, and other important project decisions.

That gives the human a stable thread to follow.

And it gives the AI something better than a blank slate every time. The model can work from an existing foundation instead of guessing from a short prompt.

For me, this is one of the key ideas.

If a project is developed together with AI, then an important part of the context should live not only in the author’s head and not only in chat history, but in a clear structure inside the repository.

That is what gives the work continuity.

This is what the .skaro folder structure looks like: (trimmed)

.skaro
│   config.yaml
│   constitution.md
│   devplan.md
│   secrets.yaml
│   state.yaml
│   token_usage.yaml
│   usage_log.jsonl
│
├───architecture
│   │   adr-001-using-fastapi-as-web-framework.md
│   │   adr-002-simplified-layered-monolith-as-architectural-pattern.md
│   │   adr-003-using-psutil-for-system-metrics.md
│   │   adr-004-no-database-in-favor-of-stateless-architecture.md
│   │   adr-005-no-docker-in-favor-of-native-windows-run.md
│   │   adr-006-no-authentication-and-authorization-for-public-....md
│   │   adr-007-using-pydantic-settings-for-config.md
│   │   adr-008-sync-psutil-calls-in-async-endpoints.md
│   │   adr-009-testing-strategy
│   │   architecture.md
│   │   chat-conversation.json
│   │
│   └───diagrams
├───chat
│       tasks.json
│
├───docs
│       review-results.json
│
├───features
├───milestones
│   ├───01-foundation
│   │   │   milestone.md
│   │   │   order.json
│   │   │
│   │   ├───config-module
│   │   │   │   clarifications.md
│   │   │   │   plan.md
│   │   │   │   spec.md
│   │   │   │   tasks.md
│   │   │   │   tests-confirmed
│   │   │   │   tests.json
│   │   │   │   verify.yaml
│   │   │   │
│   │   │   └───stages
│   │   │       └───stage-01
│   │   │               AI_NOTES.md
│   │   │
├───models_cache
│       groq.json
│
├───ops
└───templates
        adr-template.md
        ai-notes-template.md
        architecture-template.md
        constitution-template.md
        devplan-template.md
        plan-template.md
        security-checklist.md
        spec-template.md

What the workflow is supposed to look like

The workflow I believe in looks roughly like this:

First, the human and the AI think through the project and create the core architecture documents.

Then those documents are used to shape a plan, break it into milestones, and define concrete tasks.

Only after that does implementation begin, again with AI, but no longer in a chaotic way. It happens with a recorded foundation behind it.

This is also why chat matters to me — but only where discussion is actually needed.

The point is not “the product has chat.”

There is already enough chat in the world.

The point is that architecture, plans, tasks, and other working materials can be discussed right where they live, and the result can be saved directly into the repository.

That keeps the workflow coherent. Context stays attached to the thing it belongs to.

What changed in Skaro 2.0

With version 2.0, my goal was not to add isolated features.

The goal was to improve the overall process of human + AI collaboration around a software project.

Not “a few more screens,” but a product that makes this way of working more understandable, more natural, and more usable in day-to-day practice.

Here are the changes that matter most to me.

Chat is now embedded where the work happens

In Skaro 2.0, chat is available wherever discussion with AI is actually part of the workflow.

That matters not because “there is now a chat inside the product.” Plenty of tools already have that.

What matters is that the discussion now happens in the context of artifacts, tasks, and working pages. You do not have to leave the workflow or move important conversations into a disconnected place.

The model gets a real starting point before implementation

Before executing a task, the LLM receives an initial project context and can then request the files it needs for implementation.

That is an important step toward consistency.

The model is not just given a short prompt and expected to work almost blindly. It starts from a defined context and can retrieve the relevant material within the scope of the task.

That makes the implementation more coherent and reduces the number of cases where generated changes drift away from decisions that were already made.

Auto-commit when a task is completed

There is now an option to enable automatic commits after task completion.

This does not look like a headline feature, but in practice it is genuinely useful.

When your workflow is moving quickly, small things like this reduce friction and help maintain momentum.

Statistics now live on a separate page

This made the interface cleaner and easier to reason about.

Core workflows no longer compete for space on the same screen, and model usage and activity metrics are easier to inspect in a dedicated place.

The start page reflects project state better

The start page now includes a Kanban-style task board.

This is not just a nicer overview. It gives a quick read on the current project state, shows where work stopped, and helps you get back into the flow without extra navigation.

For a tool that is supposed to help run a project, not just generate code fragments, that matters a lot.

The interface became more flexible and more calm

Version 2.0 adds lightweight theme customization. You can choose an accent color or set your own.

More broadly, the UI was improved to feel more stable and predictable during daily use.

I do not think of interface design as decoration. If a product is meant to be a real workspace, it should feel calm, readable, and consistent.

So in 2.0 I paid attention not only to what was added, but also to how the product feels while you work in it every day.

Known issues were also fixed

A less glamorous but important part of the work in 2.0 was fixing known issues that were getting in the way of the product being used the way it was intended.

For me, that kind of work matters just as much as shipping new features.

If a tool wants to become a long-term workspace, it has to be solid in everyday use, not only interesting as an idea.

Where I want to take the project next

The core of Skaro will remain Open Source.

That is a principle for me.

The underlying idea — building software with AI around artifacts, project memory, and a tighter link between discussion and implementation — should stay open.

At the same time, I want to build a separate workspace layer around Skaro for teams and companies.

That means a broader collaboration environment: access control, analytics, cost visibility, boards, shared workflows, and other capabilities that matter when the product is used by a team rather than a single developer.

That feels like the next logical layer.

But the open source core is not going away, and it is not meant to become a closed showcase.

Final thoughts

I do not see Skaro as an attempt to make “just another AI coding tool.”

And I do not see it as another shell around a model.

I see it as a working environment where humans and AI build software projects together, while key decisions, plans, milestones, and tasks are stored in a clear structure so the project does not dissolve into memory and scattered chat threads.

That is what Skaro 2.0 was rebuilt for.

If this model resonates with you, I would genuinely like to hear your thoughts.

And if you are already building software with AI and have run into the same problems — project memory, decision consistency, context loss — I would be especially interested in comparing approaches.

GitHub: https://github.com/skarodev/skaro

Website: https://skaro.dev

Docs: https://docs.skaro.dev

Telegram: https://t.me/skarodev

Discord: https://discord.gg/zUv6AHuJwD

Skaro — AI-Powered Software Development Platform

Andrey — Tue, 10 Mar 2026 15:24:24 +0000

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.

GitHub · Docs · Website

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 stage automatically
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: