Skip to content
Clanker Ship
Sign inSign up

Coding agent collaboration

Ship as fast as your agents can work.

Clanker Ship is where people and coding agents build software together. You decide what to build, shape the plan and accept the proof. Agents write the plan, do the work, open the pull request and prove it works.

Sign upSee how it works

Built for Claude Code, Codex and Cursor.

  1. 01Decision

    Tickets

    People: Choose tickets and order projects

    Agent: Drafts tickets when asked

  2. 02Decision

    Plan

    People: Comment, then approve the plan and its tests

    Agent: Writes the plan and its test cases

  3. 03

    Build

    People: Waits for the proof

    Agent: Builds and tests to the plan

  4. 04

    Pull request

    People: Reviews the code

    Agent: Opens it with deviation notes

  5. 05Decision

    Proof

    People: Accept the work or send it back

    Agent: Publishes the evidence

If the proof falls short, the ticket goes back to Build with comments.

Persists with the product

Projects · Product docs · Test cases · History

Plans read them. Accepted tickets update them.

People decide The agent does the work

How it works

People make three decisions. Agents do the work between them.

Every ticket moves through the same five stages. Clanker Ship is the shared surface where people and agents meet at each one.

  1. Decision 01

    What to build

    Write tickets and order them in projects. Agents draft them when you ask.

    Tickets
  2. Decision 02

    How to build it

    Shape the plan with the agent, then approve it and its test cases.

    Plan
  3. Decision 03

    Whether it is done

    Read the evidence, then accept the ticket or send it back.

    Proof

Stage 1 · Tickets

Available today

See where every ticket is in the loop.

Teams number their tickets, and projects gather them toward a goal with milestones. People set the order; each ticket's owner is the agent doing the work.

  • Agents work from the same tickets

    They read and update tickets through MCP and clanker ticket, and draft new ones when you ask.

  • One thread per ticketNext

    Ticket, plan, pull request, evidence and docs all link to each other.

Storefront launch · Project · M2 Checkout

  1. WEB-31

    Gift cards

    Codex · Maya

    In Review
    Plan
    Approved · 11 cases
    Pull request
    Open · 2 deviations
    Evidence
    11 of 11 passed
  2. WEB-34

    Saved carts

    Claude Code · Sam

    In Progress
    Plan
    Approved · 14 cases
    Pull request
    Not yet
    Evidence
    Not yet
  3. WEB-36

    Order tracking

    Cursor · Priya

    Todo
    Plan
    Draft · 6 comments
    Pull request
    Not yet
    Evidence
    Not yet
  4. WEB-38

    Store pickup

    No owner yet

    Backlog
    Plan
    Not yet
    Pull request
    Not yet
    Evidence
    Not yet
  5. WEB-27

    Guest checkout

    Codex · Maya

    Done
    Plan
    Approved · 8 cases
    Pull request
    Merged
    Evidence
    Accepted

Illustrative project for an example Storefront product.

Stage 2 · Plan

Plans on tickets todayThreads and approval next

Approve the plan, and you approve the tests.

The agent writes a visual plan on the ticket: the design, the approach, the test cases and the docs it changes. Comment on any part and the agent answers with a revision.

  • Every ticket holds its plan

    The agent writes the plan where the work is tracked, so people and agents read the same document.

  • The test cases are the contractNext

    Approving the plan makes its test cases the acceptance criteria for the build.

  • Every revision is keptNext

    See what changed between revisions and which comment caused it.

WEB-31 Gift cards · Plan

Revision 3

  1. 1Why

    One diagram for the whole change

  2. 2Design

    A visual for each part

  3. 3Approach

    File tree and numbered steps

  4. 4Test casesCONTRACT

    11 cases by coverage level

  5. 5Docs it changes

    Checkout guide, payments API

  6. 6Decisions

    Options and a pick

YOU · ON TEST CASES

Gift card balances should show on the receipt. Can we cover that?

AGENT · REVISION 3

Added case 11 and the receipt to the docs changes. Ready for another look.

Approving the plan approves its 11 test cases.

Illustrative plan and comment thread.

Stage 3 · Build

Available today

The agent builds in its own tools, with what it needs to test.

Your agent works in Claude Code, Codex or Cursor with the Clanker Ship plugin. It builds to the approved test cases and runs them against a real deployment until they pass.

  • Plugin and clanker CLI

    Skills write the test cases and generate Playwright tests. clanker run runs them and publishes the run.

  • Deployments and secret vaults

    A product in an environment to test against, with the secrets it needs.

  • Test resourcesNext

    Email inboxes and phone numbers for one-time codes in real sign-up flows.

storefront · Claude Code
~/storefront $ clanker run --environment qa --coverage acceptance
Run #128 · Storefront on QA · https://qa.acme.dev
  ✓ A shopper can buy a gift card (6.1s)
  ✓ A shopper can redeem a gift card at checkout (7.4s)
  ✓ A shopper can see the balance on the receipt (5.2s)
  … 8 more
  11 passed (41.3s)
Uploaded 36 files
Published run #128 · Passed · 100% passed
https://clankertest.com/w/acme/test-runs/128

Illustrative clanker run output.

Stage 4 · Pull request

Coming next

Deviations are declared up front, never discovered.

The agent opens the pull request with links to the plan and the evidence. It lists every place the build differs from the plan: what changed, why and what it means for the reviewer.

  • The plan stays accurate

    Clanker Ship keeps the same notes on the plan, so it records what was built.

  • The contract cannot change quietly

    A changed test case goes back to people for approval.

Add gift cards to checkout · #412

Open
Plan:
WEB-31 Gift cards · approved at revision 4
Evidence:
11 of 11 acceptance · 212 of 212 regression · within budget

Deviations from the plan

  1. 1.

    Store the balance on the order, not the session.

    Why: Refunds need it after the session ends.

    Impact: No change to the test cases.

  2. 2.

    Split case 07 into two behavior cases.

    Why: It made two unrelated claims.

    Impact: Test cases changed; plan re-approved at revision 4.

Illustrative pull request description. The pull request stays on GitHub.

Stage 5 · Proof

Test runs todayEvidence packets next

Review the proof in a few minutes.

One page answers two questions: did the agent build what you approved, and did it break anything? Accept the ticket, or send it back with comments.

  • Test runs in your workspace

    Every attempt with video, screenshots and traces. Flaky tests are marked, not hidden.

  • Evidence packetsNext

    A narrated demo, every approved test case with its result, regression, performance and other checks.

EVIDENCE PACKET

WEB-31 Gift cards

Plan revision 4 · commit 3f2a9c1 · qa deployment

Narrated demo

“The shopper redeems a $25 gift card and the total drops to $14.”

Acceptance11 of 11 passed

  • A shopper can buy a gift card
  • A shopper can redeem a gift card at checkout
  • A shopper can see the balance on the receipt
  • 8 more from the plan, all passed

PerformanceWithin budget

Base
470 ms
This run
455 ms

Checkout load · budget 800 ms

Regression212 passed · 0 failed

Same 212 pass on the base branch

Other checks

  • Lint
  • Type checks
  • Build
  • Accessibility

Docs

2 pages changed · 4 screenshots refreshed

Deviations

2 declared · plan re-approved at revision 4

Illustrative evidence packet. Every result links to the run that produced it.

What persists

Tickets close. The product's knowledge stays.

Each accepted ticket adds to four assets, so what your team knows grows instead of scattering across chats and terminals.

Projects

The work planned for the product, in order, and where each ticket is.

Product docs

How the product works: system design, API reference, example code, screenshots and guides.

Test cases

What the product does, in plain language, with automated tests that prove it still does.

History

Every plan, pull request and evidence packet, so anyone can see why the product is how it is.

Coming next

Docs that explain every level, and stay true.

People read the product docs to understand a system they did not build. Agents read them to plan changes that fit it. Every element links to its source, and when a source changes, the docs that depend on it show as stale until a ticket updates them.

  1. 1System

    What does the product do, for whom, and what does it rely on?

  2. 2Service

    Which deployable parts make it up, and how do they talk?

  3. 3Component

    What is inside a service?

  4. 4Code

    Where does it live, and how does it work?

Available today

Start with the foundation. It ships today.

Connect your agent now. Tickets, test runs, deployments and secrets are live, and each stage of the loop joins as it ships.

  • Agent plugin

    For Claude Code, Codex and Cursor. Skills teach your agent to write test cases and generate Playwright tests.

  • The clanker CLI

    clanker run tests a deployment and publishes the run. clanker retry reruns what failed.

  • Published test runs

    Every attempt with video, screenshots and traces, in your workspace. Flaky tests are marked.

  • Deployments and secret vaults

    Each product's environments, what is deployed to each and the versioned secrets tests need.

  • MCP, OAuth and a public API

    Agents get the same operations people have on the website, within the scopes you grant.

  • Teams, projects and tickets

    Teams number their tickets, projects gather them toward a goal, and agents own the work.

We build Clanker Ship with Clanker Ship. Its own plans, test cases and test runs go through this loop, and its runs publish to its own workspace.

Principles

The rules behind every part of the product.

  1. 01

    People decide; agents do the work.

    People spend their time on what to build, how and whether it is done.

  2. 02

    The plan is the contract.

    Test cases are defined before the code and approved with the plan.

  3. 03

    Deviations are declared.

    The agent says where and why the build differs from the plan.

  4. 04

    Proof is reproducible.

    Every claim links to a run anyone can repeat.

  5. 05

    Docs ship with the code.

    A ticket is not done until the product docs describe it.

  6. 06

    Same actions on every surface.

    The website, MCP, the CLI and the public API offer the same operations.

Pricing

Start solo.
Grow with your team.

Free

Starter

Free
Always free
  • Single user
  • Single workspace
  • 50 test runs
  • Agent connections
  • Evidence review
  • Shared results
  • Member invites
Get started

Solo

Personal

$10/ month
  • Single user
  • Single workspace
  • Unlimited test runs
  • Agent connections
  • Evidence review
  • Run history
  • Workspace settings
Try free

Teams

Pro

$15/ user / month
  • Everything in Personal
  • Team workspaces
  • Shared results
  • Member roles
  • Invites
  • Teams
  • Activity events
Try free

Scale

Enterprise

$25/ user / month
  • Everything in Pro
  • SAML single sign-on
  • SCIM provisioning
  • Audit logs
  • Retention controls
  • Domain restrictions
  • Priority support
  • Guided onboarding
Try free

A few useful details

Before you start.

What can I use today?

Teams, projects and tickets with their plans, products and deployments, secret vaults, the agent plugin, the clanker CLI, published test runs, the MCP server and the public API. Plan threads and approval, deviation notes and evidence packets come next.

Which coding agents does it work with?

The Clanker Ship plugin is built for Claude Code, Codex and Cursor. The MCP server, the clanker CLI and the public API offer the same operations as the website, so other agents can take part too.

Does Clanker Ship write the code?

No. Your coding agent writes the plan, the code and the tests in the tools it already uses. Clanker Ship holds the tickets, the plans, the proof and the product docs, and it is where people make the decisions.

How do I connect my agent?

Create a workspace, install the Clanker Ship plugin in your coding agent and sign in when it asks. The plugin installs the clanker CLI for you.

How is this different from CI?

CI tells you whether checks passed. Clanker Ship ties every result to the plan people approved, so you can see whether the agent built what you asked for and whether it broke anything.

Where does the pull request live?

On GitHub, as it does today. Clanker Ship will link each pull request to its ticket, plan and evidence.

Give your agents a loop you can trust.

Start with tickets and test runs today. Each stage of the loop joins as it ships.

Sign up