[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BJ9BX3FSEPSFADNZFTZBA":3,"skill-same:01M69BJ9BX3FSEPSFADNZFTZBA":107},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":62},"01M69BJ9BX3FSEPSFADNZFTZBA","ten-lane-highway",null,"Become the Highway Manager: drive many parallel \u002Fgoal lanes continuously toward a defined outcome, refilling lanes on every manager cycle so none sit idle. Use when the user wants continuous parallel throughput toward an outcome: \"run the highway\", \"\u002Fhighway\", \"10-lane highway\", \"keep N lanes full\", \"keep re-feeding lanes as they drain\", \"drive this for me in parallel\", \"do them all and monitor\", \"keep the lanes full\", \"work the whole list in parallel until done\". NOT for a one-shot batch that launches once and drains together — use goal-batch. NOT for bounded edits that each end in their own PR — use mass-change. Requires git, tmux, the amplifier CLI on PATH, and the goalify and monitor skills.","microsoft\u002Famplifier-app-cli","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BHYVWVEWQF0DY6W6TMESV",19,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27],"ten lane highway","cli","tmux","change","pr","monitor","run","git","goalify","2026-11-10 10:12:30",false,"---\nname: ten-lane-highway\ndescription: >\n  Become the Highway Manager: drive many parallel \u002Fgoal lanes continuously\n  toward a defined outcome, refilling lanes on every manager cycle so none sit idle.\n  Use when the user wants continuous parallel throughput toward an outcome:\n  \"run the highway\", \"\u002Fhighway\", \"10-lane highway\", \"keep N lanes full\",\n  \"keep re-feeding lanes as they drain\", \"drive this for me in parallel\", \"do\n  them all and monitor\", \"keep the lanes full\", \"work the whole list in\n  parallel until done\". NOT for a one-shot batch that launches once and\n  drains together — use goal-batch. NOT for bounded edits that each end in\n  their own PR — use mass-change. Requires git, tmux, the amplifier CLI on\n  PATH, and the goalify and monitor skills.\nversion: 1.0.0\nuser-invocable: true\nshortcut: highway\nargument-hint: \"\u003Cthe outcome to drive, constraints\u002Fdeadline, and where the work lives>\"\nmodel_role: general\nvisibility:\n  summary: \"Drive many parallel \u002Fgoal lanes continuously toward an outcome — refill on drain, verify by evidence, close per completion intent.\"\n# Deliberately NOT `context: fork`: the approval gate, mid-flight steering, and\n# conflict questions must happen in THIS conversation across many turns. A fork\n# is call-and-return; a highway manager is a standing conversation partner.\n# (`allowed-tools` omitted: it only takes effect under fork.)\n---\n\n# Ten-Lane Highway\n\nRun continuous parallel agent lanes toward a defined outcome. Success is not\n\"lanes ran\": it is the outcome reached (or honestly blocked with named\nreasons), every landed lane merged, retained as a verified PR, or honestly\ndispositioned by its authorized owner under the captured completion intent, the\nOperating Picture current, and the scaffolding torn down.\n\nThe predecessor pattern (goal-batch) launches a set and drains it. The highway\nreplaces batching with **continuous scheduling**: \"I have N units of execution\ncapacity. Never wait for a batch. Continuously decide what the best available\nuse of each unit is.\" You are doing agent capacity management — closer to OS\nscheduling than to a task list.\n\n## First run (~15 minutes)\n\nNew to the highway? Do a throwaway run first — a scratch repo you can break,\n**width 2**. Invoke `\u002Fhighway` with a small outcome + that repo + \"width 2\";\napprove at the Phase 3 gate (nothing launches before you say go); then watch\n**gate → 2 lanes → watchdog → authorized landings**, refilling until the queue drains. Stop\neverything through the batch's explicit `HIGHWAY_TMUX_SOCKET` (default\n`hw-\u003Csanitized-batch>`), then delete `BATCH_DIR`. Full command sequence and\nexpected output: `examples\u002Ffirst-run.md`.\n\n## You are the Highway Manager — a strategist, not an intake clerk\n\nYou take the user's **outcome\u002Fgoal**, their **constraints** (time, authority,\nresources), the **current state**, and the set of **possible work**, and you\ndrive the whole operation in proxy for the user:\n\n- **Select** work to best achieve the outcome within the constraints — you do\n  not simply execute everything that arrives, and you do not FIFO the queue.\n- **Adjust continuously** on your own: re-prioritize as lanes land, as\n  discoveries surface, as the deadline nears.\n- **Weave in new incoming** (user feedback, lane discoveries, external events)\n  by explicit decision: do it now \u002F queue it at a priority \u002F decline it — each\n  with a reason, recorded. Nothing enters or leaves the plan silently.\n- **Keep the context straight across lanes**: the Operating Picture\n  (`HIGHWAY.md`) is your externalized brain — outcome, constraints, lane board,\n  priority rationale, weave-in log. Rewrite it every cycle.\n- **Autonomy boundary**: you decide scheduling, priority, lane composition,\n  and merge order alone. You escalate only outcome\u002Fconstraint changes,\n  irreversible external actions (publishing, deleting, spending), and genuine\n  blockers.\n\nYou do not do the lanes' work. If you catch yourself editing a lane's code\nmid-flight, stop — fix the goal file or relaunch instead.\n\n## Inputs\n\n- `$ARGUMENTS`: the outcome to drive, constraints\u002Fdeadline, and where the work\n  lives (repos, tracker project, backlog). If empty, ask for the outcome — this\n  skill is inline, so asking is cheap. Do not invent one.\n\n## Instruments (companion scripts — the mechanisms)\n\nResolve paths via the `skill_directory` returned by `load_skill`; call them as\n`\u003Cskill_directory>\u002Fscripts\u002F\u003Cname>.sh`. **Never copy a script into a target\nrepo** (a real run left `.amplifier\u002Fbin\u002F` behind as untracked pollution).\n\n| Script | Job | Rule it mechanizes |\n|---|---|---|\n| `highway_readiness.sh publish BATCH_DIR RUNNABLE` | Atomically publishes the manager's current batch-runnable count | The watchdog must not mistake unused capacity for work to invent |\n| `highway_status.sh BATCH_DIR WIDTH [RUNNABLE]` | ONE call reports every lane + watchdog liveness and **computes DEFICIT by code** from shared readiness | \"Keep lanes full\" stopped being prose the day a run sat at 1 lane with work for 10 |\n| `launch_lane.sh BATCH_DIR LANE REPO GOAL [BASE_REF]` | Worktree + branch + tmux + `\u002Fgoal` session, idempotent; the ONLY writer of `manifest.tsv` | Hand-written manifests diverged on column count and broke a real batch |\n| `verify_lane.sh BATCH_DIR LANE` | Git-facts probe for one landed lane (DONE.json, ahead-count, three-dot diffstat, uncommitted work) | \"Ground truth from git and the filesystem, not from what any session said about itself\" |\n| `highway_watchdog.sh BATCH_DIR WIDTH SESSION_ID [INTERVAL] [MAX_HOURS]` | Detached tmux loop that appends rate-limited `wake-needed` advisories for lane-end \u002F under-width \u002F stale heartbeat; `SESSION_ID` remains a required compatibility record | The highway once froze overnight because the manager stopped monitoring the moment it reported status |\n| `infra_ledger.sh BATCH_DIR add TYPE ID DESTROY_CMD...` \u002F `infra_ledger.sh BATCH_DIR sweep --all-owners` | Records any infrastructure a lane OR the manager stands up (DTU, gitea instance, container, service, background process) into `infra.tsv` at creation, each with its teardown command; `sweep` runs those commands and exits non-zero until nothing is left standing | A run closed with a DTU and a gitea container still live — nothing the highway stands up should outlive it (Rule 14) |\n| `lane_teardown.sh BATCH_DIR LANE claim ID...` \u002F `lane_teardown.sh BATCH_DIR LANE teardown\\|reconcile\\|list\\|audit` | **A LANE's** teardown: destroys only the rows that lane claimed, verifies each container is actually gone before flipping its row, and never runs another lane's destroy command. Dry-run by default; `--yes` to act | The emergency recovery path used to live in another repo, untracked — the skill named a tool it did not ship, and an operator mid-incident followed that path to nothing |\n\n**`sweep` is the MANAGER's batch-close verb, never a lane's.** It runs EVERY\nopen row's destroy command, so one lane calling it destroys every other lane's\nlive infrastructure — that is not hypothetical: on 2026-09-02 a single foreign\n`sweep` took lane l1's three DTUs and lane 161's three, 35 minutes into their\nmeasurements. The script now **refuses with exit 3, having run nothing**, when\nthe open rows span more than one owner or any row is unattributable, so:\n\n- **A lane tearing down its OWN rows uses the lane-scoped teardown tool that\n  ships with this skill** —\n  `\u003Cskill_directory>\u002Fscripts\u002Flane_teardown.sh BATCH_DIR \u003Clane> teardown --yes`;\n  omit `--yes` for a dry run — which touches only the rows that lane claimed. A\n  lane never calls `sweep`. A lane name that ALMOST matches the claimed owner\n  **exits 4 naming the candidate owners and their open-row counts**, rather than\n  reporting success for a teardown that would do nothing: on 2026-09-05\n  `lane_teardown.sh \u003Cbatch> drbf teardown --yes` printed *\"lane 'drbf' owns no\n  open rows — nothing to do\"* and exited 0 while six rows were open under\n  `drbf-compaction-notice-ab`.\n- **The manager closing the batch passes `--all-owners`** — the deliberate\n  batch-close override. Every close instruction below says\n  `sweep --all-owners` for exactly this reason: a guard that deadlocks the\n  documented close is a regression, not a fix.\n\nA destroy command for infrastructure that is **already gone** closes its row as\n`swept:already-absent` — distinct from `swept`, because the sweep did not\nperform that teardown. A REAL teardown failure still exits non-zero and leaves\nthe row open; the already-gone signature is deliberately narrow, so the signal\nthat a teardown genuinely failed is never lost.\n\n**`highway_status.sh` reports `orphan_rows=N owned by: \u003Clane>(n)`** — open\nledger rows whose owning lane is **not live**. On 2026-09-05 a tmux server\nrestart killed three lanes at once and left six DTU containers RUNNING with\nopen rows; the ledger recorded all six correctly and the status report showed\nthe lanes ENDED, but **nothing joined the two**, so the manager found the\ncontainers only by running `incus list` by hand. A non-zero `orphan_rows` means\ninfrastructure with nothing driving it (Rule 14) — reclaim each named lane with\n`\u003Cskill_directory>\u002Fscripts\u002Flane_teardown.sh BATCH_DIR \u003Clane> teardown --yes`\n(the report prints that path resolved, ready to paste). The report **destroys\nnothing**: a false positive that prints is a nuisance, a false positive that\ndestroys is another 0rg. A **live** lane's rows are never counted. Owners are\nmatched by exact lane name, else by a unique lane-name prefix (so a row claimed\nwith the short work-item id `vbs` still resolves to lane `vbs-…`); an owner\nthat matches no lane, matches ambiguously, or is unclaimed is reported as such\nrather than guessed at.\n\nUse one workspace-contained `BATCH_DIR` per highway, following the caller's\nworkspace conventions. The caller defines where `BATCH_DIR` lives, not this skill.\nEstablish that path before creating batch state or launching lanes. Keep any\n`HIGHWAY_LANES_ROOT` override within the same workspace.\n\nState lives in `BATCH_DIR`:\n`manifest.tsv` (scripts write), `HIGHWAY.md` (you write), `goals\u002F` (pre-composed\ngoal files), `lanes\u002F` (worktrees), `.width` (authoritative width), `infra.tsv`\n(the infra ledger), `infra.owners.tsv` (which lane claimed which row),\n`.manager-heartbeat`, `.runnable-work` (an atomic batch-runnable snapshot),\n`wake-needed` (append-only watchdog advisories retained while the watchdog\nruns), `watchdog.log`.\n\n## Phase 1 — Intake\n\nEstablish with the user (from `$ARGUMENTS` plus at most one round of\nquestions): the **outcome** in checkable terms, **constraints** (deadline,\nauthority boundary, protected repos\u002Fpaths), **width** (target lane count —\ndefault 10; ceiling is always ready work), **where work comes from**\n(work-tracker project, backlog file, or decompose-from-outcome), and the\n**completion intent** — how the user wants THIS engagement to end and how to\ntreat new work while it runs. This is the user's call to make; capture it, do\nnot impose one. Common shapes (not an exhaustive list — honor what they\nactually asked):\n- *Achieve-then-hold:* reach the outcome, then stop building — but stay open to\n  adjustments\u002Fnew work they send before the deadline, or surface and ask\n  whether to take more on.\n- *Run-to-deadline:* use the whole budget — get the outcome solid first, then\n  keep going, smartly choosing the most valuable beyond-minimum work from the\n  backlog until time is up.\n- *Achieve-and-close:* no live clock; when the outcome is verified and nothing\n  is pending, close.\n- *Run-to-PR:* prepare and verify the requested PRs, then hand them to their\n  authorized repository owner; do not merge without separate authority.\nRecord the captured intent in `HIGHWAY.md` as the engagement's completion\npolicy, and honor it with judgment at close (Phase 7).\n\nCreate `BATCH_DIR` and write the first `HIGHWAY.md` from\n`examples\u002Foperating-picture.md`.\n\n**Success criteria**: `HIGHWAY.md` exists with outcome, constraints, width,\nwork source, AND completion intent filled in — not placeholders.\n\n## Phase 2 — Strategize\n\nDecompose toward the outcome into independent, lane-sized items (in the\nwork-tracker when available — claim\u002Fheartbeat semantics are built for this).\nCollision-check like goal-batch Phase 1: two items wanting the same files\neither fold into one lane or get sole ownership. Order by dependency AND\nstrategic value toward the outcome — not arrival order. Mark\ninvestment\u002Fspeculative candidates (recon, spikes, de-risking) to backfill idle\ncapacity later.\n\n**Pre-compose the whole queue now.** `load_skill(\"goalify\")` **inline — never\ndelegated** (goalify reads the live transcript; a sub-agent cannot) and write a\ngoal file per queued item up front into `BATCH_DIR\u002Fgoals\u002F\u003Citem>.md`, each with a\ndisjunctive exit and per-item residuals. This makes every later refill a bare\n`launch_lane.sh` call, never compose-then-launch (idle capacity is the enemy —\nPhase 5 invariant); an item arriving at weave-in gets its goal file composed\nwhen it enters the queue, not at refill. Each goal file MUST instruct its lane to\nregister any infrastructure it stands up — DTU, gitea instance, container,\nservice, background process — with `infra_ledger.sh \u003CBATCH_DIR> add \u003Ctype> \u003Cid>\n\u003Cdestroy-cmd…>` at creation (Rule 14), and to tear down **only its own rows**\nvia the batch's lane-scoped teardown tool. A goal file must never tell a lane to\nrun `sweep`: that is the manager's batch-close verb and it destroys every other\nlane's live infrastructure.\n\n**Success criteria**: a priority queue in `HIGHWAY.md` with a one-line\nrationale per item tied to the outcome\u002Fconstraints, and a pre-composed goal file\nin `BATCH_DIR\u002Fgoals\u002F` for every item in it.\n\n## Phase 3 — Approval gate `[human]`\n\n**Human checkpoint — the one mandatory stop. Nothing launches before the user\nsays go.** Show on one screen: outcome, width, the first wave of lanes\n(lane → repo → item), the priority rationale, and watch cadence. Accept\nconversational approval (\"go\", \"go, only ping me if it breaks\"). Never infer\napproval from enthusiasm or silence.\n\n**Success criteria**: an explicit affirmative from the user.\n\n## Phase 4 — Saturate\n\nFor each lane in the first wave, launch from the goal file Phase 2 already\npre-composed in `BATCH_DIR\u002Fgoals\u002F` — no goalify here:\n\n- `launch_lane.sh BATCH_DIR \u003Clane> \u003Crepo> BATCH_DIR\u002Fgoals\u002F\u003Citem>.md [base]`.\n- **Every pre-composed goal file whose item lives in a work-tracker project\n  must clear goalify's L7 at composition time (Phase 2)**: the goal names\n  `work_erratum` as the terminal verb for the case where the item is already\n  resolved or held by another session. `work_resolve` and `work_release` both\n  refuse a session that never held the item, so a lane that ends only in\n  those verbs has no reachable terminal state the moment a sibling resolves\n  the item (rule 14).\n\nThen start the watchdog. **`\u003CBATCH_DIR>`, `\u003CWIDTH>`, `\u003CSESSION_ID>` below are\ndocumentation placeholders — substitute literal values; they do not exist as\nshell variables.** Your session ID is shown in your environment context\n(`Session ID: ...`). Persist it to disk FIRST because the compatibility\nwatchdog interface still requires it, although the watchdog records it only\nand never re-enters that session:\n\n```bash\nprintf '%s\\n' \"\u003CSESSION_ID>\" > \u003CBATCH_DIR>\u002F.session-id\nprintf '%s\\n' \"\u003CWIDTH>\" > \u003CBATCH_DIR>\u002F.width   # authoritative width — the single\n                                               # source of truth the scripts read\n# Publish the manager's verified batch-runnable count before the watchdog can\n# decide whether unused capacity needs attention. This is not raw tracker-ready:\n# exclude conflicts, dependencies, and work without a pre-composed goal.\n\u003Cskill_directory>\u002Fscripts\u002Fhighway_readiness.sh publish \u003CBATCH_DIR> \u003CRUNNABLE>\ntouch \u003CBATCH_DIR>\u002F.manager-heartbeat   # BEFORE the watchdog starts, to provide\n                                        # initial timing context for its log\nBATCH=$(printf '%s' \"$(basename \u003CBATCH_DIR>)\" | tr -c 'A-Za-z0-9_-' '_')   # same sanitization the scripts use\nHIGHWAY_TMUX_SOCKET=\"${HIGHWAY_TMUX_SOCKET:-hw-${BATCH}}\"\nexport HIGHWAY_TMUX_SOCKET\ntmux -L \"$HIGHWAY_TMUX_SOCKET\" new-session -d -s \"hw-watchdog__${BATCH}\" \\\n  \"\u003Cskill_directory>\u002Fscripts\u002Fhighway_watchdog.sh \u003CBATCH_DIR> \u003CWIDTH> \u003CSESSION_ID> 300 12 2>&1 | tee -a \u003CBATCH_DIR>\u002Fwatchdog.log\"\n```\nThen touch `\u003CBATCH_DIR>\u002F.manager-heartbeat` again at the start of every Phase 5\ncycle (step 1) and after each merge. It is advisory timing context only: a\nheartbeat cannot prove that a manager is idle or busy, and does not suppress a\n`wake-needed` record.\n\n**Width, readiness, the tmux socket, and escalation.** `\u003CBATCH_DIR>\u002F.width` is the single\nsource of truth for the target lane count (the scripts read it there); changing\nwidth mid-run is an explicit act — **edit `\u003CBATCH_DIR>\u002F.width` AND log it in the\nweave-in log**, nothing else moves width. Every highway tmux command runs on the\nper-batch socket `HIGHWAY_TMUX_SOCKET` (default `hw-\u003Csanitized-batch>`) — hence\nthe explicit `-L \"$HIGHWAY_TMUX_SOCKET\"` above and on the Phase 7 kill. The\nmanager publishes its current batch-runnable count through `highway_readiness.sh`;\n`drained` means zero fresh runnable work, while `unknown` or `stale` readiness is\nnever a zero and must be investigated. An `escalation-needed` marker or\n`ESCALATIONDEFERRED` log entry means investigate the persistent deficit; it is\nan advisory, not consent to merge or an automatic session re-entry.\n\nVerify launch: run `highway_status.sh` once — every lane LIVE past its first\nLLM call (log growing), watchdog LIVE. Then build the **todo lane board** (see\nbelow).\n\n**Success criteria**: status output pasted in the transcript showing all\nlaunched lanes LIVE, watchdog LIVE, DEFICIT=0.\n\n## Phase 5 — Steady-state cycle (the loop)\n\nRun this whenever control returns — a delegated watcher returning, a watchdog\nadvisory found in `wake-needed`, or a user message while lanes run. The watchdog\ndoes not re-enter the session or promise a notification.\n\n**The invariant: while backlog exists, live lanes == width, continuously.** A\ndrained lane is refilled the INSTANT it drains — one lane ending is one refill,\nNOT a signal to wait for the whole wave to land. Merging, verifying, reporting,\nand re-strategizing all YIELD to keeping width full. (Graded battery: the\nmanager wave-batched — drain 5 → merge+re-test all 5 → then refill — idling\ncapacity 135–286s while 15–20 items waited. That is the exact failure this\ninvariant exists to prevent.)\n\n1. `touch $BATCH_DIR\u002F.manager-heartbeat`.\n2. Get RUNNABLE (the batch's ready, dependency-clear, non-conflicting items with\n   pre-composed goals) from the work queue and current lane board.\n3. **Run `highway_status.sh BATCH_DIR WIDTH RUNNABLE` and paste its output.**\n   This atomically refreshes `.runnable-work`; use\n   `highway_readiness.sh publish BATCH_DIR RUNNABLE` when publishing without a\n   status report.\n4. **If `DEFICIT>0`: refill FIRST** — before merging, before reporting, before\n   anything. Pick the top-priority ready items (strategist's choice) and\n   `launch_lane.sh` each from its pre-composed `BATCH_DIR\u002Fgoals\u002F` file — refill\n   is a bare launch, never a compose-then-launch. Under-width with ready work is\n   allowed only with an explicit one-line justification in the transcript that\n   cycle.\n5. **Width first, then resolve landed lanes — never the reverse.** Step 4 (restore width)\n   always precedes this. For each ENDED lane: `verify_lane.sh`, then YOUR own\n   artifact check, then the authorized repository owner or batch authority may\n   `merge --no-ff` from the main checkout or retain a verified PR when the\n   captured completion intent allows; otherwise record the disposition and seek\n   that authority. Resolve the item with a user-readable reason, tear down\n   (worktree remove, branch delete, tmux kill). **Do NOT serialize a full-suite rerun after every single merge** —\n   that is what idled capacity for minutes in the battery. Instead: run the\n   merged lane's OWN tests immediately (fast proof it landed), and run the FULL\n   suite on a cadence and at close (a periodic + final full sweep catches\n   cross-lane interaction without blocking refill). **If any lane drains during\n   the merge pass, jump back to step 4 and refill BEFORE continuing to merge.**\n   Repair small defects in place or file the honest negative — never let one\n   straggler block the others.\n6. Strategize: process anything new (weave-in log: now \u002F queued \u002F declined,\n   with reasons) — and the instant you queue an incoming item, goalify it inline\n   and write its `BATCH_DIR\u002Fgoals\u002F` file (clearing L7, rule 14) so a later\n   refill stays a bare launch. Re-prioritize, handle STALLED, ENDED-NO-DONE and\n   NEEDS-MANAGER lanes (inspect the lane log tail; relaunch or reassign). A\n   **NEEDS-MANAGER** lane stopped itself because its `\u002Fgoal` evaluator\n   repeated one message verbatim for 6 turns — the loop had stopped producing\n   new information. Read the quoted message: it names the wedge. Usually the\n   goal's terminal verb is unreachable (rule 14) and the fix is a corrected\n   goal file plus a relaunch, never a bare restart of the same condition.\n7. Update the **todo lane board** and rewrite `HIGHWAY.md`. Regenerate its\n   Landed section from git ground truth — `scripts\u002Flanded_from_git.sh \u003Crepo>\n   [base]` — so the Operating Picture can never drift from what actually merged\n   (proof-run 01: it read \"Landed: none\" while 10 lanes had merged). After a\n   bounded `wake-needed` snapshot is processed, record its last processed line\n   in `HIGHWAY.md`. The watchdog never consumes this append-only file; never\n   truncate or unlink it while the watchdog runs. Archive it at close, after the\n   watchdog has stopped.\n8. Continue. The first time you reach this step, `load_skill(\"monitor\")` for\n   the polling discipline. Then delegate the watch — `delegate(agent=\"self\",\n   context_depth=\"none\", model_role=\"fast\")` — with an instruction that\n   includes ALL of:\n   - the exact loop: sleep `\u003Cinterval>`, then ONE\n     `highway_status.sh \u003CBATCH_DIR> \u003CWIDTH> \u003CRUNNABLE>` call, repeat up to N times;\n   - **SEQUENTIAL-ONLY — never issue checks in parallel** (a batched watcher\n     once issued 15 simultaneous checks sampling the same instant and\n     reported success);\n   - return the moment any lane ENDs, `DEFICIT>0`, or a flag appears, reporting\n     **observations only, no verdicts**;\n   - the return message leads with a state token (`DONE:` \u002F `NEEDS YOU:` \u002F\n     `GAVE UP:`) in its first 100 characters;\n   - sanity check: elapsed wall time must be ≈ interval × checks —\n     suspiciously cheap means the loop lied.\n   Or, if the user needs to hear something, go to Phase 6.\n\n**Success criteria**: every cycle leaves status output in the transcript,\nDEFICIT=0 (or justified), board + `HIGHWAY.md` current, heartbeat fresh.\n\n### The todo lane board (user-facing visibility)\n\nThe todo tool is the live dashboard the user watches. Maintain: one item per\nlane — `Lane \u003Cn> [\u003Crepo>]: \u003Cwork item>` — `in_progress` while running,\n`completed` at merge; plus one `Highway \u003Cbatch>: cycle \u003Ck> — \u003Cone-line state>`\nitem. Update it in step 7 of every cycle, not sporadically. The todo board,\nthe `HIGHWAY.md` lane board, and the manifest must agree at the end of every\ncycle.\n\n## Phase 6 — Talking to the human without freezing the highway\n\nThe documented failure: the manager reported status and the highway froze\nuntil morning. The watchdog preserves observations for the next manager cycle;\nit cannot keep a paused session from remaining paused. Before ANY turn-ending\nmessage while lanes run:\n\n1. `highway_status.sh` must show `watchdog=LIVE` — if DEAD, start it (Phase 4\n   command; the session ID is in `\u003CBATCH_DIR>\u002F.session-id`) and re-check.\n   **Never end a turn with the watchdog dead while lanes are live.**\n2. The todo lane board is current.\n3. The message leads with a state token in the first 100 characters —\n   `DONE:` \u002F `NEEDS YOU:` \u002F `PAUSED:` \u002F or a one-line highway status — because\n   the notification renders from those characters.\n\nThe watchdog records `wake-needed` advisories for lane-end, fresh runnable work\nunder width, or stale heartbeat with live lanes. It does not wake or re-enter\nthis session, and automatic delivery is outside this MVP; when the manager runs\nanother cycle and observes an advisory, run Phase 5.\n\n## Phase 7 — Close the highway\n\nClose **per the engagement's captured completion intent (Phase 1) — never\nreflexively at the first \"outcome looks green.\"** If a deadline or expected new\nwork is still live and the intent is *achieve-then-hold* or *run-to-deadline*,\ndo NOT tear down capacity: keep the watchdog alive and keep polling for new\nwork; put spare lanes on the next-most-valuable backlog items (harden the\noutcome, absorb injected bugs\u002Frequirements) — or, if the intent says so,\nsurface to the user (Phase 6) and ask whether to continue. Tearing down the\nwatchdog and lanes the moment current acceptance passes is the documented\n\"coasts once it thinks it's done\" failure (strategist trial 01: it closed 10\nmin before the deadline and missed four injected items). **Enter the teardown\nbelow ONLY when the captured intent's end condition is actually met** — the\ndeadline reached, the user's release given, or (for *achieve-and-close*) the\noutcome verified with nothing pending; for *run-to-PR*, the requested PRs\nverified and handed to their authorized repository owner.\n\nWhen you close: final Phase 5 pass; the authorized repository owner or batch\nauthority merges, retains a verified PR when the captured intent allows, or\nhonestly dispositions every open lane; then **run `infra_ledger.sh BATCH_DIR\nsweep --all-owners` and do not treat the highway as closed until it exits\nclean** — it tears\ndown every DTU, gitea instance, container, service, and background process the\nrun ledgered, whether a lane or the manager stood it up (Rule 14). `--all-owners`\nis the manager's batch-close override; without it `sweep` refuses (exit 3) the\nmoment the open rows span more than one lane, which is the guard that stops a\nlane from destroying its neighbours' infrastructure. Kill the\nwatchdog by the exact name `highway_status.sh` reports\n(`tmux -L \"$HIGHWAY_TMUX_SOCKET\" kill-session -t \"=\u003Cwd_name>\"`). **Archive\nthe per-lane evidence BEFORE pruning** — pruning the lane dirs otherwise deletes\n`lane.log` and the markers with them:\n```bash\nmkdir -p \u003CBATCH_DIR>\u002Flogs\nfor d in \u003CBATCH_DIR>\u002Flanes\u002F*\u002F; do L=$(basename \"$d\"); \\\n  cp \"$d\u002Flane.log\" \"\u003CBATCH_DIR>\u002Flogs\u002F$L.log\" 2>\u002Fdev\u002Fnull; \\\n  cp \"$d\u002FDONE.json\" \"\u003CBATCH_DIR>\u002Flogs\u002F$L.DONE.json\" 2>\u002Fdev\u002Fnull; done\n```\nThen prune worktrees and branches; do a final `HIGHWAY.md` rewrite (outcome\nstatus, landed list from `landed_from_git.sh`, residuals with named reasons);\nreport with `DONE:` or `GAVE UP:` leading.\n\n**Success criteria**: no `hw__` tmux sessions, no stray worktrees\u002Fbranches,\n`infra_ledger.sh BATCH_DIR sweep --all-owners` exits clean (nothing ledgered\nstill standing), final report matches git facts.\n\n## Rules — each bought with a documented failure\n\n1. **The deficit is computed, not noticed.** Run the instrument first on every\n   wake; trust its number over your impression. (A real run sat at 1 lane —\n   \"we want to keep all 10 going\" — because fullness was prose.)\n2. **Refill before anything else when DEFICIT>0.** (Nine lanes done, one\n   straggler, two hours of idle capacity — the trail-off that named this\n   pattern.)\n3. **Never end a turn with the watchdog dead while lanes run.** (An overnight\n   status report froze the whole highway until morning.)\n4. **Watchers report observations; only your own artifact check promotes to\n   proven.** (A monitor fabricated a PASS verdict from a log fragment.)\n5. **Completion is git facts, never self-report.** Prove a merge with the merged\n   lane's OWN tests immediately; run the FULL suite on a cadence and at close —\n   NOT serialized after every single merge (that idles width; see the Phase 5\n   invariant). (Two lanes reported green honestly from a suite run that predated\n   their own last file — so verify per-lane at merge AND full-sweep before DONE.)\n6. **One instrument call per poll; delegated watchers are SEQUENTIAL-ONLY.**\n   (A child once issued 15 simultaneous checks sampling the same instant and\n   reported success.)\n7. **The approval gate is not skippable.** No launch without an explicit go.\n8. **goalify runs inline, never delegated** — it must read the live transcript.\n9. **Nothing silent in the strategy.** Every accept\u002Fdefer\u002Fdecline of incoming\n   work lands in the weave-in log. (The vision living only \"implicitly in the\n   conversation\" is the documented weakness this file exists to fix.)\n10. **The script owns the manifest. Never hand-write it.**\n11. **Speculative lanes only after the critical path is saturated, and label\n    them.** Spare capacity is an investment budget, not a reason to pad.\n12. **Lanes never merge to main; only the authorized repository owner or batch\n    authority merges.** One repo per lane; live shared services are read-only\n    to lanes. A watchdog advisory is not merge consent.\n13. **If `$ARGUMENTS` is empty, ask** — do not invent an outcome. (The fork\n    sibling of this failure killed a real goal-batch invocation silently.)\n14. **Infrastructure is ledgered at creation and swept at close — nothing the\n    highway stands up outlives it.** Any DTU, gitea instance, container,\n    service, or background process a lane OR the manager stands up is recorded\n    with `infra_ledger.sh BATCH_DIR add ...` at creation, and Phase 7 does not\n    close until `infra_ledger.sh BATCH_DIR sweep --all-owners` exits clean.\n    (A run closed leaving a DTU and a gitea container running.) **`sweep` is\n    the manager's verb; a lane tears down only its own rows via the batch's\n    lane-scoped teardown tool.** (One foreign `sweep` destroyed two other\n    lanes' DTUs mid-measurement; `sweep` now refuses a multi-owner ledger with\n    exit 3 unless `--all-owners` is passed.)\n15. **A lane goal on a shared work item must name `work_erratum` as its\n    terminal verb for the already-resolved case** (goalify L7). Many lanes on\n    one container item is a normal shape here, and the first lane to resolve\n    it makes `work_resolve`\u002F`work_release` permanently unreachable for every\n    other lane — which is a stop condition that can never be satisfied, not a\n    lane that needs more turns. (`j1e6-ci-tool-web` spent **855 turns \u002F\n    $202.91** and `hd-browser-bridge` **~887 turns \u002F ~$184** repeating one\n    line — \"No verified successful `work_resolve` or `work_release` appears in\n    the available transcript\" — hours after both lanes' PRs had already\n    merged. At least 3 earlier lanes hit the same wall and each rediscovered\n    `work_erratum` alone.)\n\n## Known limits (still not built)\n\n(Width pin, escalation, and the infra ledger are now implemented above.)\n\n- A hook that injects `highway_status.sh` output into every turn (the way the\n  todo reminder does) would make drift structurally impossible to ignore —\n  requires bundle work.\n- An atomic CLI session-idleness handoff is not implemented. Until that exists,\n  the watchdog deliberately records durable advisories only.\n- Deeper work-tracker integration (auto-READY counts) would remove the one\n  hand-carried number in the status call.\n","# Ten-Lane Highway\n\nRun continuous parallel agent lanes toward a defined outcome. Success is not\n\"lanes ran\": it is the outcome reached (or honestly blocked with named\nreasons), every landed lane merged, retained as a verified PR, or honestly\ndispositioned by its authorized owner under the captured completion intent, the\nOperating Picture current, and the scaffolding torn down.\n\nThe predecessor pattern (goal-batch) launches a set and drains it. The highway\nreplaces batching with **continuous scheduling**: \"I have N units of execution\ncapacity. Never wait for a batch. Continuously decide what the best available\nuse of each unit is.\" You are doing agent capacity management — closer to OS\nscheduling than to a task list.\n\n## First run (~15 minutes)\n\nNew to the highway? Do a throwaway run first — a scratch repo you can break,\n**width 2**. Invoke `\u002Fhighway` with a small outcome + that repo + \"width 2\";\napprove at the Phase 3 gate (nothing launches before you say go); then watch\n**gate → 2 lanes → watchdog → authorized landings**, refilling until the queue drains. Stop\neverything through the batch's explicit `HIGHWAY_TMUX_SOCKET` (default\n`hw-\u003Csanitized-batch>`), then delete `BATCH_DIR`. Full command sequence and\nexpected output: `examples\u002Ffirst-run.md`.\n\n## You are the Highway Manager — a strategist, not an intake clerk\n\nYou take the user's **outcome\u002Fgoal**, their **constraints** (time, authority,\nresources), the **current state**, and the set of **possible work**, and you\ndrive the whole operation in proxy for the user:\n\n- **Select** work to best achieve the outcome within the constraints — you do\n  not simply execute everything that arrives, and you do not FIFO the queue.\n- **Adjust continuously** on your own: re-prioritize as lanes land, as\n  discoveries surface, as the deadline nears.\n- **Weave in new incoming** (user feedback, lane discoveries, external events)\n  by explicit decision: do it now \u002F queue it at a priority \u002F decline it — each\n  with a reason, recorded. Nothing enters or leaves the plan silently.\n- **Keep the context straight across lanes**: the Operating Picture\n  (`HIGHWAY.md`) is your externalized brain — outcome, constraints, lane board,\n  priority rationale, weave-in log. Rewrite it every cycle.\n- **Autonomy boundary**: you decide scheduling, priority, lane composition,\n  and merge order alone. You escalate only outcome\u002Fconstraint changes,\n  irreversible external actions (publishing, deleting, spending), and genuine\n  blockers.\n\nYou do not do the lanes' work. If you catch yourself editing a lane's code\nmid-flight, stop — fix the goal file or relaunch instead.\n\n## Inputs\n\n- `$ARGUMENTS`: the outcome to drive, constraints\u002Fdeadline, and where the work\n  lives (repos, tracker project, backlog). If empty, ask for the outcome — this\n  skill is inline, so asking is cheap. Do not invent one.\n\n## Instruments (companion scripts — the mechanisms)\n\nResolve paths via the `skill_directory` returned by `load_skill`; call them as\n`\u003Cskill_directory>\u002Fscripts\u002F\u003Cname>.sh`. **Never copy a script into a target\nrepo** (a real run left `.amplifier\u002Fbin\u002F` behind as untracked pollution).\n\n| Script | Job | Rule it mechanizes |\n|---|---|---|\n| `highway_readiness.sh publish BATCH_DIR RUNNABLE` | Atomically publishes the manager's current batch-runnable count | The watchdog must not mistake unused capacity for work to invent |\n| `highway_status.sh BATCH_DIR WIDTH [RUNNABLE]` | ONE call reports every lane + watchdog liveness and **computes DEFICIT by code** from shared readiness | \"Keep lanes full\" stopped being prose the day a run sat at 1 lane with work for 10 |\n| `launch_lane.sh BATCH_DIR LANE REPO GOAL [BASE_REF]` | Worktree + branch + tmux + `\u002Fgoal` session, idempotent; the ONLY writer of `manifest.tsv` | Hand-written manifests diverged on column count and broke a real batch |\n| `verify_lane.sh BATCH_DIR LANE` | Git-facts probe for one landed lane (DONE.json, ahead-count, three-dot diffstat, uncommitted work) | \"Ground truth from git and the filesystem, not from what any session said about itself\" |\n| `highway_watchdog.sh BATCH_DIR WIDTH SESSION_ID [INTERVAL] [MAX_HOURS]` | Detached tmux loop that appends rate-limited `wake-needed` advisories for lane-end \u002F under-width \u002F stale heartbeat; `SESSION_ID` remains a required compatibility record | The highway once froze overnight because the manager stopped monitoring the moment it reported status |\n| `infra_ledger.sh BATCH_DIR add TYPE ID DESTROY_CMD...` \u002F `infra_ledger.sh BATCH_DIR sweep --all-owners` | Records any infrastructure a lane OR the manager stands up (DTU, gitea instance, container, service, background process) into `infra.tsv` at creation, each with its teardown command; `sweep` runs those commands and exits non-zero until nothing is left standing | A run closed with a DTU and a gitea container still live — nothing the highway stands up should outlive it (Rule 14) |\n| `lane_teardown.sh BATCH_DIR LANE claim ID...` \u002F `lane_teardown.sh BATCH_DIR LANE teardown\\|reconcile\\|list\\|audit` | **A LANE's** teardown: destroys only the rows that lane claimed, verifies each container is actually gone before flipping its row, and never runs another lane's destroy command. Dry-run by default; `--yes` to act | The emergency recovery path used to live in another repo, untracked — the skill named a tool it did not ship, and an operator mid-incident followed that path to nothing |\n\n**`sweep` is the MANAGER's batch-close verb, never a lane's.** It runs EVERY\nopen row's destroy command, so one lane calling it destroys every other lane's\nlive infrastructure — that is not hypothetical: on 2026-09-02 a single foreign\n`sweep` took lane l1's three DTUs and lane 161's three, 35 minutes into their\nmeasurements. The script now **refuses with exit 3, having run nothing**, when\nthe open rows span more than one owner or any row is unattributable, so:\n\n- **A lane tearing down its OWN rows uses the lane-scoped teardown tool that\n  ships with this skill** —\n  `\u003Cskill_directory>\u002Fscripts\u002Flane_teardown.sh BATCH_DIR \u003Clane> teardown --yes`;\n  omit `--yes` for a dry run — which touches only the rows that lane claimed. A\n  lane never calls `sweep`. A lane name that ALMOST matches the claimed owner\n  **exits 4 naming the candidate owners and their open-row counts**, rather than\n  reporting success for a teardown that would do nothing: on 2026-09-05\n  `lane_teardown.sh \u003Cbatch> drbf teardown --yes` printed *\"lane 'drbf' owns no\n  open rows — nothing to do\"* and exited 0 while six rows were open under\n  `drbf-compaction-notice-ab`.\n- **The manager closing the batch passes `--all-owners`** — the deliberate\n  batch-close override. Every close instruction below says\n  `sweep --all-owners` for exactly this reason: a guard that deadlocks the\n  documented close is a regression, not a fix.\n\nA destroy command for infrastructure that is **already gone** closes its row as\n`swept:already-absent` — distinct from `swept`, because the sweep did not\nperform that teardown. A REAL teardown failure still exits non-zero and leaves\nthe row open; the already-gone signature is deliberately narrow, so the signal\nthat a teardown genuinely failed is never lost.\n\n**`highway_status.sh` reports `orphan_rows=N owned by: \u003Clane>(n)`** — open\nledger rows whose owning lane is **not live**. On 2026-09-05 a tmux server\nrestart killed three lanes at once and left six DTU containers RUNNING with\nopen rows; the ledger recorded all six correctly and the status report showed\nthe lanes ENDED, but **nothing joined the two**, so the manager found the\ncontainers only by running `incus list` by hand. A non-zero `orphan_rows` means\ninfrastructure with nothing driving it (Rule 14) — reclaim each named lane with\n`\u003Cskill_directory>\u002Fscripts\u002Flane_teardown.sh BATCH_DIR \u003Clane> teardown --yes`\n(the report prints that path resolved, ready to paste). The report **destroys\nnothing**: a false positive that prints is a nuisance, a false positive that\ndestroys is another 0rg. A **live** lane's rows are never counted. Owners are\nmatched by exact lane name, else by a unique lane-name prefix (so a row claimed\nwith the short work-item id `vbs` still resolves to lane `vbs-…`); an owner\nthat matches no lane, matches ambiguously, or is unclaimed is reported as such\nrather than guessed at.\n\nUse one workspace-contained `BATCH_DIR` per highway, following the caller's\nworkspace conventions. The caller defines where `BATCH_DIR` lives, not this skill.\nEstablish that path before creating batch state or launching lanes. Keep any\n`HIGHWAY_LANES_ROOT` override within the same workspace.\n\nState lives in `BATCH_DIR`:\n`manifest.tsv` (scripts write), `HIGHWAY.md` (you write), `goals\u002F` (pre-composed\ngoal files), `lanes\u002F` (worktrees), `.width` (authoritative width), `infra.tsv`\n(the infra ledger), `infra.owners.tsv` (which lane claimed which row),\n`.manager-heartbeat`, `.runnable-work` (an atomic batch-runnable snapshot),\n`wake-needed` (append-only watchdog advisories retained while the watchdog\nruns), `watchdog.log`.\n\n## Phase 1 — Intake\n\nEstablish with the user (from `$ARGUMENTS` plus at most one round of\nquestions): the **outcome** in checkable terms, **constraints** (deadline,\nauthority boundary, protected repos\u002Fpaths), **width** (target lane count —\ndefault 10; ceiling is always ready work), **where work comes from**\n(work-tracker project, backlog file, or decompose-from-outcome), and the\n**completion intent** — how the user wants THIS engagement to end and how to\ntreat new work while it runs. This is the user's call to make; capture it, do\nnot impose one. Common shapes (not an exhaustive list — honor what they\nactually asked):\n- *Achieve-then-hold:* reach the outcome, then stop building — but stay open to\n  adjustments\u002Fnew work they send before the deadline, or surface and ask\n  whether to take more on.\n- *Run-to-deadline:* use the whole budget — get the outcome solid first, then\n  keep going, smartly choosing the most valuable beyond-minimum work from the\n  backlog until time is up.\n- *Achieve-and-close:* no live clock; when the outcome is verified and nothing\n  is pending, close.\n- *Run-to-PR:* prepare and verify the requested PRs, then hand them to their\n  authorized repository owner; do not merge without separate authority.\nRecord the captured intent in `HIGHWAY.md` as the engagement's completion\npolicy, and honor it with judgment at close (Phase 7).\n\nCreate `BATCH_DIR` and write the first `HIGHWAY.md` from\n`examples\u002Foperating-picture.md`.\n\n**Success criteria**: `HIGHWAY.md` exists with outcome, constraints, width,\nwork source, AND completion intent filled in — not placeholders.\n\n## Phase 2 — Strategize\n\nDecompose toward the outcome into independent, lane-sized items (in the\nwork-tracker when available — claim\u002Fheartbeat semantics are built for this).\nCollision-check like goal-batch Phase 1: two items wanting the same files\neither fold into one lane or get sole ownership. Order by dependency AND\nstrategic value toward the outcome — not arrival order. Mark\ninvestment\u002Fspeculative candidates (recon, spikes, de-risking) to backfill idle\ncapacity later.\n\n**Pre-compose the whole queue now.** `load_skill(\"goalify\")` **inline — never\ndelegated** (goalify reads the live transcript; a sub-agent cannot) and write a\ngoal file per queued item up front into `BATCH_DIR\u002Fgoals\u002F\u003Citem>.md`, each with a\ndisjunctive exit and per-item residuals. This makes every later refill a bare\n`launch_lane.sh` call, never compose-then-launch (idle capacity is the enemy —\nPhase 5 invariant); an item arriving at weave-in gets its goal file composed\nwhen it enters the queue, not at refill. Each goal file MUST instruct its lane to\nregister any infrastructure it stands up — DTU, gitea instance, container,\nservice, background process — with `infra_ledger.sh \u003CBATCH_DIR> add \u003Ctype> \u003Cid>\n\u003Cdestroy-cmd…>` at creation (Rule 14), and to tear down **only its own rows**\nvia the batch's lane-scoped teardown tool. A goal file must never tell a lane to\nrun `sweep`: that is the manager's batch-close verb and it destroys every other\nlane's live infrastructure.\n\n**Success criteria**: a priority queue in `HIGHWAY.md` with a one-line\nrationale per item tied to the outcome\u002Fconstraints, and a pre-composed goal file\nin `BATCH_DIR\u002Fgoals\u002F` for every item in it.\n\n## Phase 3 — Approval gate `[human]`\n\n**Human checkpoint — the one mandatory stop. Nothing launches before the user\nsays go.** Show on one screen: outcome, width, the first wave of lanes\n(lane → repo → item), the priority rationale, and watch cadence. Accept\nconversational approval (\"go\", \"go, only ping me if it breaks\"). Never infer\napproval from enthusiasm or silence.\n\n**Success criteria**: an explicit affirmative from the user.\n\n## Phase 4 — Saturate\n\nFor each lane in the first wave, launch from the goal file Phase 2 already\npre-composed in `BATCH_DIR\u002Fgoals\u002F` — no goalify here:\n\n- `launch_lane.sh BATCH_DIR \u003Clane> \u003Crepo> BATCH_DIR\u002Fgoals\u002F\u003Citem>.md [base]`.\n- **Every pre-composed goal file whose item lives in a work-tracker project\n  must clear goalify's L7 at composition time (Phase 2)**: the goal names\n  `work_erratum` as the terminal verb for the case where the item is already\n  resolved or held by another session. `work_resolve` and `work_release` both\n  refuse a session that never held the item, so a lane that ends only in\n  those verbs has no reachable terminal state the moment a sibling resolves\n  the item (rule 14).\n\nThen start the watchdog. **`\u003CBATCH_DIR>`, `\u003CWIDTH>`, `\u003CSESSION_ID>` below are\ndocumentation placeholders — substitute literal values; they do not exist as\nshell variables.** Your session ID is shown in your environment context\n(`Session ID: ...`). Persist it to disk FIRST because the compatibility\nwatchdog interface still requires it, although the watchdog records it only\nand never re-enters that session:\n\n```bash\nprintf '%s\\n' \"\u003CSESSION_ID>\" > \u003CBATCH_DIR>\u002F.session-id\nprintf '%s\\n' \"\u003CWIDTH>\" > \u003CBATCH_DIR>\u002F.width   # authoritative width — the single\n                                               # source of truth the scripts read\n# Publish the manager's verified batch-runnable count before the watchdog can\n# decide whether unused capacity needs attention. This is not raw tracker-ready:\n# exclude conflicts, dependencies, and work without a pre-composed goal.\n\u003Cskill_directory>\u002Fscripts\u002Fhighway_readiness.sh publish \u003CBATCH_DIR> \u003CRUNNABLE>\ntouch \u003CBATCH_DIR>\u002F.manager-heartbeat   # BEFORE the watchdog starts, to provide\n                                        # initial timing context for its log\nBATCH=$(printf '%s' \"$(basename \u003CBATCH_DIR>)\" | tr -c 'A-Za-z0-9_-' '_')   # same sanitization the scripts use\nHIGHWAY_TMUX_SOCKET=\"${HIGHWAY_TMUX_SOCKET:-hw-${BATCH}}\"\nexport HIGHWAY_TMUX_SOCKET\ntmux -L \"$HIGHWAY_TMUX_SOCKET\" new-session -d -s \"hw-watchdog__${BATCH}\" \\\n  \"\u003Cskill_directory>\u002Fscripts\u002Fhighway_watchdog.sh \u003CBATCH_DIR> \u003CWIDTH> \u003CSESSION_ID> 300 12 2>&1 | tee -a \u003CBATCH_DIR>\u002Fwatchdog.log\"\n```\nThen touch `\u003CBATCH_DIR>\u002F.manager-heartbeat` again at the start of every Phase 5\ncycle (step 1) and after each merge. It is advisory timing context only: a\nheartbeat cannot prove that a manager is idle or busy, and does not suppress a\n`wake-needed` record.\n\n**Width, readiness, the tmux socket, and escalation.** `\u003CBATCH_DIR>\u002F.width` is the single\nsource of truth for the target lane count (the scripts read it there); changing\nwidth mid-run is an explicit act — **edit `\u003CBATCH_DIR>\u002F.width` AND log it in the\nweave-in log**, nothing else moves width. Every highway tmux command runs on the\nper-batch socket `HIGHWAY_TMUX_SOCKET` (default `hw-\u003Csanitized-batch>`) — hence\nthe explicit `-L \"$HIGHWAY_TMUX_SOCKET\"` above and on the Phase 7 kill. The\nmanager publishes its current batch-runnable count through `highway_readiness.sh`;\n`drained` means zero fresh runnable work, while `unknown` or `stale` readiness is\nnever a zero and must be investigated. An `escalation-needed` marker or\n`ESCALATIONDEFERRED` log entry means investigate the persistent deficit; it is\nan advisory, not consent to merge or an automatic session re-entry.\n\nVerify launch: run `highway_status.sh` once — every lane LIVE past its first\nLLM call (log growing), watchdog LIVE. Then build the **todo lane board** (see\nbelow).\n\n**Success criteria**: status output pasted in the transcript showing all\nlaunched lanes LIVE, watchdog LIVE, DEFICIT=0.\n\n## Phase 5 — Steady-state cycle (the loop)\n\nRun this whenever control returns — a delegated watcher returning, a watchdog\nadvisory found in `wake-needed`, or a user message while lanes run. The watchdog\ndoes not re-enter the session or promise a notification.\n\n**The invariant: while backlog exists, live lanes == width, continuously.** A\ndrained lane is refilled the INSTANT it drains — one lane ending is one refill,\nNOT a signal to wait for the whole wave to land. Merging, verifying, reporting,\nand re-strategizing all YIELD to keeping width full. (Graded battery: the\nmanager wave-batched — drain 5 → merge+re-test all 5 → then refill — idling\ncapacity 135–286s while 15–20 items waited. That is the exact failure this\ninvariant exists to prevent.)\n\n1. `touch $BATCH_DIR\u002F.manager-heartbeat`.\n2. Get RUNNABLE (the batch's ready, dependency-clear, non-conflicting items with\n   pre-composed goals) from the work queue and current lane board.\n3. **Run `highway_status.sh BATCH_DIR WIDTH RUNNABLE` and paste its output.**\n   This atomically refreshes `.runnable-work`; use\n   `highway_readiness.sh publish BATCH_DIR RUNNABLE` when publishing without a\n   status report.\n4. **If `DEFICIT>0`: refill FIRST** — before merging, before reporting, before\n   anything. Pick the top-priority ready items (strategist's choice) and\n   `launch_lane.sh` each from its pre-composed `BATCH_DIR\u002Fgoals\u002F` file — refill\n   is a bare launch, never a compose-then-launch. Under-width with ready work is\n   allowed only with an explicit one-line justification in the transcript that\n   cycle.\n5. **Width first, then resolve landed lanes — never the reverse.** Step 4 (restore width)\n   always precedes this. For each ENDED lane: `verify_lane.sh`, then YOUR own\n   artifact check, then the authorized repository owner or batch authority may\n   `merge --no-ff` from the main checkout or retain a verified PR when the\n   captured completion intent allows; otherwise record the disposition and seek\n   that authority. Resolve the item with a user-readable reason, tear down\n   (worktree remove, branch delete, tmux kill). **Do NOT serialize a full-suite rerun after every single merge** —\n   that is what idled capacity for minutes in the battery. Instead: run the\n   merged lane's OWN tests immediately (fast proof it landed), and run the FULL\n   suite on a cadence and at close (a periodic + final full sweep catches\n   cross-lane interaction without blocking refill). **If any lane drains during\n   the merge pass, jump back to step 4 and refill BEFORE continuing to merge.**\n   Repair small defects in place or file the honest negative — never let one\n   straggler block the others.\n6. Strategize: process anything new (weave-in log: now \u002F queued \u002F declined,\n   with reasons) — and the instant you queue an incoming item, goalify it inline\n   and write its `BATCH_DIR\u002Fgoals\u002F` file (clearing L7, rule 14) so a later\n   refill stays a bare launch. Re-prioritize, handle STALLED, ENDED-NO-DONE and\n   NEEDS-MANAGER lanes (inspect the lane log tail; relaunch or reassign). A\n   **NEEDS-MANAGER** lane stopped itself because its `\u002Fgoal` evaluator\n   repeated one message verbatim for 6 turns — the loop had stopped producing\n   new information. Read the quoted message: it names the wedge. Usually the\n   goal's terminal verb is unreachable (rule 14) and the fix is a corrected\n   goal file plus a relaunch, never a bare restart of the same condition.\n7. Update the **todo lane board** and rewrite `HIGHWAY.md`. Regenerate its\n   Landed section from git ground truth — `scripts\u002Flanded_from_git.sh \u003Crepo>\n   [base]` — so the Operating Picture can never drift from what actually merged\n   (proof-run 01: it read \"Landed: none\" while 10 lanes had merged). After a\n   bounded `wake-needed` snapshot is processed, record its last processed line\n   in `HIGHWAY.md`. The watchdog never consumes this append-only file; never\n   truncate or unlink it while the watchdog runs. Archive it at close, after the\n   watchdog has stopped.\n8. Continue. The first time you reach this step, `load_skill(\"monitor\")` for\n   the polling discipline. Then delegate the watch — `delegate(agent=\"self\",\n   context_depth=\"none\", model_role=\"fast\")` — with an instruction that\n   includes ALL of:\n   - the exact loop: sleep `\u003Cinterval>`, then ONE\n     `highway_status.sh \u003CBATCH_DIR> \u003CWIDTH> \u003CRUNNABLE>` call, repeat up to N times;\n   - **SEQUENTIAL-ONLY — never issue checks in parallel** (a batched watcher\n     once issued 15 simultaneous checks sampling the same instant and\n     reported success);\n   - return the moment any lane ENDs, `DEFICIT>0`, or a flag appears, reporting\n     **observations only, no verdicts**;\n   - the return message leads with a state token (`DONE:` \u002F `NEEDS YOU:` \u002F\n     `GAVE UP:`) in its first 100 characters;\n   - sanity check: elapsed wall time must be ≈ interval × checks —\n     suspiciously cheap means the loop lied.\n   Or, if the user needs to hear something, go to Phase 6.\n\n**Success criteria**: every cycle leaves status output in the transcript,\nDEFICIT=0 (or justified), board + `HIGHWAY.md` current, heartbeat fresh.\n\n### The todo lane board (user-facing visibility)\n\nThe todo tool is the live dashboard the user watches. Maintain: one item per\nlane — `Lane \u003Cn> [\u003Crepo>]: \u003Cwork item>` — `in_progress` while running,\n`completed` at merge; plus one `Highway \u003Cbatch>: cycle \u003Ck> — \u003Cone-line state>`\nitem. Update it in step 7 of every cycle, not sporadically. The todo board,\nthe `HIGHWAY.md` lane board, and the manifest must agree at the end of every\ncycle.\n\n## Phase 6 — Talking to the human without freezing the highway\n\nThe documented failure: the manager reported status and the highway froze\nuntil morning. The watchdog preserves observations for the next manager cycle;\nit cannot keep a paused session from remaining paused. Before ANY turn-ending\nmessage while lanes run:\n\n1. `highway_status.sh` must show `watchdog=LIVE` — if DEAD, start it (Phase 4\n   command; the session ID is in `\u003CBATCH_DIR>\u002F.session-id`) and re-check.\n   **Never end a turn with the watchdog dead while lanes are live.**\n2. The todo lane board is current.\n3. The message leads with a state token in the first 100 characters —\n   `DONE:` \u002F `NEEDS YOU:` \u002F `PAUSED:` \u002F or a one-line highway status — because\n   the notification renders from those characters.\n\nThe watchdog records `wake-needed` advisories for lane-end, fresh runnable work\nunder width, or stale heartbeat with live lanes. It does not wake or re-enter\nthis session, and automatic delivery is outside this MVP; when the manager runs\nanother cycle and observes an advisory, run Phase 5.\n\n## Phase 7 — Close the highway\n\nClose **per the engagement's captured completion intent (Phase 1) — never\nreflexively at the first \"outcome looks green.\"** If a deadline or expected new\nwork is still live and the intent is *achieve-then-hold* or *run-to-deadline*,\ndo NOT tear down capacity: keep the watchdog alive and keep polling for new\nwork; put spare lanes on the next-most-valuable backlog items (harden the\noutcome, absorb injected bugs\u002Frequirements) — or, if the intent says so,\nsurface to the user (Phase 6) and ask whether to continue. Tearing down the\nwatchdog and lanes the moment current acceptance passes is the documented\n\"coasts once it thinks it's done\" failure (strategist trial 01: it closed 10\nmin before the deadline and missed four injected items). **Enter the teardown\nbelow ONLY when the captured intent's end condition is actually met** — the\ndeadline reached, the user's release given, or (for *achieve-and-close*) the\noutcome verified with nothing pending; for *run-to-PR*, the requested PRs\nverified and handed to their authorized repository owner.\n\nWhen you close: final Phase 5 pass; the authorized repository owner or batch\nauthority merges, retains a verified PR when the captured intent allows, or\nhonestly dispositions every open lane; then **run `infra_ledger.sh BATCH_DIR\nsweep --all-owners` and do not treat the highway as closed until it exits\nclean** — it tears\ndown every DTU, gitea instance, container, service, and background process the\nrun ledgered, whether a lane or the manager stood it up (Rule 14). `--all-owners`\nis the manager's batch-close override; without it `sweep` refuses (exit 3) the\nmoment the open rows span more than one lane, which is the guard that stops a\nlane from destroying its neighbours' infrastructure. Kill the\nwatchdog by the exact name `highway_status.sh` reports\n(`tmux -L \"$HIGHWAY_TMUX_SOCKET\" kill-session -t \"=\u003Cwd_name>\"`). **Archive\nthe per-lane evidence BEFORE pruning** — pruning the lane dirs otherwise deletes\n`lane.log` and the markers with them:\n```bash\nmkdir -p \u003CBATCH_DIR>\u002Flogs\nfor d in \u003CBATCH_DIR>\u002Flanes\u002F*\u002F; do L=$(basename \"$d\"); \\\n  cp \"$d\u002Flane.log\" \"\u003CBATCH_DIR>\u002Flogs\u002F$L.log\" 2>\u002Fdev\u002Fnull; \\\n  cp \"$d\u002FDONE.json\" \"\u003CBATCH_DIR>\u002Flogs\u002F$L.DONE.json\" 2>\u002Fdev\u002Fnull; done\n```\nThen prune worktrees and branches; do a final `HIGHWAY.md` rewrite (outcome\nstatus, landed list from `landed_from_git.sh`, residuals with named reasons);\nreport with `DONE:` or `GAVE UP:` leading.\n\n**Success criteria**: no `hw__` tmux sessions, no stray worktrees\u002Fbranches,\n`infra_ledger.sh BATCH_DIR sweep --all-owners` exits clean (nothing ledgered\nstill standing), final report matches git facts.\n\n## Rules — each bought with a documented failure\n\n1. **The deficit is computed, not noticed.** Run the instrument first on every\n   wake; trust its number over your impression. (A real run sat at 1 lane —\n   \"we want to keep all 10 going\" — because fullness was prose.)\n2. **Refill before anything else when DEFICIT>0.** (Nine lanes done, one\n   straggler, two hours of idle capacity — the trail-off that named this\n   pattern.)\n3. **Never end a turn with the watchdog dead while lanes run.** (An overnight\n   status report froze the whole highway until morning.)\n4. **Watchers report observations; only your own artifact check promotes to\n   proven.** (A monitor fabricated a PASS verdict from a log fragment.)\n5. **Completion is git facts, never self-report.** Prove a merge with the merged\n   lane's OWN tests immediately; run the FULL suite on a cadence and at close —\n   NOT serialized after every single merge (that idles width; see the Phase 5\n   invariant). (Two lanes reported green honestly from a suite run that predated\n   their own last file — so verify per-lane at merge AND full-sweep before DONE.)\n6. **One instrument call per poll; delegated watchers are SEQUENTIAL-ONLY.**\n   (A child once issued 15 simultaneous checks sampling the same instant and\n   reported success.)\n7. **The approval gate is not skippable.** No launch without an explicit go.\n8. **goalify runs inline, never delegated** — it must read the live transcript.\n9. **Nothing silent in the strategy.** Every accept\u002Fdefer\u002Fdecline of incoming\n   work lands in the weave-in log. (The vision living only \"implicitly in the\n   conversation\" is the documented weakness this file exists to fix.)\n10. **The script owns the manifest. Never hand-write it.**\n11. **Speculative lanes only after the critical path is saturated, and label\n    them.** Spare capacity is an investment budget, not a reason to pad.\n12. **Lanes never merge to main; only the authorized repository owner or batch\n    authority merges.** One repo per lane; live shared services are read-only\n    to lanes. A watchdog advisory is not merge consent.\n13. **If `$ARGUMENTS` is empty, ask** — do not invent an outcome. (The fork\n    sibling of this failure killed a real goal-batch invocation silently.)\n14. **Infrastructure is ledgered at creation and swept at close — nothing the\n    highway stands up outlives it.** Any DTU, gitea instance, container,\n    service, or background process a lane OR the manager stands up is recorded\n    with `infra_ledger.sh BATCH_DIR add ...` at creation, and Phase 7 does not\n    close until `infra_ledger.sh BATCH_DIR sweep --all-owners` exits clean.\n    (A run closed leaving a DTU and a gitea container running.) **`sweep` is\n    the manager's verb; a lane tears down only its own rows via the batch's\n    lane-scoped teardown tool.** (One foreign `sweep` destroyed two other\n    lanes' DTUs mid-measurement; `sweep` now refuses a multi-owner ledger with\n    exit 3 unless `--all-owners` is passed.)\n15. **A lane goal on a shared work item must name `work_erratum` as its\n    terminal verb for the already-resolved case** (goalify L7). Many lanes on\n    one container item is a normal shape here, and the first lane to resolve\n    it makes `work_resolve`\u002F`work_release` permanently unreachable for every\n    other lane — which is a stop condition that can never be satisfied, not a\n    lane that needs more turns. (`j1e6-ci-tool-web` spent **855 turns \u002F\n    $202.91** and `hd-browser-bridge` **~887 turns \u002F ~$184** repeating one\n    line — \"No verified successful `work_resolve` or `work_release` appears in\n    the available transcript\" — hours after both lanes' PRs had already\n    merged. At least 3 earlier lanes hit the same wall and each rediscovered\n    `work_erratum` alone.)\n\n## Known limits (still not built)\n\n(Width pin, escalation, and the infra ledger are now implemented above.)\n\n- A hook that injects `highway_status.sh` output into every turn (the way the\n  todo reminder does) would make drift structurally impossible to ignore —\n  requires bundle work.\n- An atomic CLI session-idleness handoff is not implemented. Until that exists,\n  the watchdog deliberately records durable advisories only.\n- Deeper work-tracker integration (auto-READY counts) would remove the one\n  hand-carried number in the status call.\n",{"name":5,"version":33,"shortcut":34,"model_role":35,"visibility":36,"description":38,"argument-hint":39,"user-invocable":40},"1.0.0","highway","general",{"summary":37},"Drive many parallel \u002Fgoal lanes continuously toward an outcome — refill on drain, verify by evidence, close per completion intent.","Become the Highway Manager: drive many parallel \u002Fgoal lanes continuously toward a defined outcome, refilling lanes on every manager cycle so none sit idle. Use when the user wants continuous parallel throughput toward an outcome: \"run the highway\", \"\u002Fhighway\", \"10-lane highway\", \"keep N lanes full\", \"keep re-feeding lanes as they drain\", \"drive this for me in parallel\", \"do them all and monitor\", \"keep the lanes full\", \"work the whole list in parallel until done\". NOT for a one-shot batch that launches once and drains together — use goal-batch. NOT for bounded edits that each end in their own PR — use mass-change. Requires git, tmux, the amplifier CLI on PATH, and the goalify and monitor skills.\n","\u003Cthe outcome to drive, constraints\u002Fdeadline, and where the work lives>",true,"main","631c4bdbcf3dcd2da20456ad6ccef386e778c101","amplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway",28,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 01:45:24",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":40},[52,55,58],{"tool":53,"command":54},"npx","npx skills add microsoft\u002Famplifier-app-cli --skill ten-lane-highway",{"tool":56,"command":57},"bunx","bunx skills add microsoft\u002Famplifier-app-cli --skill ten-lane-highway",{"tool":59,"command":60},"pnpm","pnpm dlx skills add microsoft\u002Famplifier-app-cli --skill ten-lane-highway","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002FSKILL.md",[63,69,73,79,83,87,91,95,99,103],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"examples\u002Ffirst-run.md","REFERENCE","参考文档",4371,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002Fexamples\u002Ffirst-run.md",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"examples\u002Foperating-picture.md",2005,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002Fexamples\u002Foperating-picture.md",{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"scripts\u002Fhighway_readiness.sh","SCRIPT","脚本",2369,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002Fscripts\u002Fhighway_readiness.sh",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"scripts\u002Fhighway_status.sh",11652,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002Fscripts\u002Fhighway_status.sh",{"path":84,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":85,"sourceHtmlUrl":86},"scripts\u002Fhighway_watchdog.sh",9180,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002Fscripts\u002Fhighway_watchdog.sh",{"path":88,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":89,"sourceHtmlUrl":90},"scripts\u002Finfra_ledger.sh",7782,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002Fscripts\u002Finfra_ledger.sh",{"path":92,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":93,"sourceHtmlUrl":94},"scripts\u002Flanded_from_git.sh",685,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002Fscripts\u002Flanded_from_git.sh",{"path":96,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":97,"sourceHtmlUrl":98},"scripts\u002Flane_teardown.sh",22994,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002Fscripts\u002Flane_teardown.sh",{"path":100,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":101,"sourceHtmlUrl":102},"scripts\u002Flaunch_lane.sh",5122,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002Fscripts\u002Flaunch_lane.sh",{"path":104,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":105,"sourceHtmlUrl":106},"scripts\u002Fverify_lane.sh",3519,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002Fscripts\u002Fverify_lane.sh",[108,116,126,134],{"skillNo":109,"name":27,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":28},"01M69BJ71F38DR2QASW4HZ8K2Q","Compose and lint a \u002Fgoal stop-condition from the current conversation, catching known termination-failure patterns before showing it to the user. Use when the user wants to turn the current task into a \u002Fgoal loop, asks to \"goalify this\", wants a stop condition for autonomous work, says \"write a goal condition\", \"make this a \u002Fgoal\", \"turn this into a goal\", or asks for help wording a condition for \u002Fgoal.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fgoalify\u002FSKILL.md",[],[27,114,115],"lint","help",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":28},"01M69BJ51WJSADYHSFYAGMNDK3","goal-batch","Batch independent work into isolated \u002Fgoal lanes. Triggers: \"run these in parallel\", \"goal-batch\", \"launch lanes for these\", \"work these N tasks simultaneously\", \"batch these as goals\". Show the plan; require explicit user approval before launch; verify results before landing. Not for bounded per-PR edits (mass-change) or continuous refill-on-drain work (ten-lane-highway).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fgoal-batch\u002FSKILL.md",[],[123,124,22,23,125,25],"goal batch","launch","tasks",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":28},"01M69BJ3GMC0R27M16QKP33XYZ","doctor","Diagnose an Amplifier CLI environment through the CLI doctor agent. USE WHEN a user requests CLI runtime, settings or missing-capability inspection. DO NOT USE for project bugs or other hosts.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fdoctor\u002FSKILL.md",[],[128,20,133],"diagnose",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":28},"01M69BJ1PV3RT2VTC0PVVXJMC1","amplifier-config","Explain, inspect, troubleshoot, and safely modify Amplifier CLI configuration — providers, settings scopes, bundles, routing, skills, and source overrides. Use when someone describes desired Amplifier CLI behavior and needs effective-value provenance, a safe change plan, implementation, or outcome-based verification.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Famplifier-config\u002FSKILL.md",[],[141,142,143,22,20,144,145],"amplifier config","config","routing","troubleshoot","safe"]