[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D343DR03THN61TF0FNTGMP":3,"skill-same:01M6D343DR03THN61TF0FNTGMP":66},{"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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":47,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6D343DR03THN61TF0FNTGMP","benchmark-agent-review",null,"Review persisted benchmark run outputs with one or more agent graders and report subjective ergonomic quality separately from deterministic benchmark scores","GeorgeQLe\u002Fagentic-skills","GeorgeQLe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F21134126?v=4","01M6D2JP418S0VGJGF8M93EC3H","George Le","01M6D2JPBAKYD82TA5FS6HKQ3D",1,"MIT","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fagentic-skills-bench\u002Fcodex\u002Fbenchmark-agent-review\u002Farchive\u002Fv0.0\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34],"review","benchmark","benchmark agent review","codex","run","report","analysis","skill name","quality","v0","deterministic","2026-11-10 10:12:30",false,"---\nname: benchmark-agent-review\ndescription: Review persisted benchmark run outputs with one or more agent graders and report subjective ergonomic quality separately from deterministic benchmark scores\ntype: analysis\nversion: v0.0\nargument-hint: \"\u003Cskill name or run path> [--reviewers codex,claude] [--runs N]\"\n---\n\n# Benchmark Agent Review\n\nInvoke as `$benchmark-agent-review \u003Cskill-or-run-path>`.\n\nUse this skill after `$benchmark-test-skill \u003Cskill>` when the deterministic benchmark passed but the user wants agent judgment on whether the generated artifacts are actually excellent, ergonomic, and useful for the next operator.\n\nThis skill is a follow-up review workflow. It does not replace hard benchmark assertions, deterministic output-quality rubrics, or verify\u002Fbench commands.\n\nThe primary object of review is the generated skill output, not the benchmark harness. Treat hard assertions and deterministic output-quality scores as context and triage signals only. Lead with whether each retained output is excellent, good, usable, weak, or failing under the agent-review rubric; discuss deterministic rubric tightening only after output-quality findings, and only when it would help future triage surface the same output-quality issue.\n\n## Input\n\n- Required: a benchmark target skill name such as `run`, or a raw run directory such as `tests\u002Fbenchmarks\u002Fruns\u002Frun-codex-47e0dd54\u002F`.\n- Optional: `--reviewers codex,claude` to request named reviewer families when both outputs are available.\n- Optional: `--runs N` to request multiple independent review passes. Default to 3 when practical; use 1 when only one reviewer pass is available in the active environment.\n\n## Workflow\n\n1. Resolve benchmark evidence:\n   - If the input is a run directory, inspect that directory.\n   - If the input is a skill name, find the newest matching directories under `tests\u002Fbenchmarks\u002Fruns\u002F\u003Cskill>-*\u002F`.\n   - Prefer the latest Claude and Codex run directories when both exist.\n   - Read `report.md`, `report.json`, each `run-*.json`, and any persisted generated artifact content visible in stdout\u002Fstderr or file snapshots.\n   - If generated artifact content is not fully available, state that limitation and grade only the retained evidence.\n\n2. Extract outputs under review:\n   - Identify the artifact path the benchmark expected, such as `run-plan.md` or `benchmark\u002Ftest-*.md`.\n   - Extract the generated artifact text when available.\n   - Preserve runner identity, run index, hard assertions, deterministic quality score, and infrastructure-blocked status.\n   - Exclude infrastructure-blocked runs from subjective scoring.\n\n3. Build the review packet:\n   - Include the original benchmark prompt.\n   - Include the benchmark fixture facts.\n   - Include the output artifact text or retained summary.\n   - Include hard assertions and deterministic quality scores for context.\n   - Include the target skill contract only when needed to judge ergonomics.\n\n4. Grade each evaluated output with this rubric:\n   - **Task selection clarity**: the selected work is unambiguous and traceable to fixture evidence.\n   - **Implementation specificity**: the output gives a next operator concrete enough steps to act without redoing basic discovery.\n   - **Validation strength**: proposed checks prove behavior or artifact quality, not just file existence or generic completion.\n   - **Scope control**: the output respects the fixture and user constraints without becoming timid or incomplete.\n   - **Next-route ergonomics**: the next command is correct for the runner mode and explains what it will do.\n   - **No invented facts**: the output avoids unsupported services, files, metrics, commands, deploys, or repository claims.\n   - **Residual-risk awareness**: the output names meaningful uncertainty, missing evidence, or follow-up risk when relevant.\n\n5. Score:\n   - Use a 0-100 integer score per reviewed output.\n   - Treat 90-100 as excellent, 80-89 as good, 70-79 as usable but meaningfully incomplete, 60-69 as weak, and below 60 as failing human review.\n   - When multiple review passes are available, report median score, score range, and common findings.\n   - Do not blend subjective scores into hard assertion pass rate or deterministic quality score.\n\n6. Optional multi-reviewer handling:\n   - Use subagents only when the active Codex tool instructions permit them and the user explicitly requested multiple agent review passes.\n   - Assign each reviewer one independent grading pass over the same review packet.\n   - Do not let reviewers edit repository files.\n   - Synthesize reviewer findings into a normalized score table.\n\n7. Write the report:\n   - Create `benchmark\u002Freview-\u003CSKILL>-\u003CYYYY-MM-DD>.md` when the input resolves to a skill.\n   - Create `benchmark\u002Freview-\u003CRUN-DIR-NAME>-\u003CYYYY-MM-DD>.md` when the input is one run directory.\n   - If the review is exploratory and the user asks for chat-only output, do not write a file.\n\n8. Build the remediation handoff:\n   - Convert every material weakness into a remediation target instead of stopping at broad advice.\n   - Classify each target as target-skill contract, benchmark rubric, retained-evidence gap, harness\u002Fsetup issue, or one-off run behavior.\n   - Name the exact owner file, skill contract, benchmark setup, or report artifact when known; when the exact file is not proven, name the narrowest known owner surface and state the lookup needed to confirm it.\n   - Propose the exact contract, rubric, fixture, or evidence-capture behavior to add or tighten; avoid vague changes such as \"update the skill\" without naming the behavior that changes.\n   - Include the validation command or contract-lint assertion that would prove the issue is fixed; a focused fixture rerun is acceptable only when it names the expected assertion or artifact-quality behavior.\n   - When retained artifact text contains placeholder risk, monitoring, validation, or known-unknown sections such as `Not captured`, `Not specified`, `TBD`, `None`, or `N\u002FA`, the remediation must identify the owner target that should reject or repair that placeholder and the validation check that would fail before the fix.\n   - Choose one definitive next route from the highest-impact verified remediation; do not leave the next operator to choose among generic options.\n\n## Output\n\nReport:\n\n- Source benchmark report paths.\n- Reviewed run directories and run indexes.\n- Hard assertion pass rate and deterministic output-quality score from the benchmark report.\n- Output-quality verdict against the agent-review rubric, explicitly focused on the generated skill artifacts rather than the benchmark's ease or strictness.\n- Agent-review score table with reviewer, runner, run index, score, and grade band.\n- Median subjective score and score range when multiple scores exist.\n- Common strengths.\n- Common weaknesses.\n- Remediation table with finding, classification, owner target, proposed change, validation check, and route.\n- Remediation rows must be implementation-ready: each material finding needs a concrete owner target, a proposed behavior change, and a validation check or command. Broad rows like \"tighten the rubric\" or \"update the skill\" are incomplete unless they also name the owning file\u002Fsurface, exact behavior, and proof.\n- Optional deterministic-rubric notes only when the retained output-quality findings show the deterministic rubric failed to surface a meaningful issue or produced misleading context.\n- **Next work:** the one definitive remediation selected from the remediation table, or no follow-up when all evaluated outputs are excellent and no meaningful issue remains.\n- **Recommended next command:** one command derived from that remediation, usually `$targeted-skill-builder \u003Cskill> \u003Cspecific output-quality gap>`, `$targeted-skill-builder \u003Cbenchmark setup or reviewed skill> \u003Cspecific rubric gap>`, `$session-triage \u003Cskill> benchmark review`, or `$ship` only when no remediation is needed.\n\n## Alignment Page\n\nWhen this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page at `alignment\u002Fbenchmark-agent-review-{topic}.html`. Use a normalized topic slug derived from the app, feature, research subject, report subject, or output filename.\n\n**Full content requirement.** The alignment page must contain the complete content of every proposed markdown deliverable -- every section, every finding, every detail, every list item. It is a thorough interactive review document, not a summary. Render the full deliverable content in clean, readable HTML with appropriate hierarchy, styling, and navigation. If the skill writes multiple scoped deliverables in one run, build one alignment page that contains all deliverables with anchor-linked navigation. Durable tracker artifacts, such as `research\u002Fassumption-tracker.md`, remain canonical markdown outputs but must also be fully rendered into the alignment page before approval.\n\n**Dark-mode styling.** Use a dark color scheme by default. Base CSS variables: `--bg: #0d1117; --surface: #161b22; --border: #30363d; --text: #c9d1d9; --text-muted: #8b949e; --accent: #58a6ff; --green: #3fb950; --red: #f85149; --orange: #d29922; --purple: #bc8cff;`. Apply `background: var(--bg); color: var(--text);` on body. Use `--surface` for cards, nav, and table headers. Use `--border` for all borders. Use `--purple` for question blocks and gate headings. Use `--accent` for links and section headings. Keep headings `color: #fff` or `var(--accent)` for hierarchy. Question block backgrounds should use `#1c2333`.\n\n**Alignment gates.** Treat gates as explicit review sections inside the HTML page. A gate blocks finalization until its required inline questions are answered and compiled into YAML. Include every gate that applies to the skill output, and include these gate types whenever relevant: evidence coverage, assumptions\u002Fconfidence, scope\u002Fnon-goals, candidate\u002Fverdict decisions, artifact destination, proposed file changes, coverage checkpoint, and post-approval route.\n\n**Report-only research gates.** For report-only or pre-approval research skills, the alignment page must explicitly contain evidence coverage, assumptions\u002Fconfidence, recommended path, proposed file changes, and approval gates before any canonical research, spec, or task file is created or updated.\n\n\n**Required inline questions.** Each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: \"Other \u002F None of the above\" backed by a multi-line text box for free-form input, and \"Need clarification\" backed by an optional notes box where the user can explain what is unclear. When any radio option other than \"Other\" or \"Need clarification\" is selected, show an optional \"Additional notes\" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom \"Decisions & Clarifications\" section.\n\n**Gate YAML contract.** At the bottom of the page, include a \"Compile Answers\" button that aggregates answers from all inline gate questions throughout the page, including free-text notes. The button remains disabled until every required question has a selection, shows a count of remaining unanswered questions, and scrolls to the first unanswered question if clicked early. When every question is answered, generate a structured YAML block with one item per gate answer using this stable shape: `section`, `gate_type`, `status` (`answered`, `other`, or `needs-clarification`), `answer`, optional `notes`, and optional `target_artifact` or `target_path` when the gate controls file output. After successful compilation, automatically attempt to copy the YAML to the clipboard with the Clipboard API, display copy status, and display the YAML in a read-only textarea with an explicit \"Copy YAML\" button. The copy button must retry clipboard copy when supported and fall back to selecting the textarea contents when clipboard access is unavailable or blocked.\n\n**Pre-approval stop.** Before user approval, the next action is review of the HTML alignment page, not downstream routing. Ask the user to review the page and provide the compiled YAML answers. Do not include `Recommended next skill`, `Recommended next command`, or downstream routing language until after compiled YAML has been provided and the approved artifacts have been written or updated.\n\n**Diff highlighting on updates.** When the agent updates an existing alignment page after receiving compiled answers, highlight what changed since the previous version. The agent chooses inline annotation or side-by-side layout per situation.\n\n**Archiving.** Before replacing an existing alignment page, archive it to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002Falignment\u002Fbenchmark-agent-review-{topic}.html`.\n\n**Browser open.** Attempt to open the resulting HTML page in the browser and report whether the open succeeded or was blocked. A blocked browser-open attempt does not make the skill fail when the files were written correctly.\n\n## Constraints\n\n- Do not re-run `$benchmark-test-skill` unless the requested benchmark artifacts are missing or stale and the user explicitly asks for a fresh benchmark.\n- Do not present subjective agent-review scores as statistically definitive.\n- Do not merge subjective scores into deterministic output-quality scores.\n- Do not frame benchmark pass\u002Ffail laxness as the primary problem when the task is to judge skill output quality. If the benchmark intentionally passes weak-but-compliant outputs, grade the output quality directly and use deterministic-rubric notes only as supporting context.\n- Do not grade infrastructure-blocked runs as skill outputs.\n- Do not fabricate missing artifact content. State when only stdout summaries, assertions, or quality results are available.\n- Do not collapse multiple material weaknesses into a vague handoff such as \"tighten the rubric\"; the remediation table must preserve the responsible target, exact behavior change, and validation check for each issue.\n- Do not create or modify GitHub Actions workflows.\n","# Benchmark Agent Review\n\nInvoke as `$benchmark-agent-review \u003Cskill-or-run-path>`.\n\nUse this skill after `$benchmark-test-skill \u003Cskill>` when the deterministic benchmark passed but the user wants agent judgment on whether the generated artifacts are actually excellent, ergonomic, and useful for the next operator.\n\nThis skill is a follow-up review workflow. It does not replace hard benchmark assertions, deterministic output-quality rubrics, or verify\u002Fbench commands.\n\nThe primary object of review is the generated skill output, not the benchmark harness. Treat hard assertions and deterministic output-quality scores as context and triage signals only. Lead with whether each retained output is excellent, good, usable, weak, or failing under the agent-review rubric; discuss deterministic rubric tightening only after output-quality findings, and only when it would help future triage surface the same output-quality issue.\n\n## Input\n\n- Required: a benchmark target skill name such as `run`, or a raw run directory such as `tests\u002Fbenchmarks\u002Fruns\u002Frun-codex-47e0dd54\u002F`.\n- Optional: `--reviewers codex,claude` to request named reviewer families when both outputs are available.\n- Optional: `--runs N` to request multiple independent review passes. Default to 3 when practical; use 1 when only one reviewer pass is available in the active environment.\n\n## Workflow\n\n1. Resolve benchmark evidence:\n   - If the input is a run directory, inspect that directory.\n   - If the input is a skill name, find the newest matching directories under `tests\u002Fbenchmarks\u002Fruns\u002F\u003Cskill>-*\u002F`.\n   - Prefer the latest Claude and Codex run directories when both exist.\n   - Read `report.md`, `report.json`, each `run-*.json`, and any persisted generated artifact content visible in stdout\u002Fstderr or file snapshots.\n   - If generated artifact content is not fully available, state that limitation and grade only the retained evidence.\n\n2. Extract outputs under review:\n   - Identify the artifact path the benchmark expected, such as `run-plan.md` or `benchmark\u002Ftest-*.md`.\n   - Extract the generated artifact text when available.\n   - Preserve runner identity, run index, hard assertions, deterministic quality score, and infrastructure-blocked status.\n   - Exclude infrastructure-blocked runs from subjective scoring.\n\n3. Build the review packet:\n   - Include the original benchmark prompt.\n   - Include the benchmark fixture facts.\n   - Include the output artifact text or retained summary.\n   - Include hard assertions and deterministic quality scores for context.\n   - Include the target skill contract only when needed to judge ergonomics.\n\n4. Grade each evaluated output with this rubric:\n   - **Task selection clarity**: the selected work is unambiguous and traceable to fixture evidence.\n   - **Implementation specificity**: the output gives a next operator concrete enough steps to act without redoing basic discovery.\n   - **Validation strength**: proposed checks prove behavior or artifact quality, not just file existence or generic completion.\n   - **Scope control**: the output respects the fixture and user constraints without becoming timid or incomplete.\n   - **Next-route ergonomics**: the next command is correct for the runner mode and explains what it will do.\n   - **No invented facts**: the output avoids unsupported services, files, metrics, commands, deploys, or repository claims.\n   - **Residual-risk awareness**: the output names meaningful uncertainty, missing evidence, or follow-up risk when relevant.\n\n5. Score:\n   - Use a 0-100 integer score per reviewed output.\n   - Treat 90-100 as excellent, 80-89 as good, 70-79 as usable but meaningfully incomplete, 60-69 as weak, and below 60 as failing human review.\n   - When multiple review passes are available, report median score, score range, and common findings.\n   - Do not blend subjective scores into hard assertion pass rate or deterministic quality score.\n\n6. Optional multi-reviewer handling:\n   - Use subagents only when the active Codex tool instructions permit them and the user explicitly requested multiple agent review passes.\n   - Assign each reviewer one independent grading pass over the same review packet.\n   - Do not let reviewers edit repository files.\n   - Synthesize reviewer findings into a normalized score table.\n\n7. Write the report:\n   - Create `benchmark\u002Freview-\u003CSKILL>-\u003CYYYY-MM-DD>.md` when the input resolves to a skill.\n   - Create `benchmark\u002Freview-\u003CRUN-DIR-NAME>-\u003CYYYY-MM-DD>.md` when the input is one run directory.\n   - If the review is exploratory and the user asks for chat-only output, do not write a file.\n\n8. Build the remediation handoff:\n   - Convert every material weakness into a remediation target instead of stopping at broad advice.\n   - Classify each target as target-skill contract, benchmark rubric, retained-evidence gap, harness\u002Fsetup issue, or one-off run behavior.\n   - Name the exact owner file, skill contract, benchmark setup, or report artifact when known; when the exact file is not proven, name the narrowest known owner surface and state the lookup needed to confirm it.\n   - Propose the exact contract, rubric, fixture, or evidence-capture behavior to add or tighten; avoid vague changes such as \"update the skill\" without naming the behavior that changes.\n   - Include the validation command or contract-lint assertion that would prove the issue is fixed; a focused fixture rerun is acceptable only when it names the expected assertion or artifact-quality behavior.\n   - When retained artifact text contains placeholder risk, monitoring, validation, or known-unknown sections such as `Not captured`, `Not specified`, `TBD`, `None`, or `N\u002FA`, the remediation must identify the owner target that should reject or repair that placeholder and the validation check that would fail before the fix.\n   - Choose one definitive next route from the highest-impact verified remediation; do not leave the next operator to choose among generic options.\n\n## Output\n\nReport:\n\n- Source benchmark report paths.\n- Reviewed run directories and run indexes.\n- Hard assertion pass rate and deterministic output-quality score from the benchmark report.\n- Output-quality verdict against the agent-review rubric, explicitly focused on the generated skill artifacts rather than the benchmark's ease or strictness.\n- Agent-review score table with reviewer, runner, run index, score, and grade band.\n- Median subjective score and score range when multiple scores exist.\n- Common strengths.\n- Common weaknesses.\n- Remediation table with finding, classification, owner target, proposed change, validation check, and route.\n- Remediation rows must be implementation-ready: each material finding needs a concrete owner target, a proposed behavior change, and a validation check or command. Broad rows like \"tighten the rubric\" or \"update the skill\" are incomplete unless they also name the owning file\u002Fsurface, exact behavior, and proof.\n- Optional deterministic-rubric notes only when the retained output-quality findings show the deterministic rubric failed to surface a meaningful issue or produced misleading context.\n- **Next work:** the one definitive remediation selected from the remediation table, or no follow-up when all evaluated outputs are excellent and no meaningful issue remains.\n- **Recommended next command:** one command derived from that remediation, usually `$targeted-skill-builder \u003Cskill> \u003Cspecific output-quality gap>`, `$targeted-skill-builder \u003Cbenchmark setup or reviewed skill> \u003Cspecific rubric gap>`, `$session-triage \u003Cskill> benchmark review`, or `$ship` only when no remediation is needed.\n\n## Alignment Page\n\nWhen this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page at `alignment\u002Fbenchmark-agent-review-{topic}.html`. Use a normalized topic slug derived from the app, feature, research subject, report subject, or output filename.\n\n**Full content requirement.** The alignment page must contain the complete content of every proposed markdown deliverable -- every section, every finding, every detail, every list item. It is a thorough interactive review document, not a summary. Render the full deliverable content in clean, readable HTML with appropriate hierarchy, styling, and navigation. If the skill writes multiple scoped deliverables in one run, build one alignment page that contains all deliverables with anchor-linked navigation. Durable tracker artifacts, such as `research\u002Fassumption-tracker.md`, remain canonical markdown outputs but must also be fully rendered into the alignment page before approval.\n\n**Dark-mode styling.** Use a dark color scheme by default. Base CSS variables: `--bg: #0d1117; --surface: #161b22; --border: #30363d; --text: #c9d1d9; --text-muted: #8b949e; --accent: #58a6ff; --green: #3fb950; --red: #f85149; --orange: #d29922; --purple: #bc8cff;`. Apply `background: var(--bg); color: var(--text);` on body. Use `--surface` for cards, nav, and table headers. Use `--border` for all borders. Use `--purple` for question blocks and gate headings. Use `--accent` for links and section headings. Keep headings `color: #fff` or `var(--accent)` for hierarchy. Question block backgrounds should use `#1c2333`.\n\n**Alignment gates.** Treat gates as explicit review sections inside the HTML page. A gate blocks finalization until its required inline questions are answered and compiled into YAML. Include every gate that applies to the skill output, and include these gate types whenever relevant: evidence coverage, assumptions\u002Fconfidence, scope\u002Fnon-goals, candidate\u002Fverdict decisions, artifact destination, proposed file changes, coverage checkpoint, and post-approval route.\n\n**Report-only research gates.** For report-only or pre-approval research skills, the alignment page must explicitly contain evidence coverage, assumptions\u002Fconfidence, recommended path, proposed file changes, and approval gates before any canonical research, spec, or task file is created or updated.\n\n\n**Required inline questions.** Each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: \"Other \u002F None of the above\" backed by a multi-line text box for free-form input, and \"Need clarification\" backed by an optional notes box where the user can explain what is unclear. When any radio option other than \"Other\" or \"Need clarification\" is selected, show an optional \"Additional notes\" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom \"Decisions & Clarifications\" section.\n\n**Gate YAML contract.** At the bottom of the page, include a \"Compile Answers\" button that aggregates answers from all inline gate questions throughout the page, including free-text notes. The button remains disabled until every required question has a selection, shows a count of remaining unanswered questions, and scrolls to the first unanswered question if clicked early. When every question is answered, generate a structured YAML block with one item per gate answer using this stable shape: `section`, `gate_type`, `status` (`answered`, `other`, or `needs-clarification`), `answer`, optional `notes`, and optional `target_artifact` or `target_path` when the gate controls file output. After successful compilation, automatically attempt to copy the YAML to the clipboard with the Clipboard API, display copy status, and display the YAML in a read-only textarea with an explicit \"Copy YAML\" button. The copy button must retry clipboard copy when supported and fall back to selecting the textarea contents when clipboard access is unavailable or blocked.\n\n**Pre-approval stop.** Before user approval, the next action is review of the HTML alignment page, not downstream routing. Ask the user to review the page and provide the compiled YAML answers. Do not include `Recommended next skill`, `Recommended next command`, or downstream routing language until after compiled YAML has been provided and the approved artifacts have been written or updated.\n\n**Diff highlighting on updates.** When the agent updates an existing alignment page after receiving compiled answers, highlight what changed since the previous version. The agent chooses inline annotation or side-by-side layout per situation.\n\n**Archiving.** Before replacing an existing alignment page, archive it to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002Falignment\u002Fbenchmark-agent-review-{topic}.html`.\n\n**Browser open.** Attempt to open the resulting HTML page in the browser and report whether the open succeeded or was blocked. A blocked browser-open attempt does not make the skill fail when the files were written correctly.\n\n## Constraints\n\n- Do not re-run `$benchmark-test-skill` unless the requested benchmark artifacts are missing or stale and the user explicitly asks for a fresh benchmark.\n- Do not present subjective agent-review scores as statistically definitive.\n- Do not merge subjective scores into deterministic output-quality scores.\n- Do not frame benchmark pass\u002Ffail laxness as the primary problem when the task is to judge skill output quality. If the benchmark intentionally passes weak-but-compliant outputs, grade the output quality directly and use deterministic-rubric notes only as supporting context.\n- Do not grade infrastructure-blocked runs as skill outputs.\n- Do not fabricate missing artifact content. State when only stdout summaries, assertions, or quality results are available.\n- Do not collapse multiple material weaknesses into a vague handoff such as \"tighten the rubric\"; the remediation table must preserve the responsible target, exact behavior change, and validation check for each issue.\n- Do not create or modify GitHub Actions workflows.\n",{"name":5,"type":30,"version":40,"description":7,"argument-hint":41},"v0.0","\u003Cskill name or run path> [--reviewers codex,claude] [--runs N]","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fagentic-skills-bench\u002Fcodex\u002Fbenchmark-agent-review\u002Farchive\u002Fv0.0",0,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills","https:\u002F\u002Fagentic-skills-blush.vercel.app","https:\u002F\u002Fgithub.com\u002FGeorgeQLe","georgeqle.com","George Le is a futurist and serial tech entrepreneur who wants to work toward a world where humanity is free from robotic tasks.","2026-11-10 04:07:24",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill benchmark-agent-review",{"tool":58,"command":59},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill benchmark-agent-review",{"tool":61,"command":62},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill benchmark-agent-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fagentic-skills-bench\u002Fcodex\u002Fbenchmark-agent-review\u002Farchive\u002Fv0.0\u002FSKILL.md",true,[],[67,79,89,100,111,122],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":35},"01M6G0NJES15RJKZE6YZ0TSYGF","source-checkout-allowed","Valid source-checkout-only fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fsource-checkout-allowed\u002FSKILL.md",[],[74,75,76,77,33,78],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":35},"01M6G0NFZ3R1MNB1E3DVTM0WB7","deck-install-valid","Valid deck install fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fdeck-install\u002FSKILL.md",[],[86,87,88,78,76,33],"deck install valid","deck","install",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":35},"01M6G0ND3QZQC4MDZ9NVB97PT2","codex-pack-guard-valid","Valid Codex Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-pack-guard\u002FSKILL.md",[],[96,97,98,78,27,99,76,33],"codex pack guard valid","pack","guard","availability",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":107,"publishedAt":35},"01M6G0NA9YB3NKGZKD3S96JMNB","codex-missing-skill-valid","Valid Codex missing skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-missing-skill-fallback\u002FSKILL.md",[106],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[108,109,78,27,33,110,76],"codex missing skill valid","missing","fallback",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"publishedAt":35},"01M6G0N7PC0EKFD40ZWQAXSAQ9","codex-base-skill-fallback-valid","Valid Codex base skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-base-skill-fallback\u002FSKILL.md",[117],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[78,27,110,119,120,121,33,76],"base skill","codex base skill fallback valid","base",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":35},"01M6G0N4VRR2YKZQ6N3Y6S2BQA","claude-pack-guard-valid","Valid Claude Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fclaude-pack-guard\u002FSKILL.md",[],[78,98,97,129,99,33,76],"claude pack guard valid"]