Audit Plan

/audit-plan — gated design review

skein is published, open source, and used by people who are not in the conversation that produced the plan. This audit represents them. Run it, revise anything blocking, re-run, then build. It is the design-time counterpart to [/commit](../commit/SKILL.md): rule 4 keeps red code out of the repo, this keeps unearned scope and unearned API out of the plan, enforcing [AGENTS.md](../../../AGENTS.md) golden rule 1 and [docs/reuse.md](../../../docs/reuse.md).

Public API here is effectively permanent, and that is the stake. nx release versions every packages/* as a fixed group ([nx.json](../../../nx.json)), so one breaking change majors packages that did not change. The repo's own policy is to rename by alias and @deprecated, never by removal — and it has honoured that, carrying five live aliases in packages/*/src rather than deleting a name. So an exported symbol, config key, route or wire field is not a decision that gets revisited later; it is maintenance surface for as long as the project exists. The question is not "is this a good idea?" but "are we sure enough to keep it forever?"

The second question is whose problem it is. skein's value is plumbing users cannot write themselves and the first-party onboarding/integration surface that lets them adopt that plumbing correctly. An official CLI command, project scaffold, framework generator, or maintained starter is upstream when it only composes skein's published contracts, teaches secure supported defaults, and gives the project an upgrade path; the fact that a user could reproduce those files manually does not make it downstream. Application behavior, business rules, identity policy, and deployment-specific choices remain the user's problem. For those, the library's job is to make sure the primitives exist and then get out of the way — a primitive is smaller permanent surface than a feature, and it fits deployments whose requirements we will never see. Both standards are empirical, not invented: a store.scope setting was built and deleted because a handler expresses every policy a setting expresses one of, and a plan claimed background extraction was server-only when after_seconds plus run-cancel already made it user-buildable. The burden is on the plan — an auditor that agrees with it still hands in the rollability table, because the table is the work and agreement is not.

Two things this is not. It does not review whether the plan is correct — that is code review, once there is code. And it is not a vote: findings come from artifacts, never from a show of hands.

1. Resolve the target

In order: an explicit argument; else the harness's active plan file, if it keeps one (Claude Code writes them to ~/.claude/plans/); else a named docs/proposals/*.md; else the plan just discussed in conversation — in which case restate it and put the restatement at the top of the report, so the user can confirm the right thing was audited. If two candidates are plausible, ask rather than guessing.

Then apply the scope test, which exists to let the audit be small: if the target adds no public surface, no config key and no new user-facing capability — a refactor, a bugfix, a docs change — run only dimensions D and F and say so in the report. An auditor with a mandate and nothing to find invents things, so give it permission to have little to do.

2. Extract the inventory and the claim ledger

Two flat lists, quoted verbatim from the target, with all rationale stripped:

• Capability inventory — each thing the plan proposes to build, one bullet each.
• Claim ledger — every falsifiable assertion about this codebase, about @langchain/*, or about

a provider. "LangGraph has no X", "a user cannot do Y today", "this write is atomic".

Strip the rationale deliberately: an auditor handed the argument for a capability audits the argument instead of the capability.

3. Verify the premises

One subagent, run before the others because its output is their input. Rank the ledger by load-bearingness — a claim is load-bearing if a phase disappears when it turns out false — take the top ~10, and probe each with a command whose output is quoted back. Return a fact sheet of CONFIRMED / FALSIFIED / UNVERIFIABLE, each with its probe.

Use a subagent rather than doing this yourself: when you wrote the plan, you also wrote the premises.

| Claim | Probe | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | "LangGraph/LangChain has no X" | ls node_modules/@langchain/, read the installed .d.ts, cite the version from pnpm-lock.yaml | | "a user cannot do X today" | the export in packages/*/src/index.ts, the route in packages/agent-protocol/src/http/routes.ts, or the key in packages/config/src/langgraph-json.ts | | "this is atomic / safe" | the actual driver method — CronRepo.claimAndCreateRun is the only cross-repo atomic operation, and #withTransaction is private to PostgresSkeinStore |

4. Fan out the auditors

Six subagents in parallel — the whole audit is one verifier then these six, and it should not be decomposed further. Six plus the serial verifier sits inside the usual per-session concurrency cap (Codex defaults to 8 via agents.max_concurrent_threads_per_session), so the fan-out runs in one wave rather than queueing.

Each gets the fact sheet plus its own evidence base, and each returns a required artifact first, then findings, then a required considered-and-rejected list of at least two counter-cases it examined and dismissed. The artifact is what makes a clean pass a justification rather than an assertion.

| # | Dimension | Required artifact | Evidence base | | --- | -------------------------------- | ---------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A | Ownership and rollability | The rollability table (below) | packages/core/src/index.ts and packages/agent-protocol/src/index.ts (one public surface per package, so these are the API), http/routes.ts, langgraph-json.ts, docs/using-skein.md, docs/agent-protocol.md, docs/recipes/, and examples/triage-agent as the repo's own proof of what assembles from primitives | | B | Prior art, upstream and internal | The searched-for list: packages opened, symbols considered and rejected | [docs/reuse.md](../../../docs/reuse.md)'s reused-vs-rebuilt table, grep -rn "@langchain/" packages/*/package.json, the installed .d.ts files, and packages/*/src/index.ts for a verb we already ship | | C | Policy and seams | The policy ledger: every config key and default, and whether a seam expresses it instead | packages/core/src/auth/auth.ts, packages/agent-protocol/src/auth/route-authz.ts, and the three proven path:export seams in langgraph-json.ts (auth.path, store.adapter, telemetry paths) | | D | Surface and permanence | The surface ledger (below) | packages/*/src/index.ts for what is already exported; the five @deprecated aliases in packages/*/src as the precedent for what removal actually costs; packages/test-support/src/package-exports.test.ts; AGENTS.md Conventions and [docs/code-practices.md](../../../docs/code-practices.md) | | E | Demand and disconfirmation | The disconfirmation checklist | [docs/proposals/README.md](../../../docs/proposals/README.md) and inbound-events.md as the worked exemplar: a named workflow, success criteria measured in user code outside this repo, specific non-goals, genuinely open questions, and a phase 1 that can kill the plan | | F | Blast radius and parity | The obligations list, against the plan's phasing | A new SkeinStore resource → both drivers plus packages/test-support/src/conformance.ts plus *.integration.test.ts; new HTTP behaviour → all five packages/server-* adapters plus server-kit plus the runtime matrix in ci.yml; a Postgres schema change → the compiled-in asset path ([docs/bundling.md](../../../docs/bundling.md)); a new third-party-implemented interface → its own conformance suite |

The rollability table (A) — two questions, in order

Every capability gets both, and the second is the one that produces the actual deliverable:

1. Whose problem is this — the library's or the user's? The library's when it is plumbing a

user cannot write themselves (durable persistence, the queue, adapters, the protocol), or an official onboarding/integration surface that composes those contracts without owning the application's behavior (the CLI, scaffolds, framework generators, maintained starters). Anything a deployment assembles inside its own graph or handler to express domain behavior, identity policy, permissions, routing, or deployment-specific choices is the user's.

1. If it is the user's — can they actually solve it today? Do the primitives exist? Then the

answer is not "no". It is either "yes, and here is the recipe" or "no, and here is the one primitive that's missing" — and that primitive, scoped as narrowly as it can be, is what the plan should build instead of the feature.

Brief A constructively — "write the user code that does this today, against the shipped API, and stop at the exact line where you can't" — because a yes/no question invites assent while a construction task has a verifiable output, and because the line where it stops is the missing primitive. Cite packages/agent-protocol/src/runs/after-seconds.test.ts in the brief: it is the file that would have falsified the "server-only" claim.

| Column | | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Capability | verbatim from the inventory | | Whose problem | library · user | | Solvable today | yes · no · partly | | With what | the real exports, endpoints or config that do it | | Missing primitive | the narrowest thing that would close the gap, or — | | Verified by | file:line, or a test that demonstrates it | | Verdict | already possible (ship a recipe, not code) · needs a primitive (build the named primitive) · library's own (build it) · upstream ergonomics (official onboarding/integration; build it) · downstream ergonomics (application convenience; defer) |

The surface ledger (D)

Every permanent thing the plan would add — each exported symbol, config key, HTTP route, header, wire field, and interface method — one row each, with:

• Could it be internal? Not exported at all. The default answer is yes until the plan names an

external caller.

• Could it be narrower? A function instead of an interface; one concrete implementation instead

of a plugin seam; an optional method instead of a required one. Widening later is additive and cheap; narrowing later is a break the fixed release group charges to every package.

• What would withdrawing it cost? Given alias-and-never-remove, the honest answer is usually "we

keep it forever" — say that plainly rather than implying it can be walked back.

• What proves the shape is right? A second consumer, an example, an issue. A seam with one

implementation is a guess with an interface around it.

Check names here too, against AGENTS.md Conventions — the data/info/util/handle/manager/ process ban list, verb-first functions, noun values, named exports, kebab-case, layout by feature — plus Zod at boundaries and config keys under the reserved skein.* namespace. A name is part of the permanent surface; getting it wrong costs an alias forever.

Isolation

Withhold, from every auditor: the conversation that produced the plan, your own view or draft verdict, and any other auditor's findings. Anchoring on the author's reasoning is the whole thing this fan-out exists to prevent. Give A, B and C only the stripped inventory; D, E and F get the full document, because they judge whole-document propertie

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: skein-js
• Source: skein-js/skein-js
• License: Apache-2.0
• Homepage: https://skein-js.github.io/skein-js/

Install and usage instructions live in the source repository linked above.