Problem: a planning skill turns product plans into multi-phase execution plans for autonomous coding agents. It has grown dense with procedural rules, most of them added after past failures such as helpers shipped without runtime consumers, phases marked done on a green test run, or deploys treated as proof of product completeness. Execution is now slower than desired.

Goal: execute a sequence of remaining plans faster without losing verification quality, correct code, or proper refactoring.

Hypothesis being explored: shift the plan from prescribing how each step is done to fixing what done means. Lock requirements, acceptance proof, and authorization scope; keep a short list of non-negotiable hard lines; give general issue-handling principles; and add a running learnings log that each phase reads first and appends to, with the agent allowed to adjust how later phases are executed but never what they deliver.

Unknowns: whether letting an agent rewrite later-phase execution details causes scope drift in practice; whether accumulated failure-driven rules should become a compact failure-mode checklist instead of procedure; and where learnings should live, in the plan only or promoted back into shared skills.

Resolution of the design question, from public sources plus one team's own execution records. This is a synthesis and recommendation, not a measured result; the redesign has not yet been run.

What the local evidence showed. The most recent plan produced roughly thirty planning documents over about three weeks while the code itself landed in about two days. Hardening passes per plan ranged from four to thirty, and the largest verified failure class across them was that the plan's detailed instructions were wrong: wrong file, wrong HTTP verb, columns that did not exist, hedge phrasing like or wherever the logic lives. Executors then improvised instead of stopping. Separately, four gates were found reporting green without having checked anything, and a thirty-five unit serial run died at unit twenty-seven on context exhaustion. Validation is a single-slot queue where a full test run of about nine minutes waited another eight to nine minutes each time and ran at least four times at closeout.

What the public sources agree on. First, plans for autonomous coding agents should lock scope, acceptance proof and authority, not implementation detail; excessive upfront technical detail cascades errors, and a sprint contract that fixes what done means before code is the working pattern. Second, self evaluation is blind: separating the builder from an evaluator that holds the done contract is far more tractable than making a builder critical of its own work. Third, coding parallelizes badly on the write side. Measured across tens of thousands of agent pull requests, cross agent branches conflict at roughly double the rate of same agent branches, about forty two percent versus twenty percent. The well known sixteen agent compiler run worked because tasks were naturally independent, coordination used lock files for task claims, and most human effort went into the test oracle rather than the plan; when all agents hit one shared task they overwrote each other until the task was split. Fourth, the setups that work share one shape: one main loop carries state in files, workers are stateless with narrow scope, and fresh context per task beats compaction. Fifth, learnings files help only with a size cap and pruning; without hygiene they bloat, go stale and contradict, which is exactly what happened to the team's rule set. Sixth, operators of ten plus parallel agents report the bottleneck moved to human verification and status tracking; generation rose five to ten times while verification stayed flat.

Recommendation, in payoff order: fix the validation queue by running focused tests per task and the full suite once per packet; cut the plan to about five sections plus a capped learnings file; make every check paste its output rather than assert; separate builder and evaluator; fresh context per task with fixed format status of did, verified how, still open; parallelize reads freely but writes only with declared file ownership and sequential merges; retire at least one rule per retrospective.

Failed approach worth recording: adding a new hardening rule after every retrospective. It did not reduce recurrence and became the main source of process bloat.

Uncertainty: none of the recommendations have been measured on this team yet. Felt speed is unreliable; the randomized trial literature shows a large gap between perceived and measured speed, so the queue wait log should be the yardstick.

Changed hypothesis after inspecting a parallel rewrite of the same planning skill made by another agent for the same goal, namely planner runs once, then an executor finishes the plan with no human check-ins.

Two competing designs now exist. Design A resolves maximal detail during planning for a less capable executor: exact files, commands with working directories, chosen implementations, and recovery per unit. Design B locks outcomes, proof and authority, leaves the how to a capable executor, and adds a capped learnings log. The team's own audit history shows literal anchor drift, meaning wrong files, wrong verbs and nonexistent columns written into plans, as the largest verified failure class, which argues against design A as the primary shape.

Design A still contains pieces that are reusable regardless of which shape wins: a rule that missing paperwork is not missing permission, so an already authorized executor repairs a stale or absent record through its owner and continues instead of asking again; an explicit instruction never to return at a packet handoff, a validation queue wait, or a ready to land state, and to invoke the merge step itself; a fixed recovery table keyed by failure type such as test failure, queue wait, environment defect, interrupted apply with uncertain effect, source drift, unavailable external capability, and irreversible product decision as the one stop condition; and a short list of questions a plan must answer before handoff.

Additional evidence on cost: even a documentation only change to the skill paid roughly fifty minutes wall clock, of which about fifteen minutes were waiting on a single slot validation queue and about twenty three minutes were validation itself. Recorded incidents over the prior week show queue wait time exceeding gate run time by roughly eight to one.

Uncertainty: design B remains untested here. The likely resolution is a hybrid, keeping A's authority and recovery rules inside B's shorter plan shape, with the executor free on implementation but bound on acceptance.