Our prompt-engineer agent knows how to configure settings, write hooks, create slash commands, and author skills. Ask it to write one hook, though, and it doesn't need to read four complete manuals.
That was one of the opportunities we followed after Lean machine. The first pass reduced the context loaded at session startup by splitting our plugin catalog into a small core and optional modules. This time we looked at what gets loaded during a task, then followed the work through the harness adapters and into our paid playbooks.
A smaller starting point for the task
We moved the prompt-engineer's detailed guidance into four references. The agent body keeps the instructions for choosing and doing the work; it points to the relevant manual when a task needs more detail.
| Prompt-engineer source | Whitespace-delimited words |
|---|---|
| Agent body before | 8,713 |
| Agent body after | 2,984 |
| Reduction | 65.8% |
The manuals still ship with the plugin. We checked reference resolution in both the repository and extracted installs, so the agent can find them in either location.
The 65.8% measures source words. We'll need live task comparisons to establish the effect on tokens, latency, and output quality.
We also extended the checks in scripts/plugin-weight.py to include command descriptions alongside agents and skills. CI enforces limits of 3,000 estimated tokens for core and 18,000 for the full suite. That gives us a budget to work within as we add specialists.
Load session context once
OpenCode now loads its initial context snapshot once per session. If two requests arrive together, they share the load; if it fails, a later request can retry.
Routing still runs for each message, and safeguards still run for each tool call. Those decisions need the current request. The initial snapshot can be reused.
We reviewed the adapters for Claude Code, Codex, Grok Build, and OpenCode together. They share a source catalog, but each host has its own way of representing tools and permissions. The adapters now preserve the agent's intended tool scope through those translations. Host detection also distinguishes evidence about the running session from the presence of a CLI on the machine.
To trace those relationships, we cataloged all ten plugin roots: 84 skills, 30 agents, 14 commands, and 186 supporting resources. The inventory let us follow a reference from its source to the place an installed agent would look for it.
Give the benchmarks a fair comparison
The benchmark runner, scripts/benchmark-runner.ts, starts baseline and skill-assisted runs with the same fresh, tool-free conditions. Each evaluation names its cases and assertions, and the reports retain failures and baseline successes as well as the cases where the skill helps. Negative cases test requests the skill should leave alone.
We also separated two questions in the reports: did the request reach the intended agent, and did the workflow complete correctly? A routing result answers the first. We need execution evidence for the second. Missing usage data stays unknown; it can't stand in for an observed zero.
Preserving quality with less context can be a good result. A higher score needs repeated comparisons on fresh tasks before we treat it as a reliable improvement.
Make playbook setup specific to the task
We carried the inventory into our five paid packs, covering 204 playbooks. Each playbook's setup now accounts for both the skills it invokes and the plugins that provide its named agents. Someone running one workflow gets the prerequisites for that workflow; the pack documentation also lists the broader inventory.
The prose review covered API behavior, versioned contracts, and references to follow-up steps. These details belong in the same review as the install instructions: they're what someone follows after setup is complete.
The pack builder, scripts/build-packs.ts, checks the content before replacing its output and includes a VALIDATION.md report with the playbooks. That report distinguishes historical evidence from structured live runs, so readers can see what was checked and what still needs verification in their environment.
All 204 playbooks pass the content gate. We built and inspected six local archives: the five packs and the complete suite. Fresh execution of buyer workflows and delivery of updated customer archives are separate release steps.
Focused workers, reviewed together
We used Orchestra, our plugin for coordinating agent workers, to split the implementation into three waves. Workers received named files to own, the behavior to preserve, and checks their changes needed to pass. Smaller models handled those focused tasks; we reviewed the results together before integration.
For example, a benchmark task needs to say which inputs the runner accepts and how it should record a failed case. “Improve the benchmarks” leaves those decisions open. Writing them into the brief makes the result reviewable.
The integrated plugin changes passed twelve local verification gates and installation checks in CI. All ten extracted plugins passed Claude's strict validator. On the site, 821 tests passed along with TypeScript and repository-wide lint.
The checks now run with the code. When we add a skill or update a playbook, its context budget, references, and packaging have an established place in the review.
The public plugin update includes the implementation and verification records. The software development pack includes workflows for applying this process to a repository.