[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DVQADV6H03PQMAMT20CFJB":3,"skill-same:01M6DVQADV6H03PQMAMT20CFJB":76},{"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":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":6,"updatedAt":56,"install":57,"resources":69},"01M6DVQADV6H03PQMAMT20CFJB","supervise",null,"Launches `node goal-run.ts` with a plan path in the background and watches it to the end. On a non-zero exit it classifies before repairing — plan at fault, implementation at fault, or unknown — never the reverse. A plan fault is repaired within a closed set (declared paths, max_diff, a mistyped path, prose) with plan-guard.ts proving no gate or dod line moved, then relaunched; an implementation fault discards the tree and relaunches unchanged; anything else stops and wakes the developer. One relaunch per iteration, then stop. Unproven — two prior halts are the whole evidence this classifier has ever seen.","FabienSalles\u002Fclaude-marketplace","FabienSalles","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F937901?v=4","01M6DVJBD31CJKRB382FQFZ5FH","Fabien Salles","01M6DVJBQNY8Q18KJD1ESAD6TX",9,"MIT","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fgoal\u002Fskills\u002Fsupervise\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"implementation","line","dod","end","iteration","exit","max","classifier","gate","run","goal","evidence","never","diff","node","plan","guard","SET","ZeRO","2026-11-10 10:12:30",false,"---\nname: supervise\ndescription: Launches `node goal-run.ts` with a plan path in the background and watches it to the end. On a non-zero exit it classifies before repairing — plan at fault, implementation at fault, or unknown — never the reverse. A plan fault is repaired within a closed set (declared paths, max_diff, a mistyped path, prose) with plan-guard.ts proving no gate or dod line moved, then relaunched; an implementation fault discards the tree and relaunches unchanged; anything else stops and wakes the developer. One relaunch per iteration, then stop. Unproven — two prior halts are the whole evidence this classifier has ever seen.\ndisable-model-invocation: true\n---\n\n## Outside Claude Code\n\nThis skill needs a background shell and an agent tool. Claude Code: background `Bash`, `Agent`.\nCopilot CLI: async `bash` read with `read_bash`, `task` with `goal:goal-session-auditor`.\nCodex CLI: `exec_command` read with `write_stdin`, no agent tool. A host with neither a shell nor an agent tool cannot launch or audit a\nrun: state that reason and STOP before Phase 0 runs.\n\nThe host never sets or unsets `GOAL_RUN_PROVIDER` or `GOAL_RUN_IMPLEMENTER`: `goal-run.ts` is\nlaunched with the developer's provider settings untouched.\n\n## Host\n\n`\u003Croot>` is Claude Code's substituted `${CLAUDE_PLUGIN_ROOT}`. A host that leaves it literal\n(Copilot CLI) reads `\u003Croot>` as two levels above `Base directory for this skill:`.\nA host that injects no base-directory line and reads `SKILL.md` itself (Codex CLI) takes `\u003Croot>` as two levels\nabove that file's directory.\n`$ARGUMENTS` left literal is the text typed after the command (empty when none).\nUse `\u003Croot>` wherever a command below says `${CLAUDE_PLUGIN_ROOT}`.\n\nWhen `\u003Croot>\u002Fsrc\u002Fartifacts.ts` or a shared file this skill names is missing, print\n`cannot locate the goal plugin scripts`, the host, and the install commands, run nothing and write nothing:\n`copilot plugin marketplace add \u003Crepository>` then\n`copilot plugin install goal@fabien-claude-marketplace` under Copilot,\n`codex plugin marketplace add \u003Crepository>` then\n`codex plugin add goal@fabien-claude-marketplace` under Codex,\n`\u002Fplugin install goal@fabien-claude-marketplace` under Claude Code.\n\nThen read `\u003Croot>\u002Fshared\u002Fhost.md`.\n\n# \u002Fgoal:supervise — Watch a run, classify a halt, repair or relaunch once\n\nYou launch `node goal-run.ts` and read what it returns. `goal-run.ts` orders the iterations and\n`goal-gate.ts` decides whether each one passed; nothing here reopens either verdict. Your one job\non a non-zero exit is to say **which** of two very different things happened — the plan's contract\nwas wrong, or the implementation was — because the two halts this command was written after\n(`docs\u002Fopen-questions.md` §8) exited with the same code and the same wall message and needed\nopposite responses. Getting that call wrong is worse than not calling it: it either burns the\nimplementer's real work for nothing, or ships a plan quietly rewritten to stop refusing it.\n\n**This is a hypothesis, not a proven procedure.** The classification rule below was written from\ntwo cases. Read the report at the end as evidence for or against it, not as a verdict on this run.\n\n## Under Codex\n\nClaude stays the implementer: `goal-run.ts` runs `claude` as under any host, and the host never sets or unsets `GOAL_RUN_PROVIDER` or `GOAL_RUN_IMPLEMENTER`.\nThe background shell is `exec_command`, read with `write_stdin`. There is no agent tool.\n\nBefore Phase 1 launches anything, run a network probe and a write probe into `$HOME\u002F.claude`. Each network probe must print a code other than `000`:\n\n```bash\ncurl -s -o \u002Fdev\u002Fnull -w '%{http_code}' --max-time 10 https:\u002F\u002Fapi.github.com\ncurl -s -o \u002Fdev\u002Fnull -w '%{http_code}' --max-time 10 \"${ANTHROPIC_BASE_URL:-https:\u002F\u002Fapi.anthropic.com}\"\nf=\"$HOME\u002F.claude\u002F.goal-write-probe-$$\" && touch \"$f\" && rm -f \"$f\"\n```\n\nWhen one fails, name the failing probe, print `codex -s workspace-write -c sandbox_workspace_write.network_access=true --add-dir \"$HOME\u002F.claude\"`\nand launch nothing.\n\nPhase 7 runs `claude -p --agent goal:goal-session-auditor` from the shell, passing the plan's path and `$(pwd)`.\nA failed audit is reported with its error instead of an audit, and folds no `### Session audit`.\n\nThe supervising row is read from the rollout: sum `token_usage_record.payload.usage` once per `response_id` over the run's window\n(input = `input_tokens` minus `cached_input_tokens`, cache read = `cached_input_tokens`, cache write = `cache_write_input_tokens`,\noutput = `output_tokens`), take `model_context_window` from the `event_msg` `token_count` as the window, and show cost `—`.\n`Total` names which rows its sums cover.\n\n## Project artifact root\n\nBefore resolving the source, run the existing resolver from the installed goal plugin:\n\n```bash\nproject=\"$(git rev-parse --show-toplevel)\"\nnode \"${CLAUDE_PLUGIN_ROOT}\u002Fsrc\u002Fartifacts.ts\" \"$project\"\n```\n\nThen read `\u003Croot>\u002Fshared\u002Fartifact-root.md`.\n\nUse the effective value without asking for a location. If no value is supplied,\nuse the returned default; location selection belongs to `\u002Fgoal:spec`.\n\n## Phase 0 — Resolve the plan\n\nArgument: `$ARGUMENTS`\n\n- A full path ending in `.md` → that is the plan; fail clearly if missing or unreadable.\n- An identifier → resolve it as `\u003Croot>\u002Fshared\u002Fplan-argument.md` words it.\n- Empty → the `\u003Cplans>\u002F*-spec.md` most recently modified, excluding\n  `*-cleanup-spec.md`. Several equally plausible candidates → list them\n  and ASK. None → ask for the full path and wait.\n\nIf the developer confirms there is no existing plan to select, STOP:\n_\"No plan exists. Run `\u002Fgoal:plan` first.\"_\n\n## Phase 1 — Launch in the background\n\n```\nnode ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fgoal-run.ts \u003Cplan>\n```\n\nStart it as a background shell. It writes nothing you need to poll for: `\u003Cruns>\u002F\u003Cwork-id>\u002F\u003Crun-id>\u002F.run.log`\naccumulates the same lines it prints, so the transcript survives you looking away.\n\n## Phase 2 — Wait for it to end\n\nWatch the background shell until it exits, without polling in a tight loop. Read its exit code:\n\n| Exit | Meaning |\n|---|---|\n| `0` | every attempted iteration landed, gate-verified |\n| `1` | halted — the gate refused one iteration |\n| `2` | refused — the run never started (a faulty or unknown `GOAL_RUN_*`, `GOAL_CMD_*` or `GOAL_PROC_*` setting, listed all at once, including the retired `GOAL_RUN_SHUTDOWN_MAX_RETRIES`) |\n| `3` | paused — a clean boundary (the attempt ceiling, listing each attempt with its class; an implementer that committed on its own; an implementer that wrote nothing; a publication refused under `commit+pr`: push, pull request, scanner, fixup commit, or a closed or merged pull request, with the iterations that are local only) |\n\n## The failure report — evidence before diagnosis\n\nEvery non-zero exit is reported in one structured block, in this order:\n\n1. **Command** — the exact command the run executed, verbatim from the log (`make php\u002Fqa`, the\n   `gateN=` line the gate refused…).\n2. **Output** — the failing part of that command's output, verbatim from `\u003Cruns>\u002F\u003Cwork-id>\u002F\u003Crun-id>\u002F.run.log`: the\n   error lines plus enough surrounding context to read them (the failing suites, the assertion\n   diff, the lint error). Trim the green noise, never the failure.\n3. **Reproduce** — the command the developer can run themselves to see the same thing, what it\n   prints when healthy, and what it printed here.\n4. **Diagnosis** — what you conclude from 1–3, with your confidence.\n5. **Next move** — the repair, the relaunch, or the question for the developer.\n\nThe same evidence duty covers silent mutations: after any stage that runs project commands\n(preflight, DoD), check `git status --short` — a QA command that *fixes* instead of failing\n(a mutating cs-fixer, a formatter) leaves a dirty tree nobody reported. Show that diff\nverbatim and say which command produced it; never fold it into a commit without showing it.\n\nNever deliver 4–5 without 1–3: a solution whose problem the developer never saw is advice, not\na report — the failure this section was added after was three refusals reported as \"jest OOM,\nfix Docker\" without one line of jest output shown. And the whole block goes in the **final\nmessage of the turn**: text emitted between tool calls is not reliably displayed, so a report\nprinted mid-turn may never reach the developer at all.\n\n## Phase 3 — `0` or `3`: report, nothing to classify\n\nNeither exit names a fault. `0` → report what landed. `3` → report the boundary the log names\nand that relaunching resumes at the first unchecked box; do not relaunch it yourself, that is\nthe developer's call, not a repair.\n\n## Phase 4 — `2`: nothing was attempted\n\nA refusal exit means the preflight stopped the run before any iteration was handed to an\nimplementer — there is no work to classify and nothing to discard. Build the failure report:\nthe `STOP` line names the command (Command), the log holds its output (Output — for a\nnot-green base, the failing tests\u002Flint lines themselves, not just the summary line). Wake the\ndeveloper with it: the cause (a lock, a dirty tree, a stale branch, a red base) is almost\nalways theirs to fix, and relaunching blind repeats the same refusal.\n\n## Phase 5 — `1`: classify before repairing\n\nRead the log tail back to the gate's own `HALT` block — `REASON:` and `DETAIL:`, written by\n`plugins\u002Fgoal\u002Fsrc\u002Fgate\u002Fhalt.ts`. That text is the only evidence there is; do not re-run the\ngate to get a second opinion; it will say the same thing.\n\nSort what it names into exactly one bucket:\n\n- **Plan fault** — the `DETAIL:` names a defect in the iteration's own contract: a declared path\n  that does not exist or is misspelled, a `max_diff` too tight for work the iteration's prose\n  plainly asked for, an `impl_files`\u002F`test_files` entry missing a file the goal names, prose that\n  reads one way and was enforced another. The fix stays inside a closed set: an entry in\n  `test_files` or `impl_files`, `max_diff`, a mistyped path, or prose. **It may never touch a\n  `gateN=` or `dodN=` line**, nor empty `test_files` — `plan-guard.ts` hashes that field's\n  emptiness, not its content, so it disarms the bite check the same way a rewritten gate line\n  would: not a smaller iteration, a different one, judged by a bar nobody locked.\n- **Implementation fault** — the same gate line is correct and the code it judged is not: a\n  wrong file touched, a rule half-implemented, a helper the plan never needed guessed into\n  existence. The fix is to try again, not to edit the contract.\n- **Unknown** — anything that is not confidently one of the above: the `DETAIL:` names something\n  outside the closed repair set, points at more than one iteration, or you cannot tell which side\n  of the line it falls on. Guessing here is the failure mode this command exists to avoid.\n\n### Plan fault → repair, prove it, relaunch\n\n1. Hash the plan before touching it: `node ${CLAUDE_PLUGIN_ROOT}\u002Fsrc\u002Fplan-guard.ts \u003Cplan>` →\n   keep `guard_hash`.\n2. Make the smallest edit inside the closed set above. Nothing else in the plan moves — no\n   rewording a goal, no reordering iterations, no touching a checkbox.\n3. Prove it: `node ${CLAUDE_PLUGIN_ROOT}\u002Fsrc\u002Fplan-guard.ts \u003Cplan> \u003Cguard_hash>` must print\n   `OK: no gate or dod line moved.` and exit 0. If it halts instead, the edit reached a guarded\n   line — revert it (`git checkout -- \u003Cplan>`) and fall through to unknown.\n4. Have the gate re-judge the preserved tree **directly**: `node\n   ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fgoal-gate.ts commit \u003Cplan> \u003Citeration>` alone. `commit` runs the\n   whole `verify` first and commits only when it passes, so a separate `verify` before it would\n   replay every gate command twice. Then, on exit 0, `goal-gate.ts dod \u003Cplan>` if it was the last\n   iteration. Do NOT relaunch via `goal-run.ts` here: its preflight requires a clean tree and\n   refuses (exit 2) the very implementer tree this procedure just decided to keep — observed on\n   ct-5865 iteration 3. The gate subcommands are the run's own judge\u002Fcommit path, bite check\n   included, so nothing lands unbitten.\n\n### Implementation fault → discard the tree, relaunch unchanged\n\n1. Discard exactly what the halted attempt wrote, and nothing that predates it — the preflight\n   already required a clean tree, so everything `git status --short` shows now belongs to this\n   attempt: `git checkout -- .` for tracked changes, `git clean -fd` for untracked ones. Never\n   `-x`: that would also sweep ignored planning documents the developer chose to keep local.\n2. Confirm the tree is clean (`git status --short` prints nothing) before relaunching.\n3. Relaunch the same iteration, plan untouched:\n   `node ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fgoal-run.ts \u003Cplan> \u003Citeration>`.\n\n### Unknown → stop, wake the developer\n\nBuild the failure report — the `HALT` block verbatim is its Command\u002FOutput — say plainly that\nyou could not classify it, and name why — which detail put it outside the closed set. Do not\nguess at a repair and do not discard anything.\nThis is the same halt a human reading the log would have to solve; it stays theirs.\n\n## Phase 6 — One relaunch, then stop\n\nWhichever repair ran, watch the relaunch exactly as in Phase 2, then report Phase 3\u002F4\u002F5 against\n*its* exit code — but do not repair a second time. A second halt on the same iteration, of either\nkind, means the classification was wrong, the repair was incomplete, or the halt has a cause this\ncommand does not model: build the failure report with everything (both `HALT` blocks, the repair\nmade in between, `git status --short`) and stop for the developer. Looping again is exactly the failure the design\nguards against — an agent that keeps relaunching optimizes for the run continuing, not for the\nwork being right.\n\n## Phase 7 — Audit the session, unless nothing was attempted\n\nSkip this phase on exit `2`: the preflight refused before any iteration reached an implementer,\nso there is no implementer transcript and nothing was driven — auditing how work was done when\nnone was is waste by construction. Print the Phase 4 report and stop.\n\nOtherwise — landed, paused, halted, or a relaunch that itself landed or stopped — invoke the\n`goal:goal-session-auditor` agent exactly once before you finish, passing it the plan's path and\n`$(pwd)`. It reads the transcripts a run left behind, including this supervising session's own,\nand reports findings anchored to a tool-call sequence: an edit reverted, the same command failing\ntwice, a file read five times, a brief that named a convention skill with no `Skill` call to\nmatch. Print what it returns; nothing it finds changes the exit you already reported.\n\nOnce the audit returns, fold its highlights into the PR's run report as a `### Session audit`\nsection — short bullets, not paragraphs — but only when the plan's policy is `commit+pr` and a\npull request is open: `gh pr edit\n\u003Cbranch> --repo \u003Crepo> --body \"$(gh pr view \u003Cbranch> --repo \u003Crepo> --json body -q .body)\n\n### Session audit\n\n\u003Chighlights>\"`. Outside `commit+pr`, or with no PR open yet, there is nowhere to fold it: the\nhighlights stay in this session's own final message instead.\n\n**Write the fold in English, whatever language this session is running in.** It lands in a pull\nrequest body, and a pull request is English — the `git` skill's rule, which is not loaded here,\nso it is restated at the one point in this command that writes to the forge. The trap is that the\nhighlights are already composed, in the reply being written to the developer: pasting that reply\ninto `gh pr edit` is a new artifact for a different reader, not a copy. A French audit fold under\nan English run report is what this paragraph exists to prevent, and it happened before it did.\n\nThe same fold completes the PR's attribution table: the auditor wrote it before its own tokens\nexisted, so append the `Auditor` row (off its `RUN tokens` line) and the `Supervising session`\nrow, and rewrite the `Total` row so it covers every row. A PR whose\ntotal leaves out two of the sessions that produced it is not a total.\n\n## Duration table\n\nEvery final report — Phase 3, 4, or the end of Phase 5\u002F6 — that attempted at least one\niteration prints the same two tables the auditor writes into `report.md`, built from the run's\nown `.run.jsonl` (one JSON line per `RUN stage=\u003Cname> duration_ms=\u003Cn> exit=\u003Cn>` event\n`goal-run.ts` already emits): extend those tables with this session's own rows, never reshape\nthem into a differently-shaped one of your own. Skip both only on exit `2`: Phase 4 already\ncovers that case, and there is no per-iteration row to print when nothing was attempted.\n\n**Durations**, one row per iteration, in order. Each step's own duration goes under the stage\nthat ran it, `push` collapsing `push` and `pull-request-update` into one publication figure on\nthe row of the iteration that triggered it:\n\n| Step | Implementer | Gate | Push |\n|---|---|---|---|\n| 1 | `\u003Cduration>` | `\u003Cduration>` | — |\n| … | … | … | … |\n| **Total** | `\u003Csum>` | `\u003Csum>` | `\u003Csum>` |\n\n`preflight` (with the base-must-already-be-green sweep) and `dod` run once, outside any\niteration: their durations go in one note line under the table (`Preflight: \u003Cd> · Dod: \u003Cd>`),\nnever in all-dash rows. Show every duration in minutes once it passes 60 s (`1m 12s`, not\n`72000`); below that, milliseconds are fine. Print an exit code only on the rows whose stage\nfailed; a row that landed carries no exit code at all. `Total` sums the displayed rows, not a\nre-scan of every `duration_ms` in the file — a step this table does not show never enters the\ntotal.\n\n**Attribution**, one row per session stage — `implementer` per iteration, `lens`,\n`reviewer`, `auditor` — read off that stage's own `RUN tokens stage=\u003Cname> input_tokens=\u003Cn>\noutput_tokens=\u003Cn> cache_creation_input_tokens=\u003Cn> cache_read_input_tokens=\u003Cn>` line, right after\nits `stage=` line:\n\n| Stage | Duration | Model | Context peak | Total tokens | % cache read | Cost (list) |\n|---|---|---|---|---|---|---|\n| Iteration 1 — Implementer | `\u003Cduration>` | `\u003Cmodel>` | `\u003Cpct>` | `\u003Cn>` | `\u003Cpct>` | `\u003C$>` |\n| … | … | … | … | … | … | … |\n| **Runner subtotal** | `\u003Csum>` | — | — | `\u003Csum>` | — | `\u003Csum>` |\n| Lens | `\u003Cduration>` | `\u003Cmodel>` | `\u003Cpct>` | `\u003Cn>` | `\u003Cpct>` | `\u003C$>` |\n| Reviewer | `\u003Cduration>` | `\u003Cmodel>` | `\u003Cpct>` | `\u003Cn>` | `\u003Cpct>` | `\u003C$>` |\n| Auditor | `\u003Cduration>` | `\u003Cmodel>` | `\u003Cpct>` | `\u003Cn>` | `\u003Cpct>` | `\u003C$>` |\n| Supervising session | `\u003Cduration>` | `\u003Cmodel>` | `\u003Cpct>` | `\u003Cn>` | `\u003Cpct>` | `\u003C$>` |\n| **Total** | `\u003Csum>` | — | — | `\u003Csum>` | — | `\u003Csum>` |\n\n`Duration` is the stage's own `duration_ms` — this table is the only place the lens, reviewer\nand auditor durations appear; the supervising session's is the span from this run's\n`goal-run.ts` launch to the fold, never the whole transcript — a session that supervised an\nearlier run or did other work would otherwise report hours for minutes. `Total tokens` is the four token classes summed for the row. `Context peak` is the percentage\nonly, never the token count, and never the effective window itself, which is named once in a\nnote under the table (`Effective window: \u003Cmodel> \u003Cn> tokens`) together with the run's own\ncompaction count, `0` stated rather than left blank, rather than repeated cell by cell — a model\nabsent from that note shows its tokens instead of a percentage. `% cache read` is the row's `cache_read_input_tokens` divided by its four-class total. `Cost (list)` is priced at the\nmodel's list rate, computed by you, the writer, from the four token classes — never read off the\ntranscript. The rates themselves never appear under the table — the column already carries them\napplied, and the window-and-compactions line is the attribution table's only note. The\n`Runner subtotal` row sums the `implementer` rows above it — what driving the\nplan itself cost — and is not summed again into `Total`, which sums every other displayed row.\n\n**A Copilot row** (a role or the supervising session that ran under Copilot) shows its duration,\nits model and what the Copilot session records. Its Cost cell holds the premium-request count or `—`,\nnever a Claude-priced figure. `Total` names which rows its sums cover (token sum, cost sum).\n\n**A Copilot supervising session** is read from `~\u002F.copilot\u002Fsession-state\u002F\u003Cid>\u002Fevents.jsonl`\ninstead: sum `session.usage_record` events by token class, read `cost` as premium requests and\n`maxPromptTokens` as the effective window.\n\n**The supervising session counts itself.** Everything above measures what `goal-run.ts` spawned;\nit never measures the session reading this skill and watching it. After the run ends, locate\nthis session's own transcript under `~\u002F.claude\u002Fprojects\u002F\u003Cencoded-cwd>\u002F` (the working directory\nwith every `\u002F` turned into a `-`). A transcript repeats one message's `usage` on every\ncontent-block entry it produced, so before summing, deduplicate by message id — keep one usage\nper id — to land on the envelope-exact figure rather than an inflated one; the peak needs no such\nrule, `max` is immune to a repeated value. Sum the per-class usage that survives deduplication\nacross the transcript entries timestamped between this run's `goal-run.ts` launch and the fold\n— the same window as the row's duration, and for the same reason: the transcript may carry\nearlier runs and unrelated work — and add the `Supervising session` row to the attribution table with those\nfour numbers, and — read the same way off that transcript's own events — its served model, its\ncontext peak (percentage against the note's effective window, or tokens if the model is\nunknown), and its compaction count folded into the note alongside the rest. `Total` includes\nthat row like any other — a token total that leaves out the session that spent them is not a\ntotal.\n\n## Closing paths\n\nEvery closing report names the plan and the run directories it produced, so the developer can\nopen them without hunting: the plan path, then each run directory under `\u003Cruns>\u002F`,\none path per line — never a single `·`-joined line. A developer copy-pasting a path off a run\nthat used commas or middle dots as separators is the failure this rule exists to avoid.\n\n## Rules for THIS command\n\n- **Classify before repairing, always** — never patch a plan and never discard a tree without\n  first naming which fault this is and why.\n- **A plan fault may only move inside the closed set**, proven by `plan-guard.ts` before every\n  relaunch. A `gateN=`\u002F`dodN=` line moving is never a repair, it is the halt disappearing.\n- **It never patches implementation code.** The tree it may touch is discarded, not edited; the\n  implementer rewrites under the gate on relaunch, so nothing lands that the bite check never bit.\n- **Unknown stops.** No repair is better than a wrong one.\n- **One relaunch per iteration, then stop** — no matter which bucket, no matter the second exit.\n","## Outside Claude Code\n\nThis skill needs a background shell and an agent tool. Claude Code: background `Bash`, `Agent`.\nCopilot CLI: async `bash` read with `read_bash`, `task` with `goal:goal-session-auditor`.\nCodex CLI: `exec_command` read with `write_stdin`, no agent tool. A host with neither a shell nor an agent tool cannot launch or audit a\nrun: state that reason and STOP before Phase 0 runs.\n\nThe host never sets or unsets `GOAL_RUN_PROVIDER` or `GOAL_RUN_IMPLEMENTER`: `goal-run.ts` is\nlaunched with the developer's provider settings untouched.\n\n## Host\n\n`\u003Croot>` is Claude Code's substituted `${CLAUDE_PLUGIN_ROOT}`. A host that leaves it literal\n(Copilot CLI) reads `\u003Croot>` as two levels above `Base directory for this skill:`.\nA host that injects no base-directory line and reads `SKILL.md` itself (Codex CLI) takes `\u003Croot>` as two levels\nabove that file's directory.\n`$ARGUMENTS` left literal is the text typed after the command (empty when none).\nUse `\u003Croot>` wherever a command below says `${CLAUDE_PLUGIN_ROOT}`.\n\nWhen `\u003Croot>\u002Fsrc\u002Fartifacts.ts` or a shared file this skill names is missing, print\n`cannot locate the goal plugin scripts`, the host, and the install commands, run nothing and write nothing:\n`copilot plugin marketplace add \u003Crepository>` then\n`copilot plugin install goal@fabien-claude-marketplace` under Copilot,\n`codex plugin marketplace add \u003Crepository>` then\n`codex plugin add goal@fabien-claude-marketplace` under Codex,\n`\u002Fplugin install goal@fabien-claude-marketplace` under Claude Code.\n\nThen read `\u003Croot>\u002Fshared\u002Fhost.md`.\n\n# \u002Fgoal:supervise — Watch a run, classify a halt, repair or relaunch once\n\nYou launch `node goal-run.ts` and read what it returns. `goal-run.ts` orders the iterations and\n`goal-gate.ts` decides whether each one passed; nothing here reopens either verdict. Your one job\non a non-zero exit is to say **which** of two very different things happened — the plan's contract\nwas wrong, or the implementation was — because the two halts this command was written after\n(`docs\u002Fopen-questions.md` §8) exited with the same code and the same wall message and needed\nopposite responses. Getting that call wrong is worse than not calling it: it either burns the\nimplementer's real work for nothing, or ships a plan quietly rewritten to stop refusing it.\n\n**This is a hypothesis, not a proven procedure.** The classification rule below was written from\ntwo cases. Read the report at the end as evidence for or against it, not as a verdict on this run.\n\n## Under Codex\n\nClaude stays the implementer: `goal-run.ts` runs `claude` as under any host, and the host never sets or unsets `GOAL_RUN_PROVIDER` or `GOAL_RUN_IMPLEMENTER`.\nThe background shell is `exec_command`, read with `write_stdin`. There is no agent tool.\n\nBefore Phase 1 launches anything, run a network probe and a write probe into `$HOME\u002F.claude`. Each network probe must print a code other than `000`:\n\n```bash\ncurl -s -o \u002Fdev\u002Fnull -w '%{http_code}' --max-time 10 https:\u002F\u002Fapi.github.com\ncurl -s -o \u002Fdev\u002Fnull -w '%{http_code}' --max-time 10 \"${ANTHROPIC_BASE_URL:-https:\u002F\u002Fapi.anthropic.com}\"\nf=\"$HOME\u002F.claude\u002F.goal-write-probe-$$\" && touch \"$f\" && rm -f \"$f\"\n```\n\nWhen one fails, name the failing probe, print `codex -s workspace-write -c sandbox_workspace_write.network_access=true --add-dir \"$HOME\u002F.claude\"`\nand launch nothing.\n\nPhase 7 runs `claude -p --agent goal:goal-session-auditor` from the shell, passing the plan's path and `$(pwd)`.\nA failed audit is reported with its error instead of an audit, and folds no `### Session audit`.\n\nThe supervising row is read from the rollout: sum `token_usage_record.payload.usage` once per `response_id` over the run's window\n(input = `input_tokens` minus `cached_input_tokens`, cache read = `cached_input_tokens`, cache write = `cache_write_input_tokens`,\noutput = `output_tokens`), take `model_context_window` from the `event_msg` `token_count` as the window, and show cost `—`.\n`Total` names which rows its sums cover.\n\n## Project artifact root\n\nBefore resolving the source, run the existing resolver from the installed goal plugin:\n\n```bash\nproject=\"$(git rev-parse --show-toplevel)\"\nnode \"${CLAUDE_PLUGIN_ROOT}\u002Fsrc\u002Fartifacts.ts\" \"$project\"\n```\n\nThen read `\u003Croot>\u002Fshared\u002Fartifact-root.md`.\n\nUse the effective value without asking for a location. If no value is supplied,\nuse the returned default; location selection belongs to `\u002Fgoal:spec`.\n\n## Phase 0 — Resolve the plan\n\nArgument: `$ARGUMENTS`\n\n- A full path ending in `.md` → that is the plan; fail clearly if missing or unreadable.\n- An identifier → resolve it as `\u003Croot>\u002Fshared\u002Fplan-argument.md` words it.\n- Empty → the `\u003Cplans>\u002F*-spec.md` most recently modified, excluding\n  `*-cleanup-spec.md`. Several equally plausible candidates → list them\n  and ASK. None → ask for the full path and wait.\n\nIf the developer confirms there is no existing plan to select, STOP:\n_\"No plan exists. Run `\u002Fgoal:plan` first.\"_\n\n## Phase 1 — Launch in the background\n\n```\nnode ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fgoal-run.ts \u003Cplan>\n```\n\nStart it as a background shell. It writes nothing you need to poll for: `\u003Cruns>\u002F\u003Cwork-id>\u002F\u003Crun-id>\u002F.run.log`\naccumulates the same lines it prints, so the transcript survives you looking away.\n\n## Phase 2 — Wait for it to end\n\nWatch the background shell until it exits, without polling in a tight loop. Read its exit code:\n\n| Exit | Meaning |\n|---|---|\n| `0` | every attempted iteration landed, gate-verified |\n| `1` | halted — the gate refused one iteration |\n| `2` | refused — the run never started (a faulty or unknown `GOAL_RUN_*`, `GOAL_CMD_*` or `GOAL_PROC_*` setting, listed all at once, including the retired `GOAL_RUN_SHUTDOWN_MAX_RETRIES`) |\n| `3` | paused — a clean boundary (the attempt ceiling, listing each attempt with its class; an implementer that committed on its own; an implementer that wrote nothing; a publication refused under `commit+pr`: push, pull request, scanner, fixup commit, or a closed or merged pull request, with the iterations that are local only) |\n\n## The failure report — evidence before diagnosis\n\nEvery non-zero exit is reported in one structured block, in this order:\n\n1. **Command** — the exact command the run executed, verbatim from the log (`make php\u002Fqa`, the\n   `gateN=` line the gate refused…).\n2. **Output** — the failing part of that command's output, verbatim from `\u003Cruns>\u002F\u003Cwork-id>\u002F\u003Crun-id>\u002F.run.log`: the\n   error lines plus enough surrounding context to read them (the failing suites, the assertion\n   diff, the lint error). Trim the green noise, never the failure.\n3. **Reproduce** — the command the developer can run themselves to see the same thing, what it\n   prints when healthy, and what it printed here.\n4. **Diagnosis** — what you conclude from 1–3, with your confidence.\n5. **Next move** — the repair, the relaunch, or the question for the developer.\n\nThe same evidence duty covers silent mutations: after any stage that runs project commands\n(preflight, DoD), check `git status --short` — a QA command that *fixes* instead of failing\n(a mutating cs-fixer, a formatter) leaves a dirty tree nobody reported. Show that diff\nverbatim and say which command produced it; never fold it into a commit without showing it.\n\nNever deliver 4–5 without 1–3: a solution whose problem the developer never saw is advice, not\na report — the failure this section was added after was three refusals reported as \"jest OOM,\nfix Docker\" without one line of jest output shown. And the whole block goes in the **final\nmessage of the turn**: text emitted between tool calls is not reliably displayed, so a report\nprinted mid-turn may never reach the developer at all.\n\n## Phase 3 — `0` or `3`: report, nothing to classify\n\nNeither exit names a fault. `0` → report what landed. `3` → report the boundary the log names\nand that relaunching resumes at the first unchecked box; do not relaunch it yourself, that is\nthe developer's call, not a repair.\n\n## Phase 4 — `2`: nothing was attempted\n\nA refusal exit means the preflight stopped the run before any iteration was handed to an\nimplementer — there is no work to classify and nothing to discard. Build the failure report:\nthe `STOP` line names the command (Command), the log holds its output (Output — for a\nnot-green base, the failing tests\u002Flint lines themselves, not just the summary line). Wake the\ndeveloper with it: the cause (a lock, a dirty tree, a stale branch, a red base) is almost\nalways theirs to fix, and relaunching blind repeats the same refusal.\n\n## Phase 5 — `1`: classify before repairing\n\nRead the log tail back to the gate's own `HALT` block — `REASON:` and `DETAIL:`, written by\n`plugins\u002Fgoal\u002Fsrc\u002Fgate\u002Fhalt.ts`. That text is the only evidence there is; do not re-run the\ngate to get a second opinion; it will say the same thing.\n\nSort what it names into exactly one bucket:\n\n- **Plan fault** — the `DETAIL:` names a defect in the iteration's own contract: a declared path\n  that does not exist or is misspelled, a `max_diff` too tight for work the iteration's prose\n  plainly asked for, an `impl_files`\u002F`test_files` entry missing a file the goal names, prose that\n  reads one way and was enforced another. The fix stays inside a closed set: an entry in\n  `test_files` or `impl_files`, `max_diff`, a mistyped path, or prose. **It may never touch a\n  `gateN=` or `dodN=` line**, nor empty `test_files` — `plan-guard.ts` hashes that field's\n  emptiness, not its content, so it disarms the bite check the same way a rewritten gate line\n  would: not a smaller iteration, a different one, judged by a bar nobody locked.\n- **Implementation fault** — the same gate line is correct and the code it judged is not: a\n  wrong file touched, a rule half-implemented, a helper the plan never needed guessed into\n  existence. The fix is to try again, not to edit the contract.\n- **Unknown** — anything that is not confidently one of the above: the `DETAIL:` names something\n  outside the closed repair set, points at more than one iteration, or you cannot tell which side\n  of the line it falls on. Guessing here is the failure mode this command exists to avoid.\n\n### Plan fault → repair, prove it, relaunch\n\n1. Hash the plan before touching it: `node ${CLAUDE_PLUGIN_ROOT}\u002Fsrc\u002Fplan-guard.ts \u003Cplan>` →\n   keep `guard_hash`.\n2. Make the smallest edit inside the closed set above. Nothing else in the plan moves — no\n   rewording a goal, no reordering iterations, no touching a checkbox.\n3. Prove it: `node ${CLAUDE_PLUGIN_ROOT}\u002Fsrc\u002Fplan-guard.ts \u003Cplan> \u003Cguard_hash>` must print\n   `OK: no gate or dod line moved.` and exit 0. If it halts instead, the edit reached a guarded\n   line — revert it (`git checkout -- \u003Cplan>`) and fall through to unknown.\n4. Have the gate re-judge the preserved tree **directly**: `node\n   ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fgoal-gate.ts commit \u003Cplan> \u003Citeration>` alone. `commit` runs the\n   whole `verify` first and commits only when it passes, so a separate `verify` before it would\n   replay every gate command twice. Then, on exit 0, `goal-gate.ts dod \u003Cplan>` if it was the last\n   iteration. Do NOT relaunch via `goal-run.ts` here: its preflight requires a clean tree and\n   refuses (exit 2) the very implementer tree this procedure just decided to keep — observed on\n   ct-5865 iteration 3. The gate subcommands are the run's own judge\u002Fcommit path, bite check\n   included, so nothing lands unbitten.\n\n### Implementation fault → discard the tree, relaunch unchanged\n\n1. Discard exactly what the halted attempt wrote, and nothing that predates it — the preflight\n   already required a clean tree, so everything `git status --short` shows now belongs to this\n   attempt: `git checkout -- .` for tracked changes, `git clean -fd` for untracked ones. Never\n   `-x`: that would also sweep ignored planning documents the developer chose to keep local.\n2. Confirm the tree is clean (`git status --short` prints nothing) before relaunching.\n3. Relaunch the same iteration, plan untouched:\n   `node ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fgoal-run.ts \u003Cplan> \u003Citeration>`.\n\n### Unknown → stop, wake the developer\n\nBuild the failure report — the `HALT` block verbatim is its Command\u002FOutput — say plainly that\nyou could not classify it, and name why — which detail put it outside the closed set. Do not\nguess at a repair and do not discard anything.\nThis is the same halt a human reading the log would have to solve; it stays theirs.\n\n## Phase 6 — One relaunch, then stop\n\nWhichever repair ran, watch the relaunch exactly as in Phase 2, then report Phase 3\u002F4\u002F5 against\n*its* exit code — but do not repair a second time. A second halt on the same iteration, of either\nkind, means the classification was wrong, the repair was incomplete, or the halt has a cause this\ncommand does not model: build the failure report with everything (both `HALT` blocks, the repair\nmade in between, `git status --short`) and stop for the developer. Looping again is exactly the failure the design\nguards against — an agent that keeps relaunching optimizes for the run continuing, not for the\nwork being right.\n\n## Phase 7 — Audit the session, unless nothing was attempted\n\nSkip this phase on exit `2`: the preflight refused before any iteration reached an implementer,\nso there is no implementer transcript and nothing was driven — auditing how work was done when\nnone was is waste by construction. Print the Phase 4 report and stop.\n\nOtherwise — landed, paused, halted, or a relaunch that itself landed or stopped — invoke the\n`goal:goal-session-auditor` agent exactly once before you finish, passing it the plan's path and\n`$(pwd)`. It reads the transcripts a run left behind, including this supervising session's own,\nand reports findings anchored to a tool-call sequence: an edit reverted, the same command failing\ntwice, a file read five times, a brief that named a convention skill with no `Skill` call to\nmatch. Print what it returns; nothing it finds changes the exit you already reported.\n\nOnce the audit returns, fold its highlights into the PR's run report as a `### Session audit`\nsection — short bullets, not paragraphs — but only when the plan's policy is `commit+pr` and a\npull request is open: `gh pr edit\n\u003Cbranch> --repo \u003Crepo> --body \"$(gh pr view \u003Cbranch> --repo \u003Crepo> --json body -q .body)\n\n### Session audit\n\n\u003Chighlights>\"`. Outside `commit+pr`, or with no PR open yet, there is nowhere to fold it: the\nhighlights stay in this session's own final message instead.\n\n**Write the fold in English, whatever language this session is running in.** It lands in a pull\nrequest body, and a pull request is English — the `git` skill's rule, which is not loaded here,\nso it is restated at the one point in this command that writes to the forge. The trap is that the\nhighlights are already composed, in the reply being written to the developer: pasting that reply\ninto `gh pr edit` is a new artifact for a different reader, not a copy. A French audit fold under\nan English run report is what this paragraph exists to prevent, and it happened before it did.\n\nThe same fold completes the PR's attribution table: the auditor wrote it before its own tokens\nexisted, so append the `Auditor` row (off its `RUN tokens` line) and the `Supervising session`\nrow, and rewrite the `Total` row so it covers every row. A PR whose\ntotal leaves out two of the sessions that produced it is not a total.\n\n## Duration table\n\nEvery final report — Phase 3, 4, or the end of Phase 5\u002F6 — that attempted at least one\niteration prints the same two tables the auditor writes into `report.md`, built from the run's\nown `.run.jsonl` (one JSON line per `RUN stage=\u003Cname> duration_ms=\u003Cn> exit=\u003Cn>` event\n`goal-run.ts` already emits): extend those tables with this session's own rows, never reshape\nthem into a differently-shaped one of your own. Skip both only on exit `2`: Phase 4 already\ncovers that case, and there is no per-iteration row to print when nothing was attempted.\n\n**Durations**, one row per iteration, in order. Each step's own duration goes under the stage\nthat ran it, `push` collapsing `push` and `pull-request-update` into one publication figure on\nthe row of the iteration that triggered it:\n\n| Step | Implementer | Gate | Push |\n|---|---|---|---|\n| 1 | `\u003Cduration>` | `\u003Cduration>` | — |\n| … | … | … | … |\n| **Total** | `\u003Csum>` | `\u003Csum>` | `\u003Csum>` |\n\n`preflight` (with the base-must-already-be-green sweep) and `dod` run once, outside any\niteration: their durations go in one note line under the table (`Preflight: \u003Cd> · Dod: \u003Cd>`),\nnever in all-dash rows. Show every duration in minutes once it passes 60 s (`1m 12s`, not\n`72000`); below that, milliseconds are fine. Print an exit code only on the rows whose stage\nfailed; a row that landed carries no exit code at all. `Total` sums the displayed rows, not a\nre-scan of every `duration_ms` in the file — a step this table does not show never enters the\ntotal.\n\n**Attribution**, one row per session stage — `implementer` per iteration, `lens`,\n`reviewer`, `auditor` — read off that stage's own `RUN tokens stage=\u003Cname> input_tokens=\u003Cn>\noutput_tokens=\u003Cn> cache_creation_input_tokens=\u003Cn> cache_read_input_tokens=\u003Cn>` line, right after\nits `stage=` line:\n\n| Stage | Duration | Model | Context peak | Total tokens | % cache read | Cost (list) |\n|---|---|---|---|---|---|---|\n| Iteration 1 — Implementer | `\u003Cduration>` | `\u003Cmodel>` | `\u003Cpct>` | `\u003Cn>` | `\u003Cpct>` | `\u003C$>` |\n| … | … | … | … | … | … | … |\n| **Runner subtotal** | `\u003Csum>` | — | — | `\u003Csum>` | — | `\u003Csum>` |\n| Lens | `\u003Cduration>` | `\u003Cmodel>` | `\u003Cpct>` | `\u003Cn>` | `\u003Cpct>` | `\u003C$>` |\n| Reviewer | `\u003Cduration>` | `\u003Cmodel>` | `\u003Cpct>` | `\u003Cn>` | `\u003Cpct>` | `\u003C$>` |\n| Auditor | `\u003Cduration>` | `\u003Cmodel>` | `\u003Cpct>` | `\u003Cn>` | `\u003Cpct>` | `\u003C$>` |\n| Supervising session | `\u003Cduration>` | `\u003Cmodel>` | `\u003Cpct>` | `\u003Cn>` | `\u003Cpct>` | `\u003C$>` |\n| **Total** | `\u003Csum>` | — | — | `\u003Csum>` | — | `\u003Csum>` |\n\n`Duration` is the stage's own `duration_ms` — this table is the only place the lens, reviewer\nand auditor durations appear; the supervising session's is the span from this run's\n`goal-run.ts` launch to the fold, never the whole transcript — a session that supervised an\nearlier run or did other work would otherwise report hours for minutes. `Total tokens` is the four token classes summed for the row. `Context peak` is the percentage\nonly, never the token count, and never the effective window itself, which is named once in a\nnote under the table (`Effective window: \u003Cmodel> \u003Cn> tokens`) together with the run's own\ncompaction count, `0` stated rather than left blank, rather than repeated cell by cell — a model\nabsent from that note shows its tokens instead of a percentage. `% cache read` is the row's `cache_read_input_tokens` divided by its four-class total. `Cost (list)` is priced at the\nmodel's list rate, computed by you, the writer, from the four token classes — never read off the\ntranscript. The rates themselves never appear under the table — the column already carries them\napplied, and the window-and-compactions line is the attribution table's only note. The\n`Runner subtotal` row sums the `implementer` rows above it — what driving the\nplan itself cost — and is not summed again into `Total`, which sums every other displayed row.\n\n**A Copilot row** (a role or the supervising session that ran under Copilot) shows its duration,\nits model and what the Copilot session records. Its Cost cell holds the premium-request count or `—`,\nnever a Claude-priced figure. `Total` names which rows its sums cover (token sum, cost sum).\n\n**A Copilot supervising session** is read from `~\u002F.copilot\u002Fsession-state\u002F\u003Cid>\u002Fevents.jsonl`\ninstead: sum `session.usage_record` events by token class, read `cost` as premium requests and\n`maxPromptTokens` as the effective window.\n\n**The supervising session counts itself.** Everything above measures what `goal-run.ts` spawned;\nit never measures the session reading this skill and watching it. After the run ends, locate\nthis session's own transcript under `~\u002F.claude\u002Fprojects\u002F\u003Cencoded-cwd>\u002F` (the working directory\nwith every `\u002F` turned into a `-`). A transcript repeats one message's `usage` on every\ncontent-block entry it produced, so before summing, deduplicate by message id — keep one usage\nper id — to land on the envelope-exact figure rather than an inflated one; the peak needs no such\nrule, `max` is immune to a repeated value. Sum the per-class usage that survives deduplication\nacross the transcript entries timestamped between this run's `goal-run.ts` launch and the fold\n— the same window as the row's duration, and for the same reason: the transcript may carry\nearlier runs and unrelated work — and add the `Supervising session` row to the attribution table with those\nfour numbers, and — read the same way off that transcript's own events — its served model, its\ncontext peak (percentage against the note's effective window, or tokens if the model is\nunknown), and its compaction count folded into the note alongside the rest. `Total` includes\nthat row like any other — a token total that leaves out the session that spent them is not a\ntotal.\n\n## Closing paths\n\nEvery closing report names the plan and the run directories it produced, so the developer can\nopen them without hunting: the plan path, then each run directory under `\u003Cruns>\u002F`,\none path per line — never a single `·`-joined line. A developer copy-pasting a path off a run\nthat used commas or middle dots as separators is the failure this rule exists to avoid.\n\n## Rules for THIS command\n\n- **Classify before repairing, always** — never patch a plan and never discard a tree without\n  first naming which fault this is and why.\n- **A plan fault may only move inside the closed set**, proven by `plan-guard.ts` before every\n  relaunch. A `gateN=`\u002F`dodN=` line moving is never a repair, it is the halt disappearing.\n- **It never patches implementation code.** The tree it may touch is discarded, not edited; the\n  implementer rewrites under the gate on relaunch, so nothing lands that the bite check never bit.\n- **Unknown stops.** No repair is better than a wrong one.\n- **One relaunch per iteration, then stop** — no matter which bucket, no matter the second exit.\n",{"name":5,"description":7,"disable-model-invocation":48},true,"main","479b264ec17cc5fafbf36287a1087472d3a386d3","plugins\u002Fgoal\u002Fskills\u002Fsupervise",2,"https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace","https:\u002F\u002Fgithub.com\u002FFabienSalles","https:\u002F\u002Ffabiensalles.com","2026-10-13 04:33:22",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":48},[59,62,65],{"tool":60,"command":61},"npx","npx skills add FabienSalles\u002Fclaude-marketplace --skill supervise",{"tool":63,"command":64},"bunx","bunx skills add FabienSalles\u002Fclaude-marketplace --skill supervise",{"tool":66,"command":67},"pnpm","pnpm dlx skills add FabienSalles\u002Fclaude-marketplace --skill supervise","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fgoal\u002Fskills\u002Fsupervise\u002FSKILL.md",[70],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"index.json","REFERENCE","参考文档",665,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fmalware-family-rootkit\u002Findex.json",[77,109,128,148,171,188],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":88,"publishedAt":43},"01M6DW2YS1MGF65JNS1QQ15QHS","vitest-test-conventions","ACTIVATE when writing Vitest tests, creating test files, using vi.fn()\u002Fvi.mock()\u002Fvi.spyOn(), or test factories. ACTIVATE for 'Vitest', 'it.each', 'NestJS testing module', 'supertest', 'vi.fn', 'vi.mock', 'spyOn'. Provides Vitest\u002FNestJS-specific testing patterns; cross-language testing principles (DAMP, AAA, spy over mock, what NOT to test) live in craft:testing-principles. DO NOT use for: node:test files (a file importing node:test) or a project whose tests run under node --test (see node-test:node-test-conventions), TDD workflow\u002Fiterations (see vitest:vitest-tdd-workflow), PHP\u002FPHPUnit tests (see phpunit:php-test-conventions).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fvitest\u002Fskills\u002Fvitest-test-conventions\u002FSKILL.md",[83],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108],"test","vitest","conventions","vitest test conventions","testing","writing","tdd","workflow","file","testing patterns","use","files","nestjs","activate","do","project","tests","module","fn","testing principles",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":118,"publishedAt":43},"01M6DW2VFE6NPFCGQKQ68P1MVZ","vitest-tdd-workflow","ACTIVATE when building new features, endpoints, or user stories using TDD with Vitest in a TypeScript\u002FNestJS context. ACTIVATE for '\u002Ffeature-tdd-dev', 'TDD', 'red-green-refactor' in TS context. Provides Vitest\u002FNestJS-specific TDD examples and commands; cross-language TDD workflow (cross-layer iterations, RED-GREEN-REFACTOR, working app, bug-fix-first-test, mocks-hiding-bugs) lives in craft:tdd-workflow-principles. DO NOT use for: node:test files (a file importing node:test) or a project whose tests run under node --test (see node-test:node-test-conventions), test writing conventions (see vitest:vitest-test-conventions), PHP TDD (see phpunit:php-tdd-workflow).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fvitest\u002Fskills\u002Fvitest-tdd-workflow\u002FSKILL.md",[115],{"categoryNo":116,"categoryName":117,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000023","Skill与智能体开发",[95,96,119,90,120,94,121,97,122,123,99,124,100,102,103,125,104,105,126,127],"tdd workflow","vitest tdd workflow","dev","examples","fix","red-green-refactor","green","feature","app",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":43},"01M6DW2RGMQE10D8C5Z5MA2RMY","ts-refactoring","ACTIVATE when refactoring TypeScript code. ACTIVATE for 'refactor', 'extract', 'redesign', 'simplify', or 'clean up' in a TypeScript \u002F Node \u002F NestJS context. This skill provides TS-specific examples for the cross-language refactoring rules defined in craft:refactoring-principles. DO NOT use for: writing new features from scratch, general OOP patterns (see ts-oop).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-refactoring\u002FSKILL.md",[],[135,136,94,137,138,122,139,140,141,38,142,99,143,144,145,101,146,102,103,147],"refactoring","ts refactoring","typescript","code","refactor","simplify","Rules","redesign","up","general","clean","craft","patterns",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":155,"publishedAt":43},"01M6DW2MHYXNBBVYEGB058Y48J","ts-ports-adapters","ACTIVATE when a TypeScript codebase with no dependency-injection container has to declare a port and wire its adapter — a repository, a clock, an id generator, an event dispatcher the domain depends on. ACTIVATE for 'port', 'adapter', 'SPI', 'dependency inversion' or 'composition root' in a codebase that wires its dependencies by hand. Covers: the port as a type of functions in the domain layer, the adapter as an object literal annotated with it, the handler that takes its dependencies first and its data second, the composition root in the infrastructure layer, and the in-memory stub that substitutes for the adapter in a unit test. DO NOT use for: NestJS, or any container-based DI with decorators and tokens (see nest-ddd-conventions), aggregate operations and smart constructors (see ddd-ts-fp), the Result type itself (see ts-functional).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-ports-adapters\u002FSKILL.md",[154],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},[156,157,158,89,159,160,99,161,162,101,163,102,103,164,165,166,167,168,169,170],"ports","ts ports adapters","memory","ddd","Composition","container","functions","Literal","dependency-injection","domain","tokens","as","type","id","adapter",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":43},"01M6DW2GRXZFYT05HEDB26C9B8","ts-oop","ACTIVATE when designing TypeScript classes, and the value objects or collections modelled as classes, or when the user asks about object design, encapsulation, Tell Don't Ask, or Symbol.iterator. Provides TS-specific examples for the cross-language OOP rules defined in craft:oop-principles, plus TS-specific patterns (Symbol.iterator, branded types for primitive identifiers). DO NOT use for: a value object or an aggregate modelled as an immutable record rather than a class (see ddd-ts-fp), refactoring methodology (see ts-refactoring).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-oop\u002FSKILL.md",[],[178,179,180,137,159,122,181,182,135,141,183,99,184,146,102,103,185,186,187,167],"oop","ts oop","design","methodology","immutable","ask","refactoring methodology","objects","record","collections",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"publishedAt":43},"01M6DW2D26XG5MJMTP9MSE43S2","ts-layer-boundaries","ACTIVATE when wiring a Worker entry point, a Router, a controller, or a domain event consumer in a TypeScript CQRS codebase, or when deciding where a port belongs. ACTIVATE for 'composition root', 'layer boundary', 'ESLint zones', 'domain must not import infrastructure'. Covers: the *Worker.ts composition root, the curried consumer, Router wiring of command endpoints, the five-gesture controller, the domain-to-infrastructure import boundary enforced by ESLint, infrastructure-only ports, in-memory doubles for every port, the read-can-reach-write asymmetry, and read endpoints going through a domain handler. DO NOT use for: the port's own shape and adapter binding (see ts-ports-adapters), the Result type (see ts-functional), domain event structure (see ts-ddd-events).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-layer-boundaries\u002FSKILL.md",[],[195,158,159,196,197,160,156,99,198,199,200,102,103,201,165,202,203,168,170,204],"ts layer boundaries","controller","boundary","router","only","endpoints","structure","cqrs","worker","import"]