P2 (decision): Carry Only the Fleet Bootstrap Verbatim, and Reach Everything Else From the Hub

[ptr727]

Part of #1311. Priority: after the P0 and P1 work.

An option was selected on 2026-09-08. It is not the one this body proposes.

The decision, its measurements, and what is still unmeasured are recorded in
#1321 (comment). Read that
comment before acting on the text below.

The title and the proposal below describe the original option, which retires the carried skills
tree. The selection keeps that tree carried and retires four documents instead, so acting on
this body rather than on the comment implements a rejected option. The maintainer's own note on
this issue asks that the selection not be read as law, and it stays open to revisiting.

Why

The skills tree is carried as a verbatim tree and many GOVERNANCE.md and AGENTS.md sections are carried verbatim, so every wording change in the hub is a fleet-wide change. Every carrier's first review re-discovers the same defects in a repository that cannot fix them (#1138, #1139). The fidelity model cannot express a value that legitimately varies per repo nor detect one that is uniformly wrong (#1141, #1118). A carrier holds sentences that are false in the carrier (#1184). AGENTS.md "Fleet Bootstrap" already tells an agent to fetch the hub and read the rules there, and scripts/ is already reach-not-carry. The prose is the last thing still carried, and it is the thing that churns.

The decision

Reduce the carried baseline to: CLAUDE.md, AGENTS.md holding the Fleet Bootstrap section verbatim and a repo-specific remainder, the config files the tooling needs (.editorconfig, .gitattributes, lint configs, workflow stubs), and .github/copilot-instructions.md since the Copilot bot reads it directly. Everything else, GOVERNANCE.md, CODESTYLE.md, WORKFLOW.md, AUDIT.md, and the skills tree, is reached from a hub checkout the bootstrap already requires, and the skills reach Claude Code through the installer that already exists.

What this costs: a Codex or opencode session in a downstream repo loses the skills it read from .agents/skills/ by walking up, and gets them from the hub checkout instead, which the bootstrap already makes it fetch. A downstream repo's contributor without a hub checkout reads a pointer instead of the rule. A resync stops refreshing prose, so the resync becomes small and mechanical.

What it buys: a wording change in the hub is one pull request in one repository, the whole-unit pass runs once where the fix can land, the fidelity model stops having to express prose variance, and the "first review happens downstream" pump closes.

Scope, once decided

• Amend spec/files.json and spec/section-model.md to the reduced baseline.
• Amend RESYNC.md and STANDUP.md so a resync removes carried prose from a repo that holds it, with the audit reporting it as a retired file rather than drift.
• Amend the Fleet Bootstrap so the pointer names where each removed document is read.
• Run the resync across the fleet as its own campaign after the hub change promotes.

Rules that bind this task

• The Fleet Bootstrap stays byte-locked and is the one thing every repository reads identically.
• No prose rule is deleted. It moves from carried to reached.
• The decision is recorded in TODO.md "Reducing the Carried Surface Further" or its successor before the first edit.

Acceptance

• The maintainer has decided, and the decision and its reasons are recorded.
• If accepted: a downstream repo after resync carries no GOVERNANCE.md, CODESTYLE.md, WORKFLOW.md, AUDIT.md, or skills tree, and its audit reports clean.

Relates #1138, #1139, #1141, #1118, #1184, #1146, #1140, #1145.

[ptr727]

Pieter's feedback:

• Do not take "the maintainer has decided" as law, I was offered options and I selected an option, worthy to revisit with appropriate context.
• From my recollection the reason the skills and other instructions were copied from the hub to downstream repos was so that pr reviewer bots have access to the rules, as they do not reach out to the hub, this was tested.
• GitHub PR review agents need the full scope of skills and rules to make an accurate assessment.
• On-host agents can read the host copied skills and do not need the copy to live in the repo.
• The copy in the repo is cause for duplicate issues, and PR bot rules files have been updated to ignore the copies. Copilot for personal repos does not offer a rule for exclusion (org and enterprise does), while CodeRabbit and Qodo now has rule files in the repo root.
• Alternatives to consider could be to use PR review bot memories, e.g. I know there is copilot memories, don't know how to use it, and maybe Qodo and CodeRabbit has got equivalent configuration for persisted rules that do not live in the repo being reviewed, worth investigating.

Does this change the options and recommendations?

[ptr727]

Revised assessment, after the reviewer-memory investigation

Answering the question directly: yes, this changes the options, and it reverses the recommendation
on one point. The decision as written would have deleted the one carried surface a reviewer bot
provably loads, and kept four files no reviewer bot loads at all.

Everything below was read from vendor documentation on 2026-09-08, plus one measurement on this
repository. Sources are listed at the end.

1. What each reviewer actually reads

Carried path	Copilot code review	CodeRabbit	Qodo
AGENTS.md (root)	yes	yes, **/AGENTS.md	yes, root AGENTS.MD
CLAUDE.md (root)	yes	yes, **/CLAUDE.md	yes, root CLAUDE.MD
.github/copilot-instructions.md	yes	yes	no
.github/instructions/*.instructions.md	yes	yes	no
.github/skills/**/SKILL.md	yes, GA 2026-07-29	no	no
GOVERNANCE.md, CODESTYLE.md, WORKFLOW.md, AUDIT.md	no documented load	no	no

Copilot code review's support for agent skills went generally available on 2026-07-29 for Pro,
Pro+, Business and Enterprise, reading SKILL.md under .github/skills, which is exactly the tree
spec/files.json already carries. Custom instructions are read from the head branch, so a rule
change is testable on a feature branch before it merges.

CodeRabbit auto-detects a fixed list and nothing else: **/.cursorrules,
.github/copilot-instructions.md, .github/instructions/*.instructions.md, **/CLAUDE.md,
**/GEMINI.md, **/.cursor/rules/*, **/.windsurfrules, **/.clinerules/*, **/.rules/*,
**/AGENT.md, **/AGENTS.md. Any other document needs an explicit applyTo mapping.

Qodo searches the head branch root directory for AGENTS.MD, QODO.MD and CLAUDE.MD, and feeds
those to review, describe and improve.

So GOVERNANCE.md, CODESTYLE.md, WORKFLOW.md and AUDIT.md are carried for humans and for
on-host agents, never for the bots. No documented mechanism loads them. A reviewer can still open
one on its own initiative, since it sits in the repository it is reviewing, but that is
opportunistic rather than contractual, and it cannot be verified per review.

Measurement. Across the last 10 merged pull requests here, Copilot posted 13 inline comments
and none carried the skill attribution footer the documentation describes for a review that used an
agent skill. That is not proof the carried skills went unread, and it is the reason test 1 below is
worth running before betting the baseline on them.

2. Whether reviewer memories can hold rules

Copilot Memory: no. It has two scopes, repository-level facts shared with everyone who can read
the repository, and user-level preferences. Code review uses repository-level facts only and does
not apply user preferences. Memories are created only by inference from Copilot activity, and the
personal settings offer review and delete, never authoring. There is no surface to write a ruleset
into, which answers "I do not know how to use it" with "there is nothing to author".

Copilot content exclusion: confirms your reading. Code review has respected repository,
organization and enterprise content exclusion since 2026-06-12, but content exclusion itself
requires Copilot Business or Enterprise and is not available to personal accounts. The instruction
in .github/copilot-instructions.md "Reviewing Carried Fleet Content" telling the review to post no
comment on a file under .github/skills/ stays the only lever, and it is best-effort.

Copilot review environment: unverified, and the most interesting path. A repository can
configure the environment the review runs in with .github/workflows/copilot-code-review.yml,
falling back to copilot-setup-steps.yml. That is the only documented way a hub checkout could be
placed in front of the reviewer without carrying anything. Two things are unverified: whether the
reviewer reads files a setup step puts on disk, and whether the feature reaches a personal-account
repository. If both hold, reach-not-carry becomes available for every reviewer rule, and the whole
question closes.

CodeRabbit: yes, genuinely off-repo. Learnings live on CodeRabbit's servers keyed to the Git
platform organization, not in the repository. An admin can author and edit them in the dashboard,
and a file mentioned in a pull request comment can be imported as learnings. Scope is local,
global or auto, and auto applies repository-scoped learnings on public repositories, so
fleet-wide rules need global set explicitly. Organization-level path instructions exist in the web
UI as well. The cost is that none of it is in git, so the fleet cannot audit it mechanically.

Qodo: yes, and it is a git repository. A pr-agent-settings repository under the owner holds a
global .pr_agent.toml and hierarchical best_practices.md files that every repository under that
owner inherits, and a per-repository wiki page can hold configuration too. A repository's own
.pr_agent.toml overrides both. Because it is a repository, the hub can generate and audit it the
same way it generates the skills trees. The documentation says organization level, so whether it is
honored for a personal account needs test 3 below.

3. Revised options

Option 1, recommended. Carry what a reviewer loads, and reach the rest. Retire GOVERNANCE.md,
CODESTYLE.md, WORKFLOW.md and AUDIT.md from the carried baseline. Keep .github/skills
carried exactly as it is. Carry the rule text a reviewer must honor as
.github/instructions/*.instructions.md with applyTo scoping, which Copilot and CodeRabbit both
documentably load and which no longer has a 4,000 character limit. This inverts the original
proposal on the two paths that matter: it stops carrying the files nothing loads, and it puts the
rules a reviewer needs in a path that is loaded by contract rather than by luck.

What it costs: a downstream contributor without a hub checkout reads a pointer, and a reviewer loses
the chance to open the full GOVERNANCE.md opportunistically. What remains in front of it is the
skills tree plus the instructions files, which is the packaged form of the same rules. Note that
only two GOVERNANCE.md sections and three WORKFLOW.md sections are carried into skills whole as
generated includes today, so the rest reaches a skill reader as the skill's own summary. Deciding
which sections owe an instructions file is the real work in this option.

Option 2. Option 1, plus the advisory bots' rules off-repo. Generate ptr727/pr-agent-settings
from the hub for Qodo, and set CodeRabbit's organization-level path instructions once. CodeRabbit
and Qodo then depend on no carried prose at all, and both are configured in one place for the whole
fleet. The CodeRabbit half is not auditable from git, so I would take the Qodo settings repository
and the organization-level instructions, and not move rules into CodeRabbit learnings, which are
inference-adjacent and invisible to the audit.

Option 3. The decision as written, carry only the Fleet Bootstrap. Now contraindicated, on one
path only. Dropping .github/skills removes the single carried surface Copilot documentably loads
and so narrows the rule scope you say the reviewers need. Everything else in the original decision
survives inside Option 1.

Option 4. Move the fleet into a GitHub organization with Copilot Business. Independent of 1 to
3, and the only mechanical fix for the duplicate findings, since content exclusion and
organization-level custom instructions both become available. The cost is paid seats and a
migration, so it is a separate decision rather than part of this one.

4. Three cheap tests, in order

1. Does Copilot actually load the carried skills here? Watch the next few reviews for the skill
   attribution footer, or add a deliberately checkable instruction to one skill and see whether a
   review honors it. This decides between Option 1 and Option 3 on the skills tree.
2. Does a copilot-code-review.yml setup step reach the reviewer? Clone the hub in a setup step
   on one branch, add an instruction that only a hub file answers, and see whether the review
   answers it. If yes, reach-not-carry works for the reviewers too.
3. Is pr-agent-settings honored for a personal account? Create it with one observable setting
   and watch one Qodo review.

5. What is unchanged

Nothing is implemented and no tree change is made. The decision record in TODO.md stays open, and
the decision label stays on this issue until you pick from the options above.

Sources

• Copilot Memory: https://docs.github.com/en/copilot/concepts/agents/copilot-memory and
  https://docs.github.com/en/copilot/how-tos/use-copilot-agents/copilot-memory
• Copilot code review agent skills and MCP, GA 2026-07-29:
  https://github.blog/changelog/2026-07-29-copilot-code-review-agent-skills-and-mcp-now-generally-available/
• Copilot code review instructions and environment, 2026-07-17:
  https://github.blog/changelog/2026-07-17-copilot-code-review-customization-and-configurability-improvements/
• Copilot code review configurations and content exclusion, 2026-06-12:
  https://github.blog/changelog/2026-06-12-copilot-code-review-new-configurations-and-controls/
• Copilot content exclusion availability:
  https://docs.github.com/en/copilot/how-tos/configure-content-exclusion/exclude-content-from-copilot
• CodeRabbit learnings: https://docs.coderabbit.ai/knowledge-base/learnings
• CodeRabbit code guidelines: https://docs.coderabbit.ai/knowledge-base/code-guidelines
• Qodo configuration file and global settings repository:
  https://docs.qodo.ai/qodo-documentation/qodo-merge/configuration/configuration-file

[ptr727]

Test 2 is answered, and the answer is yes

A setup step can place content where the Copilot reviewer reads it. Reach-not-carry works for the
reviewer, which is the result that changes the options in the revised assessment above.

The measurement

.github/workflows/copilot-code-review.yml landed on main in #1450, with a copilot-setup-steps
job writing PROBE-SETUP-<run id> to three destinations and reporting each outcome separately. The
token is never printed, so a log cannot supply it.

The reading instruction went on the base branch of #1453, never in its diff, because a reviewer
is told to read the complete diff and would otherwise quote a token it merely read as changed
content. The reviewed diff contains zero occurrences of PROBE-, verified with gh pr diff.

The review at #1453 returned:

PROBE-CONTROL-7Q4M
PROBE-SETUP-34287683851 home

Why this is a read rather than a construction

Run 34287683851 is the review's own run:

{ "id": 34287683851, "name": "Running Copilot Code Review", "event": "dynamic",
  "path": "dynamic/agents/copilot-pull-request-reviewer",
  "head_sha": "2749526b4711112ff9eb5e98e5cf06e90feb6791", "conclusion": "success" }

Three things separate a read from a guess:

1. The label is the wrong one to guess. The workflow writes all three destinations, and the
   instruction reads the runner temp directory first. Anyone constructing an answer from the
   workflow's source, which is in the head tree, would answer temp. The review answered home,
   which is only reachable by finding the temp file absent and the home file present.
2. The run id is not on the pull request. That run appears in no check on Refuse a Tree Source That Names the Repository Root However It Is Spelled #1453, whose only
   linked run is 34287679495. It is not recoverable from the pull request surface.
3. No copilot-code-review.yml workflow run fired for this head at all. The paths: filter
   excluded it, and the setup steps still ran, so Copilot invoked the job directly rather than
   through any event. The on: triggers are irrelevant to the Copilot path.

The residual alternative, stated rather than dismissed: a reviewer holding GITHUB_RUN_ID in its
own environment could construct the token from the workflow source, and would then have had to
guess a label that differs from the documented read order. That is possible and unlikely, and one
more run with a value the workflow source does not determine would close it.

What else the run tells us

• $HOME persists into the review environment. The runner temp directory does not, or is a
  different directory by the time the review reads. Anything placed for a reviewer belongs in the
  home directory.
• The workspace destination was deliberately not read, since a pull request author can commit a
  file or a symlink at any path under the checkout and forge the answer.
• GitHub documents that Copilot checks the repository out after the setup steps finish, and that
  checkout cleans untracked files, so the workspace is the wrong place regardless.

What this changes

Option 2's reasoning holds for the advisory bots, and Option 1's premise is now weaker than it
looked: the reviewer does not need a rule carried into the repository to read it. A setup step can
clone the hub and leave its content in the home directory, which is the same reach-not-carry the
fleet already uses for tooling.

Two caveats before that becomes a design:

1. This measures file placement, not that the reviewer will consult a hub rule unprompted. It
   read the file because an instruction told it to, and that instruction was carried in
   .github/copilot-instructions.md. So a carried pointer is still needed, but only a pointer.
2. It cost one setup job per review, on every pull request in the repository, for as long as the
   workflow sits on main.

Test 1 cannot be answered this way, and that is a finding of its own

Three designs were built and discarded. A token stored anywhere in the repository proves only that
the reviewer read a file: a model reading instructions as content behaves like one loaded with them,
so "loaded as an instruction surface" and "read as repository content" are not separable from
outside. .github/copilot-instructions.md also points the reviewer into .github/skills/ by path,
so the two arms were never independent.

The sound signal is GitHub's own skill attribution footer, which the platform emits rather than the
model, and which needs no probe. This review carries none.

The general lesson, which is worth more than either test: a hosted reviewer cannot be cleanly
instrumented from inside the repository it reviews, because it is instructed to read that
repository. Anything the measurement puts in the tree is readable by the thing being measured.

Still open

Test 3, whether ptr727/pr-agent-settings is honored for a personal account, is untouched. The
workflow on main is temporary and its revert is next.

[ptr727]

Test 2 is proved, not merely indicated

A setup step can place content where the Copilot reviewer reads it. Reach-not-carry works for the
reviewer.

The proof

The review on #1460 returned:

PROBE-CONTROL-7Q4M
PROBE-SETUP temp=621701914358249822391282 home=621701914358249822391282

That value was generated inside the setup step from /dev/urandom at run time. It is in no tree, in
no environment variable a review holds, and in no repository setting. It was never printed. Only its
SHA-256 reached the run log, and the value cannot be recovered from a digest:

run 34294049782, dynamic/agents/copilot-pull-request-reviewer
  probe: nonce digest 9985a3de8394a649873a2aa5d6680bd64fa3251e70565ae0db08bb337baf5f76
  probe: temp written
  probe: home written
  probe: workspace written

sha256("621701914358249822391282") is 9985a3de…5f76, which is the logged digest exactly. There is
no source for that answer other than the file, so the reviewer read it.

The reading instruction sat on the pull request's base branch and never appeared in the reviewed
diff, verified with gh pr diff, so the reviewer did not quote a token it read as changed content.

Three earlier rounds, and why they were not enough

Worth recording, because each failed for a different reason and the reasons are the transferable
part.

1. Token built from the run id. A run id sits in the reviewing environment's own variables, so a
   review that never opened a file could produce a well-formed answer. Two rounds ran and disagreed
   with each other while both runs' logs recorded all three destinations written. Both explanations
   predicted the same observation, so neither round decided anything.
2. Token from a repository secret. The step failed, with its own message: the value was empty or
   absent. A Copilot code review setup environment receives no repository secret. That is a
   finding in its own right and it bounds what such a step can ever be handed. A setup step can clone
   a public repository; it cannot authenticate to a private one.
3. That same failed run was the negative control the measurement had been missing. No files were
   written and the review reported both slots absent, where a construction from the run id would have
   produced digits.

What the environment looks like

• $HOME and the runner temp directory are both reachable, and this run wrote and had read from
  both.
• The reviewer's own run is event: dynamic, path: dynamic/agents/copilot-pull-request-reviewer,
  and it is not exposed as a check on the pull request.
• The on: triggers are irrelevant to the Copilot path. No copilot-code-review.yml workflow run
  fired for the measured head, and the setup steps ran anyway, so Copilot invokes the job directly
  rather than through any event.
• Copilot's incremental re-review does not honour custom review-body instructions. A re-request
  on an existing pull request returned an abbreviated body carrying neither probe line. A measurement
  needs a fresh pull request, which is why several were opened and closed here.

What this changes for the decision

Option 1's premise is weaker than it looked. A rule does not have to be carried into a repository for
the reviewer to read it: a setup step can fetch the hub and leave content in the home directory,
which is the same reach-not-carry the fleet already uses for tooling.

Two caveats bound that, and both are load-bearing.

1. A carried pointer is still required. The reviewer read the file because
   .github/copilot-instructions.md told it to, and that file is carried. Reach-not-carry moves the
   content, not the instruction to go and get it.
2. It costs one setup job per review, on every pull request in the repository, for as long as the
   workflow exists.

Test 1 remains unanswerable this way, and that is itself the finding

Three designs were built and discarded. A token stored anywhere in the repository proves only that
the reviewer read a file, because a model reading instructions as content behaves like one loaded
with them, and .github/copilot-instructions.md points the reviewer into .github/skills/ by path,
so the two arms were never independent.

The sound signal is GitHub's own skill attribution footer, which the platform emits rather than the
model. None of the reviews in this series carried one.

The general lesson is worth more than either test. A hosted reviewer cannot be cleanly instrumented
from inside the repository it reviews, because it is instructed to read that repository. Anything
the measurement puts in the tree is readable by the thing being measured. The only values that
survive are ones generated at run time and never committed, which is what finally worked here.

Reviewer quality, observed in passing

Across this series the Copilot reviewer produced one confident, specific, checkable claim that was
simply false: that .copilot-probe/setup-token.txt "already exists in the repository tree (checked
in)". git ls-tree finds it on no branch and git log --all --diff-filter=A shows it was never
added. Filed here rather than separately because it bears on how much weight a review's assertions
about repository state should carry.

Cleanup

The workflow and the unused PROBE_NONCE secret are removed next. Test 3, whether
ptr727/pr-agent-settings is honored for a personal account, is still untouched.