This page shows how SpecViber gives the developer and the AI agent one shared working layer for the full development loop — planning, execution, progress, verification, and closing.
At the centre is the action spec: a living markdown document that carries the work forward instead of leaving the plan, progress, and verification scattered across chat, docs, and memory.
Problem analysis → planning → execution → progress tracking → verification → closing → next spec.
Same documents, same task objects, same state throughout — instead of a plan in one place, progress in another, and verification nowhere.
SpecViber drops into the project that already exists. Your repo, your markdown, your IDE, your git workflow and your AI assistant stay where they are.
The shared working layer is added around them — it doesn't replace the foundation.
Your code and your documents never leave your machine. Only the metadata that coordinates the work is shared.
Before any code is written, the agent can draft the first action spec: the problem, the goal, the relevant context, related documents and dependencies, a proposed solution, implementation steps, possible sub-specs, and verification criteria.
You review the plan directly in the document and leave inline comments where the decisions belong. The agent responds, updates the spec, and sharpens the plan until it's clear enough to execute.
Most AI coding failures don't start in the code. They start earlier — with an unclear problem, missing context, or a weak plan. SpecViber makes planning part of the working system instead of letting it scroll away in chat.
Once the plan is ready, the action spec becomes the working map. The agent doesn't just emit code and leave you to reconstruct what happened.
It keeps the spec current as work moves: steps checked off, blockers flagged, missing steps added, open questions attached to the right place.
Checkboxes carry real work states — todo, in progress, done, cancelled, blocked, needs investigation — so the work is readable while it's happening, not only afterwards in a summary.
When you need to understand the reasoning, you read the document. When you need to choose what to do next, you read Kanban. When you need to orient yourself in a dense project, you read the relation graph. When you want to drive work fast, you use chat. Same project objects underneath.
Different surfaces. Same shared working layer. The agent reads it through MCP; you read it through the Web UI and VS Code.
Document — reasoning & plan
Kanban — live cockpit
Graph — relations you can walk
Chat — momentum, same spec
Every action spec can end with explicit verification steps. The agent runs the checks it can handle itself: terminal commands, syntax checks, tests, API calls, other automated validation. Anything needing human judgment, UI interaction, or external confirmation stays visible for you to handle.
A close-guard keeps a spec from being marked done while open steps, failed checks, or unmet criteria remain. Every step is logged and timestamped, so closing a spec leaves a record rather than a vague “done.”
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.
Usually in a document — or in a chat conversation that becomes an action spec the agent and you can plan against together.
A task is enough when the work mainly needs to move through the flow. An action spec is the right level when the work needs to carry plan, execution, and verification in one living object.
No. The point isn't to always use everything — it's that every surface reads the same shared working layer when you need it.