[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C30SVXBRPDDN5YY9QNH507":3,"skill-same:01M6C30SVXBRPDDN5YY9QNH507":73},{"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":17,"publishedAt":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":40,"install":41,"resources":54},"01M6C30SVXBRPDDN5YY9QNH507","advice",null,"Hermes entry point for canonical advice and static-review: capability tiers, qualified quorum and complete revision-bound review.","jleechanorg\u002Fjleechan-skills","jleechanorg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F221404966?v=4","01M6C1VJ99XG950X1DWPEBCBGX","01M6C1VJDK5YVDNT3362RT5WSB",6,"MIT","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fadvice\u002FSKILL.md",[],[5,18,19,20,21,22,23,24,25,26,27],"review","hermes","static","revision","canonical","capability","point","for","complete","entry","2026-11-10 10:12:30",false,"---\nname: advice\nversion: 1.5.0\ndescription: \"Hermes entry point for canonical advice and static-review: capability tiers, qualified quorum and complete revision-bound review.\"\n---\n\n# \u002Fadvice — Token-Efficient Second Opinion (Hermes overlay)\n\n**This is the Hermes-side wrapper.** The canonical skill lives at:\n- `~\u002F.claude\u002Fskills\u002Fadvice\u002FSKILL.md` — quorum, dispatch order, fallback chain\n\n**Read the canonical file for the full procedure.** This overlay exists so that:\n1. `skill_view(name='advice')` works from the Hermes session (the canonical Claude skill is not registered in the Hermes skill registry).\n2. Future agents learn to **search both `~\u002F.hermes\u002Fskills\u002F` AND `~\u002F.claude\u002Fskills\u002F`** when a user invokes a `\u002Fslash` command — slash commands are not Hermes-native; they are Claude Code constructs.\n\n## Canonical reviewer contract\n\nThe canonical advice skill owns reviewer capabilities, risk-selected count,\ntier order and class caps. Static-review owns cold prompts, access-mode\npreambles, full pinned source coverage and receipts. Load both current owners;\nfill exactly the fields of advice §4's selected mode rather than assuming only\na URL\u002FSHA pair. This overlay supplies no separate prompt or dispatch policy.\nUse actual authorized accounts\u002Fcapabilities on the current host; preserve\ncomplete coverage, deadlines, identity deduplication and explicit outside\nrequirements. Missing an integration means UNAVAILABLE, not an improvised\nreview or approval.\n\n\n## When to use\n\nUser says `\u002Fadvice [optional question]`, or you reach a decision point that needs a second opinion without shipping the full conversation uncached.\n\n## Historical notes — not review-dispatch instructions\n\nThe legacy examples, templates, seat-availability claims and fanout recommendations below are preserved as\nhistorical context only. They do not authorize dispatch, establish current machine capability, supply a review\nprompt or override the canonical advice\u002Fstatic-review owners. For every live review, resolve current local\ncapabilities, quorum and tiers from the canonical skills above and use only static-review's current templates\nand transport preambles. Do not execute a historical command or request a named seat merely because it appears\nbelow.\n\n## Review types (added 2026-07-06)\n\nThe canonical `\u002Fadvice` SKILL.md describes the general-purpose \"extract decision + artifact, fan out 3 reviewers, synthesize\" pattern. For docs-accuracy reviews (e.g. \"are these merged docs accurate against the source?\"), use this specialized template — it produces far more useful verdicts than the generic one:\n\n### Docs-accuracy review template\n\n```markdown\n# \u002Fadvice Decision + Artifact\n\n## DECISION (3-5 sentences)\n[What specifically needs review — be concrete. For docs-accuracy:\n\"docs X\u002FY\u002FZ were merged in PR #N; need a second opinion on whether\nthe claims match the actual `src\u002F` code, whether the terminology\nis consistent across files, and whether anything was fabricated.\"]\n\n## ARTIFACT (≤150 lines, claim-bearing excerpts only)\n[Paste ONLY the claim-bearing sections from each doc, plus the\nload-bearing source files. Drop boilerplate, drop \"Install\" sections,\ndrop Config tables — they don't bear accuracy claims. If the docs\ntotal 800+ lines, summarize to ≤150 lines.]\n\n### Doc §\"\u003Csection name>\" — claim-bearing excerpts\n> [quote 1-3 sentences that make a verifiable claim]\n\n### Doc §\"\u003Csection name>\" — claims under review\n**L1 ...**: enforces X\n**L2 ...**: enforces Y\n**L3 ...**: enforces Z\n\n### Source: `src\u002F\u003Cfile>.rs::\u003Cfn>()`\n```rust\n[the actual source code that backs the claim]\n```\n\n## QUESTIONS FOR THE REVIEWER\n\n1. **[Specific factual claim]**: does doc say X? does code do X?\n2. **[Terminology consistency]**: are the terms used consistently?\n3. **[Missing callout]**: is there a case the doc should surface that\n   it doesn't? (e.g. macOS short-circuit, sudo escalation wording)\n4. **[Fabrication check]**: does any claim in the doc contradict\n   actual source?\n\n## DELIVERABLE\n\nReturn exactly:\nVERDICT: [docs accurate \u002F docs need fixes (list) \u002F docs misleading (explain)]\nREASONING: [3-4 sentences citing file:line evidence]\nRISK: [main risk if docs are wrong, one sentence]\nCONFIDENCE: [high \u002F medium \u002F low]\n\nPlus a numbered list of every inaccurate claim you found, each with:\ndoc-file:line, source-file:line, what the doc says vs what the code\nactually does.\n```\n\n**Why this template works (verified 2026-07-06, ez-gh-actions PR #9 review):**\n\n1. The \"QUESTIONS FOR THE REVIEWER\" numbered list forces the reviewer to\n   address each load-bearing claim explicitly instead of waving a hand\n   at \"looks accurate\".\n2. The 3 reviewer roles get differentiated goals:\n   - **Reviewer A (source accuracy)**: file:line citations from the docs\n     AND the source for each claim — every claim must trace to code.\n   - **Reviewer B (public docs)**: cross-reference with Docker\u002FColima\u002FQEMU\n     official docs, GitHub Security Lab research, kernel docs.\n   - **Reviewer C (internal consistency)**: terminology drift between\n     README\u002FDESIGN\u002FSVG\u002Fwiki\u002Froadmap, broken anchor links, jargon overload.\n3. The \"Plus a numbered list of every inaccurate claim you found\"\n   output format surfaces EVERY gap in one table — easier to synthesize\n   into a follow-up PR than prose paragraphs.\n4. The 150-line artifact budget forces distillation: only the claims\n   that matter go to the reviewer. Boilerplate config tables and install\n   instructions are noise for accuracy review.\n\n**When NOT to use the docs-accuracy template:** use the generic pattern from\nthe canonical SKILL.md when the question is about code design, an\narchitecture decision, a trade-off between two approaches, or anything\nthat doesn't fit \"are these docs accurate against source X\".\n\n### Outcome-driven product spec review template (added 2026-07-31)\n\nWhen the artifact is a design doc \u002F product spec (not a merged doc, not a patch) AND the product **supersedes** an existing tool's contract — i.e. the spec contradicts an existing README \u002F CLAUDE.md \u002F architecture doc in the same repo — use this variant. The shape of `QUESTIONS FOR THE REVIEWER` changes because three load-bearing questions are unique to supersession reviews:\n\n1. **What does the new spec say that the old contract explicitly forbids?** This is the question that breaks \"the design says X\" if X is forbidden by the existing CLAUDE.md \u002F README.\n2. **Does the new spec name where the old contract gets amended?** Most supersession PRs land without amending the old contract, leaving the repo internally contradictory.\n3. **Does the spec invent new mechanisms, or re-skin old ones?** A spec that \"moves cookies out of the design\" or \"drops manual auth\" without naming the mechanism it's replacing is doing more than it admits.\n\nThe artifact shape (≤150 lines, claim-bearing excerpts only) is the same as docs-accuracy; what differs is the questions + a new section in the artifact. Add a `Source: existing v1 contract` block alongside `Source: src\u002F\u003Cfile>.rs`, with the verbatim v1 text that the new spec contradicts. This lets the reviewer do an apples-to-apples diff instead of re-deriving the conflict.\n\nAlso include the **state-machine ↔ classification cross-check**: if the spec defines a state machine and a failure-classification list, verify every classification maps to a real state. The most common miss is \"names `recovery_exhausted` in classifications but the state diagram has no terminal edge for it.\" Surface this explicitly in `QUESTIONS FOR THE REVIEWER` as Q0.\n\n**Provenance:** browserclaw-autonomous-browser-control-design.md review (2026-07-31, doc-id `doc_f51132550e72_…`, 791 lines after 4 doc-level fixes). Verdict: NEEDS-FIXES, confidence high (Reviewer A source-accuracy) + medium (Reviewer B external-docs) + high (Reviewer C adversarial). 4 unresolved issues closed by the 4 doc-level patches: state-machine gap (added `recovery → recovery_exhausted → escalated` edge), `operator_id` source (named `HERMES_OPERATOR_ID`), cookie storage backend (`cryptography.fernet` + macOS Keychain + `keyring` fallback), fetched Aside password-autofill citation (`Agent-safe password manager autofill` + scoped access + audit log, with live `curl https:\u002F\u002Faside.com\u002F` evidence).\n\n### Patch review template (added 2026-07-15)\n\nUse this variant when the artifact IS a patch \u002F diff \u002F content-edit, NOT a\nstatic merged doc — the user uploaded a `.patch`\u002F`.diff`, pasted a \"fix\ntypo \u002F rename \u002F trim \u002F refactor\" PR diff, or the input is a sequence of\n`--- a\u002Fpath +++ b\u002Fpath` hunks. Reviewers must answer BOTH \"is the new\ncontent accurate?\" AND \"did the diff remove anything load-bearing?\". The\ndocs-accuracy template only covers the first question.\n\nThe full taxonomy (5-bucket `-` line classification, orphan-reference\ndetection, the overclaim-pitfall, worked example from the 2026-07-15\nsidekick-swarm-trim review) lives in\n[`references\u002Fpatch-review-taxonomy.md`](references\u002Fpatch-review-taxonomy.md).\nRead it before dispatching reviewers on a patch. Quick recap:\n\n- **Phase -0 (state-corruption pre-flight)**: md5\u002Fsize\u002Fmtime of every file in\n  the patch BEFORE running reviewers. If on-disk state has been replaced\n  with unrelated content (e.g. sidekick\u002FSKILL.md = swarm content), the patch\n  physically can't apply and reviewers are wasting quota. Verified\n  failure mode — 2026-07-15.\n- **Reviewer B's 5-bucket classification**: every `-` line is flavor \u002F\n  load-bearing-example \u002F safeguard \u002F cross-reference \u002F snuck-in.\n- **Reviewer C's orphan-reference check**: grep `+` lines for \"see X below\",\n  \"forbidden\", \"mandatory\"; verify each referenced section survives.\n- **Reviewer A's overclaim pitfall**: hunks titled \"fix overclaim\" require\n  EXTRA scrutiny. The author has already convinced themselves the claim\n  is wrong; verify the NEW disclaimer against the cited source, not just\n  the OLD claim. Common failure: patch removes an accurate paraphrase and\n  replaces it with a strawman that denies real source features.\n\n## Hermes-adapted Reviewer A fallback chain\n\nThe canonical Claude chain is `subagent → cursor → agy`. On this machine `cursor` is **not installed** (only `claude`, `codex`, `agy` are available). Use this adapted chain:\n\n| Priority | Tool | When |\n|---|---|---|\n| A1 | `delegate_task` (subagent) | Primary inside Hermes |\n| A2 | `agy --print --dangerously-skip-permissions` | subagent unavailable \u002F failed |\n| A3 | `codex ...` (headless codex invocation) | agy failed; codex has quota |\n| A4 | `claude -p --dangerously-skip-permissions --cwd \u002Ftmp` | last resort; requires `claude` login |\n\n## Known pitfalls (learned 2026-06-28)\n\n5. **`\u002Fadvice` is NOT a PR comment bot.** Posting `\u002Fadvice` as a PR comment does nothing — the skill is processed locally by the calling LLM, not by a GitHub workflow. Confirm this with `grep -rln \"\u002Fadvice\" $HOME\u002Fprojects_other\u002Fyour-project.com\u002F.github\u002Fworkflows\u002F` (returns empty).\n6. **Mid-tier source-code-review subagents can hit the 600s hard timeout** (verified 2026-07-15, wa-campaign-content-analysis + Drive template integration review). The subagent model (`delegate_task` `MiniMax-M3` per the standard chain) reads 30+ files line-by-line and never converges inside the 600s budget. Symptoms: API call counter climbs to ~28 before timeout, last action is a `read_file` or `search_files`. Two safer patterns: (a) split the review into 2-3 narrower sub-tasks each scoped to one file or one question; (b) skip the subagent entirely and do the source review inline using `read_file` + `search_files` directly — fast and deterministic when the file paths are known. Reserve full 3-reviewer fan-out for **decisions \u002F designs \u002F trade-offs** where opinion diversity matters; for **source-accuracy reviews** of a finite file set, inline is faster + cheaper.\n2. **The skill is in `~\u002F.claude\u002Fskills\u002F`, not `~\u002F.hermes\u002Fskills\u002F`.** `skill_view(name='advice')` will fail with \"Skill not found\" until this overlay exists. After this overlay is loaded, `skill_view(name='advice')` returns this file.\n3. **`claude -p` requires login** on this machine (`claude -p` → \"Not logged in · Please run \u002Flogin\"). Do not burn time on Reviewer A4 if A1-A3 also fail — just note \"Reviewer A unavailable.\"\n4. **No Hermes parallel exists.** `~\u002F.hermes\u002Fskills\u002F` has no native `advice` skill; this overlay is the only Hermes-side path.\n5. **`\u002Fresearch` and `\u002Fsecondo` referenced by the canonical skill are also Claude-Code slash commands** — not available in Hermes. Replace them with `delegate_task` (research flavor) and `delegate_task` (multi-model opinion flavor) if needed.\n\n## How to invoke \u002Fadvice from Hermes\n\n1. **Discover:** Call `skill_view(name='advice')` — returns this overlay. For full text, `cat ~\u002F.claude\u002Fskills\u002Fadvice\u002FSKILL.md`.\n2. **Extract:** Decision (3-5 sentences) + Artifact (≤150 lines).\n3. **Fan out (parallel):**\n   - Reviewer A: `delegate_task(goal=\"Senior engineer second opinion...\", toolsets=[\"terminal\",\"web\"])` — that's the Hermes equivalent of the Claude subagent.\n   - Reviewer B: `delegate_task(goal=\"Research question...\", toolsets=[\"web\",\"search\"])`\n   - Reviewer C (optional): `delegate_task(goal=\"Second-opinion from a different model...\", toolsets=[\"terminal\",\"web\"])` — note `claude -p` is not logged in.\n4. **Synthesize:** Same table format as canonical skill.\n\n## Worked example: Codex hook review (2026-07-17)\n\nWhen asked to \"review the evidence that the hooks worked\", the natural pattern\nis unit tests + tmux replay. The unit tests passed; the tmux replay showed the\nhook firing; everything looked green. `\u002Fadvice` fan-out found **4 real bugs**:\n\n1. **apply_patch regex was case-sensitive** — silently allowed the canonical `*** Delete File:` (capital D\u002FF) per the Codex\u002FClaude apply_patch grammar.\n2. **`cwd` field-name mismatch** — hook read `payload.working_dir` (Claude shape); Codex 0.144+ nests it under `tool_input.cwd`. Bare relative paths resolved against hook process's cwd, not the caller's.\n3. **Schema trap** — hook emitted `{\"continue\":false,\"stopReason\":\"...\"}`. Codex docs explicitly say these are \"parsed but not supported yet. Codex marks the hook run as failed, reports the error, and continues the tool call.\" My denies were being IGNORED, not enforced.\n4. **Non-dict `tool_input` silent allow** — `_extract_command` returned `\"\"` for `tool_input: [1,2,3]` → `_classify(\"\")` returned None → `_allow()`. The documented fail-closed posture was broken.\n\nNone of these showed up in unit tests because the tests were written to match\nthe hook's expectations, not the spec. The fix chain:\n- Reviewer A (source accuracy, MiniMax-M3): FAIL with file:line evidence\n- Reviewer B (external docs, MiniMax-M3): schema-deviation; fetched learn.chatgpt.com\u002Fdocs\u002Fhooks.md verbatim\n- Reviewer C (adversarial, MiniMax-M3): 9-vector probe, 2 real bypasses + 3 heuristic gaps\n\nAll 4 fixes were inline (`\u003C10 lines` each per `diagnosis-requires-followthrough-or-handoff`); 38-case test suite extended; skill rewritten to surface the Codex schema rules in Pitfall #0 \u002F Codex schema section. Live tmux replay also revealed the deeper Codex 0.144.5 limitation: **`unified_exec` skips PreToolUse entirely** per docs warning. The hook is a guardrail not a boundary — must be paired with sandbox + approval policy + backup.\n\n**Lesson for future `\u002Fadvice` reviews of CLI hook code**: never trust \"the unit tests pass\" alone. Always (a) fetch the vendor's hook schema docs verbatim, (b) drive a live CLI session in tmux to confirm the hook is actually invoked, (c) run an adversarial probe of payload shape edge cases (non-dict types, wrong field names, case-sensitive regex vs spec). All three found different classes of bugs in the same session.\n\n**The \"fixtures+docs\" trap on cross-CLI hook reviews (added 2026-07-30, PR `jleechanorg\u002Fclaude-commands#344`):** A `\u002Fadvice` review on a cross-CLI hook is not complete until the reviewer confirms the hook fires in a real CLI session. Two failure modes that this trap catches:\n\n1. **Codex discovery indirection** — the PR shipped `\u003Crepo>\u002F.codex\u002Fhooks.json` + `\u003Crepo>\u002Fcodex_hooks.json` Stop entries. Vendor docs list those as canonical. Neither was actually executed; Codex dispatches through `~\u002F.codex\u002Fstop-hook-dispatch.sh` and the project's Stop entry just suppresses the legacy fallback. The hook was silently never invoked until `stop-hook-dispatch.sh` was replaced. Two iterations of \"the JSON file is missing, the hook must be wrong\" followed before the indirection was traced.\n2. **Claude v2.1.220 Stop payload schema divergence from statusline docs** — the docs say `model`, `context_window`, and `cost` are present in any lifecycle payload. They are NOT present in the Stop payload (statusline-only). Fixture tests passed against the docs; the live `claude --print` session revealed the missing fields. The unit tests were rewritten with `CLAUDE_LIVE_PAYLOAD` (the actual captured payload) as the regression fixture.\n\n**Reviewer B's mandatory gate for any cross-CLI hook review (effective 2026-07-30):** before approving the verdict, the external-docs reviewer must also confirm:\n\n- A live CLI session has been run for EACH supported CLI (paste the `jq . \"$HOME\u002F.claude\u002Fvar\u002F\u003Chook>\u002Flast.json\"` transcript or equivalent live-payload capture into the synthesis).\n- The unit-test fixtures in `tests\u002Ftest_\u003Chook>.py` reference the captured payloads, NOT the docs' claimed shapes.\n- The discovery indirection is verified for each CLI (e.g. for Codex, the reviewer must confirm `~\u002F.codex\u002Fstop-hook-dispatch.sh` actually invokes the hook, not just sets `local_stop_configured=true`).\n\nIf any of these three are missing, the verdict must be `NEEDS-FIXES` with a specific item: \"live-payload capture missing for CLI X\" or \"discovery indirection unverified for CLI Y\". Do NOT let \"the unit tests pass\" stand as evidence for cross-CLI hook code.\n\nCompanion skill: `~\u002F.hermes\u002Fskills\u002Fcross-cli-hook-integration\u002FSKILL.md` — the full cross-CLI hook recipe including the discovery-indirection table (§1), the live-payload capture protocol (§4), and the per-CLI response-schema rules (§3). Verified 2026-07-30 against Claude v2.1.220, Codex 0.144.5, Cursor 3.11.13, Antigravity, agy 1.1.8.\n\n## Cross-reference\n- Canonical Claude-Code skill: `~\u002F.claude\u002Fskills\u002Fadvice\u002FSKILL.md`\n- Hermes skill paths: `~\u002F.hermes\u002Fskills\u002F` (staging, git-tracked), `~\u002F.hermes_prod\u002Fskills\u002F` (prod runtime)\n- Hermes deploy pipeline: `~\u002F.hermes\u002Fscripts\u002Fdeploy.sh --system hermes` syncs this overlay to prod\n- Codex canonical mirror: `~\u002F.codex\u002Fskills\u002F` archived 2026-06-13; new path is `~\u002F.agents\u002Fskills\u002F`\n- Companion skill `~\u002F.hermes\u002Fskills\u002Fcodex-path-deletion-guard\u002FSKILL.md` — the hook that triggered this review, with full Pitfall #0 (Codex 0.144 unified_exec) and Codex-schema-allowlist details\n- Companion reference `~\u002F.hermes\u002Fskills\u002Fcodex-path-deletion-guard\u002Freferences\u002Fadversarial-probe-2026-07-17.md` — 9-vector probe transcripts + v1-vs-v2 comparison table\n\n---\n\n## Pinned synthesis output format (added 2026-07-15)\n\nEvery `\u002Fadvice` synthesis reply — whether the verdict is \"ship it\", \"needs more changes\", or \"no fix needed\" — MUST end with the same 5-block shape so the user can parse it the same way every session. Tested on the merge_train PR #43 cross-CLI hook review (Jeffrey accepted with no follow-up).\n\n```markdown\n### Recommended next action (one tap)\n[One shell command OR \"no action — PR is ready at the standard green gate\"]\n\n### Evidence table\n| Bug-report claim (file:line) | PR\u002Ffix evidence (file:line) | Test coverage |\n|---|---|---|\n| ... | ... | ... |\n\n### Reviewers consulted\n- Reviewer A (source accuracy, model X): verdict + confidence\n- Reviewer B (external docs, model Y): verdict + confidence\n- Reviewer C (adversarial, model Z): verdict + confidence\n\n### Disagreements not resolved\n[Numbered list of claims where reviewers disagree, with what evidence\nwould settle each one. Skip this section if all three agreed.]\n\n? Memories used: [source:…, ids_or_labels:…, effect:…]\n```\n\nThe Evidence table is the load-bearing piece — it's what makes \"fix as needed\" answers parseable. Without it, the user has to re-read the synthesis to know whether the dispatch was actually justified.\n\n---\n\n## \"Fix as needed\" pattern — no-fix-is-a-valid-answer (added 2026-07-15)\n\nWhen the user says \"fix X as needed and use \u002Fadvice to review first\", the default execution flow is:\n\n1. `\u002Fadvice` review of the existing PR\u002Fdiff against the supplied context (Slack bug report, issue body, doc, etc.).\n2. Map every claim in the supplied context to a concrete diff hunk + test in the existing branch. The Evidence table above is built from this mapping.\n3. **Stop with no dispatch** if every claim is already addressed and the reviewers converged. This is a first-class outcome, not a failure mode — the user wants the question answered, not necessarily new code.\n4. Dispatch via `ao spawn` (NOT `agento` — see Known Pitfalls) only when the Evidence table has unresolved rows.\n\n**Anti-pattern to avoid:** dispatching an `ao spawn` worker \"just in case\" because the task framing implies action. The dispatch adds latency, consumes quota, and produces a noisy PR diff that the user has to review. When reviewers converge and CI is green, the right reply is one tap (`gh pr merge N --auto --squash`) and a `? Memories used:` line — nothing more.\n\n**Provenance:** merge_train PR #43 (jleechanorg\u002Fmerge_train, head SHA `431faca`, 2026-07-15). The supplied context was a 9-section Slack bug report covering 4 separate concerns (installer reinstall, runtime-specific matchers, migration cleanup, OpenCode `apply_patch` paths). All 4 had corresponding diff hunks in the existing single commit; CI was green across 7 GH Actions checks (cross-OS pytest + install.sh smoke + evidence staleness); all 3 reviewers converged. No dispatch.\n\n## Verified 2026-07-21 — `\u002Fadvice` as Gate-3 substitute for the fullrun cycle\n\n**Use this path when all three official review bots are simultaneously unavailable** AND the user is waiting in-thread for a green verdict. Verified on jleechanorg\u002Fdark-factory PR #407 (commit `f461f93`) — both Reviewer A (source-accuracy) and Reviewer B (architecture) ran as Hermes subagents in parallel; combined latency \u003C60 sec vs 51-55 min for the v2.5.7 babysit-cron path.\n\n**Pre-flight signature** (all three must be present):\n```bash\ngh pr checks N --repo OWNER\u002FREPO\n# CodeRabbit       fail    \"Review rate limited\"\n# Cursor Bugbot    skipping \"usage limit reached\"\n# chatgpt-codex-connector skipping \"Codex usage limits\"\n```\n\n**Fan-out recipe** (parallel):\n- Reviewer A: source-accuracy with file:line citations for every claim\n- Reviewer B: architecture + design-intent + audit-chain correctness (catches ordering + opt-in-pattern mismatches that Reviewer A misses)\n- Optional Reviewer C: adversarial probe (9-vector for sandbox\u002Ffork\u002Fedge cases)\n\n**Verdict format** (verbatim, parseable by `green.md` Step 3.4):\n```\nVERDICT: [APPROVED-as-is \u002F NEEDS-FIXES (numbered list) \u002F REJECT]\nREASONING: [3-4 sentences citing file:line evidence]\nRISK: [main risk if merged as-is, one sentence]\nCONFIDENCE: [high \u002F medium \u002F low]\nNUMBERED FINDINGS: [file:line — what — why — suggested fix]\n```\n\n**Then post the synthesis as a PR comment** (`gh pr comment N --body '\u003Csynthesis>'`) so the gate-3 substitute is recorded on the PR thread per `green.md` Step 3.4's \"current-head ... independent adversarial review recorded on the PR\" requirement.\n\n**Cross-reference**: full recipe in `workflow\u002Fdrive-pr-to-green\u002FSKILL.md` v2.5.9 addendum + `references\u002Fadvice-substitute-and-fork-divergent-rebase-2026-07-21.md`.\n\n## \"Needs fixes (cosmetic\u002Fclarity, not blocking)\" middle ground (added 2026-07-20, PR #8467)\n\nThe most common `\u002Fadvice` verdict on a real PR is **\"needs fixes (cosmetic\u002Fclarity, not blocking)\"** with confidence: medium. This is neither \"ship as-is\" nor \"fundamentally wrong\" — the PR shape is correct, but Reviewer A found N soft contradictions or polish issues. The right flow is:\n\n1. **Apply the most-impactful findings inline in a follow-up commit on the same PR branch.** Sort findings by user-visible impact (boundary mismatches → duplicate labels → terminology drift → ortho\u002Fcanon notes). Skip findings whose fix would expand scope beyond the original directive.\n2. **Document the rest in the PR comment thread.** Acknowledge what was not fixed and why. Reviewer A's numbered list becomes a tracked-issue backlog rather than a blocking PR revision.\n3. **Re-push.** The precheck re-runs; the new commit shows up in `git log origin\u002Fmain..HEAD`.\n4. **Re-poll CI** (passive — `gh api` REST endpoints, not GraphQL when rate-limited).\n5. **Do NOT spin up a fresh AO worker.** The PR already exists; the work is in-place. A new AO spawn burns quota on a duplicate diff.\n\n**Anti-pattern:** treating \"needs fixes (not blocking)\" as license to `ao spawn` a worker to do the fixes. The findings are 1-10 line edits in known files — `patch` calls inline are faster, deterministic, and the diff stays reviewable.\n\n**Why this middle ground matters:** the alternative is \"merge as-is\" (defies the verdict) or \"draft follow-up PR\" (loses context, requires CodeRabbit re-review of the whole branch). The follow-up-commit-on-same-branch pattern keeps the PR atomic and reviewable.\n\n**Provenance:** $GITHUB_REPOSITORY PR #8467 (head SHA `0314a434e4`, 2026-07-20). Reviewer A returned 10 findings; 4 most-impactful (band-boundary mismatch, duplicate Exposure label, Ma[REDACTED_OPENAI_KEY]\u002FForbidden-Spell semantic drift, Ao 1-3%\u002Fscene trickle inconsistency) were applied as commit `0314a434e4` on top of `ec74ca2dda`. The other 6 (dual attribution tables, mitigation-token interpretation, \"offending faction\" terminology, A.5 Inevitables FR canon note, etc.) were logged as known follow-ups. Green Gate passed on the new SHA with REAL-mode smoke dispatch via `scripts\u002Fdispatch-real-smoke.sh` from the `wa-green-gate-pr-shape` skill.\n\n**When this middle ground does NOT apply:** if Reviewer A returns VERDICT: misleading or RISK: \u003Ca concrete hazard if shipped as-is>, the right move is either a follow-up PR (not follow-up commit) or explicit user-call on whether to ship with the documented risk. Don't auto-merge a \"misleading\" verdict regardless of \"not blocking\" wording.\n\n14. **\"I don't care about X\" = indifferent to mechanism, not a ban** (learned 2026-07-30, browserclaw-autonomous-browser-control-design.md review). When the operator says \"I don't care about X\" during a design review, the right fix is to **mark X as an implementation detail the operator is indifferent to** — keep X in the design, add a one-line \"operator-indifferent\" note, and move on. The wrong fix is to remove X from the design (verified failure: removed all cookie-promotion language from Goals, CredentialBroker, Security, Recovery, Final-design-decisions, and the transport-preference diagram — operator immediately pushed back with \"browserclaw can store cookies its fine\"). Symptom: you find yourself gutting 6+ sections to \"respect\" a clarifying answer. Counter-symptom: the user complains and you have to restore 6 sections. **Read the meta-question, not the literal one.** Same pattern: \"I don't care how you do X\" \u002F \"any way is fine\" \u002F \"doesn't matter to me\" → operator-indifference clause, not removal.\n15. **Gateway re-injection creates a no-op echo chain — break it on turn 2** (learned 2026-07-30, browserclaw thread, verified 11 consecutive idle turns). When the Slack\u002FHermes gateway re-injects your prior reply as a new \"user\" message (common after gateway shutdown\u002Frestart cycles), the next turn is a forward with no new directive. The wrong response is to keep producing longer status reports that themselves get re-injected. The right response is to reply once with a short \"Idle. Awaiting real directive.\" and stop. If the same echo arrives again (turn 2, turn 3, ...), reply **literally one line** — \"Idle.\" — without any tool calls. Do not re-run the same `grep` for \"verification\" (the state hasn't changed); do not re-explain the work; do not re-post a multi-option menu. The work is done; the gate is silent. When real content eventually arrives, resume normal behavior. Confirmed pattern: every \"Idle.\" turn in the browserclaw thread used zero tool calls and zero new claims — the long-idle review thread stayed parseable when the operator came back.\n16. **Operator preference for env-driven configuration** (learned 2026-07-30, browserclaw thread). When the operator says \"lets have X configurable\" or \"lets make this optional\" or \"other people may have other setups,\" the right encoding is **a `BROWSERCLAW_\u003CTHING>` env var with a sensible default + a `local` opt-out slot**. The wrong encoding is to hardcode \"Slack + email\" (verified failure: original design said \"Slack and email simultaneously,\" operator immediately said \"lets have hermes DM me and lets make this optional\"). Same pattern: any system that has to integrate with the operator's preferred channel\u002Fnotification\u002Fstorage MUST read its target from env, with a default that matches the current operator's setup but an explicit way to redirect or silence it. Document the env vars next to the component, not in a separate \"configuration\" section. (Design-doc-level capture lives in browserclaw §NotificationRouter; this pitfall is the principle.) When the operator says \"I don't care about X\" during a design review, the right fix is to **mark X as an implementation detail the operator is indifferent to** — keep X in the design, add a one-line \"operator-indifferent\" note, and move on. The wrong fix is to remove X from the design (verified failure: removed all cookie-promotion language from Goals, CredentialBroker, Security, Recovery, Final-design-decisions, and the transport-preference diagram — operator immediately pushed back with \"browserclaw can store cookies its fine\"). Symptom: you find yourself gutting 6+ sections to \"respect\" a clarifying answer. Counter-symptom: the user complains and you have to restore 6 sections. **Read the meta-question, not the literal one.** Same pattern: \"I don't care how you do X\" \u002F \"any way is fine\" \u002F \"doesn't matter to me\" → operator-indifference clause, not removal.\n- When external verification requires fetching plain-text from a URL, use the `curl + grep` recipe in [`references\u002Fplain-text-web-extraction-curl-fallback.md`](references\u002Fplain-text-web-extraction-curl-fallback.md) instead of `web_extract` (ddgs backend is search-only; Tavily is disabled per SOUL.md).\n\n17. **\"Default with manual fallback as exception\" = load-bearing binding constraint, not a config setting** (learned 2026-07-30, browserclaw thread). When the operator says \"X is the default, manual fallback is the exception\" or \"I want X automatic, never [manual] unless forced,\" that phrasing encodes a **binding design constraint** — it must appear in the design doc as an explicit clause (e.g. \"manual operator step only after every automated path is exhausted\") and the implementation must enforce it. The wrong encoding is to treat it as a config knob (`--manual-fallback-allowed=false`) — that lets the binding constraint erode over time when a future operator flips the flag. Three concrete patterns: (1) §Goals bullet rewritten as \"**automatically** — the operator should never need to open a browser for routine work, and manual fallback is the exception, not the default\" (bold + \"not the default\"); (2) §3 Recover step 9 rewritten as \"Only if every automated path is exhausted, escalate with a request that the operator open a browser and complete the specific step the system could not\"; (3) §Relationship to existing browserclaw v1 contract explicitly supersedes the v1 \"Manual auth only\" ceiling with the new automatic-auth posture. The Rule: any operator-phrased \"automatic X, manual only when forced\" is a §Goals-level invariant, not a §Configuration-level switch.\n\n18. **`delegate_task` thread-pool capacity failure is silent — check `result[0].get(\"status\") == \"error\"` immediately** (verified 2026-07-21, PR #8488 `\u002Fadvice` fan-out). Three failure modes all return a non-obvious `status: error` payload that is easy to miss:\n    - `\"DaemonThreadPoolExecutor' object has no attribute '_initializer'\"` — pool capacity exhausted, the task DID NOT run\n    - `\"background delegation pool was at capacity\"` — concurrent children limit reached\n    - `\"spawn-failed-but-worktree-exists\"` — see `dispatch-task` SKILL\n    The error message naming can mislead (mentions `_initializer`, not `delegation.max_concurrent_children`), and the failed call returns the same shape (`{\"results\": [{...}], \"note\": ...}`) as a successful one — so a quick `if result[0].status == 'error'` check is mandatory. **Fix:** always check before synthesizing. The fan-out is non-atomic; the right behavior on error is to immediately fall back to inline 3-reviewer reading via `read_file` + `skill_view` on the relevant skill files (per Pitfall #6 below — inline is faster anyway for finite-file-set reviews).\n\n---\n\n## Cross-CLI hook schema verification recipe (added 2026-07-15)\n\nWhen the review question involves cross-CLI hook payloads (Codex \u002F Claude \u002F Gemini \u002F Cursor \u002F OpenCode \u002F Antigravity `agy`), reviewers often need to verify whether field names like `permissionDecision`, `additionalContext`, `patchText`, `apply_patch`, `write_file`, `write_to_file` actually exist in the live vendor docs. The recipe:\n\n```bash\nmkdir -p \u002Ftmp\u002Fadvice-hooks && cd \u002Ftmp\u002Fadvice-hooks\nfor url in \\\n  \"https:\u002F\u002Flearn.chatgpt.com\u002Fdocs\u002Fhooks.md\" \\\n  \"https:\u002F\u002Fgeminicli.com\u002Fdocs\u002Fhooks\u002Freference\u002F\" \\\n  \"https:\u002F\u002Fgeminicli.com\u002Fdocs\u002Fhooks\u002Fbest-practices\u002F\" \\\n  \"https:\u002F\u002Fopencode.ai\u002Fdocs\u002Ftools\u002F\"; do\n  fname=$(echo \"$url\" | sed -E 's|https?:\u002F\u002F([^\u002F]+)\u002F.*|\\1|; s|\\.|_|g').txt\n  curl -fsS \"$url\" -o \"$fname\" || echo \"FAIL $url\"\ndone\n\npython3 - \u003C\u003C'PY'\nfrom pathlib import Path\nterms = [\"write_to_file\",\"write_file\",\"replace\",\"apply_patch\",\"patchText\",\n         \"additionalContext\",\"permissionDecisionReason\",\"statusMessage\",\"timeout\"]\nfor f in Path('.').glob('*.txt'):\n    s = f.read_text(errors='ignore')\n    print(f.name, len(s))\n    for t in terms:\n        i = s.find(t)\n        print(f'  {t}:', 'HIT @', i if i>=0 else 'MISS',\n              s[i:i+300].replace('\\n',' ')[:300] if i>=0 else '')\nPY\n```\n\n**What this gives the reviewer:** ground-truth presence\u002Fabsence of each candidate field name in vendor docs at session time. Reviewer B (the external-docs reviewer) cites the `HIT @ \u003Coffset>` line as file:line evidence for their verdict.\n\n**What this does NOT give:** schema-version drift, undocumented changes between SDK releases, or runtime-specific behaviors that only show up in `--help` output. For those, the reviewer must say \"external verification unavailable\" and downweight their confidence — do not assert the absence of a field as a positive fact just because it didn't appear in fetched docs (research-integrity rule: proving presence needs only one hit, proving absence requires exhausting sources).\n\nSee [`references\u002Fcross-cli-hook-schema-verification.md`](references\u002Fcross-cli-hook-schema-verification.md) for the full transcript (URLs hit, terms searched, hit\u002Fmiss counts) from the 2026-07-15 merge_train PR #43 review. Future agents should re-run the curl loop, not trust the cached transcript verbatim — vendor docs change.\n\n---\n\n## Known pitfalls (extended 2026-07-15)\n\n6. **`agento` is not a CLI on this machine** (verified 2026-07-15, jleechanorg\u002Fmerge_train PR #43 triage). The `agento` SKILL.md description claims it's the entrypoint, but `command -v agento` returns not-found. The actual dispatcher is `ao` (`$HOME\u002F.local\u002Fbin\u002Fao`). When you need to dispatch a coding worker, use `ao spawn --project \u003Cid> --claim-pr \u003CN> --prompt \"...\"`, not `agento`. If `ao project list` doesn't show the target repo, run `ao project add \u003Cpath>` first (interactive prompt — preflight that the path exists before spawning). The `agento` keyword in user messages still routes here, but the underlying command is `ao`.\n7. **Treating \"fix X as needed\" as license to dispatch unconditionally** — see the \"no-fix-is-a-valid-answer\" section above. Dispatch burns quota and produces noisy PRs; the Evidence table tells you whether dispatch is warranted.\n8. **Quoting absence as fact** — see the verification recipe's \"What this does NOT give\" caveat. Reviewer B must explicitly downgrade confidence when external verification is incomplete.\n9. **Skipping state-corruption pre-flight on patch reviews** (learned 2026-07-15, sidekick-swarm-trim): when the artifact is a patch \u002F diff, verify `md5 + size + mtime` of every file the patch targets BEFORE fanning out reviewers. If on-disk state has been replaced with unrelated content (verified failure mode: sidekick\u002FSKILL.md was byte-identical to swarm\u002FSKILL.md since 2026-07-14), the patch will produce `.rej` files when applied, reviewers will quote line numbers from a corrupted source, and you'll spend quota to ship a verdict against the wrong file. Phase -0 takes 5 seconds and prevents 30+ minutes of reviewer churn. Full recipe: [`references\u002Fpatch-review-taxonomy.md`](references\u002Fpatch-review-taxonomy.md) § \"State-corruption pre-flight\".\n10. **Patch hunks titled \"fix overclaim\" \u002F \"correct attribution\" \u002F \"remove inaccurate claim\" require EXTRA scrutiny** (learned 2026-07-15): the author has already convinced themselves the original claim is wrong, so they're working backwards. Verify the NEW disclaimer against the cited source — does the thing they're disclaiming actually exist? Common failure: patch removes an accurate paraphrase and replaces it with a strawman that denies real source features (verified this session: Fusion's two headline techniques ARE dynamic mid-session routing + cache-preserving model switches; the \"overclaim fix\" denied both).\n11. **`git apply --stat` from a non-repo parent dir is NOT a valid pre-flight** (learned 2026-07-20, jleechanai `C09GRLXF9GR\u002Fp1784582518.247009`, infra03q patch bundle). When the artifact is a patch from a Slack attachment or `~\u002FDownloads`, `cd $HOME && git apply --stat \u003Cpatch>` exits 0 even when every target file is missing — missing-file warnings get treated as warnings rather than errors at the parent level. The gating signal is `git apply --check` from the repo root that actually contains the patch's target tree. See `finish-the-job\u002Freferences\u002Fpatch-bundle-cwd-preflight-2026-07-20.md` for the full recipe. Companion to pitfall #9 — file-existence (cheap check) + content-match (`md5 + size + mtime`, full check) + hunk-applicability (`git apply --check`, gating check) form a layered defense.\n12. **`\u002Fsuper` and `\u002Faar` resolve differently than session memory suggests** (learned 2026-07-20). `\u002Fsuper` is Superpowers Cloud Build dispatch (remote GLM-5.2 box) per the 2026-07-20 rewrite of `~\u002F.claude\u002Fcommands\u002Fsuper.md` — NOT the legacy local `claudeg` thin-router. `\u002Faar` = `\u002Faccept-adapt-reject` (feedback triage into Accept\u002FAdapt\u002FReject), NOT a generic after-action-review. When `\u002Fadvice` says \"dispatch via `\u002Fsuper`\", verify the user's intent matches the dispatch semantics before quoting the slash command back.\n14. **\"I don't care about X\" = indifferent to mechanism, not a ban** (learned 2026-07-30, browserclaw-autonomous-browser-control-design.md review). When the operator says \"I don't care about X\" during a design review, the right fix is to **mark X as an implementation detail the operator is indifferent to** — keep X in the design, add a one-line \"operator-indifferent\" note, and move on. The wrong fix is to remove X from the design (verified failure: removed all cookie-promotion language from Goals, CredentialBroker, Security, Recovery, Final-design-decisions, and the transport-preference diagram — operator immediately pushed back with \"browserclaw can store cookies its fine\"). Symptom: you find yourself gutting 6+ sections to \"respect\" a clarifying answer. Counter-symptom: the user complains and you have to restore 6 sections. **Read the meta-question, not the literal one.** Same pattern: \"I don't care how you do X\" \u002F \"any way is fine\" \u002F \"doesn't matter to me\" → operator-indifference clause, not removal.\n15. **Gateway re-injection creates a no-op echo chain — break it on turn 2** (learned 2026-07-30, browserclaw thread; reinforced 2026-07-30, superpowers\u002Fgsd\u002Fgrill-me thread, 20+ consecutive idle turns). When the Slack\u002FHermes gateway re-injects your prior reply as a new \"user\" message (common after gateway shutdown\u002Frestart cycles), the next turn is a forward with no new directive. The wrong response is to keep producing longer status reports that themselves get re-injected. The right response is to reply once with a short \"Idle. Awaiting real directive.\" and stop. If the same echo arrives again (turn 2, turn 3), reply **literally one line** — \"Idle.\" — without any tool calls. Do not re-run the same `grep` for \"verification\" (the state hasn't changed); do not re-explain the work; do not re-post the multi-option menu. The work is done; the gate is silent. Verified pattern: 11 consecutive idle turns in one session, all single-line replies, zero tool calls, all preserved the operator's review-thread context for when they next engage.\n\n    **Anti-pattern: emitting structured-report replies on echo turns** (learned 2026-07-30, superpowers\u002Fgsd\u002Fgrill-me thread, 20+ idle turns). Even after correctly identifying the echo chain and citing the SOUL.md `never-hallucinate-no-new-content` rule, the agent kept producing Healthy\u002FRisky\u002FBlocked sections, multi-option decision menus, and \"Memories used\" footers on every echo turn — each ~200-500 words, each structurally identical to a real report, each one more candidate for the next re-injection. **The report template is itself the failure mode on echo turns.** The right output for turn 2+ of the echo chain is one literal line (\"Idle.\") with NO sections, NO menus, NO footer, NO `? Memories used:` line. If you feel the urge to write a structured status update on an echo turn, that urge is the bug — resist it. The structured template is for real directives; the literal one-liner is for echoes. Confirmed: the long-idle thread stayed parseable across ~20 idle turns only when the operator's gateway finally started emitting templated queue notices instead of echo-looping the prior reply.\n\n15a. **Multi-hour gateway stalls need durable state, not just one-line replies** (learned 2026-07-30, browserclaw thread, ~3 hours of stall). Pitfall #15 covers the per-turn reply discipline; this pitfall covers the *system* discipline when the stall extends beyond a few turns. After 5–10 idle turns with no real operator directive: (a) persist the work-product paths as durable memory — file paths, line ranges, commit SHAs (or absent), PR numbers (or absent) — so a fresh session can recover state without re-deriving 30+ turns of context; (b) capture any unresolved decisions to `~\u002F.hermes\u002Fmemory.md` or the project's `specs\u002F` directory, not just in the thread; (c) if the operator's intent is unambiguous, write the work product to disk even if no PR\u002Fdispatch is happening (design docs in `~\u002F.hermes\u002Fcache\u002Fdocuments\u002F`, plans in `projects\u002F\u003Crepo>\u002Fdocs\u002Fplans\u002F`); (d) do NOT delete in-progress artifacts because \"they're not authoritative yet\" — a recovery agent needs the partial state to continue. Verified pattern: browserclaw thread stalled ~3 hours with the design doc + TDD plan + 4 D-patches all on disk at known paths; recovery means point at the paths, not re-run the conversation. Anti-pattern: keeping everything in the conversation memory and trusting the session resume. When the gateway finally responds with a real directive, state the recovered state in the first 50 words — \"Doc at path X (Y lines, Z patches verified), TDD plan at path W (N tasks), no PR open, awaiting execute directive\" — and let the operator redirect from there.\n","# \u002Fadvice — Token-Efficient Second Opinion (Hermes overlay)\n\n**This is the Hermes-side wrapper.** The canonical skill lives at:\n- `~\u002F.claude\u002Fskills\u002Fadvice\u002FSKILL.md` — quorum, dispatch order, fallback chain\n\n**Read the canonical file for the full procedure.** This overlay exists so that:\n1. `skill_view(name='advice')` works from the Hermes session (the canonical Claude skill is not registered in the Hermes skill registry).\n2. Future agents learn to **search both `~\u002F.hermes\u002Fskills\u002F` AND `~\u002F.claude\u002Fskills\u002F`** when a user invokes a `\u002Fslash` command — slash commands are not Hermes-native; they are Claude Code constructs.\n\n## Canonical reviewer contract\n\nThe canonical advice skill owns reviewer capabilities, risk-selected count,\ntier order and class caps. Static-review owns cold prompts, access-mode\npreambles, full pinned source coverage and receipts. Load both current owners;\nfill exactly the fields of advice §4's selected mode rather than assuming only\na URL\u002FSHA pair. This overlay supplies no separate prompt or dispatch policy.\nUse actual authorized accounts\u002Fcapabilities on the current host; preserve\ncomplete coverage, deadlines, identity deduplication and explicit outside\nrequirements. Missing an integration means UNAVAILABLE, not an improvised\nreview or approval.\n\n\n## When to use\n\nUser says `\u002Fadvice [optional question]`, or you reach a decision point that needs a second opinion without shipping the full conversation uncached.\n\n## Historical notes — not review-dispatch instructions\n\nThe legacy examples, templates, seat-availability claims and fanout recommendations below are preserved as\nhistorical context only. They do not authorize dispatch, establish current machine capability, supply a review\nprompt or override the canonical advice\u002Fstatic-review owners. For every live review, resolve current local\ncapabilities, quorum and tiers from the canonical skills above and use only static-review's current templates\nand transport preambles. Do not execute a historical command or request a named seat merely because it appears\nbelow.\n\n## Review types (added 2026-07-06)\n\nThe canonical `\u002Fadvice` SKILL.md describes the general-purpose \"extract decision + artifact, fan out 3 reviewers, synthesize\" pattern. For docs-accuracy reviews (e.g. \"are these merged docs accurate against the source?\"), use this specialized template — it produces far more useful verdicts than the generic one:\n\n### Docs-accuracy review template\n\n```markdown\n# \u002Fadvice Decision + Artifact\n\n## DECISION (3-5 sentences)\n[What specifically needs review — be concrete. For docs-accuracy:\n\"docs X\u002FY\u002FZ were merged in PR #N; need a second opinion on whether\nthe claims match the actual `src\u002F` code, whether the terminology\nis consistent across files, and whether anything was fabricated.\"]\n\n## ARTIFACT (≤150 lines, claim-bearing excerpts only)\n[Paste ONLY the claim-bearing sections from each doc, plus the\nload-bearing source files. Drop boilerplate, drop \"Install\" sections,\ndrop Config tables — they don't bear accuracy claims. If the docs\ntotal 800+ lines, summarize to ≤150 lines.]\n\n### Doc §\"\u003Csection name>\" — claim-bearing excerpts\n> [quote 1-3 sentences that make a verifiable claim]\n\n### Doc §\"\u003Csection name>\" — claims under review\n**L1 ...**: enforces X\n**L2 ...**: enforces Y\n**L3 ...**: enforces Z\n\n### Source: `src\u002F\u003Cfile>.rs::\u003Cfn>()`\n```rust\n[the actual source code that backs the claim]\n```\n\n## QUESTIONS FOR THE REVIEWER\n\n1. **[Specific factual claim]**: does doc say X? does code do X?\n2. **[Terminology consistency]**: are the terms used consistently?\n3. **[Missing callout]**: is there a case the doc should surface that\n   it doesn't? (e.g. macOS short-circuit, sudo escalation wording)\n4. **[Fabrication check]**: does any claim in the doc contradict\n   actual source?\n\n## DELIVERABLE\n\nReturn exactly:\nVERDICT: [docs accurate \u002F docs need fixes (list) \u002F docs misleading (explain)]\nREASONING: [3-4 sentences citing file:line evidence]\nRISK: [main risk if docs are wrong, one sentence]\nCONFIDENCE: [high \u002F medium \u002F low]\n\nPlus a numbered list of every inaccurate claim you found, each with:\ndoc-file:line, source-file:line, what the doc says vs what the code\nactually does.\n```\n\n**Why this template works (verified 2026-07-06, ez-gh-actions PR #9 review):**\n\n1. The \"QUESTIONS FOR THE REVIEWER\" numbered list forces the reviewer to\n   address each load-bearing claim explicitly instead of waving a hand\n   at \"looks accurate\".\n2. The 3 reviewer roles get differentiated goals:\n   - **Reviewer A (source accuracy)**: file:line citations from the docs\n     AND the source for each claim — every claim must trace to code.\n   - **Reviewer B (public docs)**: cross-reference with Docker\u002FColima\u002FQEMU\n     official docs, GitHub Security Lab research, kernel docs.\n   - **Reviewer C (internal consistency)**: terminology drift between\n     README\u002FDESIGN\u002FSVG\u002Fwiki\u002Froadmap, broken anchor links, jargon overload.\n3. The \"Plus a numbered list of every inaccurate claim you found\"\n   output format surfaces EVERY gap in one table — easier to synthesize\n   into a follow-up PR than prose paragraphs.\n4. The 150-line artifact budget forces distillation: only the claims\n   that matter go to the reviewer. Boilerplate config tables and install\n   instructions are noise for accuracy review.\n\n**When NOT to use the docs-accuracy template:** use the generic pattern from\nthe canonical SKILL.md when the question is about code design, an\narchitecture decision, a trade-off between two approaches, or anything\nthat doesn't fit \"are these docs accurate against source X\".\n\n### Outcome-driven product spec review template (added 2026-07-31)\n\nWhen the artifact is a design doc \u002F product spec (not a merged doc, not a patch) AND the product **supersedes** an existing tool's contract — i.e. the spec contradicts an existing README \u002F CLAUDE.md \u002F architecture doc in the same repo — use this variant. The shape of `QUESTIONS FOR THE REVIEWER` changes because three load-bearing questions are unique to supersession reviews:\n\n1. **What does the new spec say that the old contract explicitly forbids?** This is the question that breaks \"the design says X\" if X is forbidden by the existing CLAUDE.md \u002F README.\n2. **Does the new spec name where the old contract gets amended?** Most supersession PRs land without amending the old contract, leaving the repo internally contradictory.\n3. **Does the spec invent new mechanisms, or re-skin old ones?** A spec that \"moves cookies out of the design\" or \"drops manual auth\" without naming the mechanism it's replacing is doing more than it admits.\n\nThe artifact shape (≤150 lines, claim-bearing excerpts only) is the same as docs-accuracy; what differs is the questions + a new section in the artifact. Add a `Source: existing v1 contract` block alongside `Source: src\u002F\u003Cfile>.rs`, with the verbatim v1 text that the new spec contradicts. This lets the reviewer do an apples-to-apples diff instead of re-deriving the conflict.\n\nAlso include the **state-machine ↔ classification cross-check**: if the spec defines a state machine and a failure-classification list, verify every classification maps to a real state. The most common miss is \"names `recovery_exhausted` in classifications but the state diagram has no terminal edge for it.\" Surface this explicitly in `QUESTIONS FOR THE REVIEWER` as Q0.\n\n**Provenance:** browserclaw-autonomous-browser-control-design.md review (2026-07-31, doc-id `doc_f51132550e72_…`, 791 lines after 4 doc-level fixes). Verdict: NEEDS-FIXES, confidence high (Reviewer A source-accuracy) + medium (Reviewer B external-docs) + high (Reviewer C adversarial). 4 unresolved issues closed by the 4 doc-level patches: state-machine gap (added `recovery → recovery_exhausted → escalated` edge), `operator_id` source (named `HERMES_OPERATOR_ID`), cookie storage backend (`cryptography.fernet` + macOS Keychain + `keyring` fallback), fetched Aside password-autofill citation (`Agent-safe password manager autofill` + scoped access + audit log, with live `curl https:\u002F\u002Faside.com\u002F` evidence).\n\n### Patch review template (added 2026-07-15)\n\nUse this variant when the artifact IS a patch \u002F diff \u002F content-edit, NOT a\nstatic merged doc — the user uploaded a `.patch`\u002F`.diff`, pasted a \"fix\ntypo \u002F rename \u002F trim \u002F refactor\" PR diff, or the input is a sequence of\n`--- a\u002Fpath +++ b\u002Fpath` hunks. Reviewers must answer BOTH \"is the new\ncontent accurate?\" AND \"did the diff remove anything load-bearing?\". The\ndocs-accuracy template only covers the first question.\n\nThe full taxonomy (5-bucket `-` line classification, orphan-reference\ndetection, the overclaim-pitfall, worked example from the 2026-07-15\nsidekick-swarm-trim review) lives in\n[`references\u002Fpatch-review-taxonomy.md`](references\u002Fpatch-review-taxonomy.md).\nRead it before dispatching reviewers on a patch. Quick recap:\n\n- **Phase -0 (state-corruption pre-flight)**: md5\u002Fsize\u002Fmtime of every file in\n  the patch BEFORE running reviewers. If on-disk state has been replaced\n  with unrelated content (e.g. sidekick\u002FSKILL.md = swarm content), the patch\n  physically can't apply and reviewers are wasting quota. Verified\n  failure mode — 2026-07-15.\n- **Reviewer B's 5-bucket classification**: every `-` line is flavor \u002F\n  load-bearing-example \u002F safeguard \u002F cross-reference \u002F snuck-in.\n- **Reviewer C's orphan-reference check**: grep `+` lines for \"see X below\",\n  \"forbidden\", \"mandatory\"; verify each referenced section survives.\n- **Reviewer A's overclaim pitfall**: hunks titled \"fix overclaim\" require\n  EXTRA scrutiny. The author has already convinced themselves the claim\n  is wrong; verify the NEW disclaimer against the cited source, not just\n  the OLD claim. Common failure: patch removes an accurate paraphrase and\n  replaces it with a strawman that denies real source features.\n\n## Hermes-adapted Reviewer A fallback chain\n\nThe canonical Claude chain is `subagent → cursor → agy`. On this machine `cursor` is **not installed** (only `claude`, `codex`, `agy` are available). Use this adapted chain:\n\n| Priority | Tool | When |\n|---|---|---|\n| A1 | `delegate_task` (subagent) | Primary inside Hermes |\n| A2 | `agy --print --dangerously-skip-permissions` | subagent unavailable \u002F failed |\n| A3 | `codex ...` (headless codex invocation) | agy failed; codex has quota |\n| A4 | `claude -p --dangerously-skip-permissions --cwd \u002Ftmp` | last resort; requires `claude` login |\n\n## Known pitfalls (learned 2026-06-28)\n\n5. **`\u002Fadvice` is NOT a PR comment bot.** Posting `\u002Fadvice` as a PR comment does nothing — the skill is processed locally by the calling LLM, not by a GitHub workflow. Confirm this with `grep -rln \"\u002Fadvice\" $HOME\u002Fprojects_other\u002Fyour-project.com\u002F.github\u002Fworkflows\u002F` (returns empty).\n6. **Mid-tier source-code-review subagents can hit the 600s hard timeout** (verified 2026-07-15, wa-campaign-content-analysis + Drive template integration review). The subagent model (`delegate_task` `MiniMax-M3` per the standard chain) reads 30+ files line-by-line and never converges inside the 600s budget. Symptoms: API call counter climbs to ~28 before timeout, last action is a `read_file` or `search_files`. Two safer patterns: (a) split the review into 2-3 narrower sub-tasks each scoped to one file or one question; (b) skip the subagent entirely and do the source review inline using `read_file` + `search_files` directly — fast and deterministic when the file paths are known. Reserve full 3-reviewer fan-out for **decisions \u002F designs \u002F trade-offs** where opinion diversity matters; for **source-accuracy reviews** of a finite file set, inline is faster + cheaper.\n2. **The skill is in `~\u002F.claude\u002Fskills\u002F`, not `~\u002F.hermes\u002Fskills\u002F`.** `skill_view(name='advice')` will fail with \"Skill not found\" until this overlay exists. After this overlay is loaded, `skill_view(name='advice')` returns this file.\n3. **`claude -p` requires login** on this machine (`claude -p` → \"Not logged in · Please run \u002Flogin\"). Do not burn time on Reviewer A4 if A1-A3 also fail — just note \"Reviewer A unavailable.\"\n4. **No Hermes parallel exists.** `~\u002F.hermes\u002Fskills\u002F` has no native `advice` skill; this overlay is the only Hermes-side path.\n5. **`\u002Fresearch` and `\u002Fsecondo` referenced by the canonical skill are also Claude-Code slash commands** — not available in Hermes. Replace them with `delegate_task` (research flavor) and `delegate_task` (multi-model opinion flavor) if needed.\n\n## How to invoke \u002Fadvice from Hermes\n\n1. **Discover:** Call `skill_view(name='advice')` — returns this overlay. For full text, `cat ~\u002F.claude\u002Fskills\u002Fadvice\u002FSKILL.md`.\n2. **Extract:** Decision (3-5 sentences) + Artifact (≤150 lines).\n3. **Fan out (parallel):**\n   - Reviewer A: `delegate_task(goal=\"Senior engineer second opinion...\", toolsets=[\"terminal\",\"web\"])` — that's the Hermes equivalent of the Claude subagent.\n   - Reviewer B: `delegate_task(goal=\"Research question...\", toolsets=[\"web\",\"search\"])`\n   - Reviewer C (optional): `delegate_task(goal=\"Second-opinion from a different model...\", toolsets=[\"terminal\",\"web\"])` — note `claude -p` is not logged in.\n4. **Synthesize:** Same table format as canonical skill.\n\n## Worked example: Codex hook review (2026-07-17)\n\nWhen asked to \"review the evidence that the hooks worked\", the natural pattern\nis unit tests + tmux replay. The unit tests passed; the tmux replay showed the\nhook firing; everything looked green. `\u002Fadvice` fan-out found **4 real bugs**:\n\n1. **apply_patch regex was case-sensitive** — silently allowed the canonical `*** Delete File:` (capital D\u002FF) per the Codex\u002FClaude apply_patch grammar.\n2. **`cwd` field-name mismatch** — hook read `payload.working_dir` (Claude shape); Codex 0.144+ nests it under `tool_input.cwd`. Bare relative paths resolved against hook process's cwd, not the caller's.\n3. **Schema trap** — hook emitted `{\"continue\":false,\"stopReason\":\"...\"}`. Codex docs explicitly say these are \"parsed but not supported yet. Codex marks the hook run as failed, reports the error, and continues the tool call.\" My denies were being IGNORED, not enforced.\n4. **Non-dict `tool_input` silent allow** — `_extract_command` returned `\"\"` for `tool_input: [1,2,3]` → `_classify(\"\")` returned None → `_allow()`. The documented fail-closed posture was broken.\n\nNone of these showed up in unit tests because the tests were written to match\nthe hook's expectations, not the spec. The fix chain:\n- Reviewer A (source accuracy, MiniMax-M3): FAIL with file:line evidence\n- Reviewer B (external docs, MiniMax-M3): schema-deviation; fetched learn.chatgpt.com\u002Fdocs\u002Fhooks.md verbatim\n- Reviewer C (adversarial, MiniMax-M3): 9-vector probe, 2 real bypasses + 3 heuristic gaps\n\nAll 4 fixes were inline (`\u003C10 lines` each per `diagnosis-requires-followthrough-or-handoff`); 38-case test suite extended; skill rewritten to surface the Codex schema rules in Pitfall #0 \u002F Codex schema section. Live tmux replay also revealed the deeper Codex 0.144.5 limitation: **`unified_exec` skips PreToolUse entirely** per docs warning. The hook is a guardrail not a boundary — must be paired with sandbox + approval policy + backup.\n\n**Lesson for future `\u002Fadvice` reviews of CLI hook code**: never trust \"the unit tests pass\" alone. Always (a) fetch the vendor's hook schema docs verbatim, (b) drive a live CLI session in tmux to confirm the hook is actually invoked, (c) run an adversarial probe of payload shape edge cases (non-dict types, wrong field names, case-sensitive regex vs spec). All three found different classes of bugs in the same session.\n\n**The \"fixtures+docs\" trap on cross-CLI hook reviews (added 2026-07-30, PR `jleechanorg\u002Fclaude-commands#344`):** A `\u002Fadvice` review on a cross-CLI hook is not complete until the reviewer confirms the hook fires in a real CLI session. Two failure modes that this trap catches:\n\n1. **Codex discovery indirection** — the PR shipped `\u003Crepo>\u002F.codex\u002Fhooks.json` + `\u003Crepo>\u002Fcodex_hooks.json` Stop entries. Vendor docs list those as canonical. Neither was actually executed; Codex dispatches through `~\u002F.codex\u002Fstop-hook-dispatch.sh` and the project's Stop entry just suppresses the legacy fallback. The hook was silently never invoked until `stop-hook-dispatch.sh` was replaced. Two iterations of \"the JSON file is missing, the hook must be wrong\" followed before the indirection was traced.\n2. **Claude v2.1.220 Stop payload schema divergence from statusline docs** — the docs say `model`, `context_window`, and `cost` are present in any lifecycle payload. They are NOT present in the Stop payload (statusline-only). Fixture tests passed against the docs; the live `claude --print` session revealed the missing fields. The unit tests were rewritten with `CLAUDE_LIVE_PAYLOAD` (the actual captured payload) as the regression fixture.\n\n**Reviewer B's mandatory gate for any cross-CLI hook review (effective 2026-07-30):** before approving the verdict, the external-docs reviewer must also confirm:\n\n- A live CLI session has been run for EACH supported CLI (paste the `jq . \"$HOME\u002F.claude\u002Fvar\u002F\u003Chook>\u002Flast.json\"` transcript or equivalent live-payload capture into the synthesis).\n- The unit-test fixtures in `tests\u002Ftest_\u003Chook>.py` reference the captured payloads, NOT the docs' claimed shapes.\n- The discovery indirection is verified for each CLI (e.g. for Codex, the reviewer must confirm `~\u002F.codex\u002Fstop-hook-dispatch.sh` actually invokes the hook, not just sets `local_stop_configured=true`).\n\nIf any of these three are missing, the verdict must be `NEEDS-FIXES` with a specific item: \"live-payload capture missing for CLI X\" or \"discovery indirection unverified for CLI Y\". Do NOT let \"the unit tests pass\" stand as evidence for cross-CLI hook code.\n\nCompanion skill: `~\u002F.hermes\u002Fskills\u002Fcross-cli-hook-integration\u002FSKILL.md` — the full cross-CLI hook recipe including the discovery-indirection table (§1), the live-payload capture protocol (§4), and the per-CLI response-schema rules (§3). Verified 2026-07-30 against Claude v2.1.220, Codex 0.144.5, Cursor 3.11.13, Antigravity, agy 1.1.8.\n\n## Cross-reference\n- Canonical Claude-Code skill: `~\u002F.claude\u002Fskills\u002Fadvice\u002FSKILL.md`\n- Hermes skill paths: `~\u002F.hermes\u002Fskills\u002F` (staging, git-tracked), `~\u002F.hermes_prod\u002Fskills\u002F` (prod runtime)\n- Hermes deploy pipeline: `~\u002F.hermes\u002Fscripts\u002Fdeploy.sh --system hermes` syncs this overlay to prod\n- Codex canonical mirror: `~\u002F.codex\u002Fskills\u002F` archived 2026-06-13; new path is `~\u002F.agents\u002Fskills\u002F`\n- Companion skill `~\u002F.hermes\u002Fskills\u002Fcodex-path-deletion-guard\u002FSKILL.md` — the hook that triggered this review, with full Pitfall #0 (Codex 0.144 unified_exec) and Codex-schema-allowlist details\n- Companion reference `~\u002F.hermes\u002Fskills\u002Fcodex-path-deletion-guard\u002Freferences\u002Fadversarial-probe-2026-07-17.md` — 9-vector probe transcripts + v1-vs-v2 comparison table\n\n---\n\n## Pinned synthesis output format (added 2026-07-15)\n\nEvery `\u002Fadvice` synthesis reply — whether the verdict is \"ship it\", \"needs more changes\", or \"no fix needed\" — MUST end with the same 5-block shape so the user can parse it the same way every session. Tested on the merge_train PR #43 cross-CLI hook review (Jeffrey accepted with no follow-up).\n\n```markdown\n### Recommended next action (one tap)\n[One shell command OR \"no action — PR is ready at the standard green gate\"]\n\n### Evidence table\n| Bug-report claim (file:line) | PR\u002Ffix evidence (file:line) | Test coverage |\n|---|---|---|\n| ... | ... | ... |\n\n### Reviewers consulted\n- Reviewer A (source accuracy, model X): verdict + confidence\n- Reviewer B (external docs, model Y): verdict + confidence\n- Reviewer C (adversarial, model Z): verdict + confidence\n\n### Disagreements not resolved\n[Numbered list of claims where reviewers disagree, with what evidence\nwould settle each one. Skip this section if all three agreed.]\n\n? Memories used: [source:…, ids_or_labels:…, effect:…]\n```\n\nThe Evidence table is the load-bearing piece — it's what makes \"fix as needed\" answers parseable. Without it, the user has to re-read the synthesis to know whether the dispatch was actually justified.\n\n---\n\n## \"Fix as needed\" pattern — no-fix-is-a-valid-answer (added 2026-07-15)\n\nWhen the user says \"fix X as needed and use \u002Fadvice to review first\", the default execution flow is:\n\n1. `\u002Fadvice` review of the existing PR\u002Fdiff against the supplied context (Slack bug report, issue body, doc, etc.).\n2. Map every claim in the supplied context to a concrete diff hunk + test in the existing branch. The Evidence table above is built from this mapping.\n3. **Stop with no dispatch** if every claim is already addressed and the reviewers converged. This is a first-class outcome, not a failure mode — the user wants the question answered, not necessarily new code.\n4. Dispatch via `ao spawn` (NOT `agento` — see Known Pitfalls) only when the Evidence table has unresolved rows.\n\n**Anti-pattern to avoid:** dispatching an `ao spawn` worker \"just in case\" because the task framing implies action. The dispatch adds latency, consumes quota, and produces a noisy PR diff that the user has to review. When reviewers converge and CI is green, the right reply is one tap (`gh pr merge N --auto --squash`) and a `? Memories used:` line — nothing more.\n\n**Provenance:** merge_train PR #43 (jleechanorg\u002Fmerge_train, head SHA `431faca`, 2026-07-15). The supplied context was a 9-section Slack bug report covering 4 separate concerns (installer reinstall, runtime-specific matchers, migration cleanup, OpenCode `apply_patch` paths). All 4 had corresponding diff hunks in the existing single commit; CI was green across 7 GH Actions checks (cross-OS pytest + install.sh smoke + evidence staleness); all 3 reviewers converged. No dispatch.\n\n## Verified 2026-07-21 — `\u002Fadvice` as Gate-3 substitute for the fullrun cycle\n\n**Use this path when all three official review bots are simultaneously unavailable** AND the user is waiting in-thread for a green verdict. Verified on jleechanorg\u002Fdark-factory PR #407 (commit `f461f93`) — both Reviewer A (source-accuracy) and Reviewer B (architecture) ran as Hermes subagents in parallel; combined latency \u003C60 sec vs 51-55 min for the v2.5.7 babysit-cron path.\n\n**Pre-flight signature** (all three must be present):\n```bash\ngh pr checks N --repo OWNER\u002FREPO\n# CodeRabbit       fail    \"Review rate limited\"\n# Cursor Bugbot    skipping \"usage limit reached\"\n# chatgpt-codex-connector skipping \"Codex usage limits\"\n```\n\n**Fan-out recipe** (parallel):\n- Reviewer A: source-accuracy with file:line citations for every claim\n- Reviewer B: architecture + design-intent + audit-chain correctness (catches ordering + opt-in-pattern mismatches that Reviewer A misses)\n- Optional Reviewer C: adversarial probe (9-vector for sandbox\u002Ffork\u002Fedge cases)\n\n**Verdict format** (verbatim, parseable by `green.md` Step 3.4):\n```\nVERDICT: [APPROVED-as-is \u002F NEEDS-FIXES (numbered list) \u002F REJECT]\nREASONING: [3-4 sentences citing file:line evidence]\nRISK: [main risk if merged as-is, one sentence]\nCONFIDENCE: [high \u002F medium \u002F low]\nNUMBERED FINDINGS: [file:line — what — why — suggested fix]\n```\n\n**Then post the synthesis as a PR comment** (`gh pr comment N --body '\u003Csynthesis>'`) so the gate-3 substitute is recorded on the PR thread per `green.md` Step 3.4's \"current-head ... independent adversarial review recorded on the PR\" requirement.\n\n**Cross-reference**: full recipe in `workflow\u002Fdrive-pr-to-green\u002FSKILL.md` v2.5.9 addendum + `references\u002Fadvice-substitute-and-fork-divergent-rebase-2026-07-21.md`.\n\n## \"Needs fixes (cosmetic\u002Fclarity, not blocking)\" middle ground (added 2026-07-20, PR #8467)\n\nThe most common `\u002Fadvice` verdict on a real PR is **\"needs fixes (cosmetic\u002Fclarity, not blocking)\"** with confidence: medium. This is neither \"ship as-is\" nor \"fundamentally wrong\" — the PR shape is correct, but Reviewer A found N soft contradictions or polish issues. The right flow is:\n\n1. **Apply the most-impactful findings inline in a follow-up commit on the same PR branch.** Sort findings by user-visible impact (boundary mismatches → duplicate labels → terminology drift → ortho\u002Fcanon notes). Skip findings whose fix would expand scope beyond the original directive.\n2. **Document the rest in the PR comment thread.** Acknowledge what was not fixed and why. Reviewer A's numbered list becomes a tracked-issue backlog rather than a blocking PR revision.\n3. **Re-push.** The precheck re-runs; the new commit shows up in `git log origin\u002Fmain..HEAD`.\n4. **Re-poll CI** (passive — `gh api` REST endpoints, not GraphQL when rate-limited).\n5. **Do NOT spin up a fresh AO worker.** The PR already exists; the work is in-place. A new AO spawn burns quota on a duplicate diff.\n\n**Anti-pattern:** treating \"needs fixes (not blocking)\" as license to `ao spawn` a worker to do the fixes. The findings are 1-10 line edits in known files — `patch` calls inline are faster, deterministic, and the diff stays reviewable.\n\n**Why this middle ground matters:** the alternative is \"merge as-is\" (defies the verdict) or \"draft follow-up PR\" (loses context, requires CodeRabbit re-review of the whole branch). The follow-up-commit-on-same-branch pattern keeps the PR atomic and reviewable.\n\n**Provenance:** $GITHUB_REPOSITORY PR #8467 (head SHA `0314a434e4`, 2026-07-20). Reviewer A returned 10 findings; 4 most-impactful (band-boundary mismatch, duplicate Exposure label, Ma[REDACTED_OPENAI_KEY]\u002FForbidden-Spell semantic drift, Ao 1-3%\u002Fscene trickle inconsistency) were applied as commit `0314a434e4` on top of `ec74ca2dda`. The other 6 (dual attribution tables, mitigation-token interpretation, \"offending faction\" terminology, A.5 Inevitables FR canon note, etc.) were logged as known follow-ups. Green Gate passed on the new SHA with REAL-mode smoke dispatch via `scripts\u002Fdispatch-real-smoke.sh` from the `wa-green-gate-pr-shape` skill.\n\n**When this middle ground does NOT apply:** if Reviewer A returns VERDICT: misleading or RISK: \u003Ca concrete hazard if shipped as-is>, the right move is either a follow-up PR (not follow-up commit) or explicit user-call on whether to ship with the documented risk. Don't auto-merge a \"misleading\" verdict regardless of \"not blocking\" wording.\n\n14. **\"I don't care about X\" = indifferent to mechanism, not a ban** (learned 2026-07-30, browserclaw-autonomous-browser-control-design.md review). When the operator says \"I don't care about X\" during a design review, the right fix is to **mark X as an implementation detail the operator is indifferent to** — keep X in the design, add a one-line \"operator-indifferent\" note, and move on. The wrong fix is to remove X from the design (verified failure: removed all cookie-promotion language from Goals, CredentialBroker, Security, Recovery, Final-design-decisions, and the transport-preference diagram — operator immediately pushed back with \"browserclaw can store cookies its fine\"). Symptom: you find yourself gutting 6+ sections to \"respect\" a clarifying answer. Counter-symptom: the user complains and you have to restore 6 sections. **Read the meta-question, not the literal one.** Same pattern: \"I don't care how you do X\" \u002F \"any way is fine\" \u002F \"doesn't matter to me\" → operator-indifference clause, not removal.\n15. **Gateway re-injection creates a no-op echo chain — break it on turn 2** (learned 2026-07-30, browserclaw thread, verified 11 consecutive idle turns). When the Slack\u002FHermes gateway re-injects your prior reply as a new \"user\" message (common after gateway shutdown\u002Frestart cycles), the next turn is a forward with no new directive. The wrong response is to keep producing longer status reports that themselves get re-injected. The right response is to reply once with a short \"Idle. Awaiting real directive.\" and stop. If the same echo arrives again (turn 2, turn 3, ...), reply **literally one line** — \"Idle.\" — without any tool calls. Do not re-run the same `grep` for \"verification\" (the state hasn't changed); do not re-explain the work; do not re-post a multi-option menu. The work is done; the gate is silent. When real content eventually arrives, resume normal behavior. Confirmed pattern: every \"Idle.\" turn in the browserclaw thread used zero tool calls and zero new claims — the long-idle review thread stayed parseable when the operator came back.\n16. **Operator preference for env-driven configuration** (learned 2026-07-30, browserclaw thread). When the operator says \"lets have X configurable\" or \"lets make this optional\" or \"other people may have other setups,\" the right encoding is **a `BROWSERCLAW_\u003CTHING>` env var with a sensible default + a `local` opt-out slot**. The wrong encoding is to hardcode \"Slack + email\" (verified failure: original design said \"Slack and email simultaneously,\" operator immediately said \"lets have hermes DM me and lets make this optional\"). Same pattern: any system that has to integrate with the operator's preferred channel\u002Fnotification\u002Fstorage MUST read its target from env, with a default that matches the current operator's setup but an explicit way to redirect or silence it. Document the env vars next to the component, not in a separate \"configuration\" section. (Design-doc-level capture lives in browserclaw §NotificationRouter; this pitfall is the principle.) When the operator says \"I don't care about X\" during a design review, the right fix is to **mark X as an implementation detail the operator is indifferent to** — keep X in the design, add a one-line \"operator-indifferent\" note, and move on. The wrong fix is to remove X from the design (verified failure: removed all cookie-promotion language from Goals, CredentialBroker, Security, Recovery, Final-design-decisions, and the transport-preference diagram — operator immediately pushed back with \"browserclaw can store cookies its fine\"). Symptom: you find yourself gutting 6+ sections to \"respect\" a clarifying answer. Counter-symptom: the user complains and you have to restore 6 sections. **Read the meta-question, not the literal one.** Same pattern: \"I don't care how you do X\" \u002F \"any way is fine\" \u002F \"doesn't matter to me\" → operator-indifference clause, not removal.\n- When external verification requires fetching plain-text from a URL, use the `curl + grep` recipe in [`references\u002Fplain-text-web-extraction-curl-fallback.md`](references\u002Fplain-text-web-extraction-curl-fallback.md) instead of `web_extract` (ddgs backend is search-only; Tavily is disabled per SOUL.md).\n\n17. **\"Default with manual fallback as exception\" = load-bearing binding constraint, not a config setting** (learned 2026-07-30, browserclaw thread). When the operator says \"X is the default, manual fallback is the exception\" or \"I want X automatic, never [manual] unless forced,\" that phrasing encodes a **binding design constraint** — it must appear in the design doc as an explicit clause (e.g. \"manual operator step only after every automated path is exhausted\") and the implementation must enforce it. The wrong encoding is to treat it as a config knob (`--manual-fallback-allowed=false`) — that lets the binding constraint erode over time when a future operator flips the flag. Three concrete patterns: (1) §Goals bullet rewritten as \"**automatically** — the operator should never need to open a browser for routine work, and manual fallback is the exception, not the default\" (bold + \"not the default\"); (2) §3 Recover step 9 rewritten as \"Only if every automated path is exhausted, escalate with a request that the operator open a browser and complete the specific step the system could not\"; (3) §Relationship to existing browserclaw v1 contract explicitly supersedes the v1 \"Manual auth only\" ceiling with the new automatic-auth posture. The Rule: any operator-phrased \"automatic X, manual only when forced\" is a §Goals-level invariant, not a §Configuration-level switch.\n\n18. **`delegate_task` thread-pool capacity failure is silent — check `result[0].get(\"status\") == \"error\"` immediately** (verified 2026-07-21, PR #8488 `\u002Fadvice` fan-out). Three failure modes all return a non-obvious `status: error` payload that is easy to miss:\n    - `\"DaemonThreadPoolExecutor' object has no attribute '_initializer'\"` — pool capacity exhausted, the task DID NOT run\n    - `\"background delegation pool was at capacity\"` — concurrent children limit reached\n    - `\"spawn-failed-but-worktree-exists\"` — see `dispatch-task` SKILL\n    The error message naming can mislead (mentions `_initializer`, not `delegation.max_concurrent_children`), and the failed call returns the same shape (`{\"results\": [{...}], \"note\": ...}`) as a successful one — so a quick `if result[0].status == 'error'` check is mandatory. **Fix:** always check before synthesizing. The fan-out is non-atomic; the right behavior on error is to immediately fall back to inline 3-reviewer reading via `read_file` + `skill_view` on the relevant skill files (per Pitfall #6 below — inline is faster anyway for finite-file-set reviews).\n\n---\n\n## Cross-CLI hook schema verification recipe (added 2026-07-15)\n\nWhen the review question involves cross-CLI hook payloads (Codex \u002F Claude \u002F Gemini \u002F Cursor \u002F OpenCode \u002F Antigravity `agy`), reviewers often need to verify whether field names like `permissionDecision`, `additionalContext`, `patchText`, `apply_patch`, `write_file`, `write_to_file` actually exist in the live vendor docs. The recipe:\n\n```bash\nmkdir -p \u002Ftmp\u002Fadvice-hooks && cd \u002Ftmp\u002Fadvice-hooks\nfor url in \\\n  \"https:\u002F\u002Flearn.chatgpt.com\u002Fdocs\u002Fhooks.md\" \\\n  \"https:\u002F\u002Fgeminicli.com\u002Fdocs\u002Fhooks\u002Freference\u002F\" \\\n  \"https:\u002F\u002Fgeminicli.com\u002Fdocs\u002Fhooks\u002Fbest-practices\u002F\" \\\n  \"https:\u002F\u002Fopencode.ai\u002Fdocs\u002Ftools\u002F\"; do\n  fname=$(echo \"$url\" | sed -E 's|https?:\u002F\u002F([^\u002F]+)\u002F.*|\\1|; s|\\.|_|g').txt\n  curl -fsS \"$url\" -o \"$fname\" || echo \"FAIL $url\"\ndone\n\npython3 - \u003C\u003C'PY'\nfrom pathlib import Path\nterms = [\"write_to_file\",\"write_file\",\"replace\",\"apply_patch\",\"patchText\",\n         \"additionalContext\",\"permissionDecisionReason\",\"statusMessage\",\"timeout\"]\nfor f in Path('.').glob('*.txt'):\n    s = f.read_text(errors='ignore')\n    print(f.name, len(s))\n    for t in terms:\n        i = s.find(t)\n        print(f'  {t}:', 'HIT @', i if i>=0 else 'MISS',\n              s[i:i+300].replace('\\n',' ')[:300] if i>=0 else '')\nPY\n```\n\n**What this gives the reviewer:** ground-truth presence\u002Fabsence of each candidate field name in vendor docs at session time. Reviewer B (the external-docs reviewer) cites the `HIT @ \u003Coffset>` line as file:line evidence for their verdict.\n\n**What this does NOT give:** schema-version drift, undocumented changes between SDK releases, or runtime-specific behaviors that only show up in `--help` output. For those, the reviewer must say \"external verification unavailable\" and downweight their confidence — do not assert the absence of a field as a positive fact just because it didn't appear in fetched docs (research-integrity rule: proving presence needs only one hit, proving absence requires exhausting sources).\n\nSee [`references\u002Fcross-cli-hook-schema-verification.md`](references\u002Fcross-cli-hook-schema-verification.md) for the full transcript (URLs hit, terms searched, hit\u002Fmiss counts) from the 2026-07-15 merge_train PR #43 review. Future agents should re-run the curl loop, not trust the cached transcript verbatim — vendor docs change.\n\n---\n\n## Known pitfalls (extended 2026-07-15)\n\n6. **`agento` is not a CLI on this machine** (verified 2026-07-15, jleechanorg\u002Fmerge_train PR #43 triage). The `agento` SKILL.md description claims it's the entrypoint, but `command -v agento` returns not-found. The actual dispatcher is `ao` (`$HOME\u002F.local\u002Fbin\u002Fao`). When you need to dispatch a coding worker, use `ao spawn --project \u003Cid> --claim-pr \u003CN> --prompt \"...\"`, not `agento`. If `ao project list` doesn't show the target repo, run `ao project add \u003Cpath>` first (interactive prompt — preflight that the path exists before spawning). The `agento` keyword in user messages still routes here, but the underlying command is `ao`.\n7. **Treating \"fix X as needed\" as license to dispatch unconditionally** — see the \"no-fix-is-a-valid-answer\" section above. Dispatch burns quota and produces noisy PRs; the Evidence table tells you whether dispatch is warranted.\n8. **Quoting absence as fact** — see the verification recipe's \"What this does NOT give\" caveat. Reviewer B must explicitly downgrade confidence when external verification is incomplete.\n9. **Skipping state-corruption pre-flight on patch reviews** (learned 2026-07-15, sidekick-swarm-trim): when the artifact is a patch \u002F diff, verify `md5 + size + mtime` of every file the patch targets BEFORE fanning out reviewers. If on-disk state has been replaced with unrelated content (verified failure mode: sidekick\u002FSKILL.md was byte-identical to swarm\u002FSKILL.md since 2026-07-14), the patch will produce `.rej` files when applied, reviewers will quote line numbers from a corrupted source, and you'll spend quota to ship a verdict against the wrong file. Phase -0 takes 5 seconds and prevents 30+ minutes of reviewer churn. Full recipe: [`references\u002Fpatch-review-taxonomy.md`](references\u002Fpatch-review-taxonomy.md) § \"State-corruption pre-flight\".\n10. **Patch hunks titled \"fix overclaim\" \u002F \"correct attribution\" \u002F \"remove inaccurate claim\" require EXTRA scrutiny** (learned 2026-07-15): the author has already convinced themselves the original claim is wrong, so they're working backwards. Verify the NEW disclaimer against the cited source — does the thing they're disclaiming actually exist? Common failure: patch removes an accurate paraphrase and replaces it with a strawman that denies real source features (verified this session: Fusion's two headline techniques ARE dynamic mid-session routing + cache-preserving model switches; the \"overclaim fix\" denied both).\n11. **`git apply --stat` from a non-repo parent dir is NOT a valid pre-flight** (learned 2026-07-20, jleechanai `C09GRLXF9GR\u002Fp1784582518.247009`, infra03q patch bundle). When the artifact is a patch from a Slack attachment or `~\u002FDownloads`, `cd $HOME && git apply --stat \u003Cpatch>` exits 0 even when every target file is missing — missing-file warnings get treated as warnings rather than errors at the parent level. The gating signal is `git apply --check` from the repo root that actually contains the patch's target tree. See `finish-the-job\u002Freferences\u002Fpatch-bundle-cwd-preflight-2026-07-20.md` for the full recipe. Companion to pitfall #9 — file-existence (cheap check) + content-match (`md5 + size + mtime`, full check) + hunk-applicability (`git apply --check`, gating check) form a layered defense.\n12. **`\u002Fsuper` and `\u002Faar` resolve differently than session memory suggests** (learned 2026-07-20). `\u002Fsuper` is Superpowers Cloud Build dispatch (remote GLM-5.2 box) per the 2026-07-20 rewrite of `~\u002F.claude\u002Fcommands\u002Fsuper.md` — NOT the legacy local `claudeg` thin-router. `\u002Faar` = `\u002Faccept-adapt-reject` (feedback triage into Accept\u002FAdapt\u002FReject), NOT a generic after-action-review. When `\u002Fadvice` says \"dispatch via `\u002Fsuper`\", verify the user's intent matches the dispatch semantics before quoting the slash command back.\n14. **\"I don't care about X\" = indifferent to mechanism, not a ban** (learned 2026-07-30, browserclaw-autonomous-browser-control-design.md review). When the operator says \"I don't care about X\" during a design review, the right fix is to **mark X as an implementation detail the operator is indifferent to** — keep X in the design, add a one-line \"operator-indifferent\" note, and move on. The wrong fix is to remove X from the design (verified failure: removed all cookie-promotion language from Goals, CredentialBroker, Security, Recovery, Final-design-decisions, and the transport-preference diagram — operator immediately pushed back with \"browserclaw can store cookies its fine\"). Symptom: you find yourself gutting 6+ sections to \"respect\" a clarifying answer. Counter-symptom: the user complains and you have to restore 6 sections. **Read the meta-question, not the literal one.** Same pattern: \"I don't care how you do X\" \u002F \"any way is fine\" \u002F \"doesn't matter to me\" → operator-indifference clause, not removal.\n15. **Gateway re-injection creates a no-op echo chain — break it on turn 2** (learned 2026-07-30, browserclaw thread; reinforced 2026-07-30, superpowers\u002Fgsd\u002Fgrill-me thread, 20+ consecutive idle turns). When the Slack\u002FHermes gateway re-injects your prior reply as a new \"user\" message (common after gateway shutdown\u002Frestart cycles), the next turn is a forward with no new directive. The wrong response is to keep producing longer status reports that themselves get re-injected. The right response is to reply once with a short \"Idle. Awaiting real directive.\" and stop. If the same echo arrives again (turn 2, turn 3), reply **literally one line** — \"Idle.\" — without any tool calls. Do not re-run the same `grep` for \"verification\" (the state hasn't changed); do not re-explain the work; do not re-post the multi-option menu. The work is done; the gate is silent. Verified pattern: 11 consecutive idle turns in one session, all single-line replies, zero tool calls, all preserved the operator's review-thread context for when they next engage.\n\n    **Anti-pattern: emitting structured-report replies on echo turns** (learned 2026-07-30, superpowers\u002Fgsd\u002Fgrill-me thread, 20+ idle turns). Even after correctly identifying the echo chain and citing the SOUL.md `never-hallucinate-no-new-content` rule, the agent kept producing Healthy\u002FRisky\u002FBlocked sections, multi-option decision menus, and \"Memories used\" footers on every echo turn — each ~200-500 words, each structurally identical to a real report, each one more candidate for the next re-injection. **The report template is itself the failure mode on echo turns.** The right output for turn 2+ of the echo chain is one literal line (\"Idle.\") with NO sections, NO menus, NO footer, NO `? Memories used:` line. If you feel the urge to write a structured status update on an echo turn, that urge is the bug — resist it. The structured template is for real directives; the literal one-liner is for echoes. Confirmed: the long-idle thread stayed parseable across ~20 idle turns only when the operator's gateway finally started emitting templated queue notices instead of echo-looping the prior reply.\n\n15a. **Multi-hour gateway stalls need durable state, not just one-line replies** (learned 2026-07-30, browserclaw thread, ~3 hours of stall). Pitfall #15 covers the per-turn reply discipline; this pitfall covers the *system* discipline when the stall extends beyond a few turns. After 5–10 idle turns with no real operator directive: (a) persist the work-product paths as durable memory — file paths, line ranges, commit SHAs (or absent), PR numbers (or absent) — so a fresh session can recover state without re-deriving 30+ turns of context; (b) capture any unresolved decisions to `~\u002F.hermes\u002Fmemory.md` or the project's `specs\u002F` directory, not just in the thread; (c) if the operator's intent is unambiguous, write the work product to disk even if no PR\u002Fdispatch is happening (design docs in `~\u002F.hermes\u002Fcache\u002Fdocuments\u002F`, plans in `projects\u002F\u003Crepo>\u002Fdocs\u002Fplans\u002F`); (d) do NOT delete in-progress artifacts because \"they're not authoritative yet\" — a recovery agent needs the partial state to continue. Verified pattern: browserclaw thread stalled ~3 hours with the design doc + TDD plan + 4 D-patches all on disk at known paths; recovery means point at the paths, not re-run the conversation. Anti-pattern: keeping everything in the conversation memory and trusting the session resume. When the gateway finally responds with a real directive, state the recovered state in the first 50 words — \"Doc at path X (Y lines, Z patches verified), TDD plan at path W (N tasks), no PR open, awaiting execute directive\" — and let the operator redirect from there.\n",{"name":5,"version":33,"description":7},"1.5.0","main","d57b06df00b496fc5debe2002b49987696f02a8c","hermes\u002Fskills\u002Fadvice",0,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills","https:\u002F\u002Fgithub.com\u002Fjleechanorg","2026-11-14 14:55:35",{"source":8,"skillName":5,"commands":42,"prompt":52,"zipAvailable":53},[43,46,49],{"tool":44,"command":45},"npx","npx skills add jleechanorg\u002Fjleechan-skills --skill advice",{"tool":47,"command":48},"bunx","bunx skills add jleechanorg\u002Fjleechan-skills --skill advice",{"tool":50,"command":51},"pnpm","pnpm dlx skills add jleechanorg\u002Fjleechan-skills --skill advice","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fadvice\u002FSKILL.md",true,[55,61,65,69],{"path":56,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":60},"references\u002Fcross-cli-hook-schema-verification.md","REFERENCE","参考文档",3586,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fadvice\u002Freferences\u002Fcross-cli-hook-schema-verification.md",{"path":62,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":63,"sourceHtmlUrl":64},"references\u002Fdesign-spec-review-template.md",8408,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fadvice\u002Freferences\u002Fdesign-spec-review-template.md",{"path":66,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Fpatch-review-taxonomy.md",10860,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fadvice\u002Freferences\u002Fpatch-review-taxonomy.md",{"path":70,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fplain-text-web-extraction-curl-fallback.md",3776,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fadvice\u002Freferences\u002Fplain-text-web-extraction-curl-fallback.md",[74,92,113,127,140,156],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":28},"01M716Y5MTJ6GYJZ2ATXCJK8G4","instinct","Use when the user invokes \u002Finstinct or \u002Fin, or asks to \"message Instinct\", \"ask Instinct\", \"tell Instinct\", \"check Instinct\", or read replies from the configured peer assistant. iMessage first, WhatsApp Web as fallback.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finstinct\u002FSKILL.md",[],[76,81,82,83,84,85,86,87,88,89,90,91],"user","when","replies","check","use","identity","whatsapp","gmail","read","message","ask",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":103,"publishedAt":28},"01M716Y4HF7FVVMJSA2CCVN5VF","hr","Compatibility alias for history-resume; produce the same fresh-state, provenance-aware resume briefing.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhr\u002FSKILL.md",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[94,104,105,106,25,107,108,109,110,111,112],"resume","compatibility","provenance","history","produce","alias","briefing","state","fresh",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":28},"01M716Y1FFNFKFJYYKF8HQA6T8","history-resume","Resume briefing for the current repository branch or worktree using fresh state and admitted history sources.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhistory-resume\u002FSKILL.md",[119],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},[107,104,121,122,81,123,110,124,25,125,126,111,112],"history resume","branch","analysis","repository","worktree","sources",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":28},"01M716XWXJ8EPHK4RH9T14TR85","grok","Alias for the canonical grokbot browser conversation workflow; \u002Fgrok talks to the Grok bot the same way \u002Fdot talks to Dot.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgrok\u002FSKILL.md",[],[129,134,135,136,25,22,109,137,138,139],"dot","bot","workflow","conversation","browser","grokbot",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":28},"01M70N9Q07DTE0EW5KFXMMMSJ0","codexa-bench","Compare `codexa` and normal `codex` on a fair split of comparable work by default; use `--strict` for duplicate runs of the exact same task.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcodexa-bench\u002FSKILL.md",[],[147,148,149,85,150,25,151,152,153,154,155],"codexa bench","work","split","default","duplicate","task","compare","normal","codex",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":160,"licenseFileUrl":161,"sourceHtmlUrl":162,"categories":163,"keywords":175,"publishedAt":28},"01M6C24S2X60SP8BBFGAEKPEGW","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FSKILL.md",[164,169,172],{"categoryNo":165,"categoryName":166,"taxonomyType":167,"taxonomyTypeDesc":168},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":170,"categoryName":171,"taxonomyType":167,"taxonomyTypeDesc":168},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":173,"categoryName":174,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000032","设计师",[176,177,178,85,179,180,181,81,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,82,200],"frontend","design","frontend design","generic","ui design","react","html","components","code","artifacts","ui","aesthetics","Production","web components","landing","applications","quality","web","css","create","examples","with","react components","web ui","pages"]