Evaluate splitting session-flow's SessionStart hook from its 14 skills

[kyle-sexton]

A Class C candidate under
ADR 0028.
The ADR gates the proposal; it does not mandate the split. A decline with recorded reasoning
closes this issue.

The shape

session-flow carries 14 skills and one hook: SessionStart → observer-arm.sh
("Arming session observer..."). It is the highest skill-to-hook ratio in the fleet, which is what
puts it first among the Class C candidates.

What to decide

Does a consumer exist who wants the skills without the always-on SessionStart hook, or the hook
without the skills?

Concretely for this plugin:

• The hook arms the session observer, which is the data source for
  /session-flow:running-retro and the retro ledger. If the observer is what several OTHER skills
  read, the hook is closer to Class B than the ratio suggests, and that finding closes this issue.
• Conversely, a consumer who wants /session-flow:handoff and /session-flow:orient and does not
  want per-session observation is a real profile, and today can only get it through the kill switch.

The bar a split has to clear

Per the ADR: one consumer wanting one half, weighed against a second plugin to install, a second
version to keep in step, and a second catalog entry. Also weigh what the per-hook
<name>_enabled switch already delivers — it is the reason no Class C split is urgent, and a split
that only reproduces what the switch already does is not worth the packaging.

Constraints

• The <name>_enabled userConfig boolean stays either way.
• If split, the hook half still needs the topic-docs memory-tier convention it writes under; check
  whether that binding survives the separation before proposing it.

Related

• PreToolUse guard remediation: scratch-root default, kill-switch hoist, MCP coverage, two conventions #3719 — the audit that produced the taxonomy
• ADR 0028 — the classification and the bar