telemetry-verify
Skill20 starsChanged 13 days agoMITView on GitHub
The telemetry witness: reads what the services recorded during one closed window of traffic another skill produced (ui-verify, verify, a repro), traces each acceptance criterion from web event to backend trace to database, and finds errors behind a green UI, slow paths, and missing signals. Never edits code; run on its own, it posts its receipt to the PR's verify comment. Triggers on "check the telemetry", "prove it with traces", "/telemetry-verify".
In this repository48 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- skills/workflow/autonomous-workflow/CLAUDE.mdCLAUDE.md
- ideateSkill
- interviewSkill
- playwright-trace-analyzerSkill
- profile-optimizerSkill
- rum-trackingSkill
- screencastSkill
- video-analyserSkill
- youtube-transcriptSkill
- create-skillSkill
- docsSkill
- handoffSkill
- optimize-claude-mdSkill
- persistent-memorySkill
- attach-mediaSkill
- ci-auto-fixSkill
- create-prSkill
- github-actions-authorSkill
- resolve-conflictsSkill
- animations-nativeSkill
- animationsSkill
- behavioral-designSkill
- chartingSkill
- storybookSkill
- uxSkill
- visual-designSkill
- ai-engineeringSkill
- confidenceSkill
- criticalSkill
- impact-mapSkill
- jev-assertSkill
- measurableSkill
- optimize-approachSkill
- polishSkill
- pr-reviewSkill
- review-loopSkill
- tddSkill
- verify-behaviorSkill
- aw-verifySkill
- e2e-testing-mobileSkill
- e2e-testingSkill
- ui-verifySkill
- autonomous-workflowSkill
- aw-create-planSkill
- aw-create-walkthroughSkill
- fix-bugSkill
- implement-suggestionSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 3 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 36
Use general as the sub-agent type on OpenCode and Dash0 Agent0.
- Very specific: line 65
If now < --to + ingest_wait_seconds, sleep the difference.
- Very specific: line 76
Every component that served traffic in the window, and the web SDK when browser traffic ran, must have left at least one record.
- Very specific: line 84
Every telemetry: acceptance criterion in the brief, refused when it is by-construction.
- Distinctive: line 85
Every signal the diff adds: spans, attributes, logs, metrics, and custom web events.
- Distinctive: line 94
Performance: only for routes a journey exercised.
- Very specific: line 96
Read only the backend file and rules/receipt.md § Output.
- Very specific: line 98
Run the backend file's queries for steps 2–4 of rules/receipt.md: journeys, errors, performance.
- Very specific: line 113
Run on its own (no --no-comment), post the receipt as the telemetry region of the PR's one verify comment, per the aw-verify skill's …
- Distinctive: line 163
Silence is never clean: No records means the pipe is broken or the read is early, not that nothing went wrong.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Telemetry verify
The browser proves what the user saw; this skill proves what the services saw while they saw it.
It reads closed time windows of traffic someone else produced and returns one TELEMETRY block.
It never produces traffic, never edits code, and never widens the window to find something.
Invocation
Skill("telemetry-verify", "--env <local|preview> (--windows <probes.jsonl> | --from <ISO-8601 UTC> --to <ISO-8601 UTC>) [--host <preview host>] [--driver playwright|chrome] [--brief <plan.md path>] [--out <findings.jsonl path>] [--pr <url|number>] [--no-comment]")Callers run it in a sub-agent, so query results stay out of their context, and pass --no-comment, because they post the receipt in their own region:
Agent(subagent_type="general-purpose", prompt="Run Skill(\"telemetry-verify\", \"<args> --no-comment\") and return only its TELEMETRY block")Use general as the sub-agent type on OpenCode and Dash0 Agent0.
| Argument | Meaning |
--env | The environment in .agents/aw/environments.yml the traffic ran against |
--from, --to | The traffic window, recorded by the caller immediately before and after it |
--windows | A probes.jsonl whose lines carry id, window_start, window_end, and optional log_offsets: read them all in one pass, from the first start to the last end, and attribute each record to the window that contains it |
--host | The preview host; filters web events to this run's pages |
--driver | The browser driver; chrome is the user's own browser, so sessions cannot be isolated |
--brief | plan.md; its telemetry: acceptance criteria become expectations. Default .agent/{branch}/plan.md when it exists |
--out | Append findings to this file in the aw-verify skill's findings record shape |
--pr | The PR whose verify comment gets the telemetry region; default the current branch's PR (gh pr view --json url) |
--no-comment | Post nothing; every calling skill passes it |
Step 0 — Resolve config and skip honestly
Resolve .agents/aw/telemetry.yml and environments.yml plus the personal overlay (~/.agents/aw/config.yml → repos.<owner>/<name>), as the aw-verify skill's rules/config.md defines.
Take the first row that applies; each prints its line and returns verdict: null:
| Condition | pipe: line |
No .agents/aw/environments.yml | skipped (no .agents/aw config — run /aw-verify setup) |
backend: none | skipped (telemetry.backend: none) |
backend: dash0-mcp and no connected tool ends in getSpans or getWebEvents | skipped (no Dash0 MCP server connected) |
The window holds only browser traffic and the app ships no web SDK (no telemetry.yml → web block, no @dash0/sdk-web dependency) | skipped (no web SDK in this app) |
Step 1 — Wait for ingest
With --windows, --from is the first window_start and --to the last window_end.
If now < --to + ingest_wait_seconds, sleep the difference.
Query from = --from − 30 s and to = --to + 30 s, the same on every retry.
✗ Wrong — 0 events → widen to the last 15 minutes → judge what came back (someone else's traffic)
✓ Right — 0 events → wait 30 s → re-query the same window, at most 4 attemptsStep 2 — Pipe check
Prove the backend can see the window before reading any absence as good news.
Every component that served traffic in the window, and the web SDK when browser traffic ran, must have left at least one record.
A component that served requests and left nothing is missing-signal; zero records everywhere after the retries is pipe: inconclusive (no records in window), never clean.
A signal the environment does not export (for example logs that go only to stdout) is not-exported (<signal>), not missing-signal; read it from the process log under the window's log_offsets.
Step 3 — Expectations
Collect them per rules/expectations.md:
- Every
telemetry:acceptance criterion in the brief, refused when it is by-construction. - Every signal the diff adds: spans, attributes, logs, metrics, and custom web events.
Step 4 — Read and judge
Spend queries in this order and stop as soon as every expectation and AC has a verdict; about 12 calls covers a run:
- Errors, whole span: one query each for ERROR spans, ERROR/WARN logs, and error web events, scoped to this run's service or instance. Attribute each hit to its window.
- Expectations: one query per
telemetry:criterion and per new signal. - Journeys:
getTraceDetailsonly for an AC whose window had an error, or whose path you cannot otherwise confirm. - Performance: only for routes a journey exercised.
Read only the backend file and rules/receipt.md § Output; the other rule files are for disputes.
Run the backend file's queries for steps 2–4 of rules/receipt.md: journeys, errors, performance.
backend | File | Sees |
dash0-mcp | rules/dash0-mcp.md | Spans, logs, metrics, and web events in a Dash0 dataset |
logs | rules/logs.md | Service logs the stack driver captured, plus browser console and network evidence |
A configured backend that is unreachable is pipe: skipped (<reason>); never swap backends silently.
Step 5 — Return the block
Print exactly the block in rules/receipt.md § Output, and append findings to --out when given.
Step 6 — Post the telemetry region
Run on its own (no --no-comment), post the receipt as the telemetry region of the PR's one verify comment, per the aw-verify skill's rules/pr-comment.md (its § When to post gate, and its script):
node "${CLAUDE_SKILL_DIR}/../aw-verify/scripts/verify-comment.mjs" --pr <pr-url> --section telemetry --file .agent/<branch>/telemetry-verify/comment-telemetry.mdRegion body, in the aw-verify skill's rules/pr-comment.md § Layout shape, a ### headline because it may sit under an aggregate region:
### <✅ Telemetry confirms | ❌ Telemetry contradicts | ⚠️ Telemetry is ambiguous | ⏭️ Telemetry not graded> — <what the services recorded, in the user's words>
<One sentence: which journeys were recorded end to end.> <under a ✅ with nothing open: **Nothing needs your attention.**>
<the attention section, per the `aw-verify` skill's `rules/pr-comment.md` § Attention line: `#### Why not ✅` under ⚠️, ❌, and ⏭️ (`#### Needs you` under a ✅ with an open critical/high finding), then one `- **<what the user would notice>** (<tag>) → <next step>` bullet per `contradicts` journey (`failed check`), ambiguous journey and what would settle it (`ambiguous`), or reason it was not graded and the fix (`not graded`), then each open critical/high finding; omitted under a ✅ with nothing open>
<sub>`<head-sha7>` · <env> · window <from> → <to> · updated {{UPDATED}}</sub>
#### What I checked
<details><summary>✅ <b>Save a view</b> → traced from the click to the database</summary>
click "Save" → POST /api/views 201 (84 ms) → views-service PUT (21 ms) → postgres INSERT (4 ms). [trace 4bf92f35](<Dash0 link>)
<sub>Proves AC-2</sub>
</details>
<details><summary>Details</summary>
**Run details**
**telemetry-verify** · head `<head-sha>` · `<env>` · window <from> → <to> · backend <backend and scope>
- pipe: <the pipe line>
- verdict: <confirms | contradicts | ambiguous | null>
| ID | Kind | Severity | What happened | Evidence |
| --- | --- | --- | --- | --- |
</details>Row glyphs: confirms ✅, contradicts ❌, ambiguous ⚠️, null ⏭️.
One row per journey, <what the user did> → <what the services recorded>; a contradicts row comes first and is <details open>, every other row is closed.
Evidence is a link from the backend's URL tool (generateDash0Url) or a trace ID; never a log file path.
Print comment: <comment-url> (region telemetry), or the not posted (<reason>) / failed (<reason>) line.
Core principles
- Read-only, one window. Judge only records inside the window the caller produced; the only write is the PR comment's
telemetryregion. - Silence is never clean. No records means the pipe is broken or the read is early, not that nothing went wrong.
- Behavioral, never by-construction. A claim that reading the source could satisfy is refused, not graded.
- Findings never change the verdict. The verdict answers the brief's telemetry criteria; findings are reported beside it.
- No repo values in
rules/. Datasets, services, and thresholds come from.agents/aw/.
Definition of done
- Config resolved, or a
skipped (<reason>)line printed. - Ingest waited; every retry used the same window.
- Pipe checked before any absence was judged.
- One journey line per acceptance criterion the window exercised.
- The
TELEMETRYblock printed exactly; findings appended when--outwas given. - Run on its own: the
telemetryregion posted, or acomment: not posted (<reason>)line.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

