This page exists to remove ambiguity fast. Answers are short, direct, and aligned with the same shared-working-layer model described on the homepage and mechanics page.
If something still feels fuzzy after the main positioning pages, it should become concrete here.
Every answer should make the model clearer while avoiding overclaim.
SpecViber is a shared working layer for AI-assisted development. It gives the developer and the AI agent one connected working layer — same documents, same task objects, same state, same routines — for planning, execution, progress, verification, and closing.
No. SpecViber drops into the project you already have. Your repo, markdown, IDE, git workflow, and AI assistant stay where they are — the shared working layer is added around them.
No. It works from day one in new projects and can also be added later. Being able to add it later is a strength, not the main identity.
No. Chat is fast for starting and driving work, but documents, tasks, relations, status, and verification stay readable in the project. The agent works against the same shared layer as you do — not from a chat snapshot.
Because developers already write specs, notes, design decisions, READMEs, and implementation plans in markdown. SpecViber starts from that familiar material and makes it operational instead of replacing it with a proprietary format.
Regular markdown files that gain operational meaning — properties, comments, relations, status, tracked checkboxes — without ceasing to be readable markdown in your repo.
A task is the simpler work unit in a flow. An action spec is a living document that carries the work from problem statement to verified delivery — plan, steps, progress, and verification in one place.
That the board doesn't just show work after the fact. Tasks and action specs move there in real time, with the same status and progress the document and the agent are working against.
Because a project with many interconnected documents and work objects otherwise becomes hard to navigate.
Because AI-assisted work often fails at the last step — the chat says it's done before anything was actually checked. A close-guard plus explicit verification steps keeps a spec from closing while open work remains.
The strongest current public fit is a developer or technical lead. The team story matters, but it's meant to come as the next layer.
Web UI gives overview, dashboard, and flow reading. VS Code gives document-near collaboration close to the files. Both work against the same shared working layer underneath.
Both work against the same documents, the same task objects, the same relations, the same IDs, and the same rules. The agent reads the shared working layer through MCP; you read it through the Web UI and VS Code.
Access is invite-only in phase 1a. Start by deciding fit. If the model fits the project, request an invite or contact us directly.
The page exists for serious evaluation. The content is kept conservative and marks what isn't yet public to avoid overclaim.