Enrollment (login/join) never installs skills or agents; decide who should get them

[bgmcmullen]

Problem

hyp remote login is supposed to be a complete setup: one command and the machine is enrolled, forwarding, and capturing. It gets most of the way there - it seeds credentials, provisions the central sink, installs the daemon, and waits for the org-config reconcile to attach clients (runBrowserLogin, src/core/cli/remote_commands.js). But neither login nor hyp join ever installs the skill/agent contributions the client plugins register.

Today the complete install-path picture is:

• hyp init walkthrough - installs skills + agents for the picked clients
• hyp skills install / hyp agents install - explicit manual commands
• hyp remote login, hyp join, daemon reconcile - attach only, never install

So every fleet-enrolled machine gets capture working but ends up without the hypaware-* skills and the hypaware-analyst subagent unless someone runs the manual commands. That contradicts the "login is the full setup" promise.

The complication: not every enrolled user needs the skills

The contributions are query/analysis oriented: hypaware-query, the four report skills, hypaware-report-to-html, and the hypaware-analyst fan-out subagent. An org may enroll many engineers purely to capture and forward; the people who actually query and build reports are a smaller set (admins, analysts). Unconditionally dropping ~10 skills plus a subagent into every enrolled user's ~/.claude / ~/.codex is real footprint (skill descriptions load into every session's context) that a capture-only user gets no value from.

Counterpoint: local query works for anyone with local recordings regardless of server permissions, and skills like hypaware-ignore / hypaware-unignore are privacy controls arguably everyone being recorded should have at their fingertips. So "capture-only users need nothing" is not obviously right either - the skill set may need tiering (privacy/opt-out skills for everyone, analysis/report skills gated).

Design questions to settle (needs an LLP)

There is currently no LLP decision governing when skills/agents install - the only anchor is the adapter comment @ref LLP 0011#interactive-walkthrough tying installs to the first-run walkthrough, which predates fleet enrollment being the primary path.

1. Where does the install hook live? Options:
   • In the login/join CLI flow, after the attach wait - simple, but misses machines whose clients attach later via a subsequent org-config reconcile, and misses skill additions shipped in plugin updates.
   • In the daemon reconciler, alongside attach (the LLP 0044 model) - org config drives skill install the same way it drives client attach; covers later attaches and plugin updates; keeps login thin. Probably the right shape.
2. What gates the install?
   • Follow attach: install a contribution when its target client attaches (skills are per-client already: contributes.skills[].clients).
   • Org-config flag: the server decides whether enrolled machines get the analysis skills, mirroring how org config already decides which clients attach.
   • Skill tiering: split contributions into always-install (privacy: ignore/unignore, reference) vs gated (query/report/analyst), if the capture-only persona is real.
3. Idempotency/teardown: installs are already idempotent copies; decide whether hyp leave / detach should remove org-driven installs (the attach reconciler has a marker/undo model, LLP 0045, that skills currently have no equivalent of).

Acceptance sketch

• A fresh machine enrolled via hyp remote login (or hyp join) with an org config that attaches claude ends up with the claude-targeted skills and the hypaware-analyst agent installed, without running any further command.
• Whatever gate is chosen is documented in a new/updated LLP, and the adapter's LLP 0011#interactive-walkthrough refs are updated to point at it.

🤖 Generated with Claude Code