The spec is the work.
Claude writes the first draft of everything now. What your team actually produces is decisions — what we're building, how, who stood behind it. RelayWork is where those decisions live, versioned and approved, anchored to the code that implements them.
Twelve stages from discovery to released. Agents draft and submit through MCP. People approve. Nothing ships past a gate nobody stood behind.
A spec that can't point at the code isn't finished
Every spec has a Code section: the handful of places that carry its decisions, each one a GitHub permalink pinned to a commit, each with a line saying why it matters. Reviewers read the reasoning and the implementation side by side, in one page, without cloning anything.
Paste a permalink, get the source
Anchor a spec to github.com/acme/checkout-api/blob/<commit>/meter.go#L88-L112 and RelayWork renders those lines inline, read from the commit you pinned. The doc says why; the card shows what.
Pinned to a commit, not a branch
A ref keeps showing the code the decision was made against. When the file moves, the card says so instead of quietly showing something else.
Draft PRs attach themselves
Open a draft PR against the spec and the files it touches land in the Code section automatically. Draft PRs never advance a gate — exploring is how the implementation doc gets written, not proof that it is done.
Blast radius, marked as such
Tag a ref as blast radius for code the work could break but does not touch. Reviewers see the risk without reading the whole diff.
Twelve stages, two of them gates
A spec moves in one direction, and everyone can see where it is. Two stages are gates: a named reviewer has to approve before the spec moves on. Approvals are bound to a version — edit the document underneath one and it is superseded, and the spec goes back to review.
Skipping ahead is possible and audited. Every hop is recorded with who moved it and when, so “who decided this?” has an answer six months later.
- DiscoveryShaping the problem
- RequirementsSpec being written
- Requirements reviewapproval gateWaiting on reviewers
- Explore nextApproved — read the code, open a draft PR
- ExploringDraft PR open, implementation doc taking shape
- Implementation reviewapproval gateWaiting on reviewers
- Ready to buildBoth specs approved — pull tasks in
- BuildingExecuting tasks
- ValidationPR merged, verifying
- ReleasedShipped
- Outcome reviewDid it work?
- DoneClosed out
Claude writes into the same gates your team uses
RelayWork speaks MCP. Mint a workspace token, run one command, and Claude Code can read a spec, push a requirements or implementation document in your house template, attach the code it wrote as pinned refs, and ask for review.
What it cannot do is approve. There is no approve tool — not hidden behind a permission, not there at all. Machine writes are attributed to the token, never to a teammate, and a spec Claude edited carries a mark saying so.
- list_specs
- get_spec
- pending_reviews
- list_tasks
- create_spec
- update_spec
- push_spec
- add_code_ref
- request_review
- create_task
- update_task
Lime is write-scoped. Read-only tokens get the rest.
Every spec in the company, grouped by where it stands
List, board, or timeline. Filter by owner, product, quarter or stage; search by reference — AC-24 works in the search box, in a branch name, and in a sentence you type at Claude.
Buckets are Now, Next and Later, and the same board has a shareable customer view — so the roadmap your customers read is the roadmap your team works from, not a slide someone redraws each month.
One page for everything waiting on you
Spec reviews with their age in days and which version you were asked about. Blockers someone else can't move without you. Decisions with your name on them.
A review that has sat for thirteen days says so, in the same colour a fire alarm would. Higher-risk specs ask for two approvers before they can move.
Everything in the box
Shipped and running today — this is a list of what the app does, not a roadmap of what it might.
Specs & approvals
Requirements & implementation docs
Two documents per spec, each with its own approval gate and house template.
Version history & diffs
Every edit past review snapshots the old body. Compare any version to the current one.
Review notes
Feedback stamped with the version it was raised against, resolved one by one.
Named approvers & risk tiers
One approver, or two for work that warrants it. Approvals die when the doc changes.
Audit trail
Who moved a spec, from where to where, and when — every hop.
Linked specs
Split a large piece of work and keep the parts navigable from each other.
Code & GitHub
Linked code refs
GitHub permalinks pinned to a commit, rendered as expandable source next to the doc.
Draft-PR exploration
A draft PR attaches the files it touches and never advances a gate.
PR-driven status
Open a PR and the task moves to In Review; merge it and the work ships.
Branch names from refs
Copy the branch name off the spec — the webhook does the rest.
Read-only by design
RelayWork reads your repository. It never writes to your code.
Done checklist
Code, demo, docs and an outcome review before a spec is allowed to be Done.
Plan & track
Sprints that plan in specs
Commit the specs you are advancing this week — writing requirements counts as work.
Typed issues
Features, bugs, chores and a tech-debt bucket, with priorities that mean something.
Tasks under a spec
Slices of two days or less, or standalone work with no ceremony at all.
Products
Group specs by the product they belong to, across one workspace.
Intake requests
Ideas arrive in one queue and get promoted into specs, or declined on the record.
Ship review & delivery overview
What shipped, what slipped, and where the week actually went.
Docs & the workspace
Notion-style docs
A real editor: slash menu, nested pages, private notes, markdown underneath.
Wiki links & backlinks
Reference another doc with [[double brackets]] and see what points back.
Changelog
A public page your customers can read, built from what you actually released.
Google & Microsoft sign-in
Native SSO on your own domain. No third-party identity detour.
Invites, roles & admins
Invite in seconds; the last admin can never lock the team out.
API tokens
Scoped read or write tokens per workspace, revocable, for agents and scripts.
Why not Linear, plus Notion,
plus a prompt doc somewhere?
Your tools disagree about where truth lives.
The PRD is in Notion, the tickets are in Linear, the real decisions are in a Slack thread, and the prompt that generated the code is in someone’s chat history. When the spec is the work, it needs one home — versioned, approved, linked to the tasks that implement it.
AI output needs gates, not vibes.
Claude can draft a requirements doc in a minute. The question is whether anyone stood behind it before the code shipped. RelayWork makes approval a first-class object: version-bound, named reviewers, superseded the moment the doc changes underneath it.
One vocabulary, requirement to release.
A spec moves through requirements review, implementation review, the sprint, and onto the public roadmap without being renamed, re-pasted, or re-explained. Your team — and your agents — speak the same language the whole way.
Simple, honest pricing
Start free. Upgrade when you grow.
- Specs, twelve stages, real approval gates
- Linked code refs pinned to a commit
- Claude via MCP — eleven tools, no approve tool
- Docs, tasks, bugs, sprints & products
- Public roadmap & changelog
- Google & Microsoft sign-in
- Everything in beta, kept
- Unlimited version history
- Advanced roles & permissions
- Audit exports
- Priority support
No credit card · Export your data anytime
Write your next spec here.
Create a workspace, connect Claude, and put your first requirements doc through a real gate — today.
Create your workspace