Skip to content
Content
Skill

/imagineer

Fan out MANY candidate interactive concepts from the data + narrative — the ideation pool the Editor curates a hero + supporting set from. Deliberate over-generation: one concept per finding worth making hands-on, each declaring its archetype, purpose, what the reader produces,

BOOST
From plugin
data2story-skill
15827 skills
Install
$ npx -y skills add QinghongLin/data2story-skill --skill imagineer --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/imagineer

Context preview

The summary Claude sees to decide when to auto-load this skill.

Fan out MANY candidate interactive concepts from the data + narrative — the ideation pool the Editor curates a hero + supporting set from. Deliberate over-generation: one concept per finding worth making hands-on, each declaring its archetype, purpose, what the reader produces,

SKILL.md

imagineer.SKILL.md
name: imagineer
description: "Fan out MANY candidate interactive concepts from the data + narrative — the ideation pool the Editor curates a hero + supporting set from. Deliberate over-generation: one concept per finding worth making hands-on, each declaring its archetype, purpose, what the reader produces, and an honest feasibility (node-checked against the Analyst's client_model). Builds NOTHING on-page — img_xx concepts are internal and never reach HTML. Outputs imagineer.json after the Analyst, before the Editor."
argument-hint: "[PROJECT_DIR]"
allowed-tools: Bash(*), Read, Write, Glob

Imagineer

Your job is **ideation, not construction**. You read the findings and the narrative and you fan out a wide pool of candidate *interactive concepts* — ways a reader could **produce** a finding (run the model, guess-then-reveal, enter their own value, play the odds) instead of just reading it. You deliberately **over-generate**: propose one concept for every finding worth making hands-on, even the marginal ones. The Editor curates this pool down to a hero + a ranked supporting set; the Interaction Engineer builds only what the Editor keeps.

You build **nothing on the page**. Your `img_xx` ids are **internal** — a planning vocabulary the Editor reads. They never reach the HTML, are tagged on no element, and are added to no provenance tuple. Your one job is to make the candidate pool rich, honest about feasibility, and bound to real findings.

Setup

  • `PROJECT_DIR` = first argument.
  • `SKILL_DIR` = the directory containing this `SKILL.md` (`.../skills/data2story-pro/imagineer`).
  • Read `PROJECT_DIR/analyst.json` — its `items` give you the findings (`ana_xx`: `label`, `content`, `data_table`, and any **`client_model`**). The `client_model`s are what make `explorable_recompute` concepts feasible; note which findings carry one.
  • Read `PROJECT_DIR/detective.json` — for the shared **[`topic_profile`](../references/topic_profile.json)** (the S3 classifier: `is_computational` / `is_visual` / `tags`) that gates how hard you fan out.
  • Read `PROJECT_DIR/editor.md` + `editor.json` **if they already exist** (the spine — which finding is the lead, the section order); they may not yet, since you usually run before the Editor. When absent, work straight from `analyst.json` and mark the lead candidate yourself.
  • Output: `PROJECT_DIR/imagineer.json` (write incrementally).

When to run (and when to stay light)

Key this off the shared **[`topic_profile`](../references/topic_profile.json)** (the same two-condition default the Cinematographer uses, read from `detective.json`; if absent, classify the dataset yourself the same way and record it). The pool's size should track what the data can actually support:

  • **Fan out widely** when **`is_computational` is true** (the headline is a reproducible calculation — a probability, rate, ranking, model output, aggregate): these are the findings a reader can re-run, so `explorable_recompute` / `tune_the_assumption` / `scored_quiz` concepts are all on the table. Propose several.
  • **Fan out moderately** when **`is_visual` is true** but the lead is not computational: `guess_then_reveal` / `personal_input` / scrollytelling concepts still let the reader produce a finding without a model.
  • **An abstract topic is still a first-class flagship target** — read **[`../../frontend-design-pro/references/abstract_excellence.json`](../../frontend-design-pro/references/abstract_excellence.json)** to choose the engagement + narrative moves before deciding how hard to fan out. When **`is_computational` is true but `is_visual` is false** (finance, web-analytics, elections, pure statistics, benchmarks), the page wins on insight + transparency, not photos: the runnable-verify layer FAVORS these topics, and an `explorable_recompute` / `tune_the_assumption` on the computed headline is strong hero material — propose them. Reach also for `personal_input` "where you land" whenever the data has rows the reader fits into (income, age, region, score).
  • **Engagement floor (purely-descriptive sub-case) — now a HARD floor** — when **BOTH `is_computational` and `is_visual` are false** (no computed headline to re-run, no imagery): you **MUST propose ≥1 simple engagement-floor concept** — a `personal_input` / `personal_input_where_you_land` or a `sortable` (`sortable_table`) (a `scored_quiz` also qualifies) on a **descriptive** finding (where you land in the distribution, sort the catalog yourself) — so the Editor isn't forced to ship an empty/charts-only page. This is NOT forced decoration: the restraint still holds — do not force a concept onto a finding with no reader-producible payoff. The ONLY sanctioned way to ship **zero** interactives on a resolved descriptive topic is for an explicit `engagement_blocker` reason to be recorded (e.g. the data has no row a reader fits into AND no entity set to sort). You are the one who **proposes** that blocker, but the contract gate (`missing_engagement_floor`) reads the honored reason **only** from `interaction.meta` (NOT from your `imagineer.json`) — so your recorded reason is **advisory**, and the Interaction Engineer must **propagate** it into `interaction.meta.engagement_blocker` (alias `engagement_floor_reason`) for the gate to honor it. "Ship zero with no recorded blocker" is **no longer allowed**: it hard-errors at the contract gate (`missing_engagement_floor`). (`privacy_sensitive` topics are auto-exempt.) When you propose the blocker, note in **one** item why the pool is near-empty (a clean editorial column + the signature annotated chart is acceptable) so the Editor sees the omission is intentional, and STOP.

Record the resolved `is_computational` / `is_visual` in `meta` so the Editor sees the gate you applied. On a resolved descriptive topic where you propose shipping zero interactives, also record an **advisory** copy of the escape field in `meta` — `engagement_blocker` (the honest reason no reader-fits-in lever exists; the alias

Read more
Ships withdata2story-skill

A data-journalist agent skill that turns any dataset into a verifiable, evidence-grounded multimodal story — a self-contained HTML article where every sentence traces back to the data or source that justifies it.

Get the whole plugin
Stats
158
Stars
23
Forks
Maintained
Maintenance
Python
Language
MIT
License
3mo ago
Last commit
5mo ago
Created
6d ago
Added

Repo: QinghongLin/data2story-skill

Other skills on data2story-skill.