Claude Code — Global Skills

A curated catalog of the global Claude Code skills we find most useful, with a description of what each one does and its full source code so you can install any of them into your own global skill set. (One entry — pr-review-loop — is a maintained repo skill, so instead of embedding source that would drift it gives a one-line command to install it straight from cred-platform-ts.)

Global skills live in ~/.claude/skills/<skill-name>/SKILL.md and travel with you across every repo and session — unlike repo-scoped skills (.claude/skills/ inside a project). Each skill is a single SKILL.md file with YAML frontmatter (name + description, which controls when the model auto-invokes it) followed by the instructions the model loads on demand. A few skills ship extra companion files (templates, scripts) alongside SKILL.md.

Install one of these with your agent

Point Claude Code at this page and ask it to install the skill(s) you want:

"Read the Global Skills wiki page and install the babysit-pr and watch-pr-merge-verify skills into my global skills."

For each skill you pick, the agent should:

Create the folder ~/.claude/skills/<skill-name>/.
Write the SKILL.md source below into ~/.claude/skills/<skill-name>/SKILL.md. (For a skill that links to a repo instead of embedding source — e.g. pr-review-loop — run its install command rather than writing a file.)
Write any companion files (e.g. template.html) into the same folder.
If the skill documents an auto-trigger hook (e.g. babysit-pr), install the hook script and its settings.json wiring too — the SKILL.md alone does not auto-fire; the hook is what binds the skill to an event.
Restart Claude Code (or start a new session) so the skill (and any hook) is picked up.

Adapt the machine-specific and repo-specific bits

Some of these skills were authored against one engineer's setup and contain personal coordinates — pod names (workspace-alex-0), absolute paths (/Users/user/Briefings), a local server port (8765), GKE cluster/project IDs, and internal DNS. Treat those as examples: swap in your own pod, paths, and hostnames when you install. None of the sources contain secrets or tokens.

They also bake in CRED repo-specific behavior — e.g. bun run agent-check as the lint/typecheck gate, the CRED review bots (cred-rabbit, the Dev Pipeline Agent), the credinvest/cred-platform-ts auto-merge pilot, and the develop → dev deploy flow. In a different repo, substitute that repo's own check command, review bots, and branch/deploy conventions.

The dev-workspace skill: derive your coordinates, don't hardcode them

cred-dev-workspace is the most setup-specific skill. Everyone's workspace is a different pod/VM with a different name and IP, so don't copy the sample workspace-alex-0 coordinates verbatim — point the skill at the team tooling in cred-local-workspace and let it derive the live values:

Two workspace types, attached differently. GKE (a pod, e.g. workspace-<you>-0; URL https://workspace-<you>.dev.cred.internal) is driven by infra/gke-workspace/gke-workspace.py; GCE VM (a raw 10.128.x.x:8002) by infra/remote-workspace/workspace.py. Find yours with gke-workspace.py list / workspace.py template-instance list.
Prefer gke-workspace.py ssh <you> / gke-workspace.py port-forward <you> 8002:8002 over hand-rolled kubectl — it handles the pod user, key, and (for GKE) a Twingate-free kubectl exec tunnel.
The repo already ships maintained, workspace-agnostic skills — remote-ssh-connect (wire an editor to the pod) and fed-stack-recover (the ./fed recovery loop). Reuse those for the mechanics instead of duplicating them globally.

The skills

Skill	What it does	Extra files
`cred-dev-workspace`	Deliver, run, hot-reload & test code inside your personal CRED dev-workspace pod — without deploying to shared dev.	—
`babysit-pr`	After opening a PR, run exactly two bounded passes of review-comment triage, then stop.	—
`pr-review-loop`	The mechanics `babysit-pr` delegates to — commit → PR → loop resolving bot review comments until clean. Lives in `cred-platform-ts`.	—
`watch-pr-merge-verify`	Watch a PR to merge, then autonomously verify it post-deploy if the session implied verification was pending.	—
`html-briefing`	Render a substantial briefing/audit/report as a clean, self-contained HTML page served over `localhost`. Install via the repo's `enable-html-briefings.sh` (sets up server + skill in one step).	`template.html`

The PR skills chain together

babysit-pr → watch-pr-merge-verify are designed to run back-to-back: babysit does the bounded comment triage, then watch-pr-merge-verify picks up, watches the PR to merge, and (only when warranted) verifies after deploy. Install both if you want the full "open a PR → babysit → watch to merge/deploy" loop.

cred-dev-workspace

What it does. Deliver, run, hot-reload, and test code inside a personal CRED Coder/GKE dev-workspace pod that runs the entire federated stack (web/apis/router/postgres) via docker-compose — without deploying to shared dev. Editing the in-pod repo hot-reloads the running app, so the loop is: change code → it reloads → test it live (Playwright, GraphQL, direct DB). It is an isolated, persistent dev sandbox, not a deploy target.

When it triggers. "run/build/test this in my workspace", "deploy into my workspace", "iterate in the pod", "run Playwright in the workspace", "hit the workspace GraphQL/DB", or any get-code-in → build → hot-reload → test loop.

Files: SKILL.md

The source below hardcodes ONE engineer's coordinates — don't copy it verbatim

The SKILL.md source in this section is the original, authored against workspace-alex-0 (its pod name, cluster/project IDs, paths, and *.dev.cred.internal URLs are all Alex's). It is included as a worked example, not a drop-in. Before installing, replace every coordinate with your own — and prefer deriving them from the cred-local-workspace tooling rather than hand-editing, per the "derive your coordinates, don't hardcode them" tip near the top of this page. Your workspace is a different pod/VM with a different name and IP.

SKILL.md — full source for name: cred-dev-workspace (click to expand)

---
name: cred-dev-workspace
description: Deliver, run, hot-reload, and test code inside Alex's CRED Coder/GKE dev workspace pod (workspace-alex-0) WITHOUT deploying to shared dev. Use when the user says "run/build/test this in my workspace", "deploy into my workspace", "iterate in the pod", "run Playwright in the workspace", "hit the workspace GraphQL/DB", or any time the loop is: get code into the pod → build → hot-reload → get the URL → run Playwright / fire GraphQL / query the DB → iterate. The full federated stack (web/apis/router/postgres) runs inside one pod; editing the in-pod repo hot-reloads it. NOT a deploy target — iterating here never touches shared dev.
---

# CRED dev workspace — deliver, run & test in-pod

Alex has a personal **Coder dev workspace = one GKE pod** that runs the entire
federated CRED stack via docker-compose. Editing the in-pod repo **hot-reloads**
the running app, so the loop is: change code → it reloads → test it live. This
is an isolated, persistent dev environment, **not a deploy target** — nothing
here touches shared dev/staging.

## Coordinates (verified 2026-06-22)

| Thing | Value |
|---|---|
| Pod | `workspace-alex-0` in namespace `cred-workspace` |
| Cluster | GKE `cred-development`, us-central1-c (project `cred-1556636033881`) |
| kube context | `gke_cred-1556636033881_us-central1-c_cred-development` |
| Repos (owned by `ubuntu`) | `/home/ubuntu/cred-workspace/repos/` — `cred-platform-ts` (on `develop`), `cred-agent-ai`, `cred-mcp`, `cred-platform-cli` |
| Stack orchestrator | `/home/ubuntu/cred-workspace/fed` (docker compose wrapper) |
| Helper scripts | `~/cred-workspace/pull-all.sh`, `snapshot.sh`, `migrate-to-repos.sh` |
| Public URL (from Mac, via Twingate) | web `https://workspace-alex.dev.cred.internal` · GraphQL `https://api.workspace-alex.dev.cred.internal/graphql` |
| Ports (in-pod localhost) | web `:8002` · commercial-api `:8000` · model-api `:3000` · filter-api `:8081` · apollo-router `:4000` · commercial Postgres `:5432` (`cred_commercial`, dev data) |

## Connect — PRIMARY: Twingate direct URLs from the Mac

The workspace publishes its **own URLs** reachable from the Mac over **Twingate**
(NOT Tailscale — the old memory note is wrong). This is the natural path: hit the
app and GraphQL directly, no shelling required.

- Web app: `https://workspace-alex.dev.cred.internal` (this is the URL to open in a browser / point Playwright at)
- GraphQL: `https://api.workspace-alex.dev.cred.internal/graphql` (== the FE's `BROWSER_FACING_API_URL`)
- These use an **internal CA** the browser/chromium doesn't trust → use `-k`
  (curl) / `PW_IGNORE_HTTPS_ERRORS=1` (Playwright) / `ignoreHTTPSErrors`.

**Preflight before assuming this path works** — Twingate must be connected AND
the `*.dev.cred.internal` Resource provisioned to the session:
```bash
pgrep -fl com.twingate           # tunnel running?
nslookup workspace-alex.dev.cred.internal   # Twingate resolver ~100.64.x; NXDOMAIN = resource not assigned/connected
curl -sk -o /dev/null -w "%{http_code}\n" https://workspace-alex.dev.cred.internal
```
**Twingate status (working as of 2026-06-22):** the `cred-internal DNS` resource
(`*.cred.internal`) resolves the hosts to Twingate proxy IPs (`100.98.76.91/.92`)
and, once the resource is **authenticated** in the Twingate client, the tunnel
routes through to the dev pod — `https://workspace-alex.dev.cred.internal` → 308,
GraphQL → `{"data":{"__typename":"Query"}}`.

If it breaks again, the failure modes seen during setup were, in order:
1. `NXDOMAIN` → the `*.cred.internal` resource wasn't resolving; fixed by a
   client restart (added resolver `100.95.0.251`).
2. Resolves to `100.98.76.x` but TCP **times out** on every port → the resource
   wasn't authenticated / no route to the cred-development pod range
   `10.0.0.0/21`; fixed by **authenticating the resource** in the client.
So: restart the client, then make sure `cred-internal DNS` is authenticated.
`kubectl port-forward` / `kubectl exec` remain the fallback if Twingate is down.

## Connect — FALLBACK: kubectl exec (Twingate-independent)

When Twingate can't resolve the host, the pod is still reachable via `kubectl`
(current context already points at `cred-development`). This shells INTO the pod,
so services are at `localhost:<port>` from there.

```bash
NS=cred-workspace; POD=workspace-alex-0
R=/home/ubuntu/cred-workspace/repos/cred-platform-ts

# one-off (run dev/git/test as `ubuntu`, NOT root — see below):
kubectl exec -n $NS $POD -- runuser -u ubuntu -- bash -lc 'cd '"$R"' && git status -sb'
# interactive shell:
kubectl exec -it -n $NS $POD -- bash -l
# expose an in-pod port on the Mac (e.g. to drive a real browser):
kubectl port-forward -n $NS $POD 8002:8002   # or 4000:4000 for GraphQL
```

- **`kubectl exec` runs as `root`.** Always wrap dev/git/build/test commands in
  `runuser -u ubuntu -- bash -lc '...'`. Root-owned files in the repo break the
  `ubuntu` dev server and pollute git status.
- SSH alias `workspace-alex` (in `~/.ssh/config`) only works when Tailscale is up
  — it usually isn't. Don't rely on it.

## Deliver code into the pod

The in-pod repo is a normal git checkout on `develop`. To get a change in:

- **Already pushed to a branch/PR?** Pull it in-pod:
  `kubectl exec -n $NS $POD -- runuser -u ubuntu -- bash -lc "cd $R && git fetch origin && git checkout <branch>"`.
- **Local uncommitted work on the Mac?** Either commit+push then pull (above), or
  pipe a diff in: `git diff | kubectl exec -i -n $NS $POD -- runuser -u ubuntu -- bash -lc "cd $R && git apply -"`.
- After changing FE source, **no rebuild needed** — the web container
  (`cred-web-commercial-dev-local`, Turbopack) hot-reloads. First hit after a cold
  change can take 30–40s to compile (a "loading forever" spinner is usually cold
  compile, not a bug). API/router changes may need their container restarted via
  `~/cred-workspace/fed` — check the compose service before assuming hot-reload.

## Verify it's up

```bash
kubectl exec -n $NS $POD -- bash -lc '
  curl -s -o /dev/null -w "web %{http_code}\n" -m 8 http://localhost:8002
  curl -s -m 8 -X POST http://localhost:4000/graphql -H "content-type: application/json" \
    --data "{\"query\":\"{ __typename }\"}"'
```
Healthy looks like `web 308` (login redirect) and `{"data":{"__typename":"Query"}}`.

## Fire direct GraphQL (no browser)

- **From the Mac (Twingate):** `curl -sk https://api.workspace-alex.dev.cred.internal/graphql ...` (`-k` for the internal CA).
- **From in-pod (fallback):** the apollo-router at `http://localhost:4000/graphql`.

For authed queries, get a token by logging in via the auth mutation first, then
pass `Authorization: Bearer`. Cross-reference `docs/agent/architecture.md` and
the schema for op shapes; this is the fastest way to check data without the UI.

## Query the database directly

In-pod Postgres on `:5432`, db `cred_commercial` (dev data):
```bash
kubectl exec -n $NS $POD -- bash -lc 'psql postgresql://localhost:5432/cred_commercial -c "\dt" | head'
```
Prefer the live DB over reading migrations (see the `pg-database-access` skill for conventions).

## Run Playwright in-pod

Tests run **inside the pod** against `http://localhost:8002` — that's the
established working pattern. Dir: `$R/playwright-new`.

```bash
kubectl exec -n $NS $POD -- runuser -u ubuntu -- bash -lc '
  cd '"$R"'/playwright-new
  set -a && . ./.env && set +a          # .env is gitignored and NOT auto-loaded — source it
  PW_IGNORE_HTTPS_ERRORS=1 ./node_modules/.bin/playwright test <spec> --project=chromium'
```

- **Critical cert gotcha:** the FE's `BROWSER_FACING_API_URL` is the internal-CA
  https endpoint chromium doesn't trust → login fails with
  `net::ERR_CERT_AUTHORITY_INVALID` ("Failed to fetch"). The fix is env-gated and
  lives **uncommitted on the pod**: `ignoreHTTPSErrors: process.env.PW_IGNORE_HTTPS_ERRORS === "1"`
  in `playwright.config.ts` `use` + both `newContext` calls in
  `fixtures/global-setup.ts`. Always run with `PW_IGNORE_HTTPS_ERRORS=1`.
- `.env` (gitignored, in-pod) holds `PLAYWRIGHT_BASE_URL=http://localhost:8002`
  and test-env creds. Don't print creds into transcripts.
- First-run browser setup if missing: `./node_modules/.bin/playwright install chromium`
  + `sudo ./node_modules/.bin/playwright install-deps chromium`.
- Cold compile makes the **first** attempt flaky (table load can exceed 180s);
  it usually passes on retry.

## Guardrails

- This pod is a dev sandbox; iterating here is safe and does NOT deploy anywhere.
- Still follow repo rules for any code that will become a PR (branch naming,
  `bun run agent-check`, etc.) — but you can validate it live here first.
- Don't commit the in-pod Playwright cert patch or `.env` to a PR; they're
  workspace-local. The cert fix could be productized env-gated, but that's a
  separate decision.
- Run as `ubuntu`, never leave root-owned files in the repo.

## Related memory
`cred-dev-workspace-ssh-and-playwright` (connection details + Playwright),
`com-36802-prompt-chain-canvas-test`, `worktree-env-graphql-404`.

babysit-pr

What it does. After a PR is opened, do exactly two bounded babysitting iterations — each round: wait ~8 minutes, fetch and triage the PR's review comments, fix and resolve the actionable ones, push; after the second round, stop and report. It is the deliberately non-looping cousin of pr-review-loop (which loops until clean). The second round matters: fixes pushed in round 1 re-trigger the review bots, so the most valuable follow-up comments often land only after the first push.

When it triggers. Right after gh pr create (if you wire the auto-trigger rule), or on "babysit this PR", "check the PR comments", "a couple passes on the PR".

Companion skill: pr-review-loop

The babysit-pr source below delegates the low-level mechanics — the exact gh api .../pulls/<n>/comments and .../reviews fetch queries (§3.2), the Fix/Acknowledge/Dismiss triage table (§3.3), and the bot-thread reply/resolve procedure (§3.5) — to a separate pr-review-loop skill. It is a maintained repo skill (not a personal one), so rather than paste its source here, install it straight from cred-platform-ts — run this from the root of your cred-platform-ts checkout:

mkdir -p ~/.claude/skills/pr-review-loop
cp .claude/skills/pr-review-loop/SKILL.md ~/.claude/skills/pr-review-loop/SKILL.md

If you'd rather not, babysit-pr still works standalone against the standard equivalents: gh api for comments/reviews and the GraphQL resolveReviewThread mutation for resolving bot threads — you just lose the pre-canned queries and bot-specific triage notes. See pr-review-loop below.

Files: SKILL.md

SKILL.md — full source for name: babysit-pr (click to expand)

---
name: babysit-pr
description: After a PR is opened, do exactly TWO bounded babysitting iterations — for each round wait ~8 minutes, fetch and triage PR review comments, resolve the actionable ones; after the second round STOP and report. Use this (not the unbounded pr-review-loop) when the user wants a bounded couple of passes after opening a PR. Auto-triggered by the personal "open a PR → babysit twice" rule in ~/.claude/CLAUDE.md. Triggers on "babysit this PR", "check the PR comments", "a couple passes on the PR", or right after running `gh pr create`.
---

# Babysit PR — Two Iterations Only

**Two bounded** passes over a freshly opened PR. This is the deliberately
non-looping cousin of `pr-review-loop`: it waits, resolves what's actionable,
waits a second time (to catch the bot comments triggered by the first round's
fixes), resolves again, then stops. It exists so that opening a PR doesn't
silently turn into an open-ended polling loop.

> Note: this skill runs **two** rounds despite the historical "once" in earlier
> naming. If you keep the older folder name `babysit-pr-once`, update the
> cross-references (the `~/.claude/CLAUDE.md` auto-trigger rule, the
> `watch-pr-merge-verify` follow-on, and any reminder hook) to match whichever
> name you install it under.

## When this runs

- **Automatically**, right after you open a PR (`gh pr create`), per the
  personal rule in `~/.claude/CLAUDE.md`. This applies whether the user said
  "open the PR" or you reached PR-open as the end of implementing a task.
- **On request**, when the user asks to babysit / check a PR's comments.

If the user explicitly wants continuous polling until the PR is clean, use
`pr-review-loop` instead — that one loops; this one does exactly two rounds.

## The hard rule: exactly two iterations

> **Round 1:** wait → fetch comments → triage → fix & resolve actionable ones → push.
> **Round 2:** wait again → fetch comments → triage → fix & resolve actionable ones → push.
> Then report → **STOP.**

Run the wait+triage cycle (Steps 1–4) **twice**, then report once. Do **not**
start a third wait. Do **not** re-poll after the second round. After you report,
the routine is over. If new comments arrive later, the user can ask you to run
this again — that is a fresh, separate invocation.

The second round matters: fixes pushed in round 1 re-trigger the review bots,
so the most valuable follow-up comments often land only after the first push.
Round 2 catches those. If round 1 found nothing actionable (no push), still run
round 2 — late-arriving first-round comments may show up.

## Step 1 — Wait (~8 minutes per round)

Give CI bots and review tools time to post their comments. Do this at the start
of **each** of the two rounds.

Prefer a non-blocking wait so the session stays responsive — schedule a
wake-up ~8 minutes out (e.g. `ScheduleWakeup` with `delaySeconds: 480`, or the
harness's monitor/until mechanism) and resume the steps below when it fires. A
foreground `sleep 480` also works if backgrounding isn't available.

**Why 8 min, not 5:** instant comments (linear linkback, vercel, the CodeRabbit
*summary* placeholder) post within ~30s, but the **substantive** inline reviews
arrive later. Measured on cred-platform-ts PR #23538: CodeRabbit's first
actionable inline finding landed at **~6 min** after open — a 5-min wait missed
it by seconds and the pass reported "no comments yet." 8 min clears that with
margin. If a repo's bots are consistently slower, wait longer; the cost of
waiting is one cache miss, the cost of waiting too little is a wasted empty pass.

**The wait ends when the expected bots have REPORTED, not when the timer
fires.** The timer is a floor, not proof of arrival: on cred-platform-ts
PR #25958 (2026-07-23) the substantive wave (CodeRabbit's "Actionable comments
posted" review + inline Major, the deletion guard) landed **14–15 min after
open** — a sweep at 11 min declared the round clean and missed all of it.
Before triaging, check arrival: a CodeRabbit *review* exists (not just the
summary placeholder), and cred-rabbit's findings body is past placeholder
state. If an expected bot hasn't reported, extend the wait (another ~5–8 min,
**once per round** — at most one extension each in round 1 and round 2). An
extension is not a third round; the two-round cap is unchanged.

Wait **twice total** (plus at most one in-round extension each) — one round
at a time, and never a third round.

## Step 2 — Fetch the review comments (ALL THREE surfaces, fresh, every round)

Identify the PR (`gh pr view --json number,url,headRefOid,headRepository,headRepositoryOwner`),
then **re-run all three queries from scratch in each round** — never triage
from memory of an earlier fetch or from "no new notifications":

1. **Inline review comments** — `gh api --paginate repos/<o>/<r>/pulls/<n>/comments`
2. **Review bodies** — `gh api --paginate repos/<o>/<r>/pulls/<n>/reviews`
3. **Issue comments** — `gh api --paginate repos/<o>/<r>/issues/<n>/comments`

Always pass `--paginate` — a busy PR spills past the first page, and a
finding on page 2 is exactly the kind this discipline exists to catch.

CodeRabbit posts findings **inline-on-diff** while its summary can
simultaneously say "no issues"; nitpicks hide in review BODIES; cred-rabbit
**edits** findings into an issue comment in place. Any single-surface (or
stale) read misses real findings — on PR #25958 (2026-07-23) round 2 only
re-read cred-rabbit's edited body, declared clean, and missed a CodeRabbit
inline Major, a deletion-guard finding, and a human review that had all
landed minutes after round 1's fetch.

Mechanics that make the sweep honest:
- **Snapshot the comment/review IDs seen each round** and diff round 2's
  fetch against round 1's — anything new or edited (`updated_at` changed)
  gets triaged. Concretely, capture `{id, updated_at}` per surface, e.g.
  `gh api --paginate .../comments --jq '.[] | {id, updated_at}'`, and in
  round 2 re-triage any `id` that's new or whose `updated_at` advanced.
- **Read FULL bodies** of anything you will disposition — never triage a
  human comment (or dismiss a bot one) from a truncated preview.

Substitute the real owner/repo for the current repository — do not assume
`credinvest/cred-web-commercial`.

The CRED Review Agent (`cred-rabbit`, "Dev Pipeline Agent
Review") posts its findings as an issue comment that is **edited in place**:
it first appears as a placeholder ("Check workflow logs", verdict UNKNOWN)
and only later gets edited to contain the Major/Minor findings. A triage
that only queries review threads — or that read the placeholder early —
will silently miss those findings (this happened on cred-platform-ts
PR #25740, 2026-07-21: the marker was posted while a Major finding sat in
the edited comment). In each round, locate the two comments by
`user.login` + HTML marker — `github-actions[bot]` with
`<!-- dev-pipeline-agents -->` (verdict + iteration counter) and
`cred-rabbit[bot]` with `<!-- agent: agent.review.ocr -->` (the findings)
— re-read their CURRENT bodies, and triage under the same severity policy
before posting the clearance marker. A body still in placeholder state
(verdict `UNKNOWN`, iteration not final) means the review is STILL
RUNNING: wait and re-check; never post the clearance marker against a
placeholder.

## Step 3 — Triage each comment

Apply the same Fix / Acknowledge / Dismiss triage as `pr-review-loop` (§3.3):

| Verdict     | Criteria                                                                 | Action                  |
| ----------- | ------------------------------------------------------------------------ | ----------------------- |
| **Fix**     | Real bug, valid security concern, or concrete improvement that fits repo conventions | Apply the fix           |
| **Acknowledge** | Valid but out of scope for this PR                                   | Reply, do not change code |
| **Dismiss** | False positive, hallucinated reference, pre-existing, or contradicts repo conventions | Skip                    |

Verify every bot "high severity" flag against the actual diff before acting —
bots hallucinate. (See the bot-specific notes in `pr-review-loop`.)

## Step 4 — Apply fixes, push, resolve threads

If anything is a **Fix**:
1. Make the changes, run the repo's lint/typecheck (`bun run agent-check` here).
2. Commit (`Address review: <summary>`) and push.
3. Reply to and resolve the addressed **bot** threads (`pr-review-loop` §3.5).
   - Only auto-resolve bot threads (cursor[bot], coderabbitai[bot], Copilot,
     gemini-code-assist[bot], github-code-quality[bot]).
   - Never auto-resolve human-reviewer threads — leave those for the human.
   - Only resolve **after** the fix commit is pushed.

If nothing is actionable, make no code changes.

**After round 1, go back to Step 1 and run round 2.** After round 2, proceed to
Step 5. Skip already-resolved threads on the second pass; only triage comments
that are new or still open.

## Severity policy (Critical/Major must be considered)

In **each** round, every **Critical / Major** bot finding must be either **fixed
or explicitly dismissed with a reason** — never silently skipped. **Minor / nit /
style** findings are optional; don't chase them and don't let them hold anything.
This is the hard-cap-2 consideration window, not an open-ended chase.

## Step 4.5 — (cred-platform-ts only) release the auto-merge hold

For `credinvest/cred-platform-ts` PRs, the `automerge-my-develop-prs.yml` pilot
**iteration-locks** its merge: while an unresolved Critical/Major bot thread
exists, it holds the merge until babysit posts a clearance marker naming the
exact head SHA it reviewed. As the **final action of round 2** — after any
round-2 fix has been pushed, so you clear the *current* head — post the marker
comment for the current head SHA:

```bash
head=$(gh pr view <pr> --repo credinvest/cred-platform-ts --json headRefOid --jq .headRefOid)
gh pr comment <pr> --repo credinvest/cred-platform-ts \
  --body "<!-- automerge-cleared: ${head} -->
🤖 Babysit rounds complete — critical/major bot findings fixed or dismissed-with-reason. Releases the pilot's iteration-locked hold for this commit."
```

The marker is bound to that SHA, so if you push again the pilot re-holds until a
new marker is posted for the new head. Only post it once round 2's critical/major
triage is genuinely complete (fixed or dismissed-with-reason). If you pushed
nothing in round 2, still post it last against the current head. Do NOT post it
in round 1. (Other repos: skip this step — no such pilot.)

**Marker preconditions — all three, immediately before posting:**
1. A fresh three-surface fetch (Step 2) ran *after* the last push, and every
   Critical/Major in it is fixed or dismissed-with-reason.
2. The dev-pipeline-agents verdict is current AND settled: **not** in
   placeholder state (verdict `UNKNOWN` = review still running), and it
   reviewed *this* head — a non-`UNKNOWN` verdict can be left over from a
   previous push, so confirm its iteration/commit corresponds to the
   `headRefOid` you fetch in (3). If it lags the current head, wait and
   re-check rather than trusting the stale pass.
3. The head SHA in the marker matches `headRefOid` fetched *now*, not earlier
   in the round.

A marker posted over a stale sweep silently releases the hold against unseen
findings — this exact failure shipped on PR #25958 (marker at 19:21 over a
19:13 inline Major that a memory-based "round 2" never fetched).

## Step 5 — Report and STOP

After the **second** round, emit a short status (covering both rounds) and end
the routine:

```
Babysit (2 iterations) complete — PR: <url>
Fixed & resolved:   <n> bot threads (round 1: <n>, round 2: <n>)
Acknowledged:       <n> (valid, out of scope)
Left for human:     <n> threads + any CI still pending
Not re-checking — ask me to run this again for another pass.
```

Then stop. **No third iteration.**

## Guardrails

- Two waits, two passes — never a third. Never loop here.
- Never `--no-verify`, `--amend`, or force-push to work around feedback.
- Never delete the PR or its branch (cred-agent-rules 0014).
- If a comment needs an architectural decision or is ambiguous, stop and ask
  the user instead of guessing.
- Production deploys / merges still require explicit human approval.

Auto-trigger hook (bind the skill to `gh pr create`)

The SKILL.md above defines what babysit-pr does, but the "run it automatically right after opening a PR" behavior comes from a PostToolUse hook, not the skill file. The SKILL.md alone never fires itself — install this hook if you want opening a PR (gh pr create) to automatically kick off babysit-pr and then chain into watch-pr-merge-verify. Without it, just invoke the skills by name.

1. Hook script — save as ~/.claude/hooks/babysit-pr-reminder.sh, then chmod +x it. Requires jq:

babysit-pr-reminder.sh — hook source (click to expand)

#!/usr/bin/env bash
# Personal PostToolUse hook (Bash): after a SUCCESSFUL `gh pr create`, remind the
# agent to run the bounded babysit-pr routine, then the watch-pr-merge-verify
# follow-on. Requires jq.
if ! command -v jq >/dev/null 2>&1; then
  echo "babysit-pr-reminder: jq not found — install jq to enable the auto-babysit reminder." >&2
  exit 0   # non-blocking: never break the tool flow over a missing optional dep
fi

input=$(cat)
cmd=$(printf '%s' "$input" | jq -r '.tool_input.command // empty')
out=$(printf '%s' "$input" | jq -r 'if (.tool_response|type)=="string" then .tool_response else (.tool_response // {} | tojson) end')

# Fire only on a real `gh pr create` invocation — at command start or after a shell
# separator, NOT inside echoed text or a comment — that ACTUALLY produced a PR URL in
# its output. This excludes failed creates, --dry-run, and any command that merely
# contains the substring "gh pr create".
if printf '%s' "$cmd" | grep -Eq '(^|[;&|]|&&|\|\|)[[:space:]]*(sudo[[:space:]]+)?gh[[:space:]]+pr[[:space:]]+create([[:space:]]|$)' \
   && printf '%s' "$out" | grep -Eq 'https://github\.com/[^[:space:]]+/pull/[0-9]+'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PostToolUse",
      additionalContext: "A PR was just opened with `gh pr create`. Per your personal auto-babysit rule, follow the babysit-pr SKILL.md exactly (do not work from this summary): (1) Run babysit-pr — exactly TWO comment rounds. Each round: wait until the expected review bots have actually REPORTED (the ~8-min timer is a floor, not proof of arrival — a CodeRabbit *review* must exist and cred-rabbit must be past its placeholder; one in-round extension is allowed), then fetch ALL THREE comment surfaces fresh — inline (`pulls/<n>/comments`), review bodies (`pulls/<n>/reviews`), and issue comments (`issues/<n>/comments`), all with `--paginate` — because CodeRabbit posts inline findings while its summary says clean and cred-rabbit edits findings in place; triage, fix and resolve the actionable ones, push. Report after round 2. Do NOT begin a third round. For cred-platform-ts, post the automerge-cleared marker only after a fresh post-push three-surface sweep, with the dev-pipeline verdict settled on the current head SHA. (2) THEN run watch-pr-merge-verify: keep an in-session, time-boxed watch on the PR merge state; on merge, if this session implies the change must be verified after it deploys (a test token/credentials were given, you were told to test on dev/staging once merged, or you ran/planned tests for it), autonomously wait for the build/deploy and resume that verification without being asked. If it merges with no such context, just say it merged and the deploy is underway, then stop. Never merge or deploy to production to enable verification."
    }
  }'
fi

2. Wire it in ~/.claude/settings.json — register the script as a Bash-matched PostToolUse hook (merge this into an existing hooks block if you already have one):

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "$HOME/.claude/hooks/babysit-pr-reminder.sh" }
        ]
      }
    ]
  }
}

Restart Claude Code after editing settings.json. On the next successful gh pr create, the hook confirms a PR was actually opened (a PR URL in the command output — so it won't fire on a failed create, a --dry-run, or a command that merely mentions the string) and injects the reminder that drives babysit-pr → then watch-pr-merge-verify. The hook only reminds; the actual work is done by the two skills, so install those alongside it.

pr-review-loop

What it does. The unbounded, "loop until clean" engine that babysit-pr delegates its low-level mechanics to: commit → open the PR → repeatedly fetch and triage automated review comments, fix and resolve them, and keep looping until the bots go quiet. babysit-pr reuses its exact fetch queries (§3.2), the Fix/Acknowledge/Dismiss triage table (§3.3), and the bot-thread reply/resolve procedure (§3.5) but caps itself at two rounds; pr-review-loop itself does not stop until the PR is clean.

When it triggers. "open a PR and fix comments until clean", "commit, PR, and handle reviews", "resolve bot comments", or the full commit-to-clean-PR pipeline. Use babysit-pr instead when you want a bounded couple of passes.

Files: SKILL.md

Install it from the repo, not from this page

Unlike the other entries in this catalog, pr-review-loop is a maintained, repo-scoped skill that already lives in cred-platform-ts at .claude/skills/pr-review-loop/SKILL.md (~13 KB). Pasting its full source here would only drift from the canonical copy, so install it directly — run this from the root of your cred-platform-ts checkout:

mkdir -p ~/.claude/skills/pr-review-loop
cp .claude/skills/pr-review-loop/SKILL.md ~/.claude/skills/pr-review-loop/SKILL.md

Then restart Claude Code. babysit-pr delegates its comment-fetch/triage/resolve mechanics to this skill, so install it for the full babysit experience — though babysit-pr still runs standalone without it (against plain gh api + the resolveReviewThread mutation), just without the pre-canned queries.

watch-pr-merge-verify

What it does. The follow-on to babysit-pr. After the comment-triage pass, it keeps an in-session, time-boxed watch on the PR's merge state; on merge, if the session implied the change must be verified after it deploys (a test token/credentials were given, you were told to test on dev/staging once merged, or you ran/planned tests for it) it autonomously waits for the build/deploy and resumes that verification — no user request needed. If merged with no such context, it announces the merge + that the deploy is underway, then stops. It does not re-run comment triage (that's babysit-pr's one bounded job).

When it triggers. Automatically right after babysit-pr reports, or on "watch the PR until it merges", "verify after deploy", "test it on dev once it's merged". The same auto-trigger hook that starts babysit-pr chains straight into this skill — there's no separate hook to install.

Files: SKILL.md

SKILL.md — full source for name: watch-pr-merge-verify (click to expand)

---
name: watch-pr-merge-verify
description: The follow-on to babysit-pr. After babysit-pr's bounded comment-triage (two rounds) completes, keep an in-session, time-boxed watch on the PR until it merges; on merge, if the session implies the change must be verified after it deploys (a test token/credentials were given, you were told to test on dev/staging once merged, or you ran/planned tests for it), autonomously wait for the build/deploy and resume that verification — no user request needed. If merged with no such context, announce the merge + that the deploy is underway and stop. Triggers automatically after babysit-pr per the personal rule in ~/.claude/CLAUDE.md, and on "watch the PR until it merges", "verify after deploy", "test it on dev once it's merged".
---

# Watch PR → merge → verify after deploy

This is the **continuation** of `babysit-pr`. That skill does its bounded
comment-triage (two rounds) and stops. This skill picks up where it stops and answers a
different question: *"once this PR actually merges and ships, is there something
in this session I'm supposed to go test — and if so, do it without being asked?"*

It does **not** re-run the comment triage. babysit-pr already owns that
(two bounded rounds, no open-ended looping). This skill only watches **merge state** and then, when
warranted, the **deploy + verification**.

## When this runs

- **Automatically**, immediately after `babysit-pr` reports, per the
  "Open a PR → babysit, then watch to merge/deploy" rule in `~/.claude/CLAUDE.md`.
- **On request**: "watch the PR until it merges", "verify after deploy",
  "test it on dev once it's merged".

## Step 0 — Capture the verification intent NOW (before any wait)

Do this **first**, while the session context is fresh — a later wake-up may have
lost it. Decide whether **post-deploy verification is pending** by scanning this
session for signals like:

- The user handed you a **test token / credentials / a specific account** for
  testing this change.
- The user said something like *"test it after it deploys"*, *"verify on dev
  once merged"*, *"check it works once it's live"*.
- You **ran or planned** Playwright / API smoke / `bun run verify` / manual
  checks for this exact change and were waiting on a deployed environment.
- The change is the kind only meaningfully verified on a deployed env (a
  backend/enrichment/deploy-gated behavior), and the session was driving toward
  that verification.

Write the **verification plan** down in your working notes now: *what* to test,
*where* (which env/URL), *with what* (token/account), and the *pass/fail signal*.
If none of these signals are present, record "no post-deploy verification
pending" — that changes Step 3.

## Step 1 — Watch for merge (in-session, time-boxed)

Poll merge state on a relaxed cadence; do **not** busy-wait:

- Use `ScheduleWakeup` with `delaySeconds: 1800` (~30 min) and a `prompt` that
  re-enters this skill's watch (e.g. *"Resume watch-pr-merge-verify: check if PR
  <url> has merged"*). `send_later` (deliver a message back to this session) is
  an equivalent mechanism.
- On each wake: `gh pr view <url> --json state,mergedAt,mergeCommit,url`.
  - **Still open** → re-schedule the next 30-min wake.
  - **Merged** → go to Step 2.
  - **Closed unmerged** → report "PR closed without merging — nothing to
    verify" and stop.
- **Hard cap: ~2 hours** (≈4 wakes). If it's still open at the cap, report
  *"PR still unmerged after 2h, stopping the merge watch — ping me / ask me to
  resume if you want me to keep watching"* and **stop**. Don't watch forever.

This watch is **in-session only**: if the session ends, the watch ends. That's
intentional (matches the bounded philosophy). If the user needs a watch that
survives the session closing, that's a `create_trigger`/cron job — only set one
up if they explicitly ask.

## Step 2 — On merge: branch on verification intent

- **Verification IS pending** (Step 0 found signals) → announce the merge and
  go to Step 3.
- **No verification pending** → announce: *"PR merged (<url>); the deploy is now
  underway. I have nothing queued to verify post-deploy, so I'm stopping here —
  ask me if you'd like me to verify anything once it's live."* Then **stop**.
  Do not babysit a build with nothing waiting on the other side.

## Step 3 — Wait for the build / deploy (tighter cadence)

Only reached when verification is pending. Figure out the deploy signal for the
target env and poll it on a cache-friendly cadence:

- This repo merges to `develop` → CI deploys to **dev**; agent deploys to
  dev/staging are permitted, prod is **not** (human approval only — never verify
  by deploying to prod yourself).
- Use whatever "is it live yet?" signal exists: the GitHub Actions / CI run for
  the merge commit (`gh run list`/`gh run watch`), a Vercel deployment for FE, or
  the deploy/release logs. Prefer watching the **specific run for the merge
  commit** over guessing a fixed delay.
- Poll with `ScheduleWakeup` `delaySeconds: 270` (stays inside the 5-min prompt
  cache window) while the build runs. **Cap ~45 min**; if the deploy hasn't
  landed by then, report what you see (build still running / failed / unclear)
  and stop rather than spinning.
- If the build **fails**, say so plainly with the failing step — don't proceed
  to verify against a stale deploy.

## Step 4 — Resume the verification (autonomously)

Once the change is confirmed live on the target env, execute the verification
plan from Step 0 **without waiting to be asked**:

- Run the queued tests (Playwright / API smoke / `bun run verify` / the manual
  GraphQL/DB/Playwright loop), using the token/account the user provided.
- For deployed-env testing in Alex's stack, the `cred-dev-workspace` skill and
  the env/token notes in this session are the source of truth for *how* to hit
  the environment.
- Report results: what you tested, where, the outcome (pass/fail with evidence),
  and any follow-up. Then **stop** — this routine is done.

## Guardrails

- **Never** merge the PR or deploy to **production** to make verification
  possible — prod merges/deploys are human-approval-only (security rules).
- Time-box both waits (merge ≈2h, deploy ≈45 min). Never poll indefinitely.
- Don't re-run babysit's comment triage here — that was its bounded triage (two rounds).
- In-session only by default; only create a session-surviving cron watch if the
  user explicitly asks.
- If what to verify is genuinely ambiguous after a merge, announce the merge and
  ask rather than guessing at a verification you might get wrong.

html-briefing

What it does. Render a substantial summary, briefing, audit, research findings, comparison, or report as a clean, self-contained HTML page saved to a local briefings folder and handed back as a clickable http://localhost link the user opens in VSCode's integrated browser — instead of a wall of plain text or markdown. It encodes the non-obvious bits: a scroll-safe page root (the #1 failure mode is a page that won't scroll until you resize the window) and why the link must be http://localhost, not file:// (the latter is silently dead in the Claude Code VSCode webview).

When it triggers. Delivering multi-section findings or a verdict the user will want to scan — not a short answer, a single fact, or code.

Files: SKILL.md, template.html

Companion server

This skill assumes a small local static server (installed by scripts/enable-html-briefings.sh in cred-platform-ts) is serving the briefings folder over http://localhost:8765, so a file's basename is its URL. If you install this skill standalone, either set up an equivalent local server (any python3 -m http.server 8765 rooted at your briefings folder works) or adjust the delivery step to whatever local-open mechanism you use.

`SKILL.md`

SKILL.md — full source for name: html-briefing (click to expand)

---
name: html-briefing
description: >-
  Render a substantial summary, briefing, audit, research findings, comparison, or
  report as a clean, self-contained HTML file saved to the local briefings folder and
  handed back as a clickable http://localhost link the user opens in VSCode's integrated
  browser when they want (never auto-opened, never an artifact link) — instead of a wall
  of plain text or markdown. Use whenever delivering multi-section findings or a verdict
  the user will want to scan, not when answering a short question, writing code, or
  stating a single fact.
---

# HTML Briefing

When findings are substantial, deliver them as a **visual HTML page** the user can scan
— not a long text/markdown dump. This skill is the source of truth for how to do that
**without the scroll bug** and **with a link that actually opens** in the Claude Code
VSCode extension.

> Installed opt-in via `scripts/enable-html-briefings.sh` from cred-platform-ts. The
> installer fills in the port/folder below. Full background:
> `docs/solutions/clickable-local-html-claude-code-vscode.md`.

## When to use

- ✅ Research findings, an audit, a verdict/decision report, a multi-section summary,
  a comparison, a status briefing — anything with hierarchy the reader will scan.
- ❌ Short answers, a single fact, code, or a quick back-and-forth. Don't over-render a
  two-line reply into a page.

When in doubt and the content has 3+ distinct sections or a scored/verdict structure,
render it.

## The scroll rule (non-negotiable)

The #1 failure mode is a page that won't scroll until the browser window is resized. It
is caused by pinning the page root or a content wrapper to the viewport height.
**Never do this:**

```css
/* ❌ these clip everything below the fold until a resize forces reflow */
html, body { height: 100vh; overflow: hidden; }
.container, .page, .wrap { height: 100vh; }
```

**Always start from this scroll-safe root instead** — content defines height, the page
scrolls:

```css
html, body {
  margin: 0;
  height: auto;          /* NEVER 100vh */
  min-height: 100%;
  overflow-x: hidden;    /* only ever hide the X axis */
  overflow-y: auto;      /* Y must always scroll */
  background: <page-ground>;
}
```

Put the page background on `html, body` (not only on an inner div) so the document
reports its true height from the first paint. A starting skeleton lives in
[template.html](template.html) — copy it and fill it in.

## Step 0 — Preflight: is the briefings server running? (self-check)

The localhost link only works if the tiny briefings server is up. Before handing one
back, check it — a link that renders but does nothing looks broken and erodes trust:

```bash
code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 2 http://localhost:8765/ || true)
```

- **Any HTTP code (200/403/404/…)** → server is up; proceed to Delivery.
- **`000` / connection refused** → it isn't listening. Distinguish installed-but-stopped
  from never-installed:
  ```bash
  test -f "$HOME/Library/LaunchAgents/com.cred.html-briefings-server.plist" \
    && echo installed || echo not-installed
  ```
  - **installed** → it's just stopped; restart and re-check:
    `launchctl kickstart -k gui/$(id -u)/com.cred.html-briefings-server`
  - **not-installed** → do **not** fail silently. Still write the `.html` (so the content
    isn't lost), then tell the user a one-time setup is needed instead of handing back a
    dead localhost link:

    > 💡 **HTML briefings aren't enabled on this machine yet.** To get clickable localhost
    > links, run this **once** (it survives reboots):
    > `bash scripts/enable-html-briefings.sh` — from a `cred-platform-ts` checkout.
    > Your briefing is already saved at `~/Briefings/<file>.html`; open it directly for
    > now, or say the word and I'll run the installer for you.

This nudge fires **every time** the skill runs while the server is down — by design. The
user will either enable it once, or tell you to stop delivering briefings this way (then
honor that and just return markdown). Don't suppress the nudge to avoid nagging: a dead
link with no explanation is the worse failure.

## Delivery — write the file, hand back a clickable localhost link, NEVER auto-open

**Do NOT auto-open the page** (`open`, `open -a`, etc.). Force-opening a browser splashes
the report on top of whatever the user is doing. They open it themselves, when they want,
by clicking the link.

**Use an `http://localhost:8765/<file>.html` link — NOT `file://`.** In the Claude
Code VSCode chat panel (a sandboxed webview), `file://` links are silently rewritten to a
dead `vscode-cdn.net` URL: they render with a hand cursor but the click does nothing.
`vscode://file/…` links only open the raw HTML *source* in the editor. **Only
`http://localhost` links stay clickable**, and they open in VSCode's integrated browser —
in-place, no context switch.

A LaunchAgent (installed by the enable script) serves the briefings folder, so **the
file's basename IS its URL**:

- Folder: `/Users/user/Briefings`
- URL: `http://localhost:8765/<basename>`

Name files `YYYY-MM-DD-<slug>.html` so they sort by date. After writing, **prune to the
40 most recent** so the folder never grows unbounded. (Raised from 10 on 2026-07-21:
several parallel sessions each pruning to 10 evicted same-day briefings another
session had just delivered.)

## Process

1. **Calibrate the design first.** If the `artifact-design` skill is available, load it to
   pick the right treatment (most briefings want a polished-but-utilitarian look, not a
   flashy hero).
2. **Write a standalone `.html`** to `/Users/user/Briefings/YYYY-MM-DD-<slug>.html` — full doc
   (`<!doctype html>…`), a `<title>`, all CSS inlined, scroll-safe root from above.
3. **Prune old briefings (do NOT open anything):**
   ```sh
   ls -1t "/Users/user/Briefings"/*.html | tail -n +41 | xargs -I{} rm -- "{}"   # keep newest 40
   ```
4. **End the reply with the clickable localhost link + a 2-3 line recap:**
   ```md
   📄 **[Open the briefing →](http://localhost:8765/YYYY-MM-DD-<slug>.html)**
   ```
   Then 2-3 lines of plain-text headline so the gist needs no click.
   (Fallback if the link 404s — server down: `launchctl kickstart -k gui/$(id -u)/com.cred.html-briefings-server`, or open the bare path in Finder. Never use a `file://` link.)

## Design baseline

- Self-contained only — inline all CSS; embed any image as a data URI. A refined system
  font stack is fine for briefings.
- Real hierarchy: an eyebrow/label, a clear headline, scannable sections. Use semantic
  color (good/warn/critical) for state, separate from one chosen accent.
- Responsive: relative units, flex/grid with `gap`; wide tables/code get their own
  `overflow-x: auto` container so the body never scrolls sideways.
- Choose a deliberate neutral and one accent — never the generic cream-serif-terracotta
  or acid-green-on-black AI defaults.
- Tasteful restraint over flourish. The job is readability, not a landing page.

`template.html`

template.html — source (click to expand)

<!doctype html>
<!--
  Standalone HTML briefing skeleton — served over http://localhost and opened in
  VSCode's integrated browser (no Artifact iframe). Replace the palette, copy, and
  sections. Inline all CSS; embed any image as a data URI.
-->
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>{Briefing title}</title>
  <style>
    :root {
      /* Deliberate neutral + ONE accent. Replace per subject; don't ship these defaults. */
      --ground: #f1f2f4;
      --card: #ffffff;
      --ink: #16181d;
      --ink-soft: #4a4f57;
      --ink-faint: #868d96;
      --line: #d8dce1;
      --accent: #3a5bd9;
      --good: #1f7a4d;  --warn: #a86d10;  --crit: #a32f2f;  /* semantic, separate from accent */
      --sans: ui-sans-serif, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
      --mono: ui-monospace, "SF Mono", "JetBrains Mono", Menlo, monospace;
    }
    * { box-sizing: border-box; }
    html, body { margin: 0; background: var(--ground); }   /* plain doc flow — scrolls natively */

    .page { max-width: 820px; margin: 0 auto; padding: 48px 24px 80px; font-family: var(--sans); color: var(--ink); line-height: 1.55; }
    .eyebrow { font-family: var(--mono); font-size: 12px; letter-spacing: 0.1em; text-transform: uppercase; color: var(--accent); font-weight: 600; margin: 0 0 12px; }
    h1 { font-size: 28px; line-height: 1.2; letter-spacing: -0.01em; margin: 0 0 10px; text-wrap: balance; }
    .lede { font-size: 16px; color: var(--ink-soft); margin: 0; max-width: 62ch; }
    h2 { font-family: var(--mono); font-size: 12.5px; letter-spacing: 0.08em; text-transform: uppercase; color: var(--ink-faint); font-weight: 700; margin: 38px 0 14px; }
    .card { background: var(--card); border: 1px solid var(--line); border-radius: 12px; padding: 18px 20px; }
    .card + .card { margin-top: 10px; }
    p { margin: 0 0 10px; }
    .scroll-x { overflow-x: auto; }   /* wide tables/code scroll inside themselves, not the page */
    @media (max-width: 640px) { .page { padding: 36px 18px 64px; } }
  </style>
</head>
<body>
  <div class="page">
    <p class="eyebrow">Briefing · {date}</p>
    <h1>{Headline}</h1>
    <p class="lede">{One-sentence what-this-is and the bottom line.}</p>

    <h2>{Section}</h2>
    <div class="card">
      <p>{Content.}</p>
    </div>
  </div>
</body>
</html>

Contributing a skill to this page

Found a global skill worth sharing? Add it here so the rest of the team can install it:

Add a row to the summary table.
Add a ## <skill-name> section with: a What it does paragraph, a When it triggers line, the list of Files, and each file's full source inside a fenced code block (use a four-backtick ```` fence for SKILL.md, since the source itself contains triple-backtick code blocks).
Exception — maintained repo skills: if the skill lives canonically in a product repo (like pr-review-loop) where it's actively maintained, don't embed its source — it would drift from the canonical copy. Instead give a short !!! note with the exact cp-from-repo install command.
Strip any secrets/tokens, and call out machine-specific coordinates so installers know what to adapt.

Claude Code — Global Skills

The skills

cred-dev-workspace

babysit-pr

Auto-trigger hook (bind the skill to gh pr create)

pr-review-loop

watch-pr-merge-verify

html-briefing

SKILL.md

template.html

Contributing a skill to this page

Auto-trigger hook (bind the skill to `gh pr create`)

`SKILL.md`

`template.html`