Skeleton for agent developers
Every agent picks up where the last one left off.
Your coding agents are only pretending to know your project. Share your Skeleton with Claude Code, Codex and Cursor, so every agent works from the same decisions, fixes and conventions. You approve what they write, and every read is on the record.
One memory, three agents, two days apart. Sample session.
01 · Why Skeleton
Your coding agents are only pretending to know your project.
An agent in your terminal writes and explains code well, and it has still never seen your incident notes, your past sessions or the fix another agent made yesterday. Skeleton gives it that record, from what you and your agents already wrote down.
Your agent, on its own
Starts every session cold
Add retries to the payout webhook.
Your agent, with Skeleton
Starts from what your team already found
Add retries to the payout webhook.
01
Every session starts cold
The agent doesn't know the decision you made in March, last week's incident, or what Codex changed this morning. So it guesses, and it sounds sure.
02
Context is copied by hand
You keep a CLAUDE.md in sync, paste the same background into three tools, and explain the same convention again next week.
03
Agents undo each other
One agent fixes a bug the way the team agreed. The next one, with no record of that, rewrites it back.
02 · Share your Skeleton
One command, then a browser login.
Add Skeleton to Claude Code with one command, or to Cursor with one click. The first tool call opens a login in your browser. No token goes into a config file, and there is no client secret to share. Every MCP client pairs through the same OAuth flow.
Claude Code
Then run any Skeleton tool. Your browser opens to sign in and choose what it can reach.
Cursor
Add to CursorPairs the same way
Codex wants to connect to your Skeleton
Signed in as priya@example.com
Which spaces can it reach?
Codex will only see tools for what you grant. You can narrow or revoke this at any time.
Bring the context around the code. Connect GitHub for repositories, issues and pull requests, and Postgres for your schema and queries. Every connector call goes through the same approval gate.
03 · One memory
A memory Claude Code saves is there for Codex and Cursor.
A memory is one short fact: a fix, a decision, a convention. Any agent you connect can search it, and each change is kept with the agent that made it, so two agents working on one project build on each other’s work.
Memory
Webhook handlers pass the Stripe event id as the idempotency key, so a retry runs once.
History
- Tue 14:04
Claude Code · Saved
version 1 · opus
01
Stored as written
Skeleton keeps a memory exactly as the agent saved it. What Claude Code wrote is what Codex reads.
02
Every version, attributed
Each save and edit records the agent, app and session that made it, and the model it declared, in a history that stays after the memory is gone.
03
No silent overwrites
An edit that carries the version it read comes back stale if someone changed the memory since. The agent re-reads and tries again.
04 · Agents
Agents that pick up the work and tell you what they finished.
Give an agent a name, a face and three documents you own: its persona, its memory and its contract. Start a session on Claude Code or Codex. It reads the same Skeleton as your terminal, asks before it writes, and records each thing it finishes with the document it made attached.
Pike
Codex · gpt-6-astra · checking the refund handler
I traced the double payout to the webhook retry.
09:58Payout double charge: root cause
Doc · Engineering › Incidents
When the session ends, this list becomes its summary in your Skeleton.
Pike
Lives in the Engineering space
Three documents you own
Persona
Terse. Cites the file and line for every claim.
Memory
The conventions it has learned in acme/payments
Contract
Never writes to main. Asks before saving anything.
They open in the same editor as any other document, keep every version, and can be shared. Detach Pike and a session runs on the bare model, with the same rollup.
Cloud sessions
Early accessEach session works in a machine of its own.
Cloud sessions are in early access. Agent code never runs on Skeleton’s servers: a cloud session gets its own sandboxed machine and reaches only the spaces you scoped it to. Outbound traffic is blocked by default and goes through a filtered proxy, so a new host waits for your yes. The session reaches your repository through your GitHub connection.
- ›session started · its own sandboxed machine
- ›model gpt-6-astra · harness Codex
- ›space scope: Engineering · every read logged
- ›task: find why payouts were sent twice
- ›read acme/payments through your GitHub connection
- ›wants to reach docs.stripe.com · waiting for you
- ›you allowed docs.stripe.com for this session
- ›done · Payout double charge: root cause · Doc
Pick a model
Claude Code
Codex
You pick the model. The harness that runs it follows.
The same Skeleton as your terminal
A session reads and writes the memories and documents your own Claude Code and Cursor use, through the same tools and the same approvals.
A grant for each harness
Approving a tool for Claude Code does not approve it for Codex. Each one has its own app identity and its own rules.
Finished work becomes memory
When a session ends, its rollup becomes the session summary, and a finished session can propose memories for you to approve.
05 · How we build Skeleton
We build Skeleton with coding agents that work from our Skeleton.
Our team plans, builds, reviews and ships Skeleton with Claude Code and Codex. The skills they run, the runbooks they follow and the record of every run are kept in our Skeleton, so each agent starts from what the last one found. The next four sections show how, with real plans, ledgers, runbooks and pull requests from our repository.
Skills and runbooks
Kept as documents in a space. Any agent you connect opens one by its link, and a skill also appears as a slash command in clients that show them.
Plans, ledgers and fixes
When a run finishes, its playbook, ledger and review notes go back to the space as a proposal, so the next agent’s search finds them.
Episodes
Each run is wrapped in an episode with its intent and its outcome. The audit log groups by episode, so one run reads as one piece of work.
Memories
A short fact one run learned, like a trap in a migration, is there for the next agent in Claude Code, Codex or Cursor.
Approvals and proposals
Memory saves wait for your approval. A change to a document you already have arrives as a proposal you review.
The loop, part by part
06 · The compound loop
Every fix gets written down where the next agent will look.
We plan with /ce-plan, build one unit at a time with /ce-work, run the plan’s test scenarios, review with /code-review, and finish with /ce-compound. That last step writes the symptom, the cause and the fix to a solutions doc. Our CLAUDE.md tells every agent to search those docs before it changes a documented area, and in our Skeleton the same docs reach agents in any client.
The same bug, a month apart.
Your agent, on its own
Works the bug out from the code again
A chart in the doc reader remounts every time I hover a comment. Fix it.
Your agent, with Skeleton
Starts from the fix your team wrote down
A chart in the doc reader remounts every time I hover a comment. Fix it.
01
Brainstorm
/ce-brainstorm
A requirements doc that says what to build and why
02
Plan
/ce-plan
Units, each with a goal, files, dependencies and test scenarios
03
Build
/ce-work
One unit at a time, one commit per unit
04
Test
vitest · make test
The plan’s test scenarios, run as real tests
05
Review
/code-review
Each finding fixed, or answered with a reason
06
Compound
/ce-compound
A solutions doc the next agent searches before it starts
U1 · Stable renderer identities in MarkdownPreview
docs/plans/orchestration-md-html-fence-flicker-2026-09-15.md
- Goal
- A fenced html block renders once and keeps its iframe when the reader re-renders.
- Files
modifyweb/app/dashboard/context/markdown-preview.tsx
testweb/app/dashboard/context/content-blocks.test.tsx
- Deps
- none
- Test scenarios
- 1 Rendering the same html fence three times keeps the same iframe node.
- 2 The existing promotion tests still pass.
- 3 Task checkboxes still toggle through the newest callback.
An inline react-markdown renderer map remounts every widget on each render
docs/solutions/logic-errors/
category: logic-errors
severity: high
module: web/app/dashboard/context/markdown-preview.tsx
applies_when:
- A components map is written inline on ReactMarkdown
- A renderer in that map mounts something with state: an iframe, a player, a chart
react-markdown uses each entry as a component type. An inline object gives the renderer a new function on every render, so React remounts everything under it, and the iframe starts again from its fallback height.
Our solutions docs today, by category
07 · Orchestrate
Orchestrate runs a plan unit by unit and writes down every gate.
Orchestrate is a skill we keep as a document in our Skeleton, so any agent that can reach the space can run it. It turns a plan into a committed playbook and an append-only ledger. It works out waves from each unit’s dependencies and the files it touches, then runs every unit through /ce-work, its test scenarios and /code-review.
Your agent, on its own
Reports what it remembers
Run the Codex provider plan. All eight units.
Your agent, with Skeleton
Reports what the ledger shows
Run the Codex provider plan. All eight units.
Three questions before it starts
Run units one at a time, or in parallel?
Work on one branch, or a worktree per unit?
Stop after each wave, or run on its own?
Parallel units need worktrees, so two agents never write to one checkout.
Waves
U5 waits for U1 and U4. U2 runs before U3 because both touch model_access.py.
Ledger
orchestration-SKEL-373-2026-09-10/ledger.jsonl
- 10 Sep 20:24rundecisionrecorded
Probes before wave 1: 4 of 5 unknowns resolved against codex-cli 0.153.2.
- 11 Sep 01:24U4implementpass6feaec0e4
The approval seam is harness-aware.
- 11 Sep 01:59U4verifypassb2710bce8
15 test scenarios, each checked against a named test. An always-allow rule minted by one harness does not govern the other.
- 11 Sep 02:23U4reviewpass6eb2519e9
1 critical finding: approve-always read as a plain approve. Fixed. Putting the old matching back fails 7 of the new cases.
- 11 Sep 17:35finaltestpassd0e9ed584
19,470 passed. The same 23 tests fail on the merge-base, so the run added none.
When a gate fails
Stopping after each wave, the run pauses and asks you. Running on its own, it gets up to three fix passes. Then the unit is marked failed, every unit that depends on it is blocked, and the others carry on.
Evidence for every gate
Each gate adds a ledger entry with the command it ran, the commit and what it saw. A status in the playbook with no ledger entry behind it does not count.
Read back after every change
After it opens a PR, merges one or files a proposal, the run fetches the result again and records what it found.
Ship, publish, close
It ships through our merge flow, sends the playbook and ledger to our Skeleton as a proposal, and closes the episode with the outcome.
08 · Runbooks
Procedures your agents follow one step at a time.
A runbook says when to use it, lists the steps in order, and gives the command or query that shows each step worked. We keep ours next to the code, for jobs like deploying the sandbox platform or reconciling connector credentials onto one key. Saved as a document in your Skeleton, a runbook is one link that any connected agent can open, in any client or in a cloud session.
Your agent, on its own
Improvises a procedure
Some connectors show connected, but every tool call fails to decrypt. Fix it.
Your agent, with Skeleton
Follows your runbook, one step at a time
Some connectors show connected, but every tool call fails to decrypt. Fix it.
Reconcile connector credentials onto one CONNECTOR_KEK
docs/runbooks/reconcile-connector-kek.md
1 Fix the root cause first
Every server that writes to this project carries the same key.
2 Scan (read-only)
$ SKELETON_ENV=production uv run python scripts/rewrap_connector_kek.py
- new:<fp>
- readable by the current key
- ORPHANED
- wrapped under another key: the stranded rows
- v1_rows_skipped
- older rows under a separate key, left alone
3 Supply the old keys and confirm the plan
waiting for youStill read-only. The stranded rows should move into an old-key bucket.
4 Apply
--commit refuses to run without SKELETON_ADMIN=1.
5 Verify
Re-run the scan. Expect 0 orphaned rows.
Runbooks
docs/runbooks · 19 files
Deploy the cloud sandbox platform on Fly
deploy-cloud-sandbox-fly.md
Deploy the Electron app via GitHub Actions → TestFlight
deploy-electron-via-github-actions.md
Rotate the Supabase Postgres password
rotate-supabase-postgres-password.md
Verify the platform model key reaches every process
verify-platform-model-key.md
Diagnose a server memory leak
diagnose-server-memory-leak.md
Verify encryption at rest
verify-encryption-at-rest.md
01
When to use it
The symptom or the plan that calls for this procedure.
02
Steps in order
Each one small enough to do and check before the next.
03
A check for each step
The command or query that shows the step worked.
04
What to do when it fails
Like this runbook’s section on a key nobody can find.
09 · Loops
Agents that check again until the job is finished.
Some agent work waits on something else: CI, a review bot, a deploy. The agent loops in its own client, checking again until its stop condition holds, and follows steps kept in your Skeleton. Work that repeats on a schedule runs as a routine on Skeleton’s server: a skill plus a schedule, with the connectors it needs checked before every run.
Your agent, on its own
Checks once and stops
Take PR #2624 through the merge flow.
Your agent, with Skeleton
Checks again until the condition holds
Take PR #2624 through the merge flow.
Merge flow · PR #2624
loop until the stop condition holds
- check 1PR opened · read back: OPEN at a4d7c812b
- check 2gemini-code-assist and Greptile reviewed · Greptile: 1 P1, 1 P2
- fixboth confirmed · fixed in 63e491759 · replied on each thread
- check 3checks running on 63e491759 · wait, then check again
Stop when
- Every review finding answered
- Required checks green on the new head
- Your go-ahead to merge
Routine
Engineering
- Skill
- Nightly EOD sweepChecks plan status, files finished docs, and writes a digest of the last 48 hours of shipping.
- Schedule
- every night · 23:00
- Before each run
- Checks the connectors the skill lists. If one is missing, the run is blocked and the routine waits for setup.
- Writes
- proposals onlyone proposal for you to review
- Run outcomes
succeededthe run did its work
degradedit ended without finishing its work, and says why
failedit hit an error
blockedsomething it needs was missing or removed, so it stopped
10 · Benchmarks
Fewer tokens, more right answers, on the model you pick.
We asked AI models the same questions three ways: with everything pasted into the prompt, with one keyword search, and through Skeleton's read tools. Then we measured tokens, cost, accuracy, and what reached the model.
10.6x
cheaper per correct answer
than pasting everything into the prompt
Higher is better
99.5%
right on multi-step questions
against 51% with one search over the same data
Higher is better
0 of 168
planted attacks reached the model
against all 168 when everything was pasted
Lower is better
Tokens per question
Thousands of input tokens, by records in the account. Skeleton holds near 30k. One search sends under 1k, and misses more.
Lower is better
| Records | Skeleton | Paste everything | One search |
|---|---|---|---|
| 30 | 29.7k | 11.1k | 0.7k |
| 200 | 30k | 68.7k | 0.7k |
| 500 | 30.1k | 170k | 0.7k |
| 1,000 | 29.9k | 338.5k | 0.7k |
Lower is better
| Records | Skeleton | Paste everything | One search |
|---|---|---|---|
| 30 | 29.7k | 11.1k | 0.7k |
| 200 | 30k | 68.7k | 0.7k |
| 500 | 30.1k | 170k | 0.7k |
| 1,000 | 29.9k | 338.5k | 0.7k |
Cost per correct answer
US dollars, across both models and every account size. One search is the cheapest, and gets about a quarter of its answers wrong.
Lower is better
Multi-step questions
Answers that join, count or match two or more records. 192 graded answers per approach.
Higher is better
Planted attacks that reached the model
168 per approach, hidden inside records, on GPT-5.6 Luna.
Lower is better
Personal details sent to the model
Labeled contact details and one planted code, over the same 21 tasks at 30 and 120 contacts on GPT-5.6 Luna.
Lower is better
42 of 42 tasks right
41 of 42 tasks right
34 of 42 tasks right
Accurate on the model you pick
Questions answered correctly with Skeleton, against one search over the same data.
Higher is better
Claude Opus 5
GPT-5.6 Luna
GPT-5.6 Sol
Claude Haiku 4.5
Gemini 3.8 Flash
Internal benchmark on synthetic accounts, September 2026. Not yet independently verified. Not yet publication ready under our own statistical checks. Pasting was simulated by putting every record in the prompt; no chat app or project was tested. No attack was detected succeeding against any approach; the count is attacks that reached the model. Tokens, cost and multi-step accuracy on Claude Haiku 4.5 and GPT-5.6 Luna.
See All Benchmarks11 · You stay in control
Your agents reach only what you allow.
You decide which agents connect, which spaces each one reaches, and what they may write without asking. The access log shows every read, and your agents can check it too.
Access log
live
- 10:16:49
Claude Code for Priya read PR #482 through GitHub
Engineering · 10:16:49
- 10:16:08
Gemini CLI for Sam read API migration notes
Platform · 10:16:08
- 10:15:27
Cursor for Priya searched memories
Engineering · 10:15:27
- 10:14:46
Pike for Priya read Payout retry fix plan
Engineering · 10:14:46
- 10:14:05
Claude Code for Priya read Webhook retry rule
Engineering · 10:14:05
Writes pass the approval gate
Memory saves and edits wait for you, or for a rule you set. Anything that reaches another person, like a comment on a teammate’s ticket, always asks.
Each client sees only what you grant
Grant Codex one space or all of them. Its tool list is built for that grant, and you can revoke it at any time.
Every read is logged
Which client or agent read what, for whom, from which space, and when, sealed into a tamper-evident chain.
Every change is kept
Memory versions name the agent, app and session behind each edit, and documents keep their versions too.
Agent code stays in its sandbox
Early accessCloud sessions, in early access, run in their own machine, with outbound traffic limited to the hosts you allow.
Your model for each job
Route each job to your own key, OpenRouter, or a local endpoint you run, and change it whenever you like.
Take it with you. Export everything as a ZIP of JSON files whenever you want.
Give every agent the real project.
Add Skeleton to Claude Code, Codex or Cursor in a minute. Approve what they save, read the log when you want to, and keep every version.
People, repositories and records in the sample sessions are invented. Sections 05 to 09 quote real plans, ledgers, runbooks and pull requests from building Skeleton, and their conversations are illustrations.