Skills are pipelines: split deterministic fan-out from analytical reasoning

## Spark

Restructuring the `digest` skill into `collect.sh → analyze data → synthesize themes → analyze themes → present` (commits d6fc572, a63df61, 03630bf) made an implicit design choice explicit: the deterministic layer (gh queries, dedup, JSON normalisation) belongs in shell, the analytical layer (pattern-finding across sources, theme scoring) belongs in the model.

## Why it could be interesting

The dominant skill-authoring genre is "one big prompt with tool calls inside it." That works, but conflates two kinds of work the model is unequal at: it is excellent at cross-source synthesis and judgment, mediocre and expensive at fan-out + dedup + URL parsing. Splitting them buys three things: testability (`bats` on the script half), token efficiency (model never sees raw API responses, only the rolled-up JSON), and a clean place to put noise heuristics (e.g. `task/*` branch filters) that would otherwise leak into the prompt.

## Open questions

- [ ] What's the right interface between stages? JSON shapes are working here — do they generalise to skills outside summarisation?
- [ ] When should an analytical stage be a sub-agent vs inline? (Cost vs context-window trade-off.)
- [ ] When is the deterministic layer overengineering — is there a size below which one-prompt is better?
- [ ] How does this hold up when the skill is invoked autonomously vs interactively?

## Source material

- alunduil/blog.alunduil.com#64 — Add /digest skill with shell + bats verification
- Commits: d6fc572 (restructure into four-stage pipeline), a63df61 (consolidate fetchers), 03630bf (raise gh search limit + truncation)
- .claude/skills/digest/{SKILL.md,collect.sh,tests/}