We split this skill into the rules it gives an agent

27 rules. About 0 are common, 15 are distinctive, and 12 are very specific to this project.

• ≈0

  Common · estimate

  Many files like this have a rule of this kind.

• ≈15

  Distinctive · estimate

  This author's own choices. Worth a look.

• 12

  Very specific

  Tied to their project's names, files or tools. Probably skip.

• Common
• Distinctive
• Very specific

1. Very specific:

   Use this when local work is ready to publish.

   line 8
2. Very specific:

   Prefer push-pr for one branch or one PR.

   line 10
3. Very specific:

   Prefer push-my-prs only when the user wants a batch loop across many PRs.

   line 11
4. Distinctive:

   Use generic plugin publish skills only when this repo-local skill is unavailable.

   line 12
5. Distinctive:

   If the worktree contains unrelated or user-owned changes, stage only explicit paths that belong to the PR.

   line 18
6. Distinctive:

   Use git add -A only when the whole worktree is confirmed in scope.

   line 19
7. Very specific:

   If publishing from main, master, or the remote default branch, create a repo-appropriate work/...

   line 22
8. Distinctive:

   Run the relevant validation before pushing.

   line 23
9. Distinctive:

   Prefer repo scripts and documented validation commands.

   line 24
10. Distinctive:

    Do not skip validation unless the user explicitly accepts that risk.

    line 25
11. Distinctive:

    Commit intentionally with a repository-appropriate message.

    line 26
12. Distinctive:

    Keep the commit message terse and descriptive.

    line 27
13. Distinctive:

    Do not amend or rewrite unrelated commits unless the user explicitly asks.

    line 28
14. Distinctive:

    Create or update exactly one PR.

    line 30
15. Very specific:

    Prefer gh pr view --json number,url to detect an existing PR for the current branch.

    line 31
16. Very specific:

    If no PR exists, create one with gh pr create.

    line 32
17. Very specific:

    If a PR exists, update it with gh pr edit only when the title/body/base needs to change.

    line 33
18. Very specific:

    Use the GitHub app for PR creation only when the surrounding tool environment already provides it and the repository, base, and head can be …

    line 34
19. Very specific:

    Write multiline PR bodies to scratch/pr-body.md or another temporary body file.

    line 36
20. Very specific:

    Use gh pr create --body-file scratch/pr-body.md or gh pr edit --body-file scratch/pr-body.md.

    line 37
21. Very specific:

    Avoid --body "..." for multiline Markdown because shell quoting can mangle newlines.

    line 38
22. Distinctive:

    Default to a ready PR when the user asked to publish completed work.

    line 40
23. Distinctive:

    Use a draft PR when the user asks for draft status or the work is intentionally incomplete.

    line 41
24. Very specific:

    Use github-cli and validate conventions.

    line 47
25. Distinctive:

    Never use destructive git commands.

    line 48
26. Distinctive:

    Prefer squash automerge unless the repo or existing PR says otherwise.

    line 49
27. Distinctive:

    Do not create recurring automations, feedback monitors, reminders, or follow-up cron jobs as part of publishing unless the user explicitly …

    line 50

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.