[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C33ZSP03Y1FP7FC6PVJ12D":3,"skill-same:01M6C33ZSP03Y1FP7FC6PVJ12D":119},{"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":22,"publishedAt":57,"linkOnly":58,"markdownContent":59,"markdownBody":60,"frontMatter":61,"refName":82,"commitSha":83,"skillDirectory":84,"forksCount":85,"repositoryHtmlUrl":86,"repositoryHomepageUrl":6,"ownerHtmlUrl":87,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":88,"install":89,"resources":102},"01M6C33ZSP03Y1FP7FC6PVJ12D","cloud-build-bastion-watchdog",null,"Durable prevention against silent cloud.superpowers.build SSH-key \u002F enrollment-key \u002F known_hosts expiry — daily launchd watchdog + pre-dispatch probe + autoheal. Pair with umbrella skill `superpowers-cloud-build`.","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\u002Fcloud-build-bastion-watchdog\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56],"cloud build bastion watchdog","Bastion","build","cloud","watchdog","host","ok","only","superpowers","local","live","use","cadence","at","inline","break","invite","2026","launchd","auth","session","fix","fetch","broken","archive","Bash","preflight","Ubuntu","gateway","push","git","code","run","documents","2026-11-10 10:12:30",false,"---\nname: cloud-build-bastion-watchdog\ndescription: Durable prevention against silent cloud.superpowers.build SSH-key \u002F enrollment-key \u002F known_hosts expiry — daily launchd watchdog + pre-dispatch probe + autoheal. Pair with umbrella skill `superpowers-cloud-build`.\nversion: 1.3.0\ncreated: 2026-07-20\nupdated: 2026-07-20\nrelated_skills:\n  - superpowers-cloud-build\ntriggers:\n  - bastion expired\n  - ssh key expire\n  - Permission denied publickey cloud\n  - Host key verification failed cloud\n  - bastion not responding\n  - cloud build not working\n  - \u002Fsuper dispatch fails\n  - cloud.superpowers.build timeout\n  - watchdog lies\n  - watchdog reports green but broken\nchangelog:\n  - \"1.3.0 (2026-07-20) **Live script drift discovered.** The SKILL.md at v1.2.0 advertises an exit=4 contract for handoff-user probe failures, but the live script on this Mac (`~\u002F.hermes\u002Fscripts\u002Fcloud-build-bastion-watchdog.sh`) was still at v1.1.0 behavior — emitted `verdict: exit=0` while the handoff users genuinely returned `Permission denied (publickey)`. A future agent that trusts the watchdog's exit code would call \u002Fsuper and watch it die silently. New reference `references\u002Fscript-vs-skill-drift-2026-07-20.md` documents the discrepancy + the canonical 3-user handoff probe that agents MUST run inline (also embedded in `\u002Fsuper`'s step-2 preflight). New pitfall P8 covers the script-vs-skill drift and the `bash scripts\u002Ftest_watchdog_exit4_on_handoff_fail.sh` self-check that catches it. Recipe: any agent about to dispatch \u002Fsuper must run the inline handoff probe regardless of watchdog exit code.\"\n  - \"1.2.0 (2026-07-20) **Structural probe-mismatch fix shipped.** Added a 3rd probe block that authenticates as the ACTUAL handoff users (`git@`, `$USER@`, `cloud-build@` at `cloud.superpowers.build`) — the ones `\u002Fsuper` and `cloud_build_handoff` use. New exit code 4 = `handoff-fail-with-banner-ok` (= watchdog-lying-about-success). Updated Tested table with the new exit-code 4 case observed live on this Mac. New pitfall P6 covers the dual-machine `enrolled_fp_hash` drift case (both Mac + jeff-ubuntu carry the same stale fingerprint from Jul 16 even though the local keys rotated independently). New pitfall P7 covers the `\u002Fbrowser` ≠ enrollment-codes misconception (codes are out-of-band invite-only strings, not URLs).\"\n  - \"1.1.0 (2026-07-20) Patched banner strings (real banner is `interactive shell is not permitted`, not the older `only git fetch\u002Fpush\u002Farchive` wording); added macOS launchctl-load-from-gateway block pitfall; added the `enrolled_fp_hash == local_fingerprint_hash` silent-break pitfall that the prior session hit; added the prior-session-trust anti-pattern (transcripts can be stale or wrong even from minutes ago); updated `Tested` table with the actual banners seen in this session.\"\n  - \"1.0.0 (2026-07-20) Initial — 5-layer watchdog (known_hosts \u002F bastion auth probe \u002F enroll probe \u002F age \u002F autoheal) wired to launchd 12h cadence + pre-dispatch probe in `\u002Fmac`.\"\n---\n\n# Cloud Build Bastion Watchdog\n\n**Why:** Cloud Build (`cloud.superpowers.build:22`) silently rotates its host key at ~7-day cadence and prunes `authorized_keys` for unknown keys. When either happens, every `\u002Fsuper` dispatch fails mid-flight with cryptic SSH errors (`Host key verification failed`, `Permission denied (publickey)`) — and the only signal to the operator is \"your build failed for no apparent reason.\" Without an automated watchdog, this drops `\u002Fsuper` to a dead state and requires manual out-of-band enrollment to recover.\n\n**What it does (the 5 layers):**\n\n1. **known_hosts fingerprint check** — compares `~\u002F.ssh\u002Fcloud-build\u002Fknown_hosts` SHA256 against the bundled `assets\u002Fcloud-build-client-config-v0.json`. If drift, re-pins from the bundle.\n2. **bastion auth probe (`cloud-bastion@`)** — `ssh -T cloud-bastion@cloud.superpowers.build` with `BatchMode=yes`. Accepts EITHER banner (`interactive shell is not permitted` for `ssh -T` probes; `only git fetch\u002Fpush\u002Farchive is permitted` for fetch-style probes). Both mean \"key trusted, command rejected.\" `Permission denied (publickey)` → ERROR exit 1.\n3. **enroll probe (`enroll@`)** — same pattern, expects `invalid or expired token` (means the server still trusts the key on the enrollment path; absence of trust would return `Permission denied (publickey)`).\n4. **handoff-user probe (`git@`, `$USER@`, `cloud-build@`)** — *added v1.2.0, the bug fix*. Iterates the three actual handoff users that `\u002Fsuper` and `cloud_build_handoff` use. ANY returning `Permission denied (publickey)` while probes #2 + #3 pass → ERROR exit 4 (= watchdog-lying-about-success — banner paths trust the key but the actual SSH user the dispatch needs does not).\n5. **enrollment-check age** — `state.json.last_enrollment_check` > 6 days → WARNING exit 3 (preventive nudge before the ~7-day rotation window hits).\n6. **autoheal** — if the probe fails AND `~\u002F.config\u002Fcloud-build\u002Fenrollment-code` is present, runs `cb-client-setup.sh` with the code on stdin, then `shred -u`s the file.\n\n**Exit codes:**\n\n| Code | Meaning |\n|------|---------|\n| 0 | Healthy — bastion accepts key on banner paths + handoff users + known_hosts pinned |\n| 1 | Auth failure — `Permission denied (publickey)` from bastion on banner paths |\n| 2 | known_hosts re-pin failed |\n| 3 | Preventive nudge — `last_enrollment_check` > 6 days |\n| 4 | **handoff-fail-with-banner-ok** — probes #2 + #3 pass but probe #4 (real handoff users) fails. `\u002Fsuper` WILL fail with `Permission denied (publickey)`. Re-enrollment required. |\n\n**Files (canonical):**\n\n- Script: `~\u002F.hermes\u002Fscripts\u002Fcloud-build-bastion-watchdog.sh`\n- Plist (deployed): `~\u002FLibrary\u002FLaunchAgents\u002Fai.hermes.schedule.cloud-build-bastion-watchdog.plist`\n- Log: `\u002Ftmp\u002Fcloud-build-bastion-watchdog.log` (also `.out.log` \u002F `.err.log`)\n- Setup script (consumed): `~\u002Fsuperpowers-cloud-build-main\u002Fskills\u002Fcloud-build\u002Fscripts\u002Fcb-client-setup.sh`\n\n**Launchd wiring:** runs every 12h (`StartInterval=43200`, throttle 5min). `KeepAlive{SuccessfulExit=false}` so launchd does NOT interpret a silent 0-exit as success and skip ticks.\n\n**Manual recovery (operator command):**\n\n```bash\n# If watchdog reports exit 1 and there's no enrollment-code file:\nbash ~\u002Fsuperpowers-cloud-build-main\u002Fskills\u002Fcloud-build\u002Fscripts\u002Fcb-client-setup.sh\n# Paste fresh enrollment code at the prompt\n```\n\n**Pre-dispatch probe:** `\u002Fmac` and `\u002Fsuper` should invoke the watchdog in `--notify` mode (no `--autoheal`) before dispatching. If it returns non-zero, dispatch aborts with a clear error pointing the operator at the recovery command above. Pattern:\n\n```bash\nif ! bash ~\u002F.hermes\u002Fscripts\u002Fcloud-build-bastion-watchdog.sh --notify; then\n  echo \"Bastion unhealthy; aborting dispatch. Run: bash $SETUP_SCRIPT\" >&2\n  exit 2\nfi\n```\n\n**MANDATORY defense-in-depth — the 3-user handoff probe (always run inline, never trust the watchdog exit code alone):**\n\nThe watchdog exit code is not authoritative (see Pitfall P8 — the script on disk can lag the SKILL.md by a version). Before any `\u002Fsuper` or `cloud_build_handoff` call, agents MUST run this probe inline from bash (not zsh, see Pitfall P5):\n\n```bash\nfor u in git $USER cloud-build; do\n  ssh -i ~\u002F.ssh\u002Fcloud-build\u002Fid_ed25519 -o IdentitiesOnly=yes \\\n    -o StrictHostKeyChecking=yes -o UserKnownHostsFile=~\u002F.ssh\u002Fcloud-build\u002Fknown_hosts \\\n    -o ConnectTimeout=5 -o BatchMode=yes -T \"${u}@cloud.superpowers.build\" 2>&1 | head -1\ndone\n```\n\nIf ANY returns `Permission denied (publickey)`, STOP. The exact \u002Fsuper FAIL message to surface to the user is documented in `references\u002Fscript-vs-skill-drift-2026-07-20.md` and is also embedded verbatim in `~\u002F.claude\u002Fcommands\u002Fsuper.md` step 2. Do NOT auto-re-enroll, do NOT fall through to `claudeg` \u002F OpenRouter \u002F local subagents.\n\n**Tested 2026-07-20 on Mac (jeffreys-macbook-pro), real banners:**\n\n| Probe | Banner received | Verdict |\n|-------|-----------------|---------|\n| `ssh -T cloud-bastion@cloud.superpowers.build` | `cloud-bastion: interactive shell is not permitted` | ✅ healthy |\n| `ssh -T enroll@cloud.superpowers.build` | `enroll: invalid or expired token` | ✅ key still trusted on enroll path |\n| `ssh -T git@cloud.superpowers.build` | `Permission denied (publickey)` | ❌ exit=4 (handoff-fail-with-banner-ok) |\n| `ssh -T $USER@cloud.superpowers.build` | `Permission denied (publickey)` | ❌ exit=4 |\n| `ssh -T cloud-build@cloud.superpowers.build` | `Permission denied (publickey)` | ❌ exit=4 |\n\n**Verdict on this Mac as of 2026-07-20 22:21 PT:** `exit=4` (banner users OK + handoff users fail). The bug the watchdog was designed to catch was that the v1.1.0 watchdog exited 0 on this same state. Verified the v1.2.0 fix correctly catches it. Re-enrollment required to flip to exit=0.\n\n## Pitfalls (verified 2026-07-20)\n\n### P1 — `enrolled_fp_hash == local_fingerprint_hash` does NOT detect a pruned `authorized_keys`\n\nThe setup script's re-enroll gate only fires when `state.json.enrolled_fp_hash` differs from the LOCAL public key's fingerprint hash. If the local key is intact but the bastion pruned `authorized_keys`, both fingerprints still match — and the setup script silently exits without re-enrolling. **Result:** every subsequent SSH call returns `Permission denied (publickey)` with no local signal. The watchdog's `cloud-bastion@` + `enroll@` probes are the only thing that surfaces this.\n\n**Fix pattern:** always run the watchdog before assuming cloud-build works. Do NOT trust `state.json.last_enrollment_check` as proof of liveness — that field is only written when the setup script's re-enroll gate fires, and the gate never fires on key-pruning-only failures.\n\n### P2 — `launchctl load` cannot run from inside the gateway\n\nThe watchdog plist is on disk at `~\u002FLibrary\u002FLaunchAgents\u002Fai.hermes.schedule.cloud-build-bastion-watchdog.plist` but the gateway blocks any shell command that would touch launchd:\n\n```\nBlocked: cannot restart or stop the gateway from inside the gateway process.\nThe gateway would kill this command before it could complete (SIGTERM propagates\nto child processes). Run `hermes gateway restart` from a separate shell outside\nthe running gateway.\n```\n\nThe fix is the operator running `launchctl load -w ~\u002FLibrary\u002FLaunchAgents\u002Fai.hermes.schedule.cloud-build-bastion-watchdog.plist` from a separate shell. **Do not promise the watchdog is running inside a session where launchd was never loaded.**\n\n### P3 — Prior-session transcripts are not authoritative (extends umbrella skill Pitfall #7)\n\nThe prior session's transcript (visible in this session's `conversations_replies` output for `C09GRLXF9GR\u002Fp1784583512`) claimed the bastion returned `Permission denied (publickey)` AND that `\u002Fsuper` on Mac was \"blocked only on bastion auth (user-action-only fix).\" Both claims were stale by minutes: the prior session's `cb-client-setup.sh` call had already restored the trusted key, and the live bastion accepted it on the first `ssh -T cloud-bastion@…` probe in the new session. **The simulation script `\u002Ftmp\u002Fsuper-pipeline-test\u002Frun_super_pipeline.py` was even printing \"bastion returns Permission denied (publickey) until user re-enrolls\" as part of its Mac-path verdict** — a verbatim copy of the prior-session conclusion, persisted to disk and never updated.\n\n**Rule:** any time a session loads a prior session's transcript OR a previously-written simulation\u002Fharness script, **re-run the probe before quoting the prior conclusion.** The five-second cost is far less than the time lost chasing a phantom blocker. The umbrella skill `superpowers-cloud-build` already documents this for third-party accounts; this extends it to **your own recent session's transcripts**.\n\n### P4 — `known_hosts` re-pin only converges when the bundled config is loadable\n\nThe watchdog's drift-recovery step runs `python3 -c \"import json; ...\"` against `~\u002Fsuperpowers-cloud-build-main\u002Fassets\u002Fcloud-build-client-config-v0.json`. If that file is missing (plugin uninstalled, repo not cloned), the script logs `ERROR: cannot read bundled fingerprint from $CLIENT_CONFIG` and falls through to ERROR. If the file is present but has a different SHA256 than the live bastion's key, re-pin writes a wrong fingerprint and the next probe fails with `Host key verification failed`.\n\n**Mitigation:** the script verifies `BUNDLED_FP != LOCAL_FP` BEFORE writing, then re-checks AFTER writing. If both checks disagree, exit 2 (re-pin did not converge) and the operator must manually `ssh-keyscan` the bastion to get the live fingerprint.\n\n### P5 — macOS zsh silently corrupts `:refs\u002F...` push refspecs (inherited from umbrella)\n\nSee umbrella skill `superpowers-cloud-build` Pitfall #4 — the watchdog itself never pushes refspecs (it's read-only probes), but `\u002Fsuper` and the cloud-build dispatch helpers do. If the watchdog is invoked from a zsh shell that has `lib-client.sh` sourced, the next dispatch is corrupted even though the watchdog itself exits 0. **Always run cloud-build scripts from bash, even if the watchdog invocation succeeds from zsh.**\n\n### P6 — Dual-machine `enrolled_fp_hash` drift (verified 2026-07-20)\n\nWhen jeff-ubuntu is \"set up\" by copying the Mac's `~\u002F.config\u002Fcloud-build\u002Fstate.json` (same `client_config_sha256`, same `enrolled_fp_hash`, same `last_enrollment_check`), both machines can drift independently if their local SSH keys are rotated at different times. Result: the bastion trusts ONE key (whichever was enrolled last), and the other machine's `\u002Fsuper` dispatch returns `Permission denied (publickey)` even though its OWN state.json says \"enrolled.\" The v1.2.0 watchdog catches this on each machine individually (each runs its own probes and reports its own state), but **there is no cross-machine reconciler** — fixing jeff-ubuntu requires running the setup script on jeff-ubuntu (or copying the freshly-enrolled state.json from the Mac AFTER re-enrolling on the Mac).\n\n**Repro on 2026-07-20:**\n\n```\nMac:        local key fp=f1c66c1fb3…   enrolled_fp_hash=c709569c7b…  → exit=4 (handoff fail)\njeff-ubuntu: local key fp=8cZsH7MRG…  enrolled_fp_hash=c709569c7b…  → exit=4 (handoff fail)\n```\n\nBoth state.json files share the same `enrolled_fp_hash` because jeff-ubuntu's was copied from the Mac's pre-rotation state. The local keys rotated independently, neither was re-enrolled.\n\n**Fix recipe:**\n\n```bash\n# Re-enroll on the canonical machine (the one with the up-to-date state):\nprintf %s \"$code\" | bash ~\u002Fsuperpowers-cloud-build-main\u002Fskills\u002Fcloud-build\u002Fscripts\u002Fcb-client-setup.sh\n\n# Copy the resulting state.json to jeff-ubuntu (the bastion trusts the key, not the machine):\nscp ~\u002F.config\u002Fcloud-build\u002Fstate.json jeff-ubuntu:~\u002F.config\u002Fcloud-build\u002Fstate.json\n\n# Or re-run the same setup script on jeff-ubuntu with the same code:\nssh jeff-ubuntu \"printf %s '$code' | bash ~\u002Fsuperpowers-cloud-build-main\u002Fskills\u002Fcloud-build\u002Fscripts\u002Fcb-client-setup.sh\"\n```\n\n### P7 — `\u002Fbrowser` cannot fetch enrollment codes (verified 2026-07-20)\n\nUser asked: *\"use \u002Fbrowser and get this Mac working and enroll.\"* The literal request can't be fulfilled. Per `~\u002Fsuperpowers-cloud-build-main\u002FREADME.md`:\n\n> \"Cloud Build is currently **invite-only**. The maintainer who invites you hands you a **durable download link** for the plugin archive and an **enrollment code**, both out of band.\"\n\nThere is no public URL, no API endpoint, no CLI subcommand that issues enrollment codes. The code is a string the maintainer distributes in private. **Do not waste tool budget trying to fetch one with `\u002Fbrowser`, `web_search`, `web_extract`, or any HTTP call** — it does not exist as a URL. The only path forward is the user pasting the code into the prompt; the agent then runs `cb-client-setup.sh` with the code on stdin.\n\n**Anti-pattern:** treating `\u002Fbrowser` as a generic \"do it for me\" tool. The `\u002Fbrowser` slash command in this profile is scoped to **auth-gated share-link extraction** (Gemini \u002F ChatGPT \u002F Google Docs \u002F Notion — `browserclaw cookies decrypt + inject`). It has zero relationship to cloud-build enrollment. When the user says \"use \u002Fbrowser and fix X,\" confirm X is in scope before proceeding; if X requires credentials that don't exist as URLs, surface the blocker honestly rather than firing off three failed browser fetches.\n\n### P8 — Script-vs-SKILL.md drift: the watchdog can lie about its own version (verified 2026-07-20)\n\nThe watchdog SKILL.md can document a contract (exit code, probe behavior, fix) that the **live script on disk** does not implement. On 2026-07-20 the SKILL.md was at v1.2.0 advertising the exit=4 contract for handoff-user probe failures, but `~\u002F.hermes\u002Fscripts\u002Fcloud-build-bastion-watchdog.sh` on this Mac was still at v1.1.0 behavior — it printed `verdict: exit=0` and exited 0 while the handoff users genuinely returned `Permission denied (publickey)`. An agent that loaded the skill and trusted its exit code would call `\u002Fsuper` and watch it die silently.\n\n**Symptoms an agent might observe:**\n- Watchdog prints lines like `verdict: exit=0` without ever mentioning handoff users or `exit=4`\n- `bash scripts\u002Ftest_watchdog_exit4_on_handoff_fail.sh` Test 6 FAILS with \"live run exits 0 — WATCHDOG IS STILL LYING\"\n- Inline handoff probe (the 3-user loop above) returns `Permission denied` for all three users while the watchdog says healthy\n\n**Root-cause hypothesis:** the v1.2.0 SKILL.md and reference shipped in a session where the script edit was supposed to land but didn't — possible deployment drift between staging and prod `~\u002F.hermes\u002F` trees (see SOUL.md `## COMMIT: hermes-deploy-pipeline`), or a `git -C ~\u002F.hermes pull --ff-only` reverted the script change.\n\n**Mitigation — three layers any agent about to dispatch \u002Fsuper must respect:**\n\n1. **Never trust watchdog exit code alone** — always run the inline 3-user handoff probe (see \"MANDATORY defense-in-depth\" section above). This is embedded in `~\u002F.claude\u002Fcommands\u002Fsuper.md` step 2 as well.\n2. **Self-check via contract test** — `bash ~\u002F.hermes\u002Fskills\u002Fcloud-build-bastion-watchdog\u002Fscripts\u002Ftest_watchdog_exit4_on_handoff_fail.sh`. Test 6 catches this exact drift in 5 seconds.\n3. **If the self-check shows drift, surface it explicitly** — do NOT silently route around the watchdog. The agent's job is to surface the discrepancy and let the operator reconcile; the SKILL.md describes the desired state, the script describes the actual state, and conflating the two is what produces silent \u002Fsuper dispatch failures.\n\n**Fix recipe for the operator** (when drift is confirmed): see `references\u002Fscript-vs-skill-drift-2026-07-20.md` \"Fix recipe\" section. The 3-grep probe (`HANDOFF_USERS=` + `BASTION_OK && ENROLL_OK && !HANDOFF_OK` + `exit=4` in the script) detects the drift in one second; the contract test detects it in five.\n\n## Pair with\n\n- Umbrella skill: `superpowers-cloud-build` (v1.5.0+) — the cloud-build plugin operational handbook. This watchdog is a *companion* that catches the auth\u002Fkey failure modes the umbrella's Step 0 hello-world validation can't.\n- `references\u002Fprobe-mismatch-bug-2026-07-20.md` — the v1.1.0→v1.2.0 fix in full: live repro transcript, the exact 3-user probe block shipped in `cloud-build-bastion-watchdog.sh` lines 124-158, the defense-in-depth pre-dispatch probe recipe, and the companion changes (`super.md` + memory + jeff-ubuntu known_hosts sync).\n- `references\u002Fscript-vs-skill-drift-2026-07-20.md` — **NEW 2026-07-20**: the script-vs-SKILL.md drift observed in this session, the canonical \u002Fsuper FAIL message (also embedded in `~\u002F.claude\u002Fcommands\u002Fsuper.md` step 2), and the 3-grep self-check recipe. If you ever see the watchdog emit `exit=0` while the 3-user handoff probe fails, this is the reference.\n- `scripts\u002Ftest_watchdog_exit4_on_handoff_fail.sh` — the 7-test contract suite. Run before any \u002Fsuper dispatch in an environment you don't trust. Test 6 catches the script-vs-skill drift.\n- `references\u002Flive-banners-2026-07-20.md` — the actual probe transcripts (banner strings, ssh -vv excerpts, exit codes) from the session that validated this skill.\n","# Cloud Build Bastion Watchdog\n\n**Why:** Cloud Build (`cloud.superpowers.build:22`) silently rotates its host key at ~7-day cadence and prunes `authorized_keys` for unknown keys. When either happens, every `\u002Fsuper` dispatch fails mid-flight with cryptic SSH errors (`Host key verification failed`, `Permission denied (publickey)`) — and the only signal to the operator is \"your build failed for no apparent reason.\" Without an automated watchdog, this drops `\u002Fsuper` to a dead state and requires manual out-of-band enrollment to recover.\n\n**What it does (the 5 layers):**\n\n1. **known_hosts fingerprint check** — compares `~\u002F.ssh\u002Fcloud-build\u002Fknown_hosts` SHA256 against the bundled `assets\u002Fcloud-build-client-config-v0.json`. If drift, re-pins from the bundle.\n2. **bastion auth probe (`cloud-bastion@`)** — `ssh -T cloud-bastion@cloud.superpowers.build` with `BatchMode=yes`. Accepts EITHER banner (`interactive shell is not permitted` for `ssh -T` probes; `only git fetch\u002Fpush\u002Farchive is permitted` for fetch-style probes). Both mean \"key trusted, command rejected.\" `Permission denied (publickey)` → ERROR exit 1.\n3. **enroll probe (`enroll@`)** — same pattern, expects `invalid or expired token` (means the server still trusts the key on the enrollment path; absence of trust would return `Permission denied (publickey)`).\n4. **handoff-user probe (`git@`, `$USER@`, `cloud-build@`)** — *added v1.2.0, the bug fix*. Iterates the three actual handoff users that `\u002Fsuper` and `cloud_build_handoff` use. ANY returning `Permission denied (publickey)` while probes #2 + #3 pass → ERROR exit 4 (= watchdog-lying-about-success — banner paths trust the key but the actual SSH user the dispatch needs does not).\n5. **enrollment-check age** — `state.json.last_enrollment_check` > 6 days → WARNING exit 3 (preventive nudge before the ~7-day rotation window hits).\n6. **autoheal** — if the probe fails AND `~\u002F.config\u002Fcloud-build\u002Fenrollment-code` is present, runs `cb-client-setup.sh` with the code on stdin, then `shred -u`s the file.\n\n**Exit codes:**\n\n| Code | Meaning |\n|------|---------|\n| 0 | Healthy — bastion accepts key on banner paths + handoff users + known_hosts pinned |\n| 1 | Auth failure — `Permission denied (publickey)` from bastion on banner paths |\n| 2 | known_hosts re-pin failed |\n| 3 | Preventive nudge — `last_enrollment_check` > 6 days |\n| 4 | **handoff-fail-with-banner-ok** — probes #2 + #3 pass but probe #4 (real handoff users) fails. `\u002Fsuper` WILL fail with `Permission denied (publickey)`. Re-enrollment required. |\n\n**Files (canonical):**\n\n- Script: `~\u002F.hermes\u002Fscripts\u002Fcloud-build-bastion-watchdog.sh`\n- Plist (deployed): `~\u002FLibrary\u002FLaunchAgents\u002Fai.hermes.schedule.cloud-build-bastion-watchdog.plist`\n- Log: `\u002Ftmp\u002Fcloud-build-bastion-watchdog.log` (also `.out.log` \u002F `.err.log`)\n- Setup script (consumed): `~\u002Fsuperpowers-cloud-build-main\u002Fskills\u002Fcloud-build\u002Fscripts\u002Fcb-client-setup.sh`\n\n**Launchd wiring:** runs every 12h (`StartInterval=43200`, throttle 5min). `KeepAlive{SuccessfulExit=false}` so launchd does NOT interpret a silent 0-exit as success and skip ticks.\n\n**Manual recovery (operator command):**\n\n```bash\n# If watchdog reports exit 1 and there's no enrollment-code file:\nbash ~\u002Fsuperpowers-cloud-build-main\u002Fskills\u002Fcloud-build\u002Fscripts\u002Fcb-client-setup.sh\n# Paste fresh enrollment code at the prompt\n```\n\n**Pre-dispatch probe:** `\u002Fmac` and `\u002Fsuper` should invoke the watchdog in `--notify` mode (no `--autoheal`) before dispatching. If it returns non-zero, dispatch aborts with a clear error pointing the operator at the recovery command above. Pattern:\n\n```bash\nif ! bash ~\u002F.hermes\u002Fscripts\u002Fcloud-build-bastion-watchdog.sh --notify; then\n  echo \"Bastion unhealthy; aborting dispatch. Run: bash $SETUP_SCRIPT\" >&2\n  exit 2\nfi\n```\n\n**MANDATORY defense-in-depth — the 3-user handoff probe (always run inline, never trust the watchdog exit code alone):**\n\nThe watchdog exit code is not authoritative (see Pitfall P8 — the script on disk can lag the SKILL.md by a version). Before any `\u002Fsuper` or `cloud_build_handoff` call, agents MUST run this probe inline from bash (not zsh, see Pitfall P5):\n\n```bash\nfor u in git $USER cloud-build; do\n  ssh -i ~\u002F.ssh\u002Fcloud-build\u002Fid_ed25519 -o IdentitiesOnly=yes \\\n    -o StrictHostKeyChecking=yes -o UserKnownHostsFile=~\u002F.ssh\u002Fcloud-build\u002Fknown_hosts \\\n    -o ConnectTimeout=5 -o BatchMode=yes -T \"${u}@cloud.superpowers.build\" 2>&1 | head -1\ndone\n```\n\nIf ANY returns `Permission denied (publickey)`, STOP. The exact \u002Fsuper FAIL message to surface to the user is documented in `references\u002Fscript-vs-skill-drift-2026-07-20.md` and is also embedded verbatim in `~\u002F.claude\u002Fcommands\u002Fsuper.md` step 2. Do NOT auto-re-enroll, do NOT fall through to `claudeg` \u002F OpenRouter \u002F local subagents.\n\n**Tested 2026-07-20 on Mac (jeffreys-macbook-pro), real banners:**\n\n| Probe | Banner received | Verdict |\n|-------|-----------------|---------|\n| `ssh -T cloud-bastion@cloud.superpowers.build` | `cloud-bastion: interactive shell is not permitted` | ✅ healthy |\n| `ssh -T enroll@cloud.superpowers.build` | `enroll: invalid or expired token` | ✅ key still trusted on enroll path |\n| `ssh -T git@cloud.superpowers.build` | `Permission denied (publickey)` | ❌ exit=4 (handoff-fail-with-banner-ok) |\n| `ssh -T $USER@cloud.superpowers.build` | `Permission denied (publickey)` | ❌ exit=4 |\n| `ssh -T cloud-build@cloud.superpowers.build` | `Permission denied (publickey)` | ❌ exit=4 |\n\n**Verdict on this Mac as of 2026-07-20 22:21 PT:** `exit=4` (banner users OK + handoff users fail). The bug the watchdog was designed to catch was that the v1.1.0 watchdog exited 0 on this same state. Verified the v1.2.0 fix correctly catches it. Re-enrollment required to flip to exit=0.\n\n## Pitfalls (verified 2026-07-20)\n\n### P1 — `enrolled_fp_hash == local_fingerprint_hash` does NOT detect a pruned `authorized_keys`\n\nThe setup script's re-enroll gate only fires when `state.json.enrolled_fp_hash` differs from the LOCAL public key's fingerprint hash. If the local key is intact but the bastion pruned `authorized_keys`, both fingerprints still match — and the setup script silently exits without re-enrolling. **Result:** every subsequent SSH call returns `Permission denied (publickey)` with no local signal. The watchdog's `cloud-bastion@` + `enroll@` probes are the only thing that surfaces this.\n\n**Fix pattern:** always run the watchdog before assuming cloud-build works. Do NOT trust `state.json.last_enrollment_check` as proof of liveness — that field is only written when the setup script's re-enroll gate fires, and the gate never fires on key-pruning-only failures.\n\n### P2 — `launchctl load` cannot run from inside the gateway\n\nThe watchdog plist is on disk at `~\u002FLibrary\u002FLaunchAgents\u002Fai.hermes.schedule.cloud-build-bastion-watchdog.plist` but the gateway blocks any shell command that would touch launchd:\n\n```\nBlocked: cannot restart or stop the gateway from inside the gateway process.\nThe gateway would kill this command before it could complete (SIGTERM propagates\nto child processes). Run `hermes gateway restart` from a separate shell outside\nthe running gateway.\n```\n\nThe fix is the operator running `launchctl load -w ~\u002FLibrary\u002FLaunchAgents\u002Fai.hermes.schedule.cloud-build-bastion-watchdog.plist` from a separate shell. **Do not promise the watchdog is running inside a session where launchd was never loaded.**\n\n### P3 — Prior-session transcripts are not authoritative (extends umbrella skill Pitfall #7)\n\nThe prior session's transcript (visible in this session's `conversations_replies` output for `C09GRLXF9GR\u002Fp1784583512`) claimed the bastion returned `Permission denied (publickey)` AND that `\u002Fsuper` on Mac was \"blocked only on bastion auth (user-action-only fix).\" Both claims were stale by minutes: the prior session's `cb-client-setup.sh` call had already restored the trusted key, and the live bastion accepted it on the first `ssh -T cloud-bastion@…` probe in the new session. **The simulation script `\u002Ftmp\u002Fsuper-pipeline-test\u002Frun_super_pipeline.py` was even printing \"bastion returns Permission denied (publickey) until user re-enrolls\" as part of its Mac-path verdict** — a verbatim copy of the prior-session conclusion, persisted to disk and never updated.\n\n**Rule:** any time a session loads a prior session's transcript OR a previously-written simulation\u002Fharness script, **re-run the probe before quoting the prior conclusion.** The five-second cost is far less than the time lost chasing a phantom blocker. The umbrella skill `superpowers-cloud-build` already documents this for third-party accounts; this extends it to **your own recent session's transcripts**.\n\n### P4 — `known_hosts` re-pin only converges when the bundled config is loadable\n\nThe watchdog's drift-recovery step runs `python3 -c \"import json; ...\"` against `~\u002Fsuperpowers-cloud-build-main\u002Fassets\u002Fcloud-build-client-config-v0.json`. If that file is missing (plugin uninstalled, repo not cloned), the script logs `ERROR: cannot read bundled fingerprint from $CLIENT_CONFIG` and falls through to ERROR. If the file is present but has a different SHA256 than the live bastion's key, re-pin writes a wrong fingerprint and the next probe fails with `Host key verification failed`.\n\n**Mitigation:** the script verifies `BUNDLED_FP != LOCAL_FP` BEFORE writing, then re-checks AFTER writing. If both checks disagree, exit 2 (re-pin did not converge) and the operator must manually `ssh-keyscan` the bastion to get the live fingerprint.\n\n### P5 — macOS zsh silently corrupts `:refs\u002F...` push refspecs (inherited from umbrella)\n\nSee umbrella skill `superpowers-cloud-build` Pitfall #4 — the watchdog itself never pushes refspecs (it's read-only probes), but `\u002Fsuper` and the cloud-build dispatch helpers do. If the watchdog is invoked from a zsh shell that has `lib-client.sh` sourced, the next dispatch is corrupted even though the watchdog itself exits 0. **Always run cloud-build scripts from bash, even if the watchdog invocation succeeds from zsh.**\n\n### P6 — Dual-machine `enrolled_fp_hash` drift (verified 2026-07-20)\n\nWhen jeff-ubuntu is \"set up\" by copying the Mac's `~\u002F.config\u002Fcloud-build\u002Fstate.json` (same `client_config_sha256`, same `enrolled_fp_hash`, same `last_enrollment_check`), both machines can drift independently if their local SSH keys are rotated at different times. Result: the bastion trusts ONE key (whichever was enrolled last), and the other machine's `\u002Fsuper` dispatch returns `Permission denied (publickey)` even though its OWN state.json says \"enrolled.\" The v1.2.0 watchdog catches this on each machine individually (each runs its own probes and reports its own state), but **there is no cross-machine reconciler** — fixing jeff-ubuntu requires running the setup script on jeff-ubuntu (or copying the freshly-enrolled state.json from the Mac AFTER re-enrolling on the Mac).\n\n**Repro on 2026-07-20:**\n\n```\nMac:        local key fp=f1c66c1fb3…   enrolled_fp_hash=c709569c7b…  → exit=4 (handoff fail)\njeff-ubuntu: local key fp=8cZsH7MRG…  enrolled_fp_hash=c709569c7b…  → exit=4 (handoff fail)\n```\n\nBoth state.json files share the same `enrolled_fp_hash` because jeff-ubuntu's was copied from the Mac's pre-rotation state. The local keys rotated independently, neither was re-enrolled.\n\n**Fix recipe:**\n\n```bash\n# Re-enroll on the canonical machine (the one with the up-to-date state):\nprintf %s \"$code\" | bash ~\u002Fsuperpowers-cloud-build-main\u002Fskills\u002Fcloud-build\u002Fscripts\u002Fcb-client-setup.sh\n\n# Copy the resulting state.json to jeff-ubuntu (the bastion trusts the key, not the machine):\nscp ~\u002F.config\u002Fcloud-build\u002Fstate.json jeff-ubuntu:~\u002F.config\u002Fcloud-build\u002Fstate.json\n\n# Or re-run the same setup script on jeff-ubuntu with the same code:\nssh jeff-ubuntu \"printf %s '$code' | bash ~\u002Fsuperpowers-cloud-build-main\u002Fskills\u002Fcloud-build\u002Fscripts\u002Fcb-client-setup.sh\"\n```\n\n### P7 — `\u002Fbrowser` cannot fetch enrollment codes (verified 2026-07-20)\n\nUser asked: *\"use \u002Fbrowser and get this Mac working and enroll.\"* The literal request can't be fulfilled. Per `~\u002Fsuperpowers-cloud-build-main\u002FREADME.md`:\n\n> \"Cloud Build is currently **invite-only**. The maintainer who invites you hands you a **durable download link** for the plugin archive and an **enrollment code**, both out of band.\"\n\nThere is no public URL, no API endpoint, no CLI subcommand that issues enrollment codes. The code is a string the maintainer distributes in private. **Do not waste tool budget trying to fetch one with `\u002Fbrowser`, `web_search`, `web_extract`, or any HTTP call** — it does not exist as a URL. The only path forward is the user pasting the code into the prompt; the agent then runs `cb-client-setup.sh` with the code on stdin.\n\n**Anti-pattern:** treating `\u002Fbrowser` as a generic \"do it for me\" tool. The `\u002Fbrowser` slash command in this profile is scoped to **auth-gated share-link extraction** (Gemini \u002F ChatGPT \u002F Google Docs \u002F Notion — `browserclaw cookies decrypt + inject`). It has zero relationship to cloud-build enrollment. When the user says \"use \u002Fbrowser and fix X,\" confirm X is in scope before proceeding; if X requires credentials that don't exist as URLs, surface the blocker honestly rather than firing off three failed browser fetches.\n\n### P8 — Script-vs-SKILL.md drift: the watchdog can lie about its own version (verified 2026-07-20)\n\nThe watchdog SKILL.md can document a contract (exit code, probe behavior, fix) that the **live script on disk** does not implement. On 2026-07-20 the SKILL.md was at v1.2.0 advertising the exit=4 contract for handoff-user probe failures, but `~\u002F.hermes\u002Fscripts\u002Fcloud-build-bastion-watchdog.sh` on this Mac was still at v1.1.0 behavior — it printed `verdict: exit=0` and exited 0 while the handoff users genuinely returned `Permission denied (publickey)`. An agent that loaded the skill and trusted its exit code would call `\u002Fsuper` and watch it die silently.\n\n**Symptoms an agent might observe:**\n- Watchdog prints lines like `verdict: exit=0` without ever mentioning handoff users or `exit=4`\n- `bash scripts\u002Ftest_watchdog_exit4_on_handoff_fail.sh` Test 6 FAILS with \"live run exits 0 — WATCHDOG IS STILL LYING\"\n- Inline handoff probe (the 3-user loop above) returns `Permission denied` for all three users while the watchdog says healthy\n\n**Root-cause hypothesis:** the v1.2.0 SKILL.md and reference shipped in a session where the script edit was supposed to land but didn't — possible deployment drift between staging and prod `~\u002F.hermes\u002F` trees (see SOUL.md `## COMMIT: hermes-deploy-pipeline`), or a `git -C ~\u002F.hermes pull --ff-only` reverted the script change.\n\n**Mitigation — three layers any agent about to dispatch \u002Fsuper must respect:**\n\n1. **Never trust watchdog exit code alone** — always run the inline 3-user handoff probe (see \"MANDATORY defense-in-depth\" section above). This is embedded in `~\u002F.claude\u002Fcommands\u002Fsuper.md` step 2 as well.\n2. **Self-check via contract test** — `bash ~\u002F.hermes\u002Fskills\u002Fcloud-build-bastion-watchdog\u002Fscripts\u002Ftest_watchdog_exit4_on_handoff_fail.sh`. Test 6 catches this exact drift in 5 seconds.\n3. **If the self-check shows drift, surface it explicitly** — do NOT silently route around the watchdog. The agent's job is to surface the discrepancy and let the operator reconcile; the SKILL.md describes the desired state, the script describes the actual state, and conflating the two is what produces silent \u002Fsuper dispatch failures.\n\n**Fix recipe for the operator** (when drift is confirmed): see `references\u002Fscript-vs-skill-drift-2026-07-20.md` \"Fix recipe\" section. The 3-grep probe (`HANDOFF_USERS=` + `BASTION_OK && ENROLL_OK && !HANDOFF_OK` + `exit=4` in the script) detects the drift in one second; the contract test detects it in five.\n\n## Pair with\n\n- Umbrella skill: `superpowers-cloud-build` (v1.5.0+) — the cloud-build plugin operational handbook. This watchdog is a *companion* that catches the auth\u002Fkey failure modes the umbrella's Step 0 hello-world validation can't.\n- `references\u002Fprobe-mismatch-bug-2026-07-20.md` — the v1.1.0→v1.2.0 fix in full: live repro transcript, the exact 3-user probe block shipped in `cloud-build-bastion-watchdog.sh` lines 124-158, the defense-in-depth pre-dispatch probe recipe, and the companion changes (`super.md` + memory + jeff-ubuntu known_hosts sync).\n- `references\u002Fscript-vs-skill-drift-2026-07-20.md` — **NEW 2026-07-20**: the script-vs-SKILL.md drift observed in this session, the canonical \u002Fsuper FAIL message (also embedded in `~\u002F.claude\u002Fcommands\u002Fsuper.md` step 2), and the 3-grep self-check recipe. If you ever see the watchdog emit `exit=0` while the 3-user handoff probe fails, this is the reference.\n- `scripts\u002Ftest_watchdog_exit4_on_handoff_fail.sh` — the 7-test contract suite. Run before any \u002Fsuper dispatch in an environment you don't trust. Test 6 catches the script-vs-skill drift.\n- `references\u002Flive-banners-2026-07-20.md` — the actual probe transcripts (banner strings, ssh -vv excerpts, exit codes) from the session that validated this skill.\n",{"name":5,"created":62,"updated":62,"version":63,"triggers":64,"changelog":75,"description":7,"related_skills":80},1784505600000,"1.3.0",[65,66,67,68,69,70,71,72,73,74],"bastion expired","ssh key expire","Permission denied publickey cloud","Host key verification failed cloud","bastion not responding","cloud build not working","\u002Fsuper dispatch fails","cloud.superpowers.build timeout","watchdog lies","watchdog reports green but broken",[76,77,78,79],"1.3.0 (2026-07-20) **Live script drift discovered.** The SKILL.md at v1.2.0 advertises an exit=4 contract for handoff-user probe failures, but the live script on this Mac (`~\u002F.hermes\u002Fscripts\u002Fcloud-build-bastion-watchdog.sh`) was still at v1.1.0 behavior — emitted `verdict: exit=0` while the handoff users genuinely returned `Permission denied (publickey)`. A future agent that trusts the watchdog's exit code would call \u002Fsuper and watch it die silently. New reference `references\u002Fscript-vs-skill-drift-2026-07-20.md` documents the discrepancy + the canonical 3-user handoff probe that agents MUST run inline (also embedded in `\u002Fsuper`'s step-2 preflight). New pitfall P8 covers the script-vs-skill drift and the `bash scripts\u002Ftest_watchdog_exit4_on_handoff_fail.sh` self-check that catches it. Recipe: any agent about to dispatch \u002Fsuper must run the inline handoff probe regardless of watchdog exit code.","1.2.0 (2026-07-20) **Structural probe-mismatch fix shipped.** Added a 3rd probe block that authenticates as the ACTUAL handoff users (`git@`, `$USER@`, `cloud-build@` at `cloud.superpowers.build`) — the ones `\u002Fsuper` and `cloud_build_handoff` use. New exit code 4 = `handoff-fail-with-banner-ok` (= watchdog-lying-about-success). Updated Tested table with the new exit-code 4 case observed live on this Mac. New pitfall P6 covers the dual-machine `enrolled_fp_hash` drift case (both Mac + jeff-ubuntu carry the same stale fingerprint from Jul 16 even though the local keys rotated independently). New pitfall P7 covers the `\u002Fbrowser` ≠ enrollment-codes misconception (codes are out-of-band invite-only strings, not URLs).","1.1.0 (2026-07-20) Patched banner strings (real banner is `interactive shell is not permitted`, not the older `only git fetch\u002Fpush\u002Farchive` wording); added macOS launchctl-load-from-gateway block pitfall; added the `enrolled_fp_hash == local_fingerprint_hash` silent-break pitfall that the prior session hit; added the prior-session-trust anti-pattern (transcripts can be stale or wrong even from minutes ago); updated `Tested` table with the actual banners seen in this session.","1.0.0 (2026-07-20) Initial — 5-layer watchdog (known_hosts \u002F bastion auth probe \u002F enroll probe \u002F age \u002F autoheal) wired to launchd 12h cadence + pre-dispatch probe in `\u002Fmac`.",[81],"superpowers-cloud-build","main","42ccd02cbf5e8e47839dc3eab6fc754dc6b339cf","hermes\u002Fskills\u002Fcloud-build-bastion-watchdog",0,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills","https:\u002F\u002Fgithub.com\u002Fjleechanorg","2026-11-14 03:18:13",{"source":8,"skillName":5,"commands":90,"prompt":100,"zipAvailable":101},[91,94,97],{"tool":92,"command":93},"npx","npx skills add jleechanorg\u002Fjleechan-skills --skill cloud-build-bastion-watchdog",{"tool":95,"command":96},"bunx","bunx skills add jleechanorg\u002Fjleechan-skills --skill cloud-build-bastion-watchdog",{"tool":98,"command":99},"pnpm","pnpm dlx skills add jleechanorg\u002Fjleechan-skills --skill cloud-build-bastion-watchdog","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fcloud-build-bastion-watchdog\u002FSKILL.md",true,[103,109,113],{"path":104,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fprobe-mismatch-bug-2026-07-20.md","REFERENCE","参考文档",5864,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fcloud-build-bastion-watchdog\u002Freferences\u002Fprobe-mismatch-bug-2026-07-20.md",{"path":110,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fscript-vs-skill-drift-2026-07-20.md",5150,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fcloud-build-bastion-watchdog\u002Freferences\u002Fscript-vs-skill-drift-2026-07-20.md",{"path":114,"resourceType":115,"resourceTypeDesc":116,"sizeBytes":117,"sourceHtmlUrl":118},"scripts\u002Ftest_watchdog_exit4_on_handoff_fail.sh","SCRIPT","脚本",3609,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fcloud-build-bastion-watchdog\u002Fscripts\u002Ftest_watchdog_exit4_on_handoff_fail.sh",[120,137,159,173,187,203],{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":57},"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",[],[122,127,128,129,130,34,131,132,133,134,135,136],"user","when","replies","check","identity","whatsapp","gmail","read","message","ask",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":148,"publishedAt":57},"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",[143],{"categoryNo":144,"categoryName":145,"taxonomyType":146,"taxonomyTypeDesc":147},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[139,149,150,151,152,153,154,155,156,157,158],"resume","compatibility","provenance","for","history","produce","alias","briefing","state","fresh",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":166,"publishedAt":57},"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",[165],{"categoryNo":144,"categoryName":145,"taxonomyType":146,"taxonomyTypeDesc":147},[153,149,167,168,127,169,156,170,152,171,172,157,158],"history resume","branch","analysis","repository","worktree","sources",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":57},"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",[],[175,180,181,182,152,183,155,184,185,186],"dot","bot","workflow","canonical","conversation","browser","grokbot",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"publishedAt":57},"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",[],[194,195,196,34,197,152,198,199,200,201,202],"codexa bench","work","split","default","duplicate","task","compare","normal","codex",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":207,"licenseFileUrl":208,"sourceHtmlUrl":209,"categories":210,"keywords":220,"publishedAt":57},"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",[211,214,217],{"categoryNo":212,"categoryName":213,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":215,"categoryName":216,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":218,"categoryName":219,"taxonomyType":146,"taxonomyTypeDesc":147},"01JBSEEDCAT000000000000032","设计师",[221,222,223,34,224,225,226,127,227,228,54,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,128,244],"frontend","design","frontend design","generic","ui design","react","html","components","artifacts","ui","aesthetics","Production","web components","landing","applications","quality","web","css","create","examples","with","react components","web ui","pages"]