Add a Branch-Selection Rule for Negative Existence Claims

[ptr727]

What

GOVERNANCE.md "Verification Discipline" already carries "A local clone is not the
branch it names," but that bullet is phrased around staleness (a clone that has not
fetched recently). This adds a sibling bullet for the same failure mode with a
different trigger: a clone that fetched correctly but from the wrong ref for the task.

• A "does not exist" claim now has to name the branch it was checked against.
• Where the repo's branching model designates a different branch as current for the
  kind of content being searched for (develop, per "Branching Model," for a
  release-model repo's in-flight content), that branch gets checked before asserting
  absence repo-wide.
• The agent-conduct skill's "Before Claiming Done" excerpt picks up the same
  addition, since it already surfaces the sibling bullet at its decision moment.

Why

A worktree based on main (this fleet's default branch) hid develop-only skill
files during a prior task, and the agent reported them as nonexistent anywhere in the
repo instead of naming the branch the negative claim was checked against.

Fixes #714

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds an explicit verification rule to prevent incorrect "does not exist" claims caused by searching the wrong branch (e.g., checking main when in-flight content is on develop), and mirrors that rule into the agent-conduct skill so it surfaces at the "Before Claiming Done" decision point.

Changes:

• Add a new "Verification Discipline" bullet requiring negative existence claims to name the branch checked and to verify against the model-designated branch (e.g., develop) before asserting repo-wide absence.
• Update the agent-conduct skill's "Before Claiming Done" excerpt to include the same branch-selection requirement.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
GOVERNANCE.md	Adds a sibling verification bullet requiring negative existence claims to state and validate the branch used (and to check the model-designated branch).
.agents/skills/agent-conduct/SKILL.md	Mirrors the new governance rule into the skill's "Before Claiming Done" checklist so it is surfaced at the relevant decision moment.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (2)

GOVERNANCE.md:62

• The parenthetical "(a fresh worktree, a new clone)" reads like any newly created worktree lands on the repo's default branch. A git worktree can be created from the current HEAD or an explicit branch; the issue here is specifically tools/workflows that default to the repo's default branch. Tighten the wording to avoid an over-broad (and potentially inaccurate) claim.

(a fresh worktree, a new clone) lands on `main` and can silently miss content already merged to

.agents/skills/operational-vs-release-workflow/SKILL.md:46

• "(a fresh worktree, a new clone's initial checkout)" can be read as claiming that any newly created worktree lands on the repo's default branch. The actual pitfall is worktrees/clones created from (or defaulting to) the default branch. Adjust the wording to keep this bullet factually tight.

  (a fresh worktree, a new clone's initial checkout) lands on `main` and can silently miss

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (3)

GOVERNANCE.md:63

• The bolded sentence is split across a line break, which is inconsistent with the surrounding Markdown style and can be brittle for renderers/linters. Keep the full strong-emphasis span on a single line, then wrap after the closing **.

**GitHub's own "default branch" repository setting reads `main`, but `develop` is where work
starts and where in-flight content lives**, so a worktree or clone that defaults to "the default
branch" lands on `main` and can silently miss content already merged to `develop` but not yet
promoted. Branch from `develop` for a `release`-model repo unless the task is explicitly about

.agents/skills/operational-vs-release-workflow/SKILL.md:49

• This list item's bold emphasis spans a hard line break. To keep formatting robust and consistent, close the ** on the same line as the opening, then wrap after it. While touching the sentence, consider removing the awkward "cloning for" phrasing.

- **GitHub's repository setting for "default branch" reads `main`, but `develop` is where work
  starts and where in-flight content lives.** A worktree or clone that defaults to "the default
  branch" lands on `main` and can silently miss content that has merged to `develop` but not yet
  been promoted. Before branching off, cloning for, or asserting something absent from this repo,
  check `develop`, not just whichever branch a tool defaulted to. See GOVERNANCE.md "Verification

.claude-plugin/fleet-skills/skills/operational-vs-release-workflow/SKILL.md:49

• This list item's bold emphasis spans a hard line break. To keep formatting robust and consistent, close the ** on the same line as the opening, then wrap after it. While touching the sentence, consider removing the awkward "cloning for" phrasing.

- **GitHub's repository setting for "default branch" reads `main`, but `develop` is where work
  starts and where in-flight content lives.** A worktree or clone that defaults to "the default
  branch" lands on `main` and can silently miss content that has merged to `develop` but not yet
  been promoted. Before branching off, cloning for, or asserting something absent from this repo,
  check `develop`, not just whichever branch a tool defaulted to. See GOVERNANCE.md "Verification

[ptr727]

Superseded by #717, which folds this branch (through 6263752) plus the pending wording nit-fix into a combined update with #711. Closing in its favor.