This is the page for anyone who wants to understand why SpecViber isn't just a nicer surface, but a real shared working layer for AI-assisted development.
Each side through the surface that fits it best. The developer in the Web UI and VS Code. The agent through MCP tools, instructions, and skills. Same documents, same task objects, same state, same routines.
Document metadata, checklist and comment states, relations, assignments, history, task information — readable and writable from both sides.
Your markdown and your code stay in your project; SpecViber holds the metadata that coordinates the work.
The point is not that both sides see the same UI. The point is that both sides read and write the same coordination layer: document metadata, checklist states, relations, assignments, history, and task information.
That is why the agent stops working from a loose snapshot and starts working against the same live project state as the developer.
SpecViber drops into an existing setup because it doesn't replace the foundation; it adds a working layer around it. Existing repos, existing markdown, existing IDE, existing LLM, existing habits. Because the agent side is MCP-native, it works with the assistant you already use — Copilot, Claude Code, Cursor and others — with no vendor lock-in.
Your code and your documents never leave your machine. SpecViber stores only the metadata it needs to coordinate the work — states, relations, assignments, history.
SpecViber starts from ordinary markdown because that's already where developers write specs, notes, design decisions, READMEs and implementation plans. It doesn't lock those files into a proprietary format; it makes them operational.
A markdown file becomes a structured work object with status, progress, comments, relations, checkboxes, metadata and task connections — useful for the human reading it, the agent acting on it, and the system tracking the state of the project. The document stops being passive text and becomes part of the workflow.
Clear, readable metadata close to the content.
Discussion in the right place in the right document.
Real work states — todo, in progress, done, dropped, blocked, needs research — readable while work happens.
Documents and work objects explicitly linked: references, depends_on, part_of, supersedes.
The state of the work becomes visible without the document ceasing to be readable.
A task is a work object that's easy to pick up, assign, and track through a flow. An action spec is a living markdown document that carries the work from the first problem statement to a checked, documented delivery — problem, plan, steps, sub-specs, progress, and verification in the same structure.
Task for flow. Action spec for carrying work end-to-end with the agent and you working against the same plan.
Tasks and action specs share one Kanban flow, so the board is more than a planning view — it becomes a live cockpit for developer-led AI work. See what's waiting, in progress, blocked, or ready for review. Assign work to the agent, follow the card, open the related spec, and watch progress update as the work moves.
Because the board, documents, comments, tasks, relations, and verification steps all point back to the same shared working layer, the whole project becomes easier to steer.
As a project grows, search isn't enough. You need to understand how things connect. SpecViber makes relations explicit: a document can reference another document, a spec can depend on another spec, a decision can supersede an older one, a task can belong to a larger action spec, and one direction can conflict with another.
Those relations aren't just metadata buried in a table. The relation viewer lets you explore them graphically: from any object — document or task — you can see related objects and navigate straight to them, with key information surfaced as you go: progress, status, assignments, content and more.
That helps the developer navigate the project, and it helps the agent load the right context before acting. The project becomes not just searchable, but understandable as a connected system.
Chat is often the fastest way into work — that's where you ask the agent to investigate, break down, write, pick up, and suggest next steps. The difference in SpecViber is that the agent doesn't work in a vacuum. It works against the same documents, tasks, relations, and rules as the rest of the system, and the state of the work stays readable in the project even after the chat scrolls away.
The web UI is your overview and dashboard surface. The VS Code extension is your document-near collaboration surface, close to the files. Both should be described as parts of the same method, not as competing interfaces.
Web UI — overview and dashboard
VS Code — document-near work
AI-assisted work often fails at the last step. Something looks done, the chat says it's done, but nothing was actually checked. 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 the developer.
A close-guard keeps a spec from being marked done while open steps, failed checks, or unmet criteria remain — so a spec isn't complete because the agent says so, but because the plan, the progress, the checklist, and the verification all point to the same conclusion. Every step is logged and timestamped, so closing a spec leaves a record rather than a vague “done.”
That's how SpecViber keeps vibe coding honest.
If the mechanics resonate with the way you want to work, request an invite or read how access works.
Regular .md files that gain status, progress, comments, relations, and tracked checkboxes — without ceasing to be regular, readable markdown files in your repo.
Because some work needs to carry plan, execution, and verification in the same object. That's what action specs do — and why they sit at the centre of the workflow.
Because AI-assisted work often fails at the last step — the chat says it's done before anything was actually checked. Close-guard plus explicit verification steps keeps a spec from closing while open work remains.
No. The agent side is MCP-native, so it works with the assistant you already use — GitHub Copilot, Claude Code, Cursor and others.