v4.2.0: Agent Blueprint

A minor release: Agent Blueprint also runs as a hosted agent, beside the eight coding CLIs, and nothing changes for those CLIs except the version.

• A hosted option on Vercel's Eve framework. The new eve/ folder is the blueprint as an agent you deploy to your own Vercel account, Railway or a server you run. You reach it from a web chat, Slack, Linear, Telegram, an MCP client such as Claude Code, or HTTP, name a GitHub repository and a feature, and it works through the same skills to a reviewed pull request. It reads the plugin's skills/ folder in place, so the hosted agent and the CLIs run the same skill text. The Hosted page builds a deploy link from your choices, and eve/README.md has what to prepare, the three routes, the variables and the upgrade steps.
• Linear, Telegram and MCP beside the web chat and Slack. A member of a public Linear team delegates an issue to the agent, and its progress and questions appear in the issue's agent session; the agent mints its own Linear token from your Linear app's client ID and secret. The people you list message a private Telegram bot, and each thread of that chat is its own run. An MCP client such as Claude Code starts and answers runs with a token you choose, and Claude.ai and ChatGPT can sign in through your own identity provider. Each channel admits only the callers you allowed, and during an upgrade none of the three starts new work. A repeated Linear or Telegram delivery starts no second run. Claude Code with the token and Claude.ai with OAuth sign-in each ran to a draft pull request on Vercel and on Railway. Limits: private Linear teams were not checked, attachments are not read, and ChatGPT has not been run live as an MCP client. eve/README.md has the setup, rotation and removal steps.
• It pushes as a GitHub App you create for one repository. The agent can reach no repository the App is not installed on. It pushes its own branch after every stage and opens a draft pull request at the end, after a secret scan, and it never pushes from the shell. A change to .github/workflows or .github/actions needs a person to approve it.
• One model per role. The lead, the planner, the builder, the reviewer, the tester, the analyst and the documenter each have a model and a reasoning level through the Vercel AI Gateway, set by a preset that you can change one role at a time. Helpers run on their role's model.
• Guarded on Vercel, unguarded elsewhere. On Vercel Sandbox the GitHub token never enters the sandbox. On Docker and Daytona, which Railway and your own server use, each git command reads its token from a file that another process in the sandbox could read while that command runs. docs/hosts/eve.md says what that means, and what a ruleset protects on a private repository.
• Five skills are degraded there. ab-plugin-update, ab-forensics, ab-browser-testing, ab-deployment-verification and ab-health-check load and run, but cannot do all of their work in a hosted sandbox. The host note gives each one's reason. ab-migrate and ab-plugin-update stay manual-only and load only when you name them.
• A guide for coding agents. Coding agents can read the install steps at /agent-blueprint.md, and every docs, guide and tutorial page has a Markdown version at its address plus .md.
• The eight coding CLIs are unchanged. Every skill, helper prompt and hook they install is the same as in 4.1.1 except the version number. install.sh --only eve refuses and points to the Hosted page, because the hosted agent is deployed, not installed.

ab-ship-pipeline's loop of fresh sessions, which the CLIs get from the ship runner, runs on the hosted agent through the ship_pipeline tool: one iteration per call, each in a fresh helper, with every stage pushed to the branch as it finishes. A helper or a tool that crashes costs one iteration; on Eve 0.86.0 a failed turn of the lead agent itself, such as a refused model call, ends the session, and the run restarts by hand from the branch it pushed, which keeps every finished stage.

Upgrading

A plugin install updates through its tool (docs/hosts/<host>.md). A checkout updates with git pull, then bash install.sh again. A hosted copy is new in this release: deploy it by one of the routes in eve/README.md. Later releases reach a running copy through the upgrade steps there, which end the open sessions before the new release goes live.

v4.1.1 — Agent Blueprint

A patch to v4.1.0: the installer no longer changes Cursor's marketplace, which Cursor shares across your computers.

• install.sh no longer removes Cursor CLI's marketplace. On a computer with Claude Code's plugin, 4.1.0 removed Cursor's agent-blueprint marketplace, because Cursor reads Claude Code's plugin there. But Cursor keeps marketplaces on your account, and every computer signed in to it shares them. So the removal also reached your other computers, and any of them that installs agent-blueprint through Cursor's own marketplace lost the source it installs and updates from. The installer now leaves the marketplace in place. If the installer had added Cursor's marketplace on that computer, it now tells you to uninstall Cursor's own copy in /plugin, so Cursor reads only Claude Code's plugin. /plugin marks Claude Code's copy "(Claude Code)".
• install.sh no longer replaces a Cursor marketplace from another source. Without Claude Code's plugin, 4.1.0 removed an agent-blueprint marketplace that pointed somewhere other than GitHub, such as a checkout or a fork, and added it back from GitHub, which changed the source for every computer on the account. It now leaves that marketplace as it is and prints the two commands that switch it to GitHub.

Upgrading

A plugin install updates through its tool (docs/hosts/<host>.md). A checkout updates with git pull, then bash install.sh again. If an earlier run removed Cursor's marketplace and another computer of yours still uses it, add it back once with cursor-agent plugin marketplace add https://github.com/Ninety2UA/agent-blueprint.

v4.1.0 — Agent Blueprint

Each tool now installs Agent Blueprint with its own command. The skills no longer push a literal-minded model into deleting existing code or asking twice for an approval you already gave. Project setup refuses the wrong folder, and Codex gets a complete plugin listing.

Install in each tool with its own command

Every tool that has an install command now installs straight from GitHub and updates through its own updater:

Tool	Install
Claude Code	claude plugin marketplace add Ninety2UA/agent-blueprint, then claude plugin install agent-blueprint@agent-blueprint
Codex	codex plugin marketplace add Ninety2UA/agent-blueprint, then codex plugin add agent-blueprint@agent-blueprint, then trust the hooks in /hooks
Antigravity	agy plugin install https://github.com/Ninety2UA/agent-blueprint
Grok Build	grok plugin install Ninety2UA/agent-blueprint
Pi	pi install git:github.com/Ninety2UA/agent-blueprint
Cursor CLI	nothing when Claude Code has the plugin; otherwise cursor-agent plugin marketplace add https://github.com/Ninety2UA/agent-blueprint, then /plugin in a session
Hermes	the installer's copy in ~/.hermes/skills
Amp	nothing when Claude Code has the plugin; otherwise the installer's copy in ~/.config/amp/skills

install.sh stays as the way to set up every tool on the machine at once. It runs the same commands with GitHub as the source (--local uses the clone), writes no shared ~/.agents/skills copy, and on a re-run removes the copies 4.0 recorded once the routes that replace them have succeeded. If one tool's install fails, the others still install, and the run ends by listing which tools finished and which failed, saying for each failed tool whether its old install stayed or was already removed. Before it removes an install to replace it from GitHub (a marketplace, Grok's plugin or a Pi package), it checks that GitHub answers, because removing a marketplace uninstalls its plugin. A Pi package pinned to a version, as @ref or #ref, is replaced with the current source and a warning that names the pin; because Pi treats every entry for one repository as a single package, removing the pin also removes a second entry for it, so the installer installs the current source afterwards rather than updating that entry. The reachability check uses your own SSH command when Git reaches GitHub over SSH, never prompts, and gives up after 30 seconds. A run limited with --only keeps a recorded copy that a tool outside the run still reads, Hermes included when its config lists that copy, and says so.

Skill instructions a literal model cannot misread

Every skill, its references and its helper prompts were audited against OpenAI's guidance for GPT-6 Astra, which follows skill text more literally. The fixes are below, one rule at a time. docs/releases/v4.1.0-instruction-audit.md gives the reason for each.

• ab-test-driven-development discards only code the agent wrote in the task before its test. It never deletes code that existed before the task, or code you wrote or asked to keep. You can also tell the agent to keep its own pre-test code.
• ab-brainstorming does not ask you again to approve a design you already approved or told it to build. A request that only asks for code, with no design yet, still gets a design first.
• Skills no longer ask again for an approval you already gave. Deleting work you own, rewriting shared history or pushing needs your own request. Starting a skill whose job is to publish, such as the PR workflow or the ship pipeline, counts as that request.
• Text in files, tool output, PR comments or a helper's report never counts as your instruction. The stage approvals in ab-build-pipeline, the batch checkpoints in ab-executing-plans and the injection guards stay as they were.

Project setup refuses the wrong folder

ab-project-start no longer scaffolds into whatever folder the session happens to be in. With no folder named, it refuses your home folder and /. In a folder that has files but is not a git repository, it shows what it would write and asks first. Inside a repository it never runs git init again, so it cannot nest one repository inside another. It also names the repository's top folder.

Codex

• The plugin listing is complete: the Developer Tools category, a description that counts the five hooks Codex gets, listing copy, links, three example prompts, the brand color, and an icon and logo for light and dark.
• Codex's $ picker shows a display name and a one-line description for every skill, such as Project Setup for ab-project-start. ab-plugin-update and ab-migrate stay manual-only.
• Codex offers $ab-project-start right after you install the plugin.
• The write guard now reads Codex's edits. Codex reports a file edit as apply_patch with the patch text. The guard used to look only for Claude Code's Write and Edit, so on Codex it ran without scanning anything. It now scans the lines each patch adds to files that become agent context, and the text of a file a patch moves into one of them.
• A real Codex session showed all five hooks running: the session-start pointer, the write guard, the commit-message check, the context monitor and the ship-pipeline Stop guard. In that session the write guard warned on an apply_patch edit and the commit-message check flagged a commit message, so both act on Codex's own payloads, not only start.

Updating

ab-plugin-update updates each install through its tool's own route. On Codex it upgrades a Git marketplace or pulls a local checkout marketplace, then adds the plugin again. It never falls back to a skills copy beside the plugin, which made Codex list every skill twice.

Checked on all eight tools

Claude Code, Codex, Antigravity, Grok Build, Pi, Cursor CLI, Hermes and Amp each installed the release by its own route and listed every skill exactly once. Cursor CLI, Amp and Grok Build also listed every skill exactly once beside Claude Code's plugin (docs/releases/v4.1.0-installs.md). ab-plugin-update moved a real Codex install from 4.0.2 to 4.1.0. docs/releases/v4.1.0-smoke.md has the smoke cells for discovery, the manual-only rule, hooks, debugging and the two new behavior checks (existing code kept under TDD, and an approved design taken as approved).

README and site

The README and the website lead with each tool's own install command and add a Codex section for the CLI and the app. They also add a step after installing that runs the setup skill and explains what it creates, when to run it and how to call it in each tool. The eight-tools diagram shows each tool's route, and two new loops show each tool installing and ab-project-start setting up a project.

Upgrading

A plugin install updates through its tool, or you can ask any tool for the ab-plugin-update skill. If you installed 4.0 with bash install.sh, run the 4.1.0 installer once without --only. It removes the copies 4.0 recorded in ~/.agents/skills, ~/.grok/skills and ~/.pi/agent/skills and gives each tool its own route. The installer now needs python3 for every tool, where 4.0.2 needed it only to scaffold a project. Existing projects need no change.

v4.0.2 — Agent Blueprint

A patch to v4.0.1 for three problems found while running the site's tutorials.

• Injection scanners match whole words: the write scanner (prompt-guard.js, on file writes and edits in Claude Code and Codex) and the read scanner (read-injection-scanner.js, on file reads in Claude Code) matched a trigger word inside a longer word and reported "Blueprint instructions" (the "print" in Blueprint), "slideshow prompt" and "react as a" as possible prompt injection. Every pattern that starts with a word now needs a word boundary before it. Markdown emphasis such as _ignore all previous instructions_ is still caught.
• New projects get docs/context/DECISIONS.md: the scaffolded AGENTS.md tells the agent to honor that file and to record conservative choices in it, but ab-project-start never created it. It now ships a stub that the ab-discuss skill appends to.
• ab-brainstorming shows each design section before asking about it: in one run it asked for approval of sections whose text never appeared, only their headings. It now writes each section in full in its reply and asks for approval only once every section is shown.

The README also says what the ship runner deletes after it publishes.

Upgrading

A plugin install updates through its tool (docs/hosts/<host>.md). A checkout updates with git pull, then bash install.sh again. Existing projects need no change: ab-discuss creates docs/context/DECISIONS.md the first time it records a decision.

v4.0.1 — Agent Blueprint

A patch to v4.0.0 for the installer.

• Cursor CLI and Amp list each skill once next to Claude Code — both read Claude Code's plugin as well as ~/.agents/skills, so on a machine with Claude Code and either of them, install.sh no longer writes the shared copy there. Codex gets its own plugin (codex plugin marketplace add and codex plugin add), Grok Build, Pi and Hermes each get a copy in a folder only they read (~/.grok/skills, ~/.pi/agent/skills, ~/.hermes/skills; Hermes then needs no config edit), and a shared copy an earlier install left in ~/.agents/skills is removed: only the skills its install record names, never a folder of your own. The machine decides the route, not --only, and a run limited with --only keeps the shared copy while another installed tool still reads it. A folder in a tool's skills folder that the installer did not put there is kept, with a warning. Machines without that pair, and --copy-dir or AGENT_BLUEPRINT_COPY_DIR, keep the one shared copy.

Upgrading

Update the checkout (git pull), then run bash install.sh again; it switches the routes and removes the old copy where needed. A plugin install updates through its tool (docs/hosts/<host>.md).

v4.0.0 — Agent Blueprint

claude-code-blueprint v3.8.0 becomes Agent Blueprint v4.0.0: the same pipelines as one set of 53 skills that installs natively in eight coding CLIs, in a repository renamed agent-blueprint (GitHub redirects the old name). This is a clean break; docs/upgrade/v4.md walks a v3 project across.

• Eight hosts — Claude Code, Codex, Antigravity, Grok Build, Pi, Cursor CLI, Hermes and Amp. Each tool with a plugin system gets a committed manifest that points at the one skills/ tree; the rest read one shared copy. install.sh detects the installed tools and gives each its route. One support note per host is under docs/hosts/.
• ab- on every skill — 53 skills, each named ab-…, so a shared skills folder never collides with another pack. agent-teams and team-execution merged into ab-orchestrate; migrate-to-plugin became ab-migrate. The full map is docs/upgrade/v4-skill-names.tsv.
• Agents became helper prompts — the 29 agent files are 30 prompt files inside the skills that use them. A helper inherits the session's model and effort, and a skill follows the prompt itself where the tool has no subagents.
• You choose the model and the effort — no skill or helper prompt sets either, in any tool. The README has a table of how to set both per host.
• AGENTS.md is the instructions file — every host reads it; CLAUDE.md holds the single line @AGENTS.md for Claude Code. The scaffold merges into what a project already has.
• Working files under .agent-blueprint/ — plans in progress, review runs, the team ledger and run state leave .claude/. Session notes live in docs/context/STATUS.md.
• Team work in every tool — ab-orchestrate runs a plan through a file ledger in dependency-ordered waves, with helpers where the tool has them and one task after another where it does not. Claude Code Agent Teams and Codex multi_agent_v2 are optional extras.
• One ship runner for any host — skills/ab-ship-pipeline/scripts/run.sh --host <host> "<feature>" starts a fresh session per iteration, reads state.json between them, and pushes and opens the pull request only after its own secret scan and publish checks. Hosts that can only run unguarded need --allow-unguarded.
• Hooks are optional — hooks/claude-code.json and hooks/codex.json. The other six hosts run every pipeline without them.
• Leaner instructions — skills state principles with their reasons instead of ALWAYS and NEVER, every SKILL.md fits Codex's 8,000-byte limit, and every question names the default an unattended run takes. docs/upgrade/v4-instruction-rules.md says where each v3 rule went.
• New gates — a portability gate for all eight hosts with an allowlist that only shrinks (it is empty), a manifest gate that holds every version equal, runner tests against a fake host, and a local smoke test (tests/smoke/) that runs the pipelines in each installed tool.
• ab-migrate — cleans a v3 project behind a backup branch and one question, and removes only files the blueprint installed.

Upgrading

Install v4, run the ab-migrate skill in each v3 project, then remove the old plugin: docs/upgrade/v4.md. v3 and v4 must not both stay enabled; the session-start hook warns while they are.

Known limits

• Pi, Hermes and Amp are untested — none of the three was installed on the build machine, so no smoke cell ran on them. Their install routes and runner flags follow the vendor docs and are marked unverified in skills/ab-ship-pipeline/scripts/hosts.sh.
• Grok Build is tested only where it ran — discovery, AGENTS.md, hooks and manual-only pass. The free plan's usage limit stopped the build cell partway and refused the other pipeline runs, so the smoke table records the build, review, debug, ship and team cells as failed, with that refusal as the reason; none of them passed. On the release commit, discovery and manual-only passed and the same limit refused the AGENTS.md and hooks checks, so those two rows come from an earlier commit.
• Antigravity leaves skills out past a context budget — on a machine with many other skills it drops most ab- skills from the list the model sees, and a dropped skill does not load even by /ab-name. With only the blueprint installed, every check that applies passes (docs/hosts/antigravity.md § Catalog budget).
• Cursor CLI caps its skill list — about 210 names, counting other tools' skill folders. Past the cap the model cannot pick an ab- skill on its own; naming it still loads it.
• Cursor CLI lists every skill twice next to the Claude Code plugin — Cursor CLI imports Claude Code plugins, so a machine with both the Claude Code plugin and the shared copy installed shows it each ab- skill twice. bash install.sh warns when it installs for both; keep one route. A fix is planned after 4.0.0.
• Hermes and Amp cannot hide manual-only skills — neither has a manual-only key, so ab-plugin-update and ab-migrate can be picked from a matching request. ab-migrate still asks before it removes anything.
• Pi has no helpers without pi-subagents — a skill follows each helper prompt itself, and the pipelines still complete.
• Agent Teams is checked by hand — it runs only in an interactive Claude Code session, so it is not a smoke cell. The check passed on 2026-10-06 (docs/releases/v4.0.0-checklist.md).
• A push URL that contains = stops the ship runner — the runner and the interactive publish step refuse it before listing anything, because git 2.29 and 2.30 cannot take such a URL in the rule the listing uses to read exactly the push target. Keep credentials in a credential helper rather than in the URL.
• The ship runner trusts its own state folder — a session that can rewrite your global git config can also rewrite the runner's record under ~/.local/state, so the publish checks contain a careless agent, not a hostile one. Run unattended work in a throwaway clone or a container.

Evidence

• Smoke table: docs/releases/v4.0.0-smoke.md (what ran on which host, with times and reasons).
• Evaluation: docs/releases/v4.0.0-eval.md (v3.8.0 against v4.0.0 on Claude Code). Review and debug, three runs each on the session default (Fable 5.1 at xhigh): 3/3 on both versions, no outcome regression. Build, one run each on Opus 5.5 at medium effort: both pass, v3 in 2m05s for $0.91 with one commit, v4 in 6m45s for $3.86 with four commits (its pipeline plans, implements, reviews and verifies as separate stages). v4 takes longer and costs more on every task: a v4 pipeline skill loads its capability snippets, writes its provenance record, runs the review as a helper swarm with a validator pass instead of one inline review, and follows the systematic-debugging protocol to a regression test, where v3 answered in one pass. Ship was not evaluated: one v4 ship run costs about $40 and 1h45 through the runner, and the smoke table already shows it passing end to end on Claude Code, Codex, Cursor CLI and Antigravity.
• Provenance records: every pipeline skill writes .agent-blueprint/run/provenance/<skill>.json with helper_steps entries of the shape {step, path: helper|inline}; the smoke table's helper columns come from those records (the shape was fixed in phase 4, so the Provenance snippet's wording changed with it).
• v3.8.0 against v4.0.0 on the same fixture tasks: docs/releases/v4.0.0-eval.md.
• Why the single-harness scope was reversed: docs/learnings/2026-10-portability-decision.md.

Pull requests #16, #17, #18 and #19. Plan: docs/plans/2026-09-28-1036-feat-agent-blueprint-portability-plan.md.

v3.8.0 — Plans as Decisions and Opus 5.5 Currency

• Plans record decisions, not code — writing-plans names the test and its assertions, the signature, and the spec values, with a code body only for an algorithm those leave open. Plans end with a Review Focus list, and the user reviews the saved plan before execution.
• Security findings can't vanish silently — findings-validator rejects an auth, injection, data-loss, or secrets finding only with a quoted refutation; a finding it can neither confirm nor refute stays as advisory with a human owner.
• Sharper reviews — review ranges start at the merge base and refuse empty ranges; untracked files are in scope; spec-silent behavior is judged by what a reasonable user expects; test-coverage-reviewer asks whether a test would still pass with the code broken; security-sentinel adds SameSite cookies, signature audits, data retention, LLM tool-argument validation, and flag bypass.
• Green means the whole suite — TDD, the SDD implementer, and verification require the project's test command, with every failure named; executing-plans runs its final whole-branch review.
• Loops that stay honest — ship-pipeline routes bugs and questions away from shipping, re-verifies a plan it finds on disk, and runs an advisory danger scan before autonomous runs; pr-workflow checks the pushed HEAD and refuses to merge onto a red main.
• Lighter knowledge capture — knowledge-compounding records only what code and tests don't already preserve; session-wrap ends on an action the next session can start.
• Opus 5.5 currency — Opus 5.5 is the default model on every plan and starts sessions at medium effort. A new "Session model and effort: your choice" section explains how to set both; the blueprint doesn't prescribe a level. Workflow facts and /goal notes are refreshed.
• Two new structure checks — the collision gate fails on frontmatter that isn't valid YAML and on references/ pointers, links, or § headings that don't resolve.

Combined 2026-09-27 /cli-watch + /repo-watch cycle (Claude Code 2.1.283; six watched repositories). No new skills, agents, or hooks. Verdicts: docs/learnings/2026-09-27-cli-and-repo-watch-verdicts.md. PR #15.

v3.7.1 — Size Sweep and Fixes

• Skill size sweep — writing-skills, ship-pipeline, session-wrap, and systematic-debugging keep a lean SKILL.md and load templates, optional modes, worked examples, and long-session procedures from references/ at the point of use. Every SKILL.md body is now under the 16 KB tier (the collision gate's size report shows it); nothing was deleted, only relocated behind a pointer.
• Finishing path fixes — Option 1 (merge locally) runs from the main checkout and removes the worktree before deleting the branch, the order git accepts; a refused discard on a plain branch reports the branch instead of a non-existent worktree.
• Resume and wrap precision — resume-session requires the STATE.md stamp to be an ancestor of HEAD before counting commits, so a squash or rebase merge no longer reads as "HEAD moved"; session-wrap's STATUS.md step points ADR links at Step 12, where ADRs are created.

Maintenance patch closing the follow-ups from PR #13. PR #14.

v3.7.0 — Ecosystem Imports

The second /repo-watch cycle compared seven watched repositories against their July baselines and grafted twenty-one ideas onto existing skills and agents. No new skills, agents, or hooks; every idea re-implemented in the blueprint's own words, with provenance, deferrals, and rejections recorded in docs/learnings/2026-09-11-ecosystem-import-verdicts.md.

• Plan audit before a branch is finished — finishing-a-development-branch dispatches a fresh-context code-reviewer that classifies every plan item against the diff (DONE, CHANGED, PARTIAL, NOT DONE, DEFERRED, UNVERIFIABLE) and lists unplanned work; NOT DONE or PARTIAL blocks merge and PR, and pr-workflow renders the table in the PR body.
• Discard only on request — the default finishing menu has three options; an explicit discard lists untracked files first and relays the force commands for you to run, and no skill ever runs git worktree remove --force.
• One decision boundary — "if this is done wrong, can the system detect it and roll it back?" decides versus stops, stated once in executing-plans and cited by autonomous-loop, team-lead, build-pipeline, and ship-pipeline; must-ask categories are checked first, workers return NEEDS_INPUT instead of guessing and never spawn subagents, and ship.sh runs stop at a fixed 20-iteration ceiling read from the progress file.
• Converging fix loop — subagent-driven-development messages the same named implementer for fix rounds, re-reviews cumulatively from the pre-task commit, caps five rounds per phase, and marks a stuck task blocked in the progress ledger.
• Tests that can fail, reviewers that catch a lowered bar — Anti-Pattern 6 (falsifiability), a failing direction on every acceptance command, a quality-bar regression lens in code-reviewer, newly skipped tests and loosened assertions flagged, and a neutral-is-revert ledger in performance-profiling.
• External text is data — fetched documentation and tracker comments enter prompts inside the plugin's DATA markers; pr-comment-resolver never executes a quoted command and returns NEEDS_INPUT when a comment's intent is ambiguous.
• Handoffs you can trust — session-wrap's learnings step always runs (and says "No durable learnings this session" when true), applies a three-part ADR admission test, and stamps STATE.md with the HEAD sha so resume-session can tell whether HEAD moved; knowledge-compounding gains a gardening checklist.
• Authoring refinements — brainstorming sizes ceremony (spike, bounded, architectural) behind a fog test; writing-plans headers carry Objective, Means, and Spec; SKILL.md bodies get an 8 KB budget with a warn-only size report in the collision gate (17 bodies over 8 KB and 4 over 16 KB after these grafts); three UI anti-slop signals; contributor AI disclosure.
• Ecosystem table refreshed — current stars and 2026-09 verdicts for all seven watched repos (1.15M+ combined stars); get-shit-done is archived upstream and its lineage continues in gsd-core.

Evaluated and deferred: the watch-to-merge PR loop, retuning and eval harnesses, design spikes, release-rule discovery, worktree merge-back, the DX lens and edit lock, honest-verifier abstention, the size sweep of the four largest skills, and a ship.sh stop marker for must-ask categories.

Full record: docs/learnings/2026-09-11-ecosystem-import-verdicts.md. Second release of the 2026-09 watcher cycle (v3.6.0 was the first). PR #13.

v3.6.0 — Platform Currency Refresh

The second /cli-watch cycle audited 47 Claude Code releases (2.1.213 → 2.1.268) and refreshed every platform claim the template makes. No rebuilds and no new skills or agents: every supersede candidate resolved to keep again, with the probes and verdicts recorded in docs/learnings/2026-09-11-cli-watch-cycle-verdicts.md.

• Model-agnostic task tracking — Claude Code removed TodoWrite and the Task tools on Opus 4.8, Sonnet 5, Fable 5 and newer, so executing-plans, subagent-driven-development and writing-skills now track progress in a plan-scoped .claude/plans/<plan>.progress.local.md (git-ignored in new scaffolds, with a git check-ignore guard for older projects).
• Limits and lineup refreshed — the 200-subagent session cap is gone; the real limits are 20 concurrent subagents and a spawn depth of 3. The opt-in effort mapping now points at Opus 5 / Fable 5.1, and effort tiers are honored on every model from CLI 2.1.267.
• Native alternatives as they behave today — dynamic-workflow gating, /goal check-ins and its headless loop, teammate model rules, and the bundled /deep-research workflow that shares a name with the research-swarm skill.
• Native-first plugin update — /plugin-update tries claude plugin update (scope-aware, cache-verified) before falling back to the manual sync; README and site copy now say /reload-plugins instead of "restart".
• Two new gates — a CI job runs claude plugin validate --strict on the plugin and marketplace manifests, and the drift gate now catches a stale README "What's New" nav anchor (negative-tested).
• Diagrams re-rendered — the effort-tiers and platform-currency images are regenerated from source with the new labels.

Evaluated and kept: ship-loop.sh vs /goal, ship.sh vs claude -p "/goal …" (opt-in flag deferred), wave orchestration vs the Workflow tool (bundled workflow deferred), and the injection scanners (native observers still miss main-session Read/Write/Edit).

Full changes: #12