Happier PR Steward

Happier PR Steward

Own the PR lifecycle and its human gates. Delegate the actual review standard, implementation, testing, compatibility analysis, commit safety, and GitHub mutations to their canonical skills instead of duplicating them here.

1. Load the owning workflows

Use these skills as applicable:

• .agents/skills/happier-review for the review basis, affected corridor, findings, and merge assessment;
• .agents/skills/happier-implement and .agents/skills/happier-testing for approved behavior changes and RED -> GREEN evidence;
• .agents/skills/happier-compatibility for released seams and version skew;
• .agents/skills/happier-port-0-2-to-0-3 when a 0.2 PR must be represented in the 0.3 line;
• .agents/skills/happier-commit-worktree when a destination checkout is large or actively dirty;
• .agents/skills/happier-github-ops for authenticated GitHub reads and every public mutation;
• .agents/skills/verify-claims before relying on bot, human, CI, or delegated claims;
• .agents/skills/attack-conclusion and .agents/skills/handoff-report for closeout.

Read lifecycle.md before starting.

2. Establish the live basis

Treat the PR body, patch, reviews, comments, approvals, and check results as claims. Fetch the current base and head SHAs, author identity, commits, complete diff, changed files, discussion, review threads, and checks. Record the head SHA for every analysis and re-check it before acting on a result.

Use a separate worktree for a foreign PR branch when needed. Never switch the primary checkout, discard local bytes, trust inherited staging, or mix unrelated work into a PR commit.

Inventory material contribution rather than using PR authorship as an attribution shortcut. For each planned commit, identify whose code, patch, design, causal diagnosis, decisive reproduction, or substantially adopted fix direction that commit actually incorporates. Resolve and add a verified Co-authored-by: trailer for each such contributor. The PR author normally earns co-authorship on commits that preserve or refactor their contributed code/intent, but not on independent steward fixes merely because they opened the PR. A newly derived fix for a reviewer finding does not transfer co-authorship to the PR author, and an automated reviewer does not create a human co-author claim. Review comments, participation, generic suggestions, requested logs, and confirmation alone do not qualify. Evaluate every commit independently, acknowledge useful non-qualifying help publicly, and stop before a commit only when a material contributor's required identity cannot be verified; never guess or expose an email.

3. Review intent before mechanism

Reconstruct the problem the PR is trying to solve from product behavior, issue context, code, history, and tests. Then independently determine how the task should be solved from the canonical owner.

Use happier-review to report:

• the real intent and observable success condition;
• the canonical owner, callers, readers, writers, tests, and compatibility paths;
• whether the PR matches that intent and owner;
• existing or introduced duplicate logic, split-brains, bypasses, and neighboring gaps;
• correctness, regression, security, compatibility, and test risks supported by evidence;
• the simplest coherent solution and any concrete refinements;
• a merge verdict: mergeable, mergeable after named refinements, or not recommended.

Do not invent speculative requirements or preserve machinery merely because it is already in the patch.

4. Pause at the recommendation gate

Review and reporting alone are read-only. Present the evidence-backed recommendation before editing when the request did not already authorize implementation. If the user already asked for autonomous evidence-driven stewardship, that request may establish one bounded standing authorization immediately: acknowledge the repository/PR, allowed refinement and GitHub action classes, commit/push/port scope, exclusions, and terminal condition, then continue through narrow corrections that serve the stated PR outcome without pausing on the recommendation. Do not turn a valid standing grant into an initial ceremonial reapproval or repeated payload approvals later.

Exact approval covers only the described implementation batch; a standing grant covers its named outcome and action classes as evidence evolves. Return for a decision when new evidence requires a material product choice, architecture change, expanded scope, an action outside the standing grant, or a different cross-repository outcome.

5. Implement the approved source change first

Apply refinements on the PR branch before porting them. Use TDD for production behavior changes, inspect the final branch diff against the base, and validate in proportion to risk. Commit only related paths or hunks with a Conventional Commit message, the current local Git identity, and only the verified co-author trailers justified by material content in that commit.

Do not make a destination implementation the design authority for the PR branch. The PR remains the first implementation surface; the destination port follows only after the source change is coherent and validated.

6. Invoke the required version-line port

When the PR belongs to the 0.2 line, invoke .agents/skills/happier-port-0-2-to-0-3 for the complete PR intent plus every steward-authored and review-driven follow-up. Supply explicit checkout locations; do not encode local folder names in the PR lifecycle. The port skill owns destination discovery, adaptation, and validation, but it never stages or commits.

After the port is validated, this PR workflow owns the separately authorized destination commit. Use .agents/skills/happier-commit-worktree when needed, select only related paths or hunks, and preserve the same commit-specific material contributor attribution in the adapted destination change. Do not add the PR author to an independently designed destination correction unless their contribution is actually embodied there.