Package Resync a Repo and Fleet Conformance Check as Skills

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

@@ -0,0 +1,66 @@
+---
+name: fleet-conformance-check
+description: >-
+  Checks, from inside a downstream repo's own session, whether this repo and this machine are
+  current against the ptr727/ProjectTemplate hub, and safely self-applies what it can. Use this
+  whenever asked to check if this repo is up to date with the hub, whenever a fleet rule or Skill
+  seems to not be applying and the cause is unclear, or whenever about to work in a fleet repo and
+  wanting to confirm the ground under that work is current before trusting it. Needs no standing
+  hub checkout of its own and no named target repo, only the repo the session is already in,
+  though the check itself fetches a hub checkout to reach scripts/skills_install.py, since
+  scripts/ is hub-hosted rather than carried. This is the counterpart to resync-a-repo, which
+  needs both a hub checkout already in hand and a named external target to drive change from the
+  hub side instead. Also triggers on "why do I have to keep restating this rule every session,"
+  since a stale or missing Skills install is the most common cause and the cheapest one to rule
+  out first.
+---
+
+# Fleet Conformance Check
+
+## Why this exists
+
+A downstream repo today only finds out it has drifted when someone runs a hub-driven resync
+against it by name. Nothing notices from the inside on its own. This skill is that inside check,
+run with no hub-side operator watching, so a stale Skills install or an out-of-date `AGENTS.md`
+pointer gets noticed and fixed without waiting for a fleet-wide sweep to reach this particular
+repo.
+
+## What it checks
+
+1. **Is the Skills install current on this machine.** `scripts/` is hub-hosted and reached rather
+   than carried, per GOVERNANCE.md "Hub-Hosted Tooling", so fetch a hub checkout
+   (`github.com/ptr727/ProjectTemplate`, `main` branch, fetched fresh) and run
+   `python3 scripts/skills_install.py --report` from it. A stale or missing stamp is very often
+   the direct answer to "why isn't a fleet rule applying": the harness never loaded the current
+   content in the first place, and no amount of re-reading `GOVERNANCE.md` fixes that.
+2. **Does this repo's own carried content still match the hub.** Compare `AGENTS.md`'s
+   "Where the Rules Live" pointer text, and any other verbatim `AGENTS.md`/`GOVERNANCE.md` section
+   this repo carries, against the same hub checkout's current wording, by reading the text rather
+   than by feel.
+
+## What it is safe to fix on its own
+
+- **Re-run the installer**, `python3 scripts/skills_install.py`, when the stamp reports stale.
+  This is a per-machine, local-only change, nothing in it touches this repo's git history or
+  needs a review.
+
+Nothing else. This skill never re-vendors a carried file, never deletes one, and never applies a
+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.
+
+## What it escalates instead of touching
+
+- **A carried section that differs from the hub in a way that reads as a genuine local addition**
+  rather than plain staleness, the exact case `carried-instruction-file-guard` exists to protect.
+  Report precisely what differs and stop there. Per AUDIT.md, a downstream repo does not write its
+  own audit report or resync itself against the hub, it names what it found and points at
+  `resync-a-repo`, run from a hub checkout, as the next step.
+- **Anything the installer alone cannot resolve**, a broken `claude` CLI marketplace
+  registration, a settings or ruleset drift, a workflow interface mismatch. Name it and hand it to
+  the maintainer or a hub-driven resync rather than patching around it locally.
+
+## Answering "why isn't a fleet rule applying"
+
+Check the install stamp first, before assuming a Skill's description is worded wrong or that the
+rule was never carried to this repo at all. It is the most common cause, and it is the cheapest
+one to confirm.

.agents/skills/resync-a-repo/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: resync-a-repo
+description: >-
+  Drives RESYNC.md's procedure for bringing a ptr727/ProjectTemplate fleet repo that is already
+  stood up back into line with the current hub, run from a hub checkout against a named target
+  repo. Use this whenever asked to resync, sync, converge, or bring a specific repo up to date
+  with the hub, or to run a conformance sweep against a named repo and apply what it finds. Needs
+  a hub checkout and a named target repo to mean anything, so it does not usefully trigger from
+  inside a downstream repo's own session with no target named and no hub checkout present, that
+  case is fleet-conformance-check instead. Triggers even when the request sounds routine, such as
+  "just copy AGENTS.md over" or "make repo X match the hub," because that phrasing is exactly how
+  the AGENTS.md-overwrite incident happened.
+---
+
+# Resync a Repo
+
+## Why this exists
+
+RESYNC.md's own apply order already sequences the remedies so the rules land before the files
+they govern and a deletion lands before the re-vendor that would otherwise refresh it. The
+AGENTS.md-overwrite incident happened inside that same procedure, on the step that looked most
+routine. This skill exists so the mandatory check survives contact with a real, time-pressured
+resync instead of depending on an agent remembering to run it unprompted. It is a driver over
+RESYNC.md, not a replacement for it. Read RESYNC.md itself for the deletion sweep, the
+letters-versus-drift routing, the settings and ruleset step, and everything else that does not
+change from one resync to the next.
+
+## Confirm the procedure before starting
+
+Read RESYNC.md section 0. A repo with no instruction set at all, or a partial one, is not this
+skill's job, it is STANDUP.md sections 1A and 2 instead, since an absent carried file is a
+baseline that never arrived rather than drift to converge. Run `spec/audit.py <RepoName>`, the
+target's `registry/repos.json` `name` field rather than an `owner/repo` slug or a checkout path,
+and read whether the findings are letters (absent) or drift (present but stale) before doing
+anything else. The finding kind names the procedure the repo is owed.
+
+## Reach the hub and measure before changing anything
+
+Fetch a hub checkout of your own immediately before reading it, per RESYNC.md section 1, since a
+stale clone answers confidently instead of failing, and verify the host with
+`python3 scripts/host_gate.py --repo <path-to-target-checkout>`. Then run the audit end to end,
+RESYNC.md section 2, against the target's `main` branch, never `develop`. A finding is a snapshot,
+so quote the run stamp in anything derived from it and re-run before acting on a finding read
+earlier in the session.
+
+## Apply, in this order
+
+1. **The instruction set first.** `AGENTS.md` and `GOVERNANCE.md` verbatim sections, then
+   `CODESTYLE.md` and `WORKFLOW.md`, including the `AGENTS.md` skill-dependency pointer paragraph
+   (naming `scripts/skills_install.py` and where the fleet's Skills live) as one more verbatim
+   unit carried in this same step, not a separate pass. **Before any verbatim re-vendor in this
+   step, run the `carried-instruction-file-guard` skill's distinctive-phrase probe against the
+   target file, every time, without exception.** This is not advisory language to weigh against
+   how routine the diff looks, a diff that looks routine is exactly the shape the
+   AGENTS.md-overwrite incident took. Do not proceed to the re-vendor until the probe has run and
+   any local addition it finds has a destination, per that skill's own procedure.
+2. **Deletions second, before any re-vendor.** Only a `retire` disposition in
+   `spec/divergences.json` authorizes removing a file, and the removal is swept tree-wide, per
+   RESYNC.md section 4, before the deletion counts as done.
+3. **Verbatim re-vendors** for everything the probe in step 1 cleared. A finding classified
+   modified rather than stale gets its diff read before being overwritten, since it may be an
+   improvement the hub should adopt instead of a mistake to erase.
+4. **Interface workflows.** Honor the named contract, required jobs, the ruleset-bound check name,
+   the artifact-name handoff, rather than copying bytes.
+5. **Settings, rulesets, and secrets.** Run
+   `repo-config/configure.sh check <owner>/<repo> release|operational` against the repo by name,
+   then `apply` for what it reports, never from a carried copy.
+6. **Intent files last, and by hand,** since nothing mechanical judges these.
+
+Reconcile the registry entry (`status`, `types`, `releaseTrigger`, `workflowModel`,
+`driftNotes`) in the same pass, and delete a `driftNote` describing work this pass just finished
+rather than leaving it standing.
+
+## Ship it
+
+One focused pull request per drift class, branched from the target's `develop`, never a direct
+push to a protected branch and never a hand edit outside a pull request. Close the review loop,
+per the `pr-review-conduct` skill, before asking the maintainer for merge permission. The
+maintainer merges, the agent drives to green and stops. Re-run the audit after the merge and
+commit the report, done means measured, not applied.

.claude-plugin/fleet-skills/.claude-plugin/plugin.json

@@ -9,6 +9,8 @@
     "./skills/carried-instruction-file-guard",
     "./skills/comment-and-doc-style",
     "./skills/copilot-instructions-keeper",
-    "./skills/pr-review-conduct"
+    "./skills/fleet-conformance-check",
+    "./skills/pr-review-conduct",
+    "./skills/resync-a-repo"
   ]
 }

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

@@ -1 +1 @@
-1d466f7f6d091eb9
+5d298d74098bac47

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

@@ -0,0 +1,66 @@
+---
+name: fleet-conformance-check
+description: >-
+  Checks, from inside a downstream repo's own session, whether this repo and this machine are
+  current against the ptr727/ProjectTemplate hub, and safely self-applies what it can. Use this
+  whenever asked to check if this repo is up to date with the hub, whenever a fleet rule or Skill
+  seems to not be applying and the cause is unclear, or whenever about to work in a fleet repo and
+  wanting to confirm the ground under that work is current before trusting it. Needs no standing
+  hub checkout of its own and no named target repo, only the repo the session is already in,
+  though the check itself fetches a hub checkout to reach scripts/skills_install.py, since
+  scripts/ is hub-hosted rather than carried. This is the counterpart to resync-a-repo, which
+  needs both a hub checkout already in hand and a named external target to drive change from the
+  hub side instead. Also triggers on "why do I have to keep restating this rule every session,"
+  since a stale or missing Skills install is the most common cause and the cheapest one to rule
+  out first.
+---
+
+# Fleet Conformance Check
+
+## Why this exists
+
+A downstream repo today only finds out it has drifted when someone runs a hub-driven resync
+against it by name. Nothing notices from the inside on its own. This skill is that inside check,
+run with no hub-side operator watching, so a stale Skills install or an out-of-date `AGENTS.md`
+pointer gets noticed and fixed without waiting for a fleet-wide sweep to reach this particular
+repo.
+
+## What it checks
+
+1. **Is the Skills install current on this machine.** `scripts/` is hub-hosted and reached rather
+   than carried, per GOVERNANCE.md "Hub-Hosted Tooling", so fetch a hub checkout
+   (`github.com/ptr727/ProjectTemplate`, `main` branch, fetched fresh) and run
+   `python3 scripts/skills_install.py --report` from it. A stale or missing stamp is very often
+   the direct answer to "why isn't a fleet rule applying": the harness never loaded the current
+   content in the first place, and no amount of re-reading `GOVERNANCE.md` fixes that.
+2. **Does this repo's own carried content still match the hub.** Compare `AGENTS.md`'s
+   "Where the Rules Live" pointer text, and any other verbatim `AGENTS.md`/`GOVERNANCE.md` section
+   this repo carries, against the same hub checkout's current wording, by reading the text rather
+   than by feel.
+
+## What it is safe to fix on its own
+
+- **Re-run the installer**, `python3 scripts/skills_install.py`, when the stamp reports stale.
+  This is a per-machine, local-only change, nothing in it touches this repo's git history or
+  needs a review.
+
+Nothing else. This skill never re-vendors a carried file, never deletes one, and never applies a
+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.
+
+## What it escalates instead of touching
+
+- **A carried section that differs from the hub in a way that reads as a genuine local addition**
+  rather than plain staleness, the exact case `carried-instruction-file-guard` exists to protect.
+  Report precisely what differs and stop there. Per AUDIT.md, a downstream repo does not write its
+  own audit report or resync itself against the hub, it names what it found and points at
+  `resync-a-repo`, run from a hub checkout, as the next step.
+- **Anything the installer alone cannot resolve**, a broken `claude` CLI marketplace
+  registration, a settings or ruleset drift, a workflow interface mismatch. Name it and hand it to
+  the maintainer or a hub-driven resync rather than patching around it locally.
+
+## Answering "why isn't a fleet rule applying"
+
+Check the install stamp first, before assuming a Skill's description is worded wrong or that the
+rule was never carried to this repo at all. It is the most common cause, and it is the cheapest
+one to confirm.

.claude-plugin/fleet-skills/skills/resync-a-repo/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: resync-a-repo
+description: >-
+  Drives RESYNC.md's procedure for bringing a ptr727/ProjectTemplate fleet repo that is already
+  stood up back into line with the current hub, run from a hub checkout against a named target
+  repo. Use this whenever asked to resync, sync, converge, or bring a specific repo up to date
+  with the hub, or to run a conformance sweep against a named repo and apply what it finds. Needs
+  a hub checkout and a named target repo to mean anything, so it does not usefully trigger from
+  inside a downstream repo's own session with no target named and no hub checkout present, that
+  case is fleet-conformance-check instead. Triggers even when the request sounds routine, such as
+  "just copy AGENTS.md over" or "make repo X match the hub," because that phrasing is exactly how
+  the AGENTS.md-overwrite incident happened.
+---
+
+# Resync a Repo
+
+## Why this exists
+
+RESYNC.md's own apply order already sequences the remedies so the rules land before the files
+they govern and a deletion lands before the re-vendor that would otherwise refresh it. The
+AGENTS.md-overwrite incident happened inside that same procedure, on the step that looked most
+routine. This skill exists so the mandatory check survives contact with a real, time-pressured
+resync instead of depending on an agent remembering to run it unprompted. It is a driver over
+RESYNC.md, not a replacement for it. Read RESYNC.md itself for the deletion sweep, the
+letters-versus-drift routing, the settings and ruleset step, and everything else that does not
+change from one resync to the next.
+
+## Confirm the procedure before starting
+
+Read RESYNC.md section 0. A repo with no instruction set at all, or a partial one, is not this
+skill's job, it is STANDUP.md sections 1A and 2 instead, since an absent carried file is a
+baseline that never arrived rather than drift to converge. Run `spec/audit.py <RepoName>`, the
+target's `registry/repos.json` `name` field rather than an `owner/repo` slug or a checkout path,
+and read whether the findings are letters (absent) or drift (present but stale) before doing
+anything else. The finding kind names the procedure the repo is owed.
+
+## Reach the hub and measure before changing anything
+
+Fetch a hub checkout of your own immediately before reading it, per RESYNC.md section 1, since a
+stale clone answers confidently instead of failing, and verify the host with
+`python3 scripts/host_gate.py --repo <path-to-target-checkout>`. Then run the audit end to end,
+RESYNC.md section 2, against the target's `main` branch, never `develop`. A finding is a snapshot,
+so quote the run stamp in anything derived from it and re-run before acting on a finding read
+earlier in the session.
+
+## Apply, in this order
+
+1. **The instruction set first.** `AGENTS.md` and `GOVERNANCE.md` verbatim sections, then
+   `CODESTYLE.md` and `WORKFLOW.md`, including the `AGENTS.md` skill-dependency pointer paragraph
+   (naming `scripts/skills_install.py` and where the fleet's Skills live) as one more verbatim
+   unit carried in this same step, not a separate pass. **Before any verbatim re-vendor in this
+   step, run the `carried-instruction-file-guard` skill's distinctive-phrase probe against the
+   target file, every time, without exception.** This is not advisory language to weigh against
+   how routine the diff looks, a diff that looks routine is exactly the shape the
+   AGENTS.md-overwrite incident took. Do not proceed to the re-vendor until the probe has run and
+   any local addition it finds has a destination, per that skill's own procedure.
+2. **Deletions second, before any re-vendor.** Only a `retire` disposition in
+   `spec/divergences.json` authorizes removing a file, and the removal is swept tree-wide, per
+   RESYNC.md section 4, before the deletion counts as done.
+3. **Verbatim re-vendors** for everything the probe in step 1 cleared. A finding classified
+   modified rather than stale gets its diff read before being overwritten, since it may be an
+   improvement the hub should adopt instead of a mistake to erase.
+4. **Interface workflows.** Honor the named contract, required jobs, the ruleset-bound check name,
+   the artifact-name handoff, rather than copying bytes.
+5. **Settings, rulesets, and secrets.** Run
+   `repo-config/configure.sh check <owner>/<repo> release|operational` against the repo by name,
+   then `apply` for what it reports, never from a carried copy.
+6. **Intent files last, and by hand,** since nothing mechanical judges these.
+
+Reconcile the registry entry (`status`, `types`, `releaseTrigger`, `workflowModel`,
+`driftNotes`) in the same pass, and delete a `driftNote` describing work this pass just finished
+rather than leaving it standing.
+
+## Ship it
+
+One focused pull request per drift class, branched from the target's `develop`, never a direct
+push to a protected branch and never a hand edit outside a pull request. Close the review loop,
+per the `pr-review-conduct` skill, before asking the maintainer for merge permission. The
+maintainer merges, the agent drives to green and stops. Re-run the audit after the merge and
+commit the report, done means measured, not applied.