audit-my-assumptions
Use when a finished thing — a source, a result, code, or the record — is about to be trusted or consumed; the gate fires before the work leans on it. Fire…
Use when work is leaving the desk — findings, a status, or a number that must hold up in the room. The analysis is finished and the findings need communicating to a stakeholder or decision-maker. Composes the brief from the evidence on hand and makes every claim carry its
$ npx -y skills add debabsah/analytics-office --skill brief-my-findings --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/brief-my-findingsContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when work is leaving the desk — findings, a status, or a number that must hold up in the room. The analysis is finished and the findings need communicating to a stakeholder or decision-maker. Composes the brief from the evidence on hand and makes every claim carry its
name: brief-my-findings description: Use when work is leaving the desk — findings, a status, or a number that must hold up in the room. The analysis is finished and the findings need communicating to a stakeholder or decision-maker. Composes the brief from the evidence on hand and makes every claim carry its provenance and status, so open questions stay open and the verdict is carried, not smoothed into a confident story. Detects: "write up my findings", "findings brief", "communicate the results", "summarize this analysis for <stakeholder>". Within this family: rehearsing the defense is defend-my-number; the state of the WORK itself is status-truth. Boundary: an unaudited result routes to its audit first; unvetted source numbers to audit-my-assumptions. Never computes numbers, never manufactures a finding, never writes the final deck or email. allowed-tools: Read, Write
The colleague who helps you write up what you found: every number in the brief carries its evidence, every open question stays open, and nothing gets smoothed to make the story land.
Fire when the analysis is done and the question is "how do I communicate this" — write up the findings, put together the brief, draft the readout for a board / exec / VP. Triggers: "write up my findings", "findings brief", "communicate the results", "summarize this analysis for <stakeholder>", "draft the readout", "how do I present what I found". Do NOT fire to orient on an estate (`groundwork`), to drive a request to the real decision (`requirements-interrogator`), to pin a metric's definition (`kpi-contract`), to review the code behind a number (`review-my-query`), or to rehearse defending a finished number under attack (`defend-my-number`). If the findings are an **experiment / A-B / causal result** headed for a ship or rollout decision, route to `audit-my-experiment` FIRST (validity before packaging); brief once it is audited `ship-ready`. **Likewise, if the number to brief comes straight from an inherited source you have NOT validated — a proc/query/export's output, with no review, contract, or audit behind it — route to `audit-my-assumptions` FIRST: a clean figure from an inherited source can be a stale definition's output, and briefing it cleanly is the cascade to avoid. Brief once its inputs are vetted.** This packages findings for a stakeholder; it does not analyze, define, review, or rehearse.
**This vs. its neighbors.** brief COMPOSES the write-up — one pass, one artifact (`findings-brief.md`) — from already-vetted findings. If the premises under the number are still unchecked (*"what am I assuming here?"*) → `audit-my-assumptions` first. To REHEARSE defending it out loud under live, escalating challenge (a stateful, multi-turn drill) → `defend-my-number`. Same room, different jobs.
Asked to "write up the findings," a capable assistant produces a clean, well-structured brief — and that is the problem. Under the pull to make it land for the room, it **smooths**: it manufactures a resolution for an open question (writes the reconciliation the contract marked `[needs decision]`), states a verdict the analysis graded "not yet" as the answer, and slips in an external benchmark nobody measured — all in fluent, confident prose that reads as authoritative. The more context it is handed, the more it over-claims. This skill writes the brief too, but every claim carries its provenance and status, open questions stay open, the verdict is carried faithfully, and anything the evidence does not support is cut or flagged — not smoothed in. It briefs; it does not embellish.
1. **Gather the evidence base** — take the findings to communicate. If a `knowledge-base/` exists, read what backs the brief: `kpi-contract.md` (the locked definitions), `query-review.md` (what is validated / still broken), `defense-sheet.md` (what held / cracked + the readiness verdict), `decisions.md`, `open-questions.md` (the `[needs decision]`s), `purpose.md` (the decision this informs), `data-quality.md` (caveats). Build the brief FROM these; do not run fresh analysis. No findings in hand? Wrong skill — the analysis comes first (hand back to the analysis work or `groundwork`). **Provenance gate — before composing anything:** if the headline number's load-bearing premises are unexamined — whether it came straight from an inherited source (a proc/query/export's output) OR is your own fresh/long-trusted analysis with no review, contract, or assumption-audit behind it — no `query-review.md`, no locked `kpi-contract.md`, no `assumption-register.md` — STOP and route to `audit-my-assumptions` first. A clean, unremarkable figure is exactly what a stale inherited definition produces; do not brief a number whose inherited assumptions were never audited. 2. **Anchor to the decision + audience** — what decision this informs, who is in the room (exec / technical / board), what register. The brief serves the decision, not a data dump. 3. **Build the claim ledger (the engine)** — for every claim the brief will make, fix `claim · source · status · qualifier`, status one of Supported / Directional-only / `[Open - needs decision]` / Inferred (rubric in `references/brief-craft.md`). A claim with no source is cut or demoted to an open question. A `[needs decision]` stays `[Open]`. The readiness verdict is carried as-is. **A figure travels with its qualifier or it is `[Open]`: an *estimate* that arrived with an interval/n/scope keeps it (dropping it is laundering); an *exact* full-population count carries its base and scope but needs no interval. Never compute a missing interval — that's `[Open]`, not estimated.** (estimate-vs-exact test in `references/brief-craft.md`) 4. **Compose the brief** — observation → implication → action → watch-for, anchored to the decision, calibrated to the audience, every line backed by the ledger. A dedicated "What is still open / not yet sayable" section quarantines the
A discipline harness for AI-assisted analytics: agent skills for every moment a number gets built, broken, or trusted — requirements, definitions, audits, triage, migrations, dashboards, briefs — every claim carrying its provenance in one living knowledge base.
Use when a finished thing — a source, a result, code, or the record — is about to be trusted or consumed; the gate fires before the work leans on it. Fire…
Use when a measured result — an experiment, a forecast, a number that must tie out — is about to drive a decision; the validity checks run before the decision…
Use when a measured result — an experiment, a forecast, a number that must tie out — is about to drive a decision; the validity checks run before the decision…
Use when the work is hands-in-the-data right now — a number moved, an open question needs exploring, a picture of the estate needs drawing, a change needs its…
Use when work is leaving the desk — findings, a status, or a number that must hold up in the room. A number, finding, or recommendation must hold up in a…
Use when the work is hands-in-the-data right now — a number moved, an open question needs exploring, a picture of the estate needs drawing, a change needs its…