re0-merge

Goal

re0-merge

Workflow

1. Gate before landing. An additive contribution is declined by default; the burden is on the addition to show the suite is worse without it, not on you to justify a no. Judge each PR alone, never as a batch: a bug-fix subtracts a defect and is the easy yes; new tooling earns a place only if it mechanizes a rule already enforced by hand; a new skill lands only if it closes a real gap no existing one covers. A well-reasoned decline is a shipped outcome, not a failure.
2. Cold-read it first. Read the contribution end to end with fresh eyes (a

   shower

   pass when installed) before deciding; a name or claim that reads clean to its author may not to a stranger.
3. Verify, do not re-fix. Where the author already pushed a fix, prove it with a throwaway regression case rather than rewriting it; the credit for the fix is theirs.
4. Approve as you accept, then land on a

   land/pr-<n>

   branch (a range only for a genuine multi-PR batch). Submit the approving review the moment you decide to accept, before the land — it is a verdict on the contributor's code, not a receipt for a release, and giving it now (not bundled with the later close) is what keeps a closed-not-merged PR reading as accepted. Then accept each contributor commit with its authorship preserved (you become the committer; clean the message with

   re0-git

   ), add every maintainer change as its own separate commit so the credit split stays legible, and fast-forward into

   main

   .
5. Complete a new skill, don't merge it raw. Get the name right (a plain real word or tight compression, no opaque coinage), the invocation right (model- vs user-invoked), and the home right; then register it on every roster surface (

   plugin.json

   , the README Index in root and every localized copy,

   re0-upgrade

   's Current catalog,

   scripts/catalog.cjs

   ) so no drift-guard trips.
6. After the release the contribution shipped in confirms, close the PR with the comment. Close it in the same motion as a comment that credits and explains — never a silent close, and never before the release lands. The approval from step 4 already records it as accepted; this step only closes and explains.
7. The comment credits and explains, warmly. Shout the contribution out in the release notes with its PR number and author handle; and if you renamed or reframed anything, the closing comment thanks the author, says what changed and why, points at the release it shipped in, and hands the credit for the core idea back to them.

Rules

• Default-deny for surface, but decline well: a reason tied to the thesis, the branch kept, never a silent close (negatives-as-corpus).
• Preserve authorship. The contributor authors their commit; every maintainer edit is a separate commit under the maintainer's name.
• Approve as you accept, before the land — not bundled with the close after the release. The approval is a verdict on the contributor's code, not a receipt for a release that could fail. Any collaborator or maintainer with review access does this, not one fixed reviewer.
• Explain every deviation to the author, in their favor. A rename or reframe they did not ask for gets its reason.
• Reviewer-agnostic and self-degrading: run whatever pipeline skills are installed (

  shower

  ,

  re0-git

  ,

  re0-release

  ), and do their step by hand when they are not.

Verification

1. Every landed contribution kept its author's authorship, with maintainer edits as separate commits.
2. The PR was approved before it was closed, and closed with a credit comment.
3. A new skill is registered on every roster surface, checks green.
4. Every decline names a thesis-tied reason and keeps its branch.
5. Any rename or reframe was explained to the author.