[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C44ZFEBPXG7N45NEXCM3C2":3,"skill-same:01M6C44ZFEBPXG7N45NEXCM3C2":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":25,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6C44ZFEBPXG7N45NEXCM3C2","goal-run",null,"Methodology home for the goal-run harness (issue #874): the stage-machine contract, halt-reason precedence, launch arms, worktree lifecycle, the label-to-ledger join query for escape-rate segmentation, and the untrusted-content discipline for a single vendor-goal-loop harness run. Use when extending, halting, resuming, or documenting a \u002Fgoal-run invocation, or when writing the escape-rate query that segments goal-run PRs from Code-Conductor-orchestrated PRs. DO NOT USE FOR: the live \u002Fgoal-run execution prose itself (use agents\u002FGoal-Run.agent.md, the shared body this skill is referenced from) or the goal-contract plan-authoring schema (use skills\u002Fplan-authoring's goal-contract schema, decision 872-D2).","Grimblaz\u002Fagent-orchestra","Grimblaz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F74755849?v=4","01M6C430M9XZDHGHPWQVTQ3KMA","01M6C430RJY3MMX0QAZ3X8DR3Y",3,"MIT","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fgoal-run\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000037","律师与法务",[26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"goal run","run","goal","lifecycle","schema","discipline","use","vendor","decision","plan","loop","writing","segmentation","execution","methodology","worktree","content","harness","code","launch","2026-11-10 10:12:30",false,"---\nname: goal-run\ndescription: \"Methodology home for the goal-run harness (issue #874): the stage-machine contract, halt-reason precedence, launch arms, worktree lifecycle, the label-to-ledger join query for escape-rate segmentation, and the untrusted-content discipline for a single vendor-goal-loop harness run. Use when extending, halting, resuming, or documenting a \u002Fgoal-run invocation, or when writing the escape-rate query that segments goal-run PRs from Code-Conductor-orchestrated PRs. DO NOT USE FOR: the live \u002Fgoal-run execution prose itself (use agents\u002FGoal-Run.agent.md, the shared body this skill is referenced from) or the goal-contract plan-authoring schema (use skills\u002Fplan-authoring's goal-contract schema, decision 872-D2).\"\n---\n\n\u003C!-- markdownlint-disable-file MD041 MD003 -->\n\n# Goal-Run Harness\n\nReference methodology for the goal-run harness: a launcher\u002Fresumer that walks a single GitHub issue's approved goal-contract (a structured, machine-checkable target the vendor's own `\u002Fgoal` loop runs against) through to a reviewed, classed pull request, without a human answering anything mid-run. This file documents the mechanics; the runnable prose lives in [agents\u002FGoal-Run.agent.md](..\u002F..\u002Fagents\u002FGoal-Run.agent.md). For the invocation entry point and the reader-facing dual-flow orientation (conducted vs. goal-run, launch, resume, halt-reason reading guide, honest budget expectations), see [CLAUDE.md § Orchestration](..\u002F..\u002FCLAUDE.md#orchestration) and [HOW-IT-WORKS.md § Goal-run: the unattended pipeline](..\u002F..\u002FHOW-IT-WORKS.md#3-goal-run-the-unattended-pipeline).\n\n## When to Use\n\n- When extending, debugging, or reviewing a change to the goal-run harness's stage machine, halt model, worktree lifecycle, or untrusted-content barriers.\n- When writing or reviewing the `agents\u002FGoal-Run.agent.md` \u002F `agents\u002Fgoal-run.md` shared body and shell, or the customer-experience (CE) surface-class doc ([skills\u002Fcustomer-experience\u002Freferences\u002Fgoal-run-surface-classes.md](..\u002Fcustomer-experience\u002Freferences\u002Fgoal-run-surface-classes.md), 874-D8) and dual-flow guide that reference this skill.\n- When building the escape-rate segmentation query described in `## Label-To-Ledger Join`.\n- When a reader needs to know what a `goal-run-stage-{issue}`, `goal-run-inflight-{issue}`, or `goal-halt-report-{issue}` marker means.\n\n### DO NOT USE FOR\n\n- **Running `\u002Fgoal-run` itself** — that is `agents\u002FGoal-Run.agent.md` (shared body) and `agents\u002Fgoal-run.md` (Claude Code shell). This skill is the reference the body cites, not a substitute for it.\n- **The goal-contract's own shape** (targets, halt conditions, evidence obligations) — that schema lives under `skills\u002Fplan-authoring\u002Fschemas\u002Fgoal-contract.schema.json` (872-D2).\n- **General adversarial-review, CE Gate (Customer Experience Gate — the validation step confirming an implementation achieves the intended customer experience), or PR-persistence mechanics** — the Post-Loop Chain (below) reuses `adversarial-review`, `customer-experience`, and `persist-changes` unchanged; load those skills directly for their own methodology.\n\n## Purpose\n\nA goal-run invocation must survive a crash or a second concurrent launch attempt without losing track of where it is or double-provisioning a worktree. Every stage transition, halt, and terminal check is therefore read from durable GitHub artifacts — never from what a conversation remembers saying — and every function that makes one of these decisions is a tested PowerShell primitive under `.github\u002Fscripts\u002Flib\u002Fgoal-run-*-core.ps1`, not inline arithmetic in the agent prose.\n\n## Stage-Machine Contract\n\nThe stage-machine's WRITTEN marker vocabulary — the value actually persisted to the `goal-run-stage-{Issue}` comment — is a fixed four-value sequence (`$script:GoalRunStageOrder` in [goal-run-stage-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-stage-core.ps1)):\n\n`pre-loop -> loop-launched -> loop-released -> chain-dispatched`\n\n`pre-loop` is the implicit starting state — no marker is ever posted for it on its own, and (M17 fix) the stage-marker writer's own `ValidateSet` excludes it, reconciling it against the reader's `ExplicitStageMarker` `ValidateSet` (`Resolve-GoalRunResumeStage`), which never accepted it either. A single `\u003C!-- goal-run-stage-{issue} -->` issue comment is upserted in place (never appended-to) and always reflects the latest completed stage. This is deliberately the coarse top-level enum a resumed invocation switches on; finer-grained per-attempt history (why a run deviated, what it checkpointed) lives in the typed run log and the mutex marker, not here. Since the M10 fix, this marker also carries the provisioned worktree path (`-WorktreePath` on `Set-GoalRunStageMarker`), so a resuming invocation reads it directly off the marker instead of an undefined \"most recent worktree\" filesystem search.\n\n`Resolve-GoalRunResumeStage`'s returned `.ResumeStage` vocabulary is a superset of the four written values above: it adds a fifth, resolver-only value, `loop-interrupted`, that is never itself written to the stage marker — the function derives it purely from the durable signals below when an earlier session's `loop-launched` marker never reached `loop-released`. `Resolve-GoalRunResumeStage` decides where a resumed invocation re-enters, in this precedence (highest wins):\n\n1. Contract hash not verified against the launch-pinned value -> `blocked` (not a stage to execute — report and stop; the contract needs plan-side remediation).\n2. Terminal emissions already verified on a known PR -> `complete` (nothing left to do).\n3. Explicit stage marker is `chain-dispatched` or `loop-released` -> resume at `chain-dispatched` (the loop already released; only the chain remains).\n4. Explicit stage marker is `loop-launched` -> resolve to `loop-interrupted`, not literally `loop-launched`: a prior session launched the vendor loop and this resuming session has no live transcript to read a release verdict from, so the loop's true outcome must be reconstructed from durable state (see `agents\u002FGoal-Run.agent.md`'s `### loop-interrupted (resume without a transcript)` section).\n5. No explicit marker, but the typed run log has a `checkpoint`\u002F`deviation`\u002F`experience-observation` entry -> also `loop-interrupted`, for the same reason — the loop ran even though no explicit marker was ever written (e.g. a crash between launch and the next marker).\n6. `goal-run-active.json` exists but no run-log evidence -> `loop-launched` — the worktree was provisioned but the loop itself was never launched.\n7. A mutex marker exists but nothing else -> `pre-loop` (crash mid `pre-loop`).\n8. Nothing present -> `pre-loop` (fresh launch).\n\n`blocked` and `complete` are terminal reports, not stages a resumer executes — report and stop. `loop-interrupted`, unlike those two, IS a stage a resumer executes: its stage-machine section re-validates the committed worktree state directly, then either discovers the interrupted loop's work was already satisfied, relaunches the loop in the same worktree if it is genuinely dead, or reports a still-live run under a different session — it never just reports and stops.\n\n## Halt Model And Precedence\n\nA halt report is a closed, five-value-enum object validated against [`skills\u002Fgoal-run\u002Fschemas\u002Fgoal-halt-report.schema.json`](schemas\u002Fgoal-halt-report.schema.json) (`additionalProperties: false` — every field the harness or an executor can populate is named and typed). The `halt_reason` enum is reused verbatim from the goal-contract schema's `halt_conditions` (872-D2): `unachievable-target`, `invariant-conflict`, `budget-exhausted`, `gate-input-needed`, `chain-stage-failure`.\n\nWhen more than one halt condition is true at the same evaluation point, `Resolve-GoalRunHaltPrecedence` ([goal-run-chain-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-chain-core.ps1)) picks the single winner by this **total, non-negotiable** order (highest wins):\n\n`invariant-conflict > unachievable-target > gate-input-needed > budget-exhausted > chain-stage-failure`\n\nThis ordered list is the entire precedence rule; nothing else in the file overrides it. `Resolve-GoalRunHaltPrecedence` does not itself decide *whether* a condition is true — each producer's own detection lives elsewhere (the launch-pinned contract-hash mismatch and an executor's own halt-claim for `invariant-conflict`; the re-validation disposition, the fix-cycle cap, or a stage crash for `chain-stage-failure`; the wall-clock backstop for `budget-exhausted`; the chain-gate demand for `gate-input-needed`) — callers pass in the already-decided booleans.\n\nA single-condition halt (nothing else co-occurring, e.g. the loop-released bounded-retry exhaustion) skips `Resolve-GoalRunHaltPrecedence` entirely and goes straight to the report builder — the precedence function only matters when two or more producers are simultaneously true.\n\nNever hand-build a halt comment. `New-GoalRunChainHaltReport` composes the schema-shaped object (running every free-text field through secret redaction, below); `Invoke-GoalRunHaltEmit` ([goal-run-halt-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-halt-core.ps1)) schema-validates and refuses to post an invalid report.\n\n## Launch Arms\n\n### Arm I (in-session) — the only arm implemented in this PR\n\n`\u002Fgoal-run {issue}` is both launcher and resumer. The harness verifies the contract hash, posts a mutex marker (`goal-run-inflight-{issue}`) *before* provisioning any worktree so a running worktree with no live marker can never exist, tiebreaks a concurrent launch race by lowest comment id, then sets the goal on itself and becomes the executor inside the freshly provisioned worktree. When the vendor `\u002Fgoal` loop completes and control genuinely returns to the harness session, it reads the now-flushed `goal_status` verdict and enters the Post-Loop Chain (re-validate, CE Gate, adversarial review, capped fix cycles, PR creation with classing — see [agents\u002FGoal-Run.agent.md](..\u002F..\u002Fagents\u002FGoal-Run.agent.md) `## Post-Loop Chain` for the full stage-by-stage prose).\n\nThe loop-to-chain seam is deliberately built from durable artifacts only: `New-GoalRunExecutorSessionHandle` and `Invoke-GoalRunLaunchChain` take an issue number, repo root, contract hash, worktree path, and a session handle — never live conversation context — so a future arm can populate the same shapes without rewriting this transition.\n\n### Arm H (headless) — PR-2, not yet implemented\n\nA future PR will let the harness supervise an externally polled `claude -p` process instead of running in-session. The loop-to-chain seam above is already shaped to accept this without a rewrite. No further design decisions have been made yet; do not invent Arm H behavior beyond this pointer.\n\n### Arm M (manual hand-off) — PR-2, not yet implemented\n\nA future PR will define a manual two-block rendering surface for a human to hand off a run. This PR renders no Arm M output and accepts no `scope_boundaries` prompt field. No further design decisions have been made yet; do not invent Arm M behavior beyond this pointer.\n\n## Worktree Lifecycle\n\nAll worktree mechanics live in [goal-run-worktree-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-worktree-core.ps1); its own header comment is the authoritative function-by-function summary — this section is a pointer, not a re-derivation.\n\n- **Provision** — `New-GoalRunWorktree` refuses a dirty tree first, then creates a named branch `goal-run\u002Fissue-{N}-{token}` (`{token}` is a GUID-style collision-proof suffix, so two concurrent runs for the same issue never collide) at a short root outside the checkout, setting `core.longpaths` at `worktree add`.\n- **State file** — `New-GoalRunActiveState` writes `goal-run-active.json` at the worktree root: ceilings, baseline, arm, executor session id, the launch-pinned `contract_hash`, `launched_at`, a `heartbeat_at` timestamp (seeded equal to `launched_at`), and `teardown_deferred` (default `false`). `Get-GoalRunActiveState` reads it back and returns `$null` on a missing file rather than throwing. `Update-GoalRunActiveStateHeartbeat` refreshes `heartbeat_at` — wired live (M5 fix) via `Invoke-GoalRunChainStageBoundaryHousekeeping` ([goal-run-budget-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-budget-core.ps1)) at every chain-stage boundary and at the loop-release point; before that fix the function existed and was tested but had zero live callers.\n- **Run log** — `goal-run-log.jsonl` at the worktree root (alongside `goal-run-active.json`), one JSON object per line, each independently validated against [`schemas\u002Fgoal-run-log.schema.json`](schemas\u002Fgoal-run-log.schema.json) before it is appended. `Add-GoalRunLogEntry` ([goal-run-log-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-log-core.ps1), M9 fix) is the schema-validating writer; `Test-GoalRunLogHasCheckpoint` is the reader `Resolve-GoalRunResumeStage`'s `-RunLogHasCheckpoint` parameter is actually fed from (Invocation Contract step 3). A `checkpoint` entry is written at every chain-stage boundary via the same `Invoke-GoalRunChainStageBoundaryHousekeeping` call named above.\n- **Teardown** — `Remove-GoalRunWorktree` retries `git worktree remove` with backoff on every exit path and diagnoses the outcome honestly across the same six-value vocabulary used by the session-startup cleanup detector: `removed`, `removed-partial-root-held`, `removed-partial-content-remains`, `stale-registration`, `failed`, `verification-indeterminate`. On retry exhaustion it sets `teardown_deferred: true` on the state file (best-effort) rather than throwing. It never force-removes a locked worktree on a `prunable` porcelain flag alone — only on `Test-Path`-verified absence of the directory, because real git never sets `prunable` on a locked worktree.\n\n## Label-To-Ledger Join (874-D7)\n\nEvery goal-run PR carries two machine-readable markers of its own provenance, both written at PR-creation time by `Invoke-GoalRunClassEmission` ([goal-run-chain-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-chain-core.ps1)):\n\n- The `goal-run` GitHub PR label, applied by `Add-GoalRunPrLabel`.\n- A `goal_run_class` scalar field (default value `goal-run`) plus a `goal_run_issue` field, folded into the PR body's `\u003C!-- pipeline-metrics -->` block through the existing `Invoke-PipelineMetricsV4Emit` primitive. Both fields are additive-safe: a reader that does not know about them silently ignores them.\n\n**The join key is `goal_run_class` (or, equivalently, the `goal-run` label) on the PR side.** A future escape-rate query segments the frame-credit-ledger's per-PR review-defect counts by joining on that key: PRs where `goal_run_class == 'goal-run'` (or carrying the `goal-run` label) are goal-run-produced; every other PR in the ledger is Code-Conductor-orchestrated. No query tool exists yet — this section documents the join key and the intended analysis shape (per-PR defect count grouped by goal-run vs. non-goal-run) so a future maintainer can write it directly against the ledger and `gh pr list --label goal-run` without re-deriving which field to key on.\n\n## Untrusted-Content Discipline (M4\u002FM5\u002FM12)\n\nThree separate guardrails stand between content the harness does not fully trust — a transcript event, a live issue comment that could have been edited after launch, or executor-supplied evidence text — and any durable artifact the harness writes:\n\n- **Launch-pinned contract-hash check** (step 5, wired live by the M1 fix) — `Test-GoalRunContractHashPinned` ([goal-run-prompt-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-prompt-core.ps1)) compares the *live* issue-body contract hash against the hash pinned at launch time, not the contract's own self-reported `contract_hash` field — this catches a post-approval edit that kept its own field internally consistent. A mismatch is the highest-precedence halt producer, `invariant-conflict`. Three live call sites actually run this check: the vendor `\u002Fgoal` loop predicate ([goal-run-predicate.ps1](..\u002F..\u002F.github\u002Fscripts\u002Fgoal-run-predicate.ps1) \u002F [goal-run-predicate-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-predicate-core.ps1), on every loop iteration, via `Resolve-GoalRunLoopPredicate`), chain re-validation (`Invoke-GoalRunChainRevalidate`'s `-LaunchPinnedHash` parameter, [goal-run-chain-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-chain-core.ps1)), and resume-time verification (the `agents\u002FGoal-Run.agent.md` Invocation Contract step 1). Before the M1 fix, the function existed and was tested but had zero live callers.\n- **Transcript allow-list + secret-redaction pass** (step 1) — `Select-GoalRunAllowedFields` ([goal-run-transcript-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-transcript-core.ps1)) copies only explicitly named keys out of a raw transcript event and also rejects a nested dictionary or non-string enumerable found under an allow-listed key name, so a poisoned event cannot smuggle structured content in under a trusted key. `Get-GoalRunRedactedText` then runs a fixed set of secret-shaped regexes (GitHub\u002FAWS\u002FSlack tokens, PEM private-key blocks, bearer tokens, generic `key=value` secret assignments) over any string headed for a durable artifact, replacing each match with a `[REDACTED:\u003Cpattern-name>]` placeholder.\n- **Executor-evidence inert-render discipline** (step 1) — `ConvertTo-GoalRunInertEvidenceText` ([goal-run-halt-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-halt-core.ps1)) strips marker-delimiter substrings out of `evidence[]`\u002F`plan_remediation` text before a halt report is posted, so executor-authored text cannot smuggle a live `\u003C!-- ... -->` marker literal into a durable comment. `Invoke-GoalRunHaltEmit` applies this and schema-validates before ever posting — it is never bypassed by constructing a raw comment string.\n\nAny transcript-derived or executor-supplied string reaching a halt report or a PR body fragment must already have passed through the allow-list extractor and the redaction pass; the halt-report schema's closed shape (`additionalProperties: false`) cannot itself enforce that upstream discipline, only the field shape.\n\n## Gotchas\n\n| Trigger | Gotcha | Fix |\n| --- | --- | --- |\n| Polling `stream-json` stdout for the loop's release verdict | `goal_status` is transcript-only and never reaches `stream-json` stdout on either platform (goal-loop-capability-probe finding) — a harness watching stdout is blind to release | Only read the verdict after control genuinely returns to the harness session, via `Resolve-GoalRunControlReturn`'s bounded transcript retry |\n| Calling `Resolve-GoalRunHaltPrecedence` on every halt | The function only matters when two or more of the five producers are true at once | A single-condition halt (e.g. loop-released retry exhaustion) goes straight to the report builder |\n| Assuming a `chain-dispatched` marker on resume means work remains | A PR that already carries both the `goal-run` label and the classing metrics is genuinely complete | Call `Test-GoalRunPrEmissionsVerified` against the run's known PR before assuming any work remains |\n\n## Release-Hygiene Note\n\nThis file and its `schemas\u002F*.json` siblings sit under `skills\u002F*`, one of the bare glob patterns `Get-FVPluginEntryPointPatterns` ([frame-predicate-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fframe-predicate-core.ps1)) classifies as a cache-keyed plugin entry point — any path under `skills\u002F**` counts, not just files with a sibling `SKILL.md`. Claude Code's plugin cache is keyed by the `version` in `.claude-plugin\u002Fplugin.json`; a same-version reinstall keeps serving whatever entry-point snapshot that version last had. This file is a new entry point added after this PR's step-4 version bump already landed, so it requires its own coalesced `bump-version.ps1` bump — see this step's dispatch report for the resulting version.\n","\u003C!-- markdownlint-disable-file MD041 MD003 -->\n\n# Goal-Run Harness\n\nReference methodology for the goal-run harness: a launcher\u002Fresumer that walks a single GitHub issue's approved goal-contract (a structured, machine-checkable target the vendor's own `\u002Fgoal` loop runs against) through to a reviewed, classed pull request, without a human answering anything mid-run. This file documents the mechanics; the runnable prose lives in [agents\u002FGoal-Run.agent.md](..\u002F..\u002Fagents\u002FGoal-Run.agent.md). For the invocation entry point and the reader-facing dual-flow orientation (conducted vs. goal-run, launch, resume, halt-reason reading guide, honest budget expectations), see [CLAUDE.md § Orchestration](..\u002F..\u002FCLAUDE.md#orchestration) and [HOW-IT-WORKS.md § Goal-run: the unattended pipeline](..\u002F..\u002FHOW-IT-WORKS.md#3-goal-run-the-unattended-pipeline).\n\n## When to Use\n\n- When extending, debugging, or reviewing a change to the goal-run harness's stage machine, halt model, worktree lifecycle, or untrusted-content barriers.\n- When writing or reviewing the `agents\u002FGoal-Run.agent.md` \u002F `agents\u002Fgoal-run.md` shared body and shell, or the customer-experience (CE) surface-class doc ([skills\u002Fcustomer-experience\u002Freferences\u002Fgoal-run-surface-classes.md](..\u002Fcustomer-experience\u002Freferences\u002Fgoal-run-surface-classes.md), 874-D8) and dual-flow guide that reference this skill.\n- When building the escape-rate segmentation query described in `## Label-To-Ledger Join`.\n- When a reader needs to know what a `goal-run-stage-{issue}`, `goal-run-inflight-{issue}`, or `goal-halt-report-{issue}` marker means.\n\n### DO NOT USE FOR\n\n- **Running `\u002Fgoal-run` itself** — that is `agents\u002FGoal-Run.agent.md` (shared body) and `agents\u002Fgoal-run.md` (Claude Code shell). This skill is the reference the body cites, not a substitute for it.\n- **The goal-contract's own shape** (targets, halt conditions, evidence obligations) — that schema lives under `skills\u002Fplan-authoring\u002Fschemas\u002Fgoal-contract.schema.json` (872-D2).\n- **General adversarial-review, CE Gate (Customer Experience Gate — the validation step confirming an implementation achieves the intended customer experience), or PR-persistence mechanics** — the Post-Loop Chain (below) reuses `adversarial-review`, `customer-experience`, and `persist-changes` unchanged; load those skills directly for their own methodology.\n\n## Purpose\n\nA goal-run invocation must survive a crash or a second concurrent launch attempt without losing track of where it is or double-provisioning a worktree. Every stage transition, halt, and terminal check is therefore read from durable GitHub artifacts — never from what a conversation remembers saying — and every function that makes one of these decisions is a tested PowerShell primitive under `.github\u002Fscripts\u002Flib\u002Fgoal-run-*-core.ps1`, not inline arithmetic in the agent prose.\n\n## Stage-Machine Contract\n\nThe stage-machine's WRITTEN marker vocabulary — the value actually persisted to the `goal-run-stage-{Issue}` comment — is a fixed four-value sequence (`$script:GoalRunStageOrder` in [goal-run-stage-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-stage-core.ps1)):\n\n`pre-loop -> loop-launched -> loop-released -> chain-dispatched`\n\n`pre-loop` is the implicit starting state — no marker is ever posted for it on its own, and (M17 fix) the stage-marker writer's own `ValidateSet` excludes it, reconciling it against the reader's `ExplicitStageMarker` `ValidateSet` (`Resolve-GoalRunResumeStage`), which never accepted it either. A single `\u003C!-- goal-run-stage-{issue} -->` issue comment is upserted in place (never appended-to) and always reflects the latest completed stage. This is deliberately the coarse top-level enum a resumed invocation switches on; finer-grained per-attempt history (why a run deviated, what it checkpointed) lives in the typed run log and the mutex marker, not here. Since the M10 fix, this marker also carries the provisioned worktree path (`-WorktreePath` on `Set-GoalRunStageMarker`), so a resuming invocation reads it directly off the marker instead of an undefined \"most recent worktree\" filesystem search.\n\n`Resolve-GoalRunResumeStage`'s returned `.ResumeStage` vocabulary is a superset of the four written values above: it adds a fifth, resolver-only value, `loop-interrupted`, that is never itself written to the stage marker — the function derives it purely from the durable signals below when an earlier session's `loop-launched` marker never reached `loop-released`. `Resolve-GoalRunResumeStage` decides where a resumed invocation re-enters, in this precedence (highest wins):\n\n1. Contract hash not verified against the launch-pinned value -> `blocked` (not a stage to execute — report and stop; the contract needs plan-side remediation).\n2. Terminal emissions already verified on a known PR -> `complete` (nothing left to do).\n3. Explicit stage marker is `chain-dispatched` or `loop-released` -> resume at `chain-dispatched` (the loop already released; only the chain remains).\n4. Explicit stage marker is `loop-launched` -> resolve to `loop-interrupted`, not literally `loop-launched`: a prior session launched the vendor loop and this resuming session has no live transcript to read a release verdict from, so the loop's true outcome must be reconstructed from durable state (see `agents\u002FGoal-Run.agent.md`'s `### loop-interrupted (resume without a transcript)` section).\n5. No explicit marker, but the typed run log has a `checkpoint`\u002F`deviation`\u002F`experience-observation` entry -> also `loop-interrupted`, for the same reason — the loop ran even though no explicit marker was ever written (e.g. a crash between launch and the next marker).\n6. `goal-run-active.json` exists but no run-log evidence -> `loop-launched` — the worktree was provisioned but the loop itself was never launched.\n7. A mutex marker exists but nothing else -> `pre-loop` (crash mid `pre-loop`).\n8. Nothing present -> `pre-loop` (fresh launch).\n\n`blocked` and `complete` are terminal reports, not stages a resumer executes — report and stop. `loop-interrupted`, unlike those two, IS a stage a resumer executes: its stage-machine section re-validates the committed worktree state directly, then either discovers the interrupted loop's work was already satisfied, relaunches the loop in the same worktree if it is genuinely dead, or reports a still-live run under a different session — it never just reports and stops.\n\n## Halt Model And Precedence\n\nA halt report is a closed, five-value-enum object validated against [`skills\u002Fgoal-run\u002Fschemas\u002Fgoal-halt-report.schema.json`](schemas\u002Fgoal-halt-report.schema.json) (`additionalProperties: false` — every field the harness or an executor can populate is named and typed). The `halt_reason` enum is reused verbatim from the goal-contract schema's `halt_conditions` (872-D2): `unachievable-target`, `invariant-conflict`, `budget-exhausted`, `gate-input-needed`, `chain-stage-failure`.\n\nWhen more than one halt condition is true at the same evaluation point, `Resolve-GoalRunHaltPrecedence` ([goal-run-chain-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-chain-core.ps1)) picks the single winner by this **total, non-negotiable** order (highest wins):\n\n`invariant-conflict > unachievable-target > gate-input-needed > budget-exhausted > chain-stage-failure`\n\nThis ordered list is the entire precedence rule; nothing else in the file overrides it. `Resolve-GoalRunHaltPrecedence` does not itself decide *whether* a condition is true — each producer's own detection lives elsewhere (the launch-pinned contract-hash mismatch and an executor's own halt-claim for `invariant-conflict`; the re-validation disposition, the fix-cycle cap, or a stage crash for `chain-stage-failure`; the wall-clock backstop for `budget-exhausted`; the chain-gate demand for `gate-input-needed`) — callers pass in the already-decided booleans.\n\nA single-condition halt (nothing else co-occurring, e.g. the loop-released bounded-retry exhaustion) skips `Resolve-GoalRunHaltPrecedence` entirely and goes straight to the report builder — the precedence function only matters when two or more producers are simultaneously true.\n\nNever hand-build a halt comment. `New-GoalRunChainHaltReport` composes the schema-shaped object (running every free-text field through secret redaction, below); `Invoke-GoalRunHaltEmit` ([goal-run-halt-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-halt-core.ps1)) schema-validates and refuses to post an invalid report.\n\n## Launch Arms\n\n### Arm I (in-session) — the only arm implemented in this PR\n\n`\u002Fgoal-run {issue}` is both launcher and resumer. The harness verifies the contract hash, posts a mutex marker (`goal-run-inflight-{issue}`) *before* provisioning any worktree so a running worktree with no live marker can never exist, tiebreaks a concurrent launch race by lowest comment id, then sets the goal on itself and becomes the executor inside the freshly provisioned worktree. When the vendor `\u002Fgoal` loop completes and control genuinely returns to the harness session, it reads the now-flushed `goal_status` verdict and enters the Post-Loop Chain (re-validate, CE Gate, adversarial review, capped fix cycles, PR creation with classing — see [agents\u002FGoal-Run.agent.md](..\u002F..\u002Fagents\u002FGoal-Run.agent.md) `## Post-Loop Chain` for the full stage-by-stage prose).\n\nThe loop-to-chain seam is deliberately built from durable artifacts only: `New-GoalRunExecutorSessionHandle` and `Invoke-GoalRunLaunchChain` take an issue number, repo root, contract hash, worktree path, and a session handle — never live conversation context — so a future arm can populate the same shapes without rewriting this transition.\n\n### Arm H (headless) — PR-2, not yet implemented\n\nA future PR will let the harness supervise an externally polled `claude -p` process instead of running in-session. The loop-to-chain seam above is already shaped to accept this without a rewrite. No further design decisions have been made yet; do not invent Arm H behavior beyond this pointer.\n\n### Arm M (manual hand-off) — PR-2, not yet implemented\n\nA future PR will define a manual two-block rendering surface for a human to hand off a run. This PR renders no Arm M output and accepts no `scope_boundaries` prompt field. No further design decisions have been made yet; do not invent Arm M behavior beyond this pointer.\n\n## Worktree Lifecycle\n\nAll worktree mechanics live in [goal-run-worktree-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-worktree-core.ps1); its own header comment is the authoritative function-by-function summary — this section is a pointer, not a re-derivation.\n\n- **Provision** — `New-GoalRunWorktree` refuses a dirty tree first, then creates a named branch `goal-run\u002Fissue-{N}-{token}` (`{token}` is a GUID-style collision-proof suffix, so two concurrent runs for the same issue never collide) at a short root outside the checkout, setting `core.longpaths` at `worktree add`.\n- **State file** — `New-GoalRunActiveState` writes `goal-run-active.json` at the worktree root: ceilings, baseline, arm, executor session id, the launch-pinned `contract_hash`, `launched_at`, a `heartbeat_at` timestamp (seeded equal to `launched_at`), and `teardown_deferred` (default `false`). `Get-GoalRunActiveState` reads it back and returns `$null` on a missing file rather than throwing. `Update-GoalRunActiveStateHeartbeat` refreshes `heartbeat_at` — wired live (M5 fix) via `Invoke-GoalRunChainStageBoundaryHousekeeping` ([goal-run-budget-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-budget-core.ps1)) at every chain-stage boundary and at the loop-release point; before that fix the function existed and was tested but had zero live callers.\n- **Run log** — `goal-run-log.jsonl` at the worktree root (alongside `goal-run-active.json`), one JSON object per line, each independently validated against [`schemas\u002Fgoal-run-log.schema.json`](schemas\u002Fgoal-run-log.schema.json) before it is appended. `Add-GoalRunLogEntry` ([goal-run-log-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-log-core.ps1), M9 fix) is the schema-validating writer; `Test-GoalRunLogHasCheckpoint` is the reader `Resolve-GoalRunResumeStage`'s `-RunLogHasCheckpoint` parameter is actually fed from (Invocation Contract step 3). A `checkpoint` entry is written at every chain-stage boundary via the same `Invoke-GoalRunChainStageBoundaryHousekeeping` call named above.\n- **Teardown** — `Remove-GoalRunWorktree` retries `git worktree remove` with backoff on every exit path and diagnoses the outcome honestly across the same six-value vocabulary used by the session-startup cleanup detector: `removed`, `removed-partial-root-held`, `removed-partial-content-remains`, `stale-registration`, `failed`, `verification-indeterminate`. On retry exhaustion it sets `teardown_deferred: true` on the state file (best-effort) rather than throwing. It never force-removes a locked worktree on a `prunable` porcelain flag alone — only on `Test-Path`-verified absence of the directory, because real git never sets `prunable` on a locked worktree.\n\n## Label-To-Ledger Join (874-D7)\n\nEvery goal-run PR carries two machine-readable markers of its own provenance, both written at PR-creation time by `Invoke-GoalRunClassEmission` ([goal-run-chain-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-chain-core.ps1)):\n\n- The `goal-run` GitHub PR label, applied by `Add-GoalRunPrLabel`.\n- A `goal_run_class` scalar field (default value `goal-run`) plus a `goal_run_issue` field, folded into the PR body's `\u003C!-- pipeline-metrics -->` block through the existing `Invoke-PipelineMetricsV4Emit` primitive. Both fields are additive-safe: a reader that does not know about them silently ignores them.\n\n**The join key is `goal_run_class` (or, equivalently, the `goal-run` label) on the PR side.** A future escape-rate query segments the frame-credit-ledger's per-PR review-defect counts by joining on that key: PRs where `goal_run_class == 'goal-run'` (or carrying the `goal-run` label) are goal-run-produced; every other PR in the ledger is Code-Conductor-orchestrated. No query tool exists yet — this section documents the join key and the intended analysis shape (per-PR defect count grouped by goal-run vs. non-goal-run) so a future maintainer can write it directly against the ledger and `gh pr list --label goal-run` without re-deriving which field to key on.\n\n## Untrusted-Content Discipline (M4\u002FM5\u002FM12)\n\nThree separate guardrails stand between content the harness does not fully trust — a transcript event, a live issue comment that could have been edited after launch, or executor-supplied evidence text — and any durable artifact the harness writes:\n\n- **Launch-pinned contract-hash check** (step 5, wired live by the M1 fix) — `Test-GoalRunContractHashPinned` ([goal-run-prompt-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-prompt-core.ps1)) compares the *live* issue-body contract hash against the hash pinned at launch time, not the contract's own self-reported `contract_hash` field — this catches a post-approval edit that kept its own field internally consistent. A mismatch is the highest-precedence halt producer, `invariant-conflict`. Three live call sites actually run this check: the vendor `\u002Fgoal` loop predicate ([goal-run-predicate.ps1](..\u002F..\u002F.github\u002Fscripts\u002Fgoal-run-predicate.ps1) \u002F [goal-run-predicate-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-predicate-core.ps1), on every loop iteration, via `Resolve-GoalRunLoopPredicate`), chain re-validation (`Invoke-GoalRunChainRevalidate`'s `-LaunchPinnedHash` parameter, [goal-run-chain-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-chain-core.ps1)), and resume-time verification (the `agents\u002FGoal-Run.agent.md` Invocation Contract step 1). Before the M1 fix, the function existed and was tested but had zero live callers.\n- **Transcript allow-list + secret-redaction pass** (step 1) — `Select-GoalRunAllowedFields` ([goal-run-transcript-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-transcript-core.ps1)) copies only explicitly named keys out of a raw transcript event and also rejects a nested dictionary or non-string enumerable found under an allow-listed key name, so a poisoned event cannot smuggle structured content in under a trusted key. `Get-GoalRunRedactedText` then runs a fixed set of secret-shaped regexes (GitHub\u002FAWS\u002FSlack tokens, PEM private-key blocks, bearer tokens, generic `key=value` secret assignments) over any string headed for a durable artifact, replacing each match with a `[REDACTED:\u003Cpattern-name>]` placeholder.\n- **Executor-evidence inert-render discipline** (step 1) — `ConvertTo-GoalRunInertEvidenceText` ([goal-run-halt-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fgoal-run-halt-core.ps1)) strips marker-delimiter substrings out of `evidence[]`\u002F`plan_remediation` text before a halt report is posted, so executor-authored text cannot smuggle a live `\u003C!-- ... -->` marker literal into a durable comment. `Invoke-GoalRunHaltEmit` applies this and schema-validates before ever posting — it is never bypassed by constructing a raw comment string.\n\nAny transcript-derived or executor-supplied string reaching a halt report or a PR body fragment must already have passed through the allow-list extractor and the redaction pass; the halt-report schema's closed shape (`additionalProperties: false`) cannot itself enforce that upstream discipline, only the field shape.\n\n## Gotchas\n\n| Trigger | Gotcha | Fix |\n| --- | --- | --- |\n| Polling `stream-json` stdout for the loop's release verdict | `goal_status` is transcript-only and never reaches `stream-json` stdout on either platform (goal-loop-capability-probe finding) — a harness watching stdout is blind to release | Only read the verdict after control genuinely returns to the harness session, via `Resolve-GoalRunControlReturn`'s bounded transcript retry |\n| Calling `Resolve-GoalRunHaltPrecedence` on every halt | The function only matters when two or more of the five producers are true at once | A single-condition halt (e.g. loop-released retry exhaustion) goes straight to the report builder |\n| Assuming a `chain-dispatched` marker on resume means work remains | A PR that already carries both the `goal-run` label and the classing metrics is genuinely complete | Call `Test-GoalRunPrEmissionsVerified` against the run's known PR before assuming any work remains |\n\n## Release-Hygiene Note\n\nThis file and its `schemas\u002F*.json` siblings sit under `skills\u002F*`, one of the bare glob patterns `Get-FVPluginEntryPointPatterns` ([frame-predicate-core.ps1](..\u002F..\u002F.github\u002Fscripts\u002Flib\u002Fframe-predicate-core.ps1)) classifies as a cache-keyed plugin entry point — any path under `skills\u002F**` counts, not just files with a sibling `SKILL.md`. Claude Code's plugin cache is keyed by the `version` in `.claude-plugin\u002Fplugin.json`; a same-version reinstall keeps serving whatever entry-point snapshot that version last had. This file is a new entry point added after this PR's step-4 version bump already landed, so it requires its own coalesced `bump-version.ps1` bump — see this step's dispatch report for the resulting version.\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Fgoal-run",0,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002FGrimblaz","2026-08-16 01:12:46",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add Grimblaz\u002Fagent-orchestra --skill goal-run",{"tool":64,"command":65},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill goal-run",{"tool":67,"command":68},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill goal-run","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fgoal-run\u002FSKILL.md",true,[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"schemas\u002Fgoal-halt-report.schema.json","REFERENCE","参考文档",4922,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fgoal-run\u002Fschemas\u002Fgoal-halt-report.schema.json",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"schemas\u002Fgoal-run-log.schema.json",3693,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fgoal-run\u002Fschemas\u002Fgoal-run-log.schema.json",[83,116,138,153,179,199],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":97,"publishedAt":46},"01M6C48YMJVFHM7DVGG1WWW5RJ","webapp-testing","Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[89,94],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":95,"categoryName":96,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000009","前端开发",[98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,39,113,114,115,32],"testing","webapp testing","webapp","canvas","tdd","workflow","playwright","test","web","react","component","debugging","development","browser","ci","e2e","game","coverage",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":46},"01M6C48TNNP2KCSQXV8YK7SK49","verification-before-completion","Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any \"I'm finished\" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[123,124,125,126,127,128,129,130,27,44,131,132,112,36,133,134,135,32,136,137],"verification","verification before completion","review","change","commit","merge","pr","cleanup","code-review","intake","verification loop","work","check","evidence","campaign",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":46},"01M6C48QZWNTP7JGKD32QZAKKX","validation-methodology","Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fvalidation-methodology\u002FSKILL.md",[],[145,40,146,125,147,148,149,150,44,151,39,32,152],"validation","validation methodology","triage","orchestration","setup","adversarial review","flow","dispatch",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":165,"publishedAt":46},"01M6C48MCAHG5Z79BJ369CRYRZ","upstream-onboarding","Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fupstream-onboarding\u002FSKILL.md",[159,162],{"categoryNo":160,"categoryName":161,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":163,"categoryName":164,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000038","人力资源",[166,167,125,168,169,128,170,129,44,171,172,173,174,175,176,134,135,177,178,32],"onboarding","upstream onboarding","github","research","standards check","protocol","brief","boundary","designer","subagent","planner","user","session",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":193,"publishedAt":46},"01M6C48GPVE120TGPMD1CS365H","ui-testing","Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-testing\u002FSKILL.md",[185,186,187,190],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},{"categoryNo":95,"categoryName":96,"taxonomyType":92,"taxonomyTypeDesc":93},{"categoryNo":188,"categoryName":189,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":191,"categoryName":192,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000032","设计师",[98,194,195,196,197,37,101,103,104,105,107,108,109,110,111,198,113,114,32,100],"ui","ui testing","frontend","design","testing patterns",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":207,"publishedAt":46},"01M6C48DRJ9XBDR2FW0W37DY53","ui-iteration","Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-iteration\u002FSKILL.md",[205,206],{"categoryNo":95,"categoryName":96,"taxonomyType":92,"taxonomyTypeDesc":93},{"categoryNo":191,"categoryName":192,"taxonomyType":20,"taxonomyTypeDesc":21},[194,208,196,197,125,103,209,44,210,211,212,213,214,134,215,216,32,217],"ui iteration","accessibility","screenshot","Tailwind","polish","ui polish","feedback","redesign","strategy","only"]