Philosophy · ATOA

COLLABORATIVE VIBE CODING

ATOA is a collaborative Vibe Coding mode built around four ideas: cloud-hosted creation, private sessions, instant collaboration, and your personal Agent. Keep creating privately while the cloud turns accepted work into a live, runnable application.

THE MODE

Four Features of ATOA

Keep the creative process personal, remove operational friction, and collaborate through results that can be validated and experienced immediately.

No environment setup. Direct deployment.

No clone, dependency setup, runtime configuration, or local deployment. The cloud owns the environment, then validates, merges, and deploys accepted work directly as a runnable Demo.

Private sessions. Shared outcomes.

Your prompts, experiments, and development conversation remain participant-only. Collaborators see sanitized intent, implementation summaries, validation results, and runnable Demos—not your raw session.

Instant collaboration

The control plane now dispatches tasks together when their source Context paths do not overlap. Overlapping tasks remain queued, incremental Context cannot cross an active reservation, and every candidate is still hash-checked and validated before merge. Finer symbol-level dependency analysis is in development.

Bring your own Agent and tokens

Choose your preferred private Coding Agent and manage your own model tokens instead of buying model access from the platform.

LOCAL AGENT TOOLING

Install the ATOA Agent Kit

The Agent Kit connects your private Coding Agent to an ATOA project without cloning the project or moving your development conversation into the platform.

Linux / macOS

curl -fsSL https://YOUR_DOMAIN/agent-kit/install.sh | env ATOA_BASE_URL=https://YOUR_DOMAIN/agent-kit ATOA_ENDPOINT=https://YOUR_DOMAIN bash

Windows PowerShell $env:ATOA_BASE_URL="https://YOUR_DOMAIN/agent-kit"; irm https://YOUR_DOMAIN/agent-kit/install.ps1 | iex

Requires Node.js 22 or newer. Register once with an invitation, then sign in with that existing account. After installation, start a new Agent session so the installed Skill and plugin are loaded.

01atoa

CLI · Local control surface

The CLI stores the selected ATOA server and authenticated Agent identity locally. It provides explicit commands for authentication, project discovery, task creation, Context requests, progress, candidate submission, and usage inspection.

auth checks or establishes the user identity.
delegate drives the task contract and candidate lifecycle.
worker waits locally only while queued tasks exist, then starts a fresh client Agent after dispatch.
cloud reads project metadata, revisions, tests, and history.

02ATOA Agent Plugin

Plugin · Structured Agent tools

The Agent plugin exposes ATOA operations as typed MCP tools. Your Agent can resolve the exact project, hand a queued delegation to the on-demand local Worker, claim it after dispatch, request missing Context, and submit a candidate without constructing fragile shell commands or parsing page copy.

Tool inputs bind actions to a project and task ID.
Tool results return contracts, policy, revisions, and validation state.
The plugin never grants merge authority to the client Agent.

03$atoa-cocreation

Skill · Collaboration procedure

The Skill teaches the Agent how to use those tools safely and in the correct order. It keeps the session focused on the selected project, requires incremental Context instead of guessing, prefers compact hash-bound operations, and continues through server feedback until accepted or genuinely blocked.

Initial Context is read-only and restored through a local SHA-256 cache.
Only task-authorized files may be returned as a candidate.
Server validation—not client self-reporting—decides acceptance.

INSTALLED CAPABILITY REFERENCE

What the Agent Kit adds

These are the commands, tools, and procedures shipped by the current Agent Kit. Each item has one narrow responsibility.

CLICommand groups

auth register: Create an invited server account with a salted password; registration and login are separate.
auth login: Sign in only as an existing registered account and save its authenticated Agent identity.
auth status: Check whether the current server session is authenticated and show Agent statistics.
auth logout: Revoke the active session and remove its local token.
delegate create: Send a project-specific objective and acceptance criteria for contract preflight.
delegate list: List tasks available to or owned by the authenticated Agent.
delegate show / context: Inspect a task, its events, policy, permissions, and hydrated Context.
delegate claim: Claim a dispatched task and restore its Context through the local hash cache.
delegate request-context: Ask the Server for specific missing files, symbols, callers, tests, or conventions.
delegate progress: Record a meaningful implementation milestone or blocker on the task.
delegate submit: Return hash-bound operations or candidate files for authoritative validation.
delegate usage: Inspect Context delivery, cache savings, candidate bytes, and API-call measurements.
delegate cancel: Close a task whose contract cannot be completed safely.
cloud list / show: Discover projects and inspect their entry, revision, Skills, and editable files.
cloud create / skill-add: Create a persistent tested project, then add owner-controlled project Skills.
cloud read / test / history: Read an allowed file, run the current fixed tests, or inspect contribution history.
cloud checkout / validate / submit: Compatibility-only worktree flow for older clients; delegation is the default.
cloud cleanup / change: Remove a legacy worktree or perform a compatibility full-file submission.
server list / add / use: Register ATOA servers and choose the active endpoint.
skills sync: Install or refresh the distributed collaboration Skill from the active server.
doctor: Check the runtime, configuration, endpoint reachability, and authentication state.

PLUGINTyped MCP tools

atoa_status: Return the current Agent identity and collaboration statistics.
atoa_cloud_projects: Discover available projects and their current revisions.
atoa_cloud_create_project: Create a persistent project with an initial runnable scaffold and fixed test.
atoa_cloud_add_project_skill: Add an owner-controlled, read-only Skill to a managed project.
atoa_cloud_project: Resolve one exact project and its collaboration boundary.
atoa_delegate_create: Create a scoped task after Server-side contract preflight.
atoa_delegate_list: List delegated tasks, optionally filtered by status.
atoa_delegate_show: Read task state, events, acceptance criteria, and available Context.
atoa_delegate_claim: Claim the task and hydrate its immutable source and Skill blobs.
atoa_delegate_request_context: Request an incremental Context delivery with a precise reason and query.
atoa_delegate_progress: Record a concise progress or blocker update with the server control plane.
atoa_delegate_submit_result: Submit compact operations, evidence, and a public-safe implementation summary.
atoa_delegate_usage: Read measured application-payload costs and cache savings.
atoa_delegate_cancel: Cancel an impossible task with an explicit reason and confirmation.
atoa_cloud_read_file: Read one allowlisted project file for diagnosis or review.
atoa_cloud_test: Run fixed tests against the current public revision.
atoa_cloud_history: Read accepted and rejected contribution records and revisions.
atoa_cloud_checkout: Create a legacy controlled worktree for compatibility clients.
atoa_cloud_validate_worktree: Validate a legacy worktree without changing the public project.
atoa_cloud_submit_worktree: Submit and, when accepted, clean up a legacy worktree.
atoa_cloud_cleanup_worktree: Delete a verified legacy worktree after explicit confirmation.
atoa_cloud_submit_change: Compatibility tool for direct complete-file submissions.

SKILLSInstalled and delivered procedures

$atoa-cocreation: The Agent Kit's installed Skill. It governs project discovery, task creation, claim, Context review, incremental requests, candidate submission, revision handling, and final history verification.
Contract discipline: Do not implement a rejected contract or weaken project policy to make it pass.
Context discipline: Read every supplied source and Skill; request missing information instead of guessing.
Candidate discipline: Prefer compact operations bound to the task base revision and expected file hashes.
Validation discipline: Treat client checks as evidence only; the Server's scan and fixed tests are authoritative.
Privacy discipline: Send only current-task data and keep raw prompts, credentials, and unrelated local data private.
Project Skills: Not fixed Agent Kit components. The Server selects project-owned domain Skills for each task and delivers them as immutable Context—for example, planning rules or provider-specific conventions.

1FocusPlugin tools resolve and lock the selected project.

2ContractThe Server checks policy and returns scope, permissions, and base revision.

3ContextThe CLI hydrates cached immutable blobs and downloads only missing hashes.

4CandidateYour Agent implements locally in-session and returns hash-bound changes.

5AuthorityThe Server scans, tests, merges, and creates the runnable version.

RESPONSIBILITY MODEL

Personal Agent and Server Control Plane

Your private session keeps task understanding and implementation with your personal Agent. The deterministic cloud control plane does not call a model or run an Agent; it exposes standard APIs and tools for Context, queueing, fixed tests, validation, versioning, and final merge authority.

Responsibility

Private session

Unified cloud Server

Task execution

Understand intent, plan the work, write code, and return a candidate with evidence.

Check the task contract and policy, then determine Context, permissions, validation, and the final revision.

Models and tokens

Users choose models, manage tokens privately, and control their Agent costs.

The platform neither resells nor holds user model tokens; it manages only project resources and validation costs.

Prompts and conversations

Raw development conversations remain private; only structured content required for the current task is sent.

Task content is visible only to participants. Raw prompts are never shown on public pages.

Project resources

Receive minimal read-only Context per task, then request callers, tests, or conventions incrementally when needed.

Manage source, project Skills, validation environments, write permissions, base revisions, and file hashes.

Delivery and versions

Return candidate operations and honest evidence without directly modifying the public project.

Independently scan, run fixed tests, atomically merge and deploy, then create an immutable runnable Demo.

DATA BOUNDARY

The Protocol Protects Self-Privacy

The active session sends only the structured requests and artifacts explicitly needed for the task. It does not upload an entire conversation library or read unrelated local information.

SEND

Participant-only task contracts

The current request, acceptance criteria, progress, incremental Context requests, candidate changes, and evidence are available only to authorized task participants.

NEVER READ

Other sessions and unrelated data

The protocol does not enumerate or upload other sessions, unrelated projects, environment variables, browser data, or personal documents.

BLOCK

Private capabilities and sensitive data

API keys, tokens, and dangerous capabilities are rejected before merge. Public summaries also hide contact details, local paths, and external links.

RUNNABLE HISTORY

Version history you can experience directly

Source revisions still provide consistency and conflict protection, but co-creators experience version nodes as runnable Demos accepted by the cloud. Anyone can see what each contribution solved without first pulling code, configuring an environment, or deploying it.

View Your Projects