/land-contribution

name: land-contribution
description: 'Use when a maintainer or collaborator explicitly asks to review and land one external pull request. Don''t use for internal pull requests or landing without preserving contributor authorship.'
disable-model-invocation: true

Land contribution

Contract

| Field | Bound contract | |---|---| | Trigger | A maintainer or collaborator explicitly asks to review and land one external pull request. | | Authority | Remote: merges or declines one external pull request, pushes maintainer commits, and posts approval and credit comments on GitHub; requires explicit human invocation. Inspect and preview the exact landing branch, reviews, comments, and close or merge consequences before any credential use or remote mutation. | | Side effect | For an accepted contribution, create or update only `land/pr-<n>`, preserve the contributor's commits and authorship, add maintainer changes as separate commits, submit approval, land the result, and post a credit-bearing close comment. For a declined contribution, post thesis-tied reasons and retain the contributor branch. | | Done | Remote state confirms preserved authorship, separately attributed maintainer edits, approval before closure, a credit comment on closure, an explanation of any rename to the author, or a decline whose stated reasons are tied to the contribution's thesis and whose branch remains intact. |

Inputs

Required: repository identity, pull-request number, authenticated maintainer or collaborator access, and the repository's observable acceptance criteria and available checks. The pull request supplies its author, branch, commits, discussion, title, description, and changed files. An intended replacement title is optional; if supplied or discovered to be necessary, its reason must also be available before mutation.

Procedure

1. Resolve the repository and pull request, verify that the request concerns an external contribution, and record the pull request number, author, source branch, head revision, commit authorship, thesis stated by its title and description, discussion, diff, and check status. Do not mutate remote state while establishing this baseline. Done when: the baseline is recorded and the contribution is confirmed external.

2. Derive review criteria from the contribution's thesis and the repository's observable contract. Review the behavior and evidence without relying on a named reviewer, bot, or unavailable integration. Treat unavailable review automation as reduced evidence, not as permission to reject or accept automatically; continue with direct inspection and available checks, and identify any evidence that remains unavailable. Done when: review criteria are derived and direct inspection is complete with unavailable evidence identified.

3. Classify the contribution as accepted, repairable without changing its thesis, declined, or blocked. Tie every material finding to the thesis, repository contract, changed behavior, or missing proof. Stop as blocked if authorship, authority, target revision, or required evidence cannot be established; do not widen the task or invent evidence. Done when: one classification is assigned with every finding tied to its basis.

4. Before any remote mutation, present one preview naming the repository, pull request, pinned head revision, classification, intended `land/pr-<n>` branch, commits to preserve, proposed maintainer edits, any title rename and its explanation, the approval action, landing action, close comment, and branch-retention consequence. Proceed only under the user's explicit invocation and within that preview. Done when: the preview is presented and the user explicitly approves it.

5. If declined, do not rewrite, delete, or close the contributor branch. Post the thesis-tied reasons without unrelated style demands, include what evidence would change the decision when known, and close the pull request only if closure was included in the preview. Ensure the close comment names and credits the contributor. Done when: thesis-tied reasons are posted, the contributor branch is retained, and the close comment credits the contributor.

6. If accepted or repairable, create `land/pr-<n>` from the pinned pull-request head so every contributor commit and its author metadata remain unchanged. Never squash, amend, re-author, or fold maintainer work into those commits. Done when: `land/pr-<n>` is created from the pinned head with all contributor commits and authorship preserved.

7. Apply only the maintainer edits needed to satisfy the stated thesis and acceptance criteria, each in separate maintainer-authored commits. Reassess the resulting branch against the same criteria. If the repair would replace or materially broaden the thesis, stop and return blocked rather than taking ownership of a different contribution. Done when: maintainer edits are applied as separate commits and the branch reassesses against the same criteria.

8. If the title must change, explain the old title, new title, and thesis-based reason to the author before renaming it. Do not silently rename the contribution. Done when: the rename is explained to the author before it is applied, or no rename is needed.

9. Run or inspect the available checks that cover the changed behavior and record their exact outcomes. If a required check is unavailable or fails, do not approve or land; return blocked with the preserved branch and the observed failure. Done when: all available checks are run or inspected with exact outcomes recorded, or a blocking failure is returned.

10. Re-read the remote pull request and confirm its head still matches the pinned revision. On drift, stop before approval or landing, report both revisions, and require a fresh review of the new head. Done when: the remote head matches the pinned revision, or drift is reported and the skill stops.

11. Submit an approval review before any action that closes the accepted pull request. Confirm the approval is v