SpecViber creates a shared project layer where developers and AI agents can plan, structure, execute, and verify development work together.
Action specs turn larger goals into connected, executable steps. Documents preserve the reasoning. Tasks, status, and relationships show what is happening and what comes next. The developer uses familiar interfaces; the agent uses purpose-built tools—but both work with the same context, methods, and live project state.
Document metadata, checklist and comment states, relations, assignments, history, task information — readable and writable from both sides.
Your markdown text and your code stay in your project; SpecViber holds the metadata that coordinates the work, such as titles, statuses, checklist lines, tasks and comments.
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 document text stay on your machine. SpecViber stores the metadata it needs to coordinate the work — titles and paths, states, checklist lines, relations, tasks, comments and 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 are views of the same project layer — use one or both, or work entirely from the chat.
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 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.” A close-guard works in the background as a safety net: if a spec is closed while open steps, failed checks, or unmet criteria remain, it flags it and recommends the status that matches the actual state.
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. Explicit verification steps make the checks part of the job, and a close-guard flags a spec that is closed 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.