| name | haipipe-application-themes |
| description | Stage orchestrator for the intervention's 0-lifecycle/1b-themes/1b-themes.md: rung 1b of the venue-FREE evidence ladder (1a-descriptions -> 1b-themes -> 1c-claims -> 1d-advice). Thematic extraction: which patterns/topics emerge from the described data and the outside literature. Every theme cites at least one D id or discovery source. Discovery-probe lane. Markdown only. Trigger: themes, theme, topic space, what patterns emerge, thematic, /haipipe-application themes. |
| argument-hint | [intervention-path] |
| allowed-tools | Bash, Read, Write, Edit, Grep, Glob, Skill |
| metadata | {"version":"0.2.7","last_updated":"2026-07-19","summary":"Themes stage (rung 1b of the venue-FREE 1a–1d evidence ladder; the I rung) — grounded pattern-clusters extracted from 1a D ids + discovery sources, each theme carrying candidate-claim hooks that rung 1c consumes; ungrounded patterns go to Parked. Full D-consumption + counter-hunt; light discovery PROBE via 1-probes/. History: ./CHANGELOG.md."} |
Skill: haipipe-application-themes
Rung 1b of the venue-FREE evidence ladder — the exploration frame between described data and committed claims.
It answers: which patterns/topics emerge from the described data and the field, grounded, and worth committing claims on?
1a-descriptions what the data looks like
1b-themes what patterns/topics emerge <- THIS RUNG
1c-claims what generalizes (the ledger)
1d-advice what the evidence advises (the deliverable)
Read first: ../../../PHILOSOPHY.md, ../../haipipe-application-lifecycle/SKILL.md (Intervention Lifecycle Contract).
What's special: three things make themes themes
1. Themes are extracted, not invented — grounding first, naming second.
Every T cites >=1 D<n> id from 1a or a project-side discovery source.
An ungrounded pattern is a hunch: it goes to Parked, never listed as a theme.
Ids T<n> are ladder-local; rung 1c cites them as C1 (T1).
2. A theme is a question-space, not a claim.
Direction and candidate-claim hooks live here; a claim's status lives only in 1c (supported | weak | GAP).
The theme hooks are exactly what rung 1c consumes — the exploration frame that spawns claims.
Venue-FREE: the pattern space does not change with the channel.
3. Full D-consumption + a counter-hunt.
Every 1a D<n> id is cited by >=1 theme or listed in Parked as context-only (with a why) — nothing described is silently dropped.
DRAFT sweeps three lenses — data patterns (from D entries), field patterns (discovery), counter-hunt (patterns AGAINST the seed hypothesis).
A null counter-hunt is recorded in Parked, not omitted.
The four phases, in themes
DRAFT re-mine last round's Parked reservoir (did new D entries ground any?); read 1a-descriptions.md
(the grounding floor); elicit taste on which directions matter; sweep the three lenses — data /
field (discovery: "what messaging levers does the mhealth literature name?") / counter-hunt —
drafting T slots with grounding + hooks
PROBE the five-step loop raises field-pattern questions as ENTRIES in 1-probes/ and COLLECTS
(→ discovery; task only for a quick in-data confirmation); each entry's `### a-executor` lands grounding
refs onto its T entry. Routing mechanics are the probe layer's:
../../../2-phase/1-probe/haipipe-application-probe/SKILL.md
REVISE sharpen pattern sentences, merge overlapping themes, park the ungrounded
CHECK every theme grounded (>=1 resolving D id or source) + carries a hook (or a context-only note);
every 1a D id consumed; counter-hunt ran; Parked honest; no STALE tags; roster matches 1-probes/
Themes RECEIVES grounding, never PRODUCES it inline (LAW 1): it raises questions; haipipe-application-probe binds them.
When a theme's grounding refreshes (a [STALE ...] tag from 1a), re-confirm or revise the theme before CHECK.
A theme needing a number files the 1a D slot immediately and logs [ROUTE -> descriptions] — never wait for a gate to report it.
Rounds + back-routing (loop-until-dry for medium+ venues; [ROUND n] / [ROUTE -> descriptions] in _LOG) follow ../../../haipipe-application/SKILL.md (Stage Gate Protocol).
CHECK may be BATCHED into the ladder gate per the venue; announce every phase boundary in _LOG; CHECK is never implicit.
The artifact
0-lifecycle/1b-themes/1b-themes.md — full skeleton in ref/themes-template.md:
Themes one **T<n>**: name, the pattern in one sentence, grounding (D ids and/or discovery sources),
candidate-claim hooks (or an explicit "context-only" note)
Parked patterns noticed but not pursued (one line + why); context-only D ids; the counter-hunt record;
the reservoir the next DRAFT re-mines
Q-consumer the questions this rung raises, one `## Q-Theme-<n>` block each (Ask / Why / Answer=__TO_BE_FILLED__ — the doc's only state); APPROVE adds each -> 1-probes/ pointer + state
Sidecar: _LOG_1b-themes.md (phase journal).
Formatting: ===== title, ----- sections, **bold** sub-items, one sentence per line; content sections use no #, Q-consumer questions use ## Q-Theme-<n>.
The Insight KB is optional context here, never a required source.
Questions this stage typically raises
DRAFT's RAISE+PLAN step raises what the draft cannot answer. These are the kinds this stage is prone to — read this list, then walk the draft against it.
📚 outside evidence Does the literature name this pattern, and what does it call it?
A theme with no external anchor is an observation, not a theme.
🔁 is it real Does the pattern hold across subgroups / time windows, or is it
an artifact of one slice?
🆕 unnamed pattern Is there something in the data the literature has NOT named?
That is the interesting case — and it needs the most evidence.
Exits
promote -> /haipipe-application claims (rung 1c consumes the theme hooks)
End every reply with the closing block (stage line via ../../../haipipe-application/stage-strip.sh).
