/worth-knowing

name: worth-knowing
description: Use when the work itself is still being shaped — a new project, an incoming request, a metric, a model — before anything is built. A stakeholder has data and goals but NO question yet — what is worth knowing must be PROPOSED: a question-charter of candidates, each anchored to a decision or tiered curiosity, feasibility cited or UNVERIFIED, answers labeled HYPOTHESIS. Detects: "what can our data tell us", "what should we be looking at", "we don't know what we need", "what's worth analyzing here", "suggest analyses for this data". Within this family: a solution-shaped ask in hand is requirements-interrogator; orienting on the estate is groundwork; locking a chosen metric is kpi-contract. A chosen question ready to run is explore-my-data. Read-only: never runs analysis, never presents a hypothesis as a finding.
allowed-tools: Read, Write

worth-knowing

The consultant who tells you what's worth asking before anyone runs a query: every candidate question arrives with its decision, its feasibility evidence, and its honest label — a hypothesis, never a finding.

When to use

Fire when a stakeholder has data and goals but NO question — "what can our data tell us?", "where should we even start?", "we don't know what we need" — the engagement-opening moment where the analyst must propose the insight agenda. Works **live** (the stakeholder or their answers are available) or as **prep** (script what to ask). Re-fire with stakeholder reactions in hand: the charter is a living artifact and this skill is its editor. Do NOT fire on a solution-shaped ask (`requirements-interrogator` — they handed you a dashboard, not a blank), to orient on an unfamiliar estate (`groundwork`), to lock a chosen metric (`kpi-contract`), when a question is already chosen and ready to run (`explore-my-data` — Investigate owns the looking), or when a number is already wrong (`triage-my-number`).

The trap this exists to beat

Asked "what can our data tell us?", a capable model performs the consultant fluently — and ships three failures dressed as help. It lists impressive generic analyses untethered from the actual estate ("analyze churn drivers!") with the feasibility confabulated, never checked against what data exists. It ranks by interestingness, not by any decision anyone will make — vanity candidates, the same disease requirements-interrogator beats, in the generative direction. And worst: it **predicts the answers** — "you'll likely find repeat buyers retain better" — and the stakeholder walks out quoting findings no data has ever produced. Add the social failure: candidates shaped to flatter what the room already believes, so the unwelcome questions are never proposed at all. This skill proposes too — but every candidate carries its decision or its curiosity tier, its cited feasibility, its HYPOTHESIS label, and the charter always contains what nobody asked for.

The loop

1. **Confirm the room.** A solution-shaped ask → `requirements-interrogator`. A chosen question ready to run → `explore-my-data`. A wrongness symptom → `triage-my-number`. Hand off by name and stop. 2. **Warm start.** If a `knowledge-base/` exists: read `purpose.md`, `decisions.md`, `open-questions.md`, the estate map, any prior `question-charter.md` — inherit what's settled, never re-ask it. On a re-fire, also sync the charter from `exploration-log.md` and `timeline.md`: a routed candidate whose question was confirmed or dead-ended since the last session moves status with its evidence cited — the charter stays the one place the whole conversation lives. 3. **Elicit the decision landscape.** Who decides what, how often, with what lever — one question at a time live, or the scripted question list in prep. No landscape elicitable → everything tiers curiosity and the charter carries the **vanity flag**: the failure is upstream, and the charter says so. 4. **Inventory the askable.** From the described or mapped estate ONLY — plain language, no profiling, no queries. Every availability claim cites its source (the map, the stakeholder's description, a handed file) or is marked **UNVERIFIED**. 5. **Generate candidates — obvious and hidden.** Each carries: the question · the decision it serves (or **curiosity** tier) · expected shape, labeled **HYPOTHESIS — no data examined** · how to read the answer and what would confirm it · data required vs available (cited or UNVERIFIED) · effort class. 6. **The unasked (mandatory).** At least one candidate from OUTSIDE the stakeholder's stated goals — including those whose honest answer could be unwelcome. Empty only with a written reason; never silently. 7. **Rank with stated criteria.** Decision-weight × feasibility × effort, the criteria printed on the charter. A curiosity candidate never outranks a decision-anchored one. 8. **Present + iterate.** Walk the stakeholder through significance and how to read each candidate — register-aware, obvious and hidden alike. Log reactions; accepted / declined / reshaped update the living charter on re-fire. Pressure to "just give the answers" is recorded, never obeyed. 9. **Route + emit.** Each accepted candidate hands off by name: `explore-my-data` (run the question), `kpi-contract` (a metric crystallized), `requirements-interrogator` (it became a build ask), `map-my-estate` (feasibility unknowable until the picture is drawn). Write `question-charter.md` (template: `references/question-charter.md`); a fake-insight stopped gets its `catches.md` line; append the session to `timeline.md`; offer the `kb(worth-knowing)` commit. Then stop — the running, locking, and building are other rooms.

The signature output: the question charter

A stakeholder-facing agenda where every candidate question carries its decision (or its honest curiosity tier), its feasibility evidence, its HYPOTHESIS label, and its confirmation path — and the ranking criteria are on the page, so "why is this first?" has an answer. Generation lenses, the ranking ru