Ayy-man/watchdog-kit

Agent Skills that put telemetry and a watchdog on a client app, and stop for a human at every decision that matters.
Two skills, run in this order:
| Skill | What you get | When |
| /telemetry | PostHog installed properly, and a page the client opens to see the build working | Start of client testing |
| /watchdog-build | A report-only watchdog that catches silent failures, scored against the app's own past incidents | Once the build is stable |
Works in Claude Code (/name) and Codex ($name).
| The value tab, as the client sees it | The Health tab, with the watchdog's findings |
Design boards with placeholder data. All sixteen, across four very different builds, are in skills/telemetry/references/examples/, each plan ending with its own boards.
## Quick start
git clone https://github.com/Ayy-man/watchdog-kit ~/watchdog-kit
cd ~/watchdog-kit
node scripts/install.mjs --all --yes
Then open a client repo and run /telemetry. It asks three questions, scans the code, and tells you what it needs next. Run it again any time and it picks up where it stopped.
## /telemetry
1. Asks the tier, who signs off, and whose client it is.
2. Scans the code and writes .telemetry/SERVICES.md: every service the app touches and how its events will reach PostHog.
3. Installs PostHog in the account you name (yours, the client's or a partner's, new or existing project, US or EU): tags on every event, internal users filtered out, AI prompts kept private, a reverse proxy, replay masking.
4. Plans the page in ten steps, writes .telemetry/PAGE-PLAN.md, and stops for the account owner.
5. Builds the page in the client's own stack and design system.
6. Hands on to /watchdog-build on Custodian builds. The watchdog's findings page becomes the Health tab.
It never passes these without the account owner: which PostHog account and region, the billing limits, session replay consent, and the page plan. It writes only .telemetry/. Four worked plans in skills/telemetry/references/examples/ show the same steps producing very different pages.
## /watchdog-build
1. Surveys every door the app has (webhooks in, provider calls out, scheduled jobs) and how each proves it fired.
2. Builds deterministic checks on that contract, plus a model review that may only quote evidence it was handed.
3. Puts findings on a page where a human marks each one correct or a false alarm.
4. Scores itself against the app's own incident history.
Nine phases, a human stop after each. Report-only by construction: the runtime holds no credential it could send with. The phase order and gates are in skills/watchdog-build/SKILL.md and skills/watchdog-build/references/shared-contract.md.
Two ways to work (step by step, or run ahead)
On the first run it asks which way you want to work. The answer changes when it asks, never who decides.
Step by step (default): it stops and asks at every checkpoint. For when you are at the keyboard.
Run ahead: you answer up front what can be answered up front (the model key's variable name, the spend cap, the review slot times, which model to keep after the bake-off), and it builds everything whose inputs exist while queueing the questions that need you. --status lists the queue when you come back. Independent phases (the explainer, the incident history, the heartbeats) run at the same time once the survey is approved.