v2.16.0

Changed

• The outside read on a consequential technical decision names an actor and fires on a fact. technical-design said that a decision expensive to undo "gets one read from a context that did not produce it", which told nobody to take one and keyed the duty to the run's own estimate of its own choice. Ten runs in 2.4.2 produced ten sound designs and no outside read, each judging its decision cheap to reverse, and three kernel rewordings changed nothing. The read is now owed whenever the choice adds or replaces something the project then keeps: a dependency, a service, a schema, a data migration, a public interface, or custom code chosen over a maintained alternative. campaign-direction keyed its pointer to the same estimate and now keys it to the same fact.

• delegation says to set the delegate's level in the dispatch rather than to name it, and to set the host's per-delegate control rather than to name the model. In the 2.15.0 receipts one run opened the method, wrote that each lane would run at ordinary level, and passed no level in any of its five dispatches. "Named explicitly" was satisfied by saying it.

• Five rules that had two homes now have one, found by scanning every normative sentence in the package against every other. The kernel's isolated-checkout invariant was repeated word for word in advancing-tracked-work. Stopping and resuming an anomalous work stream was stated in both execution-health and campaign-direction. Reconciling an item was stated in both tracked-work methods and had already drifted, one saying an item the code has overtaken closes as done and the other that it is reported as done. The stalled-lane rule stood in three files. testing stated the regression-observation rule in two sections under two different qualifiers.

• Where the act happens in a different file from the rule's home, the point of use now carries a pointer rather than a copy. testing keeps the regression rule once, in the section that owns regression tests, and says what to do when reproducing the defect is unsafe or impractical instead of leaving that as an escape clause attached to a second copy.

• A second cross-host pass found the exclusion that bounded the first repair was the reversibility estimate in a new form. "A choice held inside one file that a later change can delete on its own" asks a run to predict future coupling, immediately after the text says these are facts rather than estimates. It is replaced by a present-state test: an implementation choice in one file is outside the rule while nothing outside that file depends on it and this same change establishes it as no boundary for later work.

• The method-list line and the scope line for campaign-direction disagreed a second time, on whether a record claiming the conditions is enough or live evidence is required. The method requires live evidence, which is what the release before it settled about records. Both lines now say so, the method's scope line as a list so that one live-evidence qualifier governs all six conditions.

• A cross-host review of the release found the first draft of the outside-read list reaching further than the rule it replaced in one direction and less far in the other: it would have fired on a one-line dependency and missed an expensive concurrency, security, deployment, or internal-architecture decision. The list now names those boundaries, and a choice held inside one file that a later change can delete on its own is excluded. docs/decisions.md says the scope moves both ways rather than claiming it did not move.

• The same review found campaign-direction's scope line naming a condition its method-list line did not, machinery delaying the outcome it protects. The method said it applied where the kernel would never open it. The method-list line now carries the condition.

Evidence

• The duplication was found mechanically and every disposition was made by hand. Every sentence of seven words or more in the kernel and the twenty-three methods was compared with every other, 865 sentences and 373,680 pairs. Forty-nine pairs passed the similarity threshold and four of them were second homes. Of the rest, nineteen are the intended pairing between a method-list trigger and the scope line repeating it, thirteen are a kernel invariant with the technique under it, and thirteen are two methods stating adjacent rules in their own terms. The fifth fix, the regression duplication inside testing, scored below the threshold because its two statements share almost no vocabulary; it was found by reading, which is where the scan ends.
• Two kernel rules that tracked-work restates as the premise of its own sections were left alone: an item exists before the branch, and an item closes on integration. Version 2.8.0 argued that placement as three options and chose it, the two copies do not disagree, and no receipt shows them drifting. Reopening it on symmetry alone is what this project's own record tells a release not to do.
• No receipt covers the new outside-read trigger. The failure it answers is measured, ten runs to zero on both hosts, and the replacement is reasoning from the text. Whether naming a fact rather than a self-estimate gets the read taken is UNVERIFIED.
• Package checks: scripts/check.py passed and git diff --check is clean. Claude package validation passed. Codex package validation is UNVERIFIED; this machine has no Codex plugin validator.

v2.14.0

Changed

• The frontier is bounded by the owner's result. advancing-tracked-work treats an open, unblocked item as takeable only when it lies on the path from live state to the requested result; an item beyond that destination is reported as takeable and deferred rather than resolved on the way. When nothing takeable reaches the result, the run stops with the human batch instead of filling the wait with enabling work the request did not name. Where the request names only the tracker, the result is recovered from the records' own parent outcome or the product brief. The always-loaded kernel states the same measure beside its continuation rule.
• campaign-direction recovers the premise from the owner's request and the owner's recorded decisions, not from a parent record the run or an audit wrote. The sentence that let security, money, recovery, and operational work produce no evidence of the result is gone; that work names the obstacle to the stated result it removes, like any other. Deferring an off-path direction is an outcome beside keep, simplify, replace, and retire, and replacing the architecture of off-path work is named as not a response. When deferral would carry the result past an unsettled risk or rollout consequence, that consequence is the one product question. With no takeable unit that reaches the result, admission stops; spare capacity admits nothing.
• The kernel extends the 2.13.1 provenance rule: a record's claim that something must precede the owner's result is a proposal on the same footing, and a record the run itself wrote carries only the authority of the request it served. A unit that must create a new prerequisite of its own before it can finish is a named trigger for campaign-direction and a stream anomaly in execution-health.

Evidence

• Two owner-run installed Codex campaigns on 2.13.0 spent a day each on enabling machinery. One asked for the tasks blocking first payments; its real blockers integrated in about seventeen hours and the remaining thirty went to one backup-recovery lineage of eight tracker items, each new one a prerequisite for resuming the last, ending uncommitted on a defect. The run admitted that lineage at hour one to use free capacity, thirty minutes after computing a money path that did not contain it, on the strength of an audit finding that said recovery precedes traffic. The other asked to exhaust the takeable frontier of a tracker built from a complexity audit; it did exactly that, closing twelve tooling and evidence items over twenty-three hours while the item the audit had called most important waited on the owner, and nothing in the package made it say so or ask whether to go on. A third run of eight hours on a scoped bug-and-staging request showed no deviation and its result was accepted.
• campaign-direction was opened in the first campaign three times and each pass replaced the architecture of the same direction. The 2.13.1 kernel wording reached that run mid-way and fifteen more hours followed on the same lineage. That is one session showing the released text in context and not stopping the drift; the second shows the tracker-only request shape the package could not measure. The wording defects are readable in the files: premise recovered from records the run wrote, an exemption for recovery work, no defer outcome, and a frontier defined by blockers alone. Details are in docs/evidence.md.
• The transcripts show the per-lane rules of execution-health being applied in those runs. No numeric limit was added; a two-hour rule and a one-item-per-session rule were both refused again, see docs/decisions.md.
• One matched isolated Claude Code pair on a five-minute fixture showed exact 2.13.1 and this package behaving the same: closing the items on the payment path, continuing past a human-gated item rather than stopping at it, marking audit-derived infrastructure as proposed, and putting the backups-before-money question to the owner as a risk choice. That is a non-regression receipt; the drift lives in day-long installed runs, so the improvement stays UNVERIFIED until the owner's next long campaign. See docs/evidence.md.

v2.13.1

Fixed

• Project evidence now settles facts without silently settling future product scope. The always-loaded kernel distinguishes code and current behavior from issues, audits, recommendations, and proposed plans. A material capability becomes future product scope only when the current request chooses that outcome, an authoritative product brief establishes it, or a recorded owner decision adopts it.
• product-decisions applies that distinction while clarifying the result. tracked-work preserves whether incoming material is proposed, accepted, or waiting on an owner decision instead of making a proposal accepted by turning it into a takeable item. Only work that depends on the unresolved choice waits; independent work continues.

Evidence

• One linked dogfood incident across three private 2.12.x sessions showed an audit recommendation becoming takeable work and then implementation without an owner decision adopting the affected capability as future product scope. The audit, planning, and execution sessions are one causal chain, not three independent observations.
• In an isolated Claude Code fixture, the exact 2.13.0 package made both an accepted core-flow repair and a capability absent from the authoritative product brief Ready. Candidate 2.13.1 runs that loaded the skill distinguished the accepted repair from the unadopted proposal, but did not reliably ask the owner the product question; one exact-package repeat did not load the skill and promoted both findings. The contract ambiguity is fixed, while the complete behavior change remains UNVERIFIED.

v2.13.0

Changed

• The new focused campaign-direction method responds when repeated repairs, competing implementations, post-target machinery growth, or overloaded integration show that recorded or active work no longer supports the requested result. It reuses the existing technical-design and deletion disciplines instead of asking the owner to choose an implementation.
• Decomposition checks whether live evidence already contradicts the common direction inside its existing cold read. It adds no second review. Continuing tracked work opens campaign direction only on observed drift, and worsening execution stops only affected lanes while independent work continues.
• Readiness no longer implies unlimited admission. Delegation starts only as many independent units as the current run can isolate, integrate, and revalidate without sibling work invalidating their evidence. The agent chooses that capacity from live state; the owner sets no technical work limit.
• The kernel now states the reporting side of technical authority directly. Technical decisions are reported as settled, not offered to the owner for approval, reversal, or a request for the alternative. Only an unresolved product consequence, protected action, or human-only step becomes a question.

Evidence

• Two owner-requested audits exposed long campaigns whose repair, testing, and delivery machinery grew faster than evidence of the product result. One also carried high concurrent work in progress and parallel business paths; the other extended certification after its internal performance target had passed. The audits establish those conditions, not that SkipHow caused them.
• Reading the 2.12.1 contract found the narrower wording defect: no reached method owned the premise shared by a campaign, and delegation required every ready unit to start.
• Five matched Claude fixtures showed the first candidate opening for three stale directions, preserving justified refund-recovery work, and staying closed on healthy product slices. The baseline also made the central corrections in all three positive cases. Review rejected both the unconditional trigger and the added decomposition gate. A later five-session candidate opened the method only for the three stale directions.
• Candidate revisions made technical decisions but still invited the owner to reverse them. The released package moves that boundary into the kernel and limits owner reversal to product choices. Exact-package repeats of the release-runner and refund fixtures kept technical alternatives internal. Codex behavior is UNVERIFIED because a properly isolated profile required a human login, and credentials were not copied to bypass it.

v2.12.1

Changed

• Public positioning now describes SkipHow as outcome-first, instruction-level orchestration. The README and product site explain the three separate responsibilities: SkipHow supplies orchestration policy, Claude Code or Codex supplies execution, and a control plane, when one exists, owns durable workers and operations.
• The README and site now lead with the product problem and mechanism: one public skill, focused internal methods selected from the work, product decisions retained by the owner, and engineering carried through evidence by the agent. A founder note records the practical mismatch that led to the design without making comparative performance claims.
• The comparison and FAQ now distinguish base agents, skill libraries, adaptive orchestration, prescribed workflow frameworks such as Superpowers, and runtime orchestrators. The package still claims no comparative advantage, automatic-selection rate, or demonstrated multi-agent delegation.
• Repository, marketplace, social, and search metadata now use the same category. GitHub topics target agent orchestration, agent instructions, agentic coding, the two supported hosts, their plugin formats, and the product-owner audience.

Evidence

• The category correction follows current primary definitions from OpenAI, Anthropic, and Google Cloud, all of which distinguish deciding the flow of agent work from providing the execution runtime. The package boundary itself remains deterministic: SkipHow ships Markdown policy and no model runner, scheduler, queue, persistent worker service, lease manager, budget enforcer, or control plane.
• No runtime instruction or focused method changed. Existing behavioral receipts and their limits are unchanged; reliable multi-agent orchestration under the shipped policy remains UNVERIFIED.

v2.12.0

Changed

• execution-health now treats a healthy long-running lane as event-driven work. Once the host has a live handle and the lane remains inside its stated expectation, the root waits for completion, attention, an expectation breach, or a result that changes the next action. An expired bounded wait with unchanged state causes no inspection, narration, or fresh decision pass.
• delegation now includes the working state a unit created in that unit's named end. Its final reconciliation follows the existing finishing-a-branch method and reports any branch or isolated checkout it could not retire, instead of declaring the delegated set finished while integrated state remains unaccounted for.

Evidence

• Across the three largest installed Codex task roots examined for this release, 1,785 delegate waits included 855 timeouts that returned no activity. In the two roots with per-turn accounting, the 472 unchanged timeouts made the following turns process 62,931,387 input tokens, 99.4 per cent of them cached. This is repeated context traffic, not unique tokens. Only six root compactions occurred across roughly 43 hours, so repeated unchanged wakeups, not compaction alone, were the larger context cost. The new observation wording has not yet run in a comparable session and remains UNVERIFIED.
• One installed task created 32 worktrees while delivering and integrating its delegated units, issued no worktree removal or prune command, and reported completion without disclosing the remaining working state. The authoritative cleanup method had reached context. The new reconciliation sentence restates the existing outcome at the point where the root closes the delegated set; whether it prevents accumulation remains UNVERIFIED.

v2.11.2

Fixed

• The unconditional resume and compaction reminder named .skiphow/handoff.md in every project, while the continuity method reserves that fallback for a project with no tracked-work destination. A genuine installed 2.11.1 compaction delivered the reminder as a developer message; the agent repeated it and probed the path on its next live-state read even though the project kept the active work elsewhere. The reminder now reloads the kernel, request, repository instructions, and live state without selecting a continuation store. The conditional handoff fallback is unchanged.

Evidence

• One installed Codex session running 2.11.1 reached a genuine compaction. The exact hook output reached the agent as a developer message, and the agent's next update and live-state read followed its unconditional handoff instruction. That proves the old wording caused the unnecessary probe. No genuine compaction has run on the corrected package, so its continuation behavior remains UNVERIFIED.

v2.11.0

Fixed

• The kernel's method list opened with a permission and closed with an obligation, and the permission stood first. "Read only the guidance that materially helps the current request" asks a run to weigh what a method would add before opening it, which is a judgment nothing can make about a file it has not read. Version 2.5.0 had already added the obligation two paragraphs below it, on receipts showing methods going unread, and left the permission in place. The obligation is now the opening sentence and the permission is gone from both places it stood, the section itself and the skill description a host reads when it selects the skill: read the method that governs an act before that act, whether its trigger matches is the only question, and one whose trigger does not match stays unopened. No rule was added: one obligation replaced the permission and the restatement of that obligation below the list, and the section is sixteen words longer than it was.
• The rule sending a plan that spans several units to the project's tracker was conditioned on "an authorized change", which left out the other way a plan becomes a record: the owner asks for the plan itself, hands it to a later run, and authorizes no change at all. The destination now follows the plan — where the request authorizes recording it, as the record the owner asked for or as the state an authorized change needs to finish safely, it goes where the project keeps tracked work. decomposition carried the same rule for a split and the same looseness, conditioned on any authorized durable record, and it is corrected with it. The grant is unchanged: a request that authorizes no record still writes nothing, and a request whose record is something else is not permission to write a plan beside it.

Evidence

• The scan that prompted this release covers every session on the maintainer's own projects that loaded an installed package, and searches each installed reference file's own opening sentence rather than its path. It splits by major version: under 1.x, twelve of nineteen sessions carried at least one method's text into context; under 2.x, none of eighteen did, and only one of those touched the package directory at all, to measure the size of the plugin cache. The two most consequential 2.x runs in the period — a triage that opened twenty-two tracker items, and a three-and-a-half-hour run with twenty-eight delegates — opened none of tracked-work, continuity, decomposition, or delegation.
• The paired isolated runs do not reproduce that failure, and the release does not claim the change repairs it. On a throwaway fixture with the host's own built-ins and nothing else, 2.10.1 opened the matching method in three of three sessions, before acting in each, and opened nothing for the request that matches no trigger. The release candidate did the same: diagnosing-bugs on the defect, tracked-work and project-setup on the request to record findings, prioritization on the request to order competing work, and nothing on the plain question. So the non-loading is real in long installed sessions and absent in a clean one, which points at what those sessions carry rather than at the sentence changed here. The cause stays UNVERIFIED.
• What the change rests on is the contradiction itself, which is readable in the shipped text and needs no receipt. Whether removing it changes what a long session does is unmeasured, and the release candidate opened somewhat more methods per session than 2.10.1 on the same prompts, which one run per cell cannot separate from noise.
• The plan-destination correction has one observation behind it. An installed 2.10.0 session asked to record a batch of findings and extend the plan for the next agent opened twenty-two items in the project's tracker and wrote the plan and the launch brief into two ignored local files, beside two more the same project had already accumulated, none of them visible to the tracker holding the items. The owner's launch prompt for the next run then had to name that file by hand.
• Package checks: scripts/check.py passed, git diff --check clean, Claude package validation and isolated install passed. Codex package validation and isolated install are UNVERIFIED: this machine has no Codex plugin validator installed.

v2.10.1

Fixed

• The kernel already forbade asking the owner to choose engineering mechanics. It now restates that where a permitted ask is actually put. Authority allows an ask for a protected action, a material product choice, or a human-only step, which governs what an ask may concern and never how it is worded. Autonomy governs the wording, and its explanation was scoped to the product choice, so nothing repeated the ban at the moment a run decides how to phrase a protected ask it is entitled to make. The two sentences compose without conflict — choose the mechanism yourself, then ask only for the grant — and the receipt below is a run that failed to compose them. The kernel now states the composition: a protected or human-only ask is put the same way as a product choice, as what it changes for the owner, their account, or their exposure, with the technical decision already taken. No choice between technical options is put to them, and where the ask exists only because a step is theirs to perform, what is asked for is that step rather than approval of the way around it.

Evidence

• An installed 2.10.0 session on a real project ended a two-hour run by asking its owner whether it might replace a named environment variable on staging with the currently authorized GitHub CLI token, offered against a properly scoped token the same sentence called better. The owner rejected it as a question that was never theirs, and named the boundary in their own words: they settle product questions and what no agent can reach, and nothing else.
• The run deviated from text that was plain and in context. "Do not ask them to choose libraries, branches, test commands, schemas, architecture, or other engineering mechanics" was in the kernel all session; the run's reasoning never reaches it, and reasons only from the credential clause it was obeying, which it quoted an hour earlier while making the staging configuration change beside it without asking, because the owner's request had named staging and had not named credentials. Told the decision was its own, it named the same defect the owner had — the phrasing, not the ask — and finished the delivery within the hour. The message's other item, a payment setting only the owner could reach, drew no objection.
• One session cannot show that agents in general need more than the sentence that was already there, and this release does not claim it does. The receipt meets the revisit condition recorded under "An unstated choice is an unfinished result" — an owner asked about engineering mechanics — and not the neighbouring condition of repeated such questions: a scan of every session on both hosts that loaded the package in a real project found this one instance, and the only other permission-shaped question was a legitimate product question about what a public ranking may reveal.
• So this is a clarification shipped against an unmet evidence bar, recorded as the owner's decision rather than as a demonstrated need, the same disposition 2.5.0, 2.8.0 and 2.10.0 took. Their ground is that the owner never handling engineering is the boundary the product exists to hold, so a single visible breach of it is worth restating the rule where the breach happened. What holds the cost down is that nothing here is a step or a gate: it constrains the wording of an ask the contract already permitted, in the section that already explains how an ask is put.
• Two narrower alternatives lost. Rescoping the existing sentence from "a product choice" to any input would have carried "recommend one option" with it, which is written for a menu and would license the very shape that failed. Narrowing the credential gate so that configuring a credential inside an already-granted destination needs no separate grant would have removed the question instead of fixing how it was put, and the receipt argues against it: what was moving was the owner's personal identity into a persistent deployed service, which is the case that clause protects, and the grant cost one turn rather than the work.
• The separation this states is the one mattpocock/skills issue #962 proposes and its maintainers have left open: ask about the situation and the outcome in plain language, and map the answer to the technical term afterward. It also carries to a protected ask a boundary this project had already drawn three times against a menu of engineering options put to the owner, in to-spec, to-tickets, and finishing-a-development-branch.
• Whether the wording changes what a run writes is UNVERIFIED. No paired receipt was made, and the rule the run broke was already there.

v2.10.0

A design method opens on what the project answers.

technical-design now opens for a technology, architecture, or system-shape choice that nothing already in the project answers, in place of one the agent judges material — a self-assessment this repository had already measured failing inside that same file. The method also says what to do when constraint recovery comes back empty because the project is new: those constraints are unstated rather than absent, they belong to the owner, and only the ones that would change the shape are asked, inside the round product-decisions already runs.

codebase-design now also opens for an existing structure the owner asks to improve, a case no method reached before. It scopes the look by what the project's history keeps returning to, and separates the survey from the change so the request keeps the grant the kernel gives it.

Reviewed on the other host in two rounds; five qualifying findings confirmed and fixed. Whether either new trigger changes what a run does is UNVERIFIED. Full notes in the 2.10.0 section of CHANGELOG.md.