Vibe coding that actually holds together

Keep the speed of AI-assisted coding — and lose the guessing, the lost context, and the work that quietly breaks

AI gets you moving fast. Then, past the first burst, it starts to drift — the agent forgets what you decided, you re-explain the project, “done” turns out not to be done.

SpecViber closes that gap. It gives the developer and the AI agent one connected working layer for the work itself — same documents, same task objects, same state, same routines — without taking over your repo, your markdown, or your tools.

Invite-only in phase 1a. Add it from the first spec or drop it into a running project — it works from day one and compounds as the project grows.

See how it works Request an invite
Composite illustration: one action spec carried across the project, board, and chat

One spec carried across document, board, graph, and chat — instead of rebuilding the project state in each place.

The core idea

The whole loop runs on one shared layer

Problem analysis → planning → execution → progress → verification → closing → the next spec. The full loop runs on one connected working layer instead of being scattered across chat, tickets, and memory.

At the centre is the action spec — a living markdown document that carries the work from the first problem statement to a checked, documented delivery. Everything below is a different surface onto that same layer.

Shared working layer Markdown that does the work Verification before done
The full loop: seven stages — problem analysis, planning, execution, progress, verification, closing, next spec — arranged in a ring around a central action spec
Every stage points back to the same action spec at the centre — one document carries the whole loop.
Markdown that does the work

Your .md files become work objects

The same files you already write for specs, notes, and plans — now carrying status, progress, comments, relations, and checkboxes that you and every agent read the same way.

Operational, not decorative. A checkbox is real progress, a comment is a tracked thread, a relation is a link you can walk. Nothing lives only in someone's head or scrolls away in a chat window.

Because it's still plain markdown in your repo, it works with the tools you already use — your editor, your diff, your git history — and stays readable even with SpecViber switched off.

See how markdown becomes operational →
A SpecViber document view: a markdown file carrying status, checkboxes, comments and relations
An ordinary markdown file, made operational.
Action specs at the centre

Plan, execute, and verify in one living document

A single document carries the work from the first problem statement to a checked, documented delivery — instead of scattering it across a chat log, a ticket, and a half-remembered plan.

Planning is part of the system. The analysis, the plan, the step-by-step checklist, inline comments, and the acceptance criteria all live in one place and update as the work moves.

The agent works on the same spec you do. You hand it the document, it ticks off steps and leaves notes; you stay in control of direction and sign-off. The spec is the shared source of truth, not the conversation.

How an action spec works →
An action spec with plan, checkboxes, comments and verification steps, linked to its task
One document, the whole job — from first idea to verified done.
Not more context. A shared working layer.

The same spec, carried across every surface

Most AI setups feed the agent text and hope it rebuilds your project state every turn. SpecViber lets you and the agent act on the same documents, tasks, relations, and verification — each through the surface that fits best.

Read and edit a spec as a document. Track it as a card on the board. See how it connects in the graph. Drive it from chat via MCP. Four views, one underlying state — change it in one place and it's the same everywhere.

That's the difference between handing an agent a fresh snapshot every session and giving it a working layer it can stand on.

The shared working layer: one project state reflected across document, board, graph, and chat
Document, board, graph, and chat — all pointing back to one working layer.
Kanban as one live cockpit

One board for you and the agent

Tasks and action specs share one flow. Assign work to the agent, follow the card, open the related spec, and watch progress update as the work actually moves.

It's a live cockpit for developer-led AI work, not just a planning view you fill in once and forget. Status changes on the board reflect real state in the documents underneath — what's in progress, what's blocked, what's waiting on you.

From any card you're one click from the spec that drives it, the related documents, and the history of how it got here.

See the board in action →
A Kanban board where tasks and action specs share one flow, with live status columns
Tasks and action specs on one live flow.
Relations you can see and walk

A project you can navigate, not just search

As a project grows, search isn't enough. Explicit relations make it navigable as a connected system instead of a flat pile of files.

Typed links carry meaning. references, depends_on, part_of, supersedes — each says something specific about how two pieces of work relate, so you and the agent both know what depends on what.

From any document or task, see what's connected and jump straight to it. When you change something, you can trace what it affects before it surprises you.

Explore the relation graph →
A relation graph showing documents and tasks connected by typed relations
The project as a connected system, not a flat list.
Verification before done

Done because it's verified — not because the chat says so

Every action spec can end with explicit verification steps, so "done" means the work was actually checked — not that an agent declared victory in a message.

The agent verifies what it can. It runs terminal commands, syntax checks, and tests itself and ticks off the results. Anything that needs human judgment stays visible and assigned to you, clearly marked.

A close-guard holds the line. A spec can't be quietly marked done while verification steps are still open — so unfinished work doesn't slip through as finished.

How the close-guard works →
A close-guard preventing a spec from closing while verification steps remain open
A close-guard that keeps “done” honest.
MCP-native, no vendor lock-in

Works with the assistant you already use

SpecViber adds a working layer around your existing repos, markdown, IDE, and LLM — instead of replacing them or asking you to move into a new walled garden.

The agent side is MCP-native. GitHub Copilot, Claude Code, Cursor and others connect through the same open protocol, so you keep the assistant you already trust and your existing workflow around it.

Your code stays yours. Documents and source never leave your machine; only the metadata that coordinates the work is shared. Switch SpecViber off and you're left with plain markdown in your own repo — nothing to migrate out of.

Web UI and VS Code extension →
The SpecViber VS Code extension working alongside the editor through MCP
Same working layer, near your files.
Outcomes

What changes for you

Less time reconstructing context. Less guessing from the agent. Fewer lost tasks. Clearer progress. Cleaner handoffs. A path from first idea to verified code that holds up as the project grows.

Less rebuilding context

The agent stops working from a loose snapshot of the project. The developer stops explaining the project state every session.

Done means verified

Close-guard, explicit verification steps, and a logged trail mean a spec isn't done because the chat says so — it's done because the plan, progress, and checks all agree.

Holds together as it grows

The structure that keeps a small task clear is what keeps a large project understandable. Built to stay useful through the messy middle, not only on day one.

Who this is for now

Built first for one developer

SpecViber is strongest when a developer or technical lead wants to make a real project hold together better.

The team layer comes naturally on top

Same tasks, same specs, same status, same reality. The team story matters — but it's a next layer, not the opening promise.

Read about the team layer →
Next step

Understand the model first. Take the next step later.

Read more about how the work flows or go deeper into the mechanics. If the way of working fits your project, you can then request an invite.

How it works

Plain-language overview of the workflow

Read page →

Mechanics

The operative model behind the workflow

Read page →

Security & privacy

Current public status and what is still unspecified

Read page →

Pricing & access

How access works right now

Read page →

FAQ

Straight answers to common questions

Read page →

Team

What the team layer adds on top of the single-developer workflow

Read page →

Contact

Start a conversation about fit or next steps

Read page →
Read the mechanics Request an invite
Common questions

Three quick answers

Is this only for projects that already exist?

No. It works from day one in a new project and can also be added later. Being able to add it afterwards is a strength, not the product's identity.

Is this just an AI chat in practice?

No. Chat is fast for starting work, but documents, tasks, relations, status, and verification need to stay readable in the project — that shared working layer is the whole point.

Why is markdown so central?

Because developers already use markdown for specs, notes, READMEs, and implementation plans. SpecViber starts there and makes those files operational instead of replacing them with a proprietary format.