Close the P1 Install-Model Gaps: G1 G2 G3 G6 G8

.agents/skills/fleet-conformance-check/SKILL.md

@@ -48,6 +48,14 @@ Nothing else. This skill never re-vendors a carried file, never deletes one, and
 setting or ruleset. Those are `resync-a-repo`'s job, driven from the hub with a named target,
 never a downstream repo acting on itself.
 
+## Refresh cadence
+
+Re-run the installer when `--report` exits non-zero, and after any hub merge that touches
+`.agents/skills/`. Session entry runs no automatic check, by design: the trigger is suspicion,
+and the restated-rule symptom below is the loudest form of it. `docs/host-setup.md`
+"Fleet Skills Install" in the hub states the same cadence for the host side, and an automated
+refresh stays out of scope until the fleet has evidence the manual cadence fails.
+
 ## What it escalates instead of touching
 
 - **A carried section that differs from the hub in a way that reads as a genuine local addition**

.claude-plugin/fleet-skills/.source-digest

@@ -1 +1 @@
-d0932cf7b1575cb5
+c0b02ee0b6452295

.claude-plugin/fleet-skills/skills/fleet-conformance-check/SKILL.md

@@ -48,6 +48,14 @@ Nothing else. This skill never re-vendors a carried file, never deletes one, and
 setting or ruleset. Those are `resync-a-repo`'s job, driven from the hub with a named target,
 never a downstream repo acting on itself.
 
+## Refresh cadence
+
+Re-run the installer when `--report` exits non-zero, and after any hub merge that touches
+`.agents/skills/`. Session entry runs no automatic check, by design: the trigger is suspicion,
+and the restated-rule symptom below is the loudest form of it. `docs/host-setup.md`
+"Fleet Skills Install" in the hub states the same cadence for the host side, and an automated
+refresh stays out of scope until the fleet has evidence the manual cadence fails.
+
 ## What it escalates instead of touching
 
 - **A carried section that differs from the hub in a way that reads as a genuine local addition**

README.md

@@ -50,6 +50,7 @@ Nothing here is installed as a dependency. The rules are read, the baseline is c
 - [How This Repo Operates](#how-this-repo-operates)
 - [Using This Repo](#using-this-repo)
   - [Deploy the Host Guardrails](#deploy-the-host-guardrails)
+  - [Install the Fleet Skills](#install-the-fleet-skills)
   - [Carry the Rules Into a Repository](#carry-the-rules-into-a-repository)
   - [Adopting Outside This Fleet](#adopting-outside-this-fleet)
 - [Diverging From a Rule](#diverging-from-a-rule)
@@ -137,7 +138,7 @@ ProjectTemplate follows the same model it documents, and audits its own rules ag
 
 ## Using This Repo
 
-Three things are deployed from here, and they land in different places. The host guardrails install once per machine, the baseline is carried once per repository, and the audit is run whenever a repository changes materially. Do them in that order on a new machine, because the guardrails bound every session that follows and retrofitting them means the sessions in between ran unguarded.
+Four things are deployed from here, and they land in different places. The host guardrails install once per machine, the fleet skills install once per user on that machine, the baseline is carried once per repository, and the audit is run whenever a repository changes materially. Do them in that order on a new machine, because the guardrails bound every session that follows and retrofitting them means the sessions in between ran unguarded.
 
 ### Deploy the Host Guardrails
 
@@ -153,6 +154,17 @@ host-setup/agent-safety/install.sh        # Linux, WSL, macOS
 
 Restart Claude Code sessions on the machine afterward so the hook and the `CLAUDE.md` blocks load. The installer is idempotent, so re-running it is also how a machine picks up an upstream change to the guard. What it installs, how to verify it, and what it deliberately does not catch are in [`host-setup/agent-safety/README.md`][agent-safety], and the surrounding host prerequisites (git identity, SSH signing, `gh`, `docker`, `uv`) are in [`docs/host-setup.md`][host-setup].
 
+### Install the Fleet Skills
+
+The skills are the per-topic rules packaged so they surface in an agent session by trigger, instead of being re-read from the law docs each time. They install once per user per machine, from a hub checkout, and land beside the guardrails rather than in any repository:
+
+```shell
+python3 scripts/skills_install.py            # or the scripts/skills_install.sh / .ps1 wrapper
+python3 scripts/skills_install.py --report   # read-only: is this machine current?
+```
+
+A host stood up end to end by the [`host-setup/`][host-setup-dir] bootstrap gets this step at the end of its host mode, so a fresh machine finishes with the tools, the identity, and the skills together. [`docs/host-setup.md`][host-setup] "Fleet Skills Install" carries the details, including how the install degrades where the `claude` CLI is absent.
+
 ### Carry the Rules Into a Repository
 
 A repository that does not exist yet is stood up with [`STANDUP.md`][standup], which is ordered rather than a menu: verify commit identity and signing before the first commit, hand the maintainer what only they can supply, classify the repo and write its [registry][repos] entry, carry the instruction set before authoring anything of your own, then carry the remaining baseline, the workflows, and the settings. The two steps with a closing window are first, because signing has to be live before the first commit and the rules have to be loaded before the first authored file.

STANDUP.md

@@ -30,7 +30,7 @@ python3 scripts/host_gate.py            # from a hub checkout, against the fleet
 
 **No `--repo` here, and that is the one place in these procedures where it is omitted deliberately.** The flag points the gate at a repo's own `host-tools.json` so its floors are layered over the fleet ones, and at this step there is no repo to point it at: the target does not exist yet, since this section runs before the `git init` in section 0B, and the file itself arrives with the baseline in section 2. So this run checks the fleet floors, which is all that is knowable now.
 
-**Re-run it with `--repo` once section 2 has carried the file**, because a bare run does not read the target's declaration at all, so any floor that repo adds goes unapplied and the run cannot tell you it was skipped:
+**Re-run it with `--repo` once section 2 has carried the file**, because a bare run reads no declaration but the one at its own working directory, so any floor the target adds goes unapplied. The gate warns when its working directory sits inside a repo whose overlay it did not read, and no warning can name a target that does not exist yet, so this re-run is the only thing that counts the target's floors:
 
 ```shell
 python3 scripts/host_gate.py --repo <path-to-target-checkout>   # after section 2, so the repo's own floors count