csh/playbook
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

📦 deps(thirdparty): update snapshots

Browse Source
This commit is contained in:
ci[bot]
2026-07-22 10:09:47 +00:00
parent 316c012df0
commit 60364c6660
353 changed files with 24740 additions and 1264 deletions
Download Patch File Download Diff File Expand all files Collapse all files
antigravity-awesome-skills/docs/maintainers/merging-prs.md
+13 -17
View File
@@ -1,19 +1,19 @@
# Merging Pull Requests
**Policy: we always Merge PRs on GitHub so contributors get credit. We never Close a PR after integrating their work locally.**
**Policy: every accepted PR is merged through `npm run merge:batch`, which uses GitHub's protected squash-merge endpoint so contributors get credit. We never push an integration directly to `main` or close a PR after copying its work.**
## Always merge via GitHub
- Use the GitHub UI **"Squash and merge"** for every accepted PR.
- Use `npm run merge:batch -- --prs <PR_NUMBER>` for every accepted PR; do not substitute the GitHub UI or a raw `gh pr merge` command.
- The PR must show as **Merged**, not Closed. That way the contributor appears in the repo’s contribution graph and the PR is clearly linked to the merge commit.
- Do **not** integrate a PR by squashing locally, pushing to `main`, and then closing the PR. That would show "Closed" and the contributor would not get proper credit.
- Before merging, require the normal PR checks from [`.github/workflows/ci.yml`](../../.github/workflows/ci.yml) to be green. If the PR touches `SKILL.md`, also require the separate [`skill-review` workflow](../../.github/workflows/skill-review.yml) to pass.
- For PRs that touch `SKILL.md` or risky guidance, require a real manual logic review in addition to the automated checks. Confirm the instructions, failure modes, and `risk:` label make sense before merging.
- Before merging, require the normal PR checks from [`.github/workflows/ci.yml`](../../.github/workflows/ci.yml) to be green. If the PR changes anything under `skills/**` or `plugins/**/skills/**`, also require a truthful outcome from the separate [`skill-review` workflow](../../.github/workflows/skill-review.yml).
- For any tracked change under a canonical `skills/<skill-id>/**` subtree, inspect the complete skill directory and require a real manual logic review in addition to the automated checks. Confirm instructions, bundled files, failure modes, provenance, and `risk:` label before attesting the exact full head SHA.
- For ordered multi-PR maintainer batches, use [Merge Batch](merge-batch.md) as the operational shortcut and keep this document as the policy reference.
## If the PR has merge conflicts
Resolve conflicts **on the PR branch** so the PR becomes mergeable, then use "Squash and merge" on GitHub.
Resolve conflicts **on the PR branch** so the PR becomes mergeable, then use `merge:batch`.
### Generated files policy
@@ -38,10 +38,10 @@ Resolve conflicts **on the PR branch** so the PR becomes mergeable, then use "Sq
`git add .` then `git commit -m "chore: merge main to resolve conflicts"` (or leave the default merge message).
5. **Push to the same branch the PR is from**
If the PR is from the contributor’s fork branch (e.g. `sraphaz:feat/uncle-bob-craft`), you need push access to that branch. Options:
- **Preferred:** Ask the contributor to merge `main` into their branch, fix conflicts, and push; then you use "Squash and merge" on GitHub.
- **Preferred:** Ask the contributor to merge `main` into their branch, fix conflicts, and push; then use `merge:batch`.
- If you have a way to push to their branch (e.g. they gave you permission, or the branch is in this repo), push:
`git push origin pr-<PR_NUMBER>:feat/uncle-bob-craft` (replace with the actual branch name from the PR).
6. **On GitHub:** The PR should now be mergeable. Click **"Squash and merge"**. The PR will show as **Merged**.
6. **Run the guarded merge:** Once the PR is mergeable, use `npm run merge:batch -- --prs <PR_NUMBER> [--reviewed-head <40-character-head-sha>]`. The PR will show as **Merged**.
### If the contributor resolves conflicts
@@ -58,23 +58,19 @@ git commit -m "chore: merge main to resolve conflicts"
git push origin <their-branch>
```
Then you use **"Squash and merge"** on GitHub. The PR will be **Merged**, not Closed.
Then use the guarded `merge:batch` command. The PR will be **Merged**, not Closed.
## Rare exception: local squash (avoid if possible)
## No local-integration exception
Only if merging via GitHub is not possible (e.g. contributor unreachable and you must integrate their work, or a one-off batch), you may squash locally and push to `main`. In that case:
1. Add a **Co-authored-by** line to the squash commit so the contributor is still credited (see [GitHub: Creating a commit with multiple authors](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors)).
2. Close the PR with a comment explaining why it was integrated locally and that attribution is in the commit.
3. Prefer to avoid this pattern in the future so PRs can be **Merged** normally.
If `merge:batch` cannot prove the immutable PR tuple, required checks, branch protection, or exact review evidence, stop and repair the PR or workflow. Never integrate locally, push directly to `main`, or replace the guarded command with a raw merge.
## Summary
| Goal | Action |
|-----------------------------|------------------------------------------------------------------------|
| Give contributors credit | Always use **Squash and merge** on GitHub so the PR shows **Merged**. |
| PR has conflicts | Resolve on the PR branch (you or the contributor), then **Squash and merge**. |
| Never | Integrate locally and then **Close** the PR without merging. |
| Give contributors credit | Use `merge:batch` so GitHub records the protected squash merge. |
| PR has conflicts | Resolve on the PR branch, then run `merge:batch`. |
| Never | Push an integration directly to `main`, use a raw merge, or close the PR after copying its work. |
## References