wordbrickswordbricks/onequery/.agents/skills/gh-pr-writing/SKILL.md

gh-pr-writing

Skill17 starsChanged 7 months agoApache-2.0View on GitHub

Write and update GitHub PR titles and PR bodies with repository templates and local conventions. Use when creating PRs with `gh pr create`, revising PR text, choosing a conventional title prefix (for example `feat(web):`), or ensuring ticket suffix rules.

Commits and pushes

In this repository19 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agent-browserSkill
- agentic-legibilitySkill
- babysit-prSkill
- better-result-adoptSkill
- code-breaking-changesSkill
- code-review-change-sizeSkill
- code-reviewSkill
- code-review-testingSkill
- drizzle-migration-conflict-resolutionSkill
- knip-deadcodeSkill
- onequery-blog-imagesSkill
- onequery-bugSkill
- onequery-pr-bodySkill
- protobufSkill
- react-no-use-effectSkill
- tanstack-query-best-practicesSkill
- tanstack-router-best-practicesSkill
- xstateSkill

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 5 are distinctive, and 3 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific
could be automatic: a setting could enforce it

Very specific:
Run bun run format manually before commit/push to avoid push-time formatter diffs.
line 12
Very specific:
Create or update the PR using gh pr create or gh pr edit.
line 15
Distinctive:
Keep summary imperative and specific.
line 19
Distinctive:
Do not omit scope unless scope is truly cross-cutting.
line 20
Very specific:
If user requires a ticket marker at the end, append exactly as requested (for example ...
line 21
Distinctive:
When multiple scopes are touched, choose the dominant user impact scope.
line 37
Distinctive:
Use the repository PR template verbatim section structure when it exists.
line 40
Distinctive:
Prefer concrete, observable outcomes over abstract summaries.
line 41

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

GH PR Writing

Workflow

Inspect changed files (git show --name-only --oneline HEAD or git diff --name-only).
Choose title type and scope from the mapping below.
Build title in Conventional Commit PR style.
Run bun run format manually before commit/push to avoid push-time formatter diffs.
Load PR template from .github/pull_request_template.md when present.
Fill the template with concrete user-facing behavior, implementation details, and executed validation commands.
Create or update the PR using gh pr create or gh pr edit.

Title Rules

Format: <type>(<scope>): <summary>.
Keep summary imperative and specific.
Do not omit scope unless scope is truly cross-cutting.
If user requires a ticket marker at the end, append exactly as requested (for example ... WOR-2610).

Type And Scope Mapping

See the following example:

feat(web): for user-visible frontend behavior in apps/dashboard, packages/ui, routing/UI/UX changes.
fix(web): for frontend bug fixes.
feat(server): for backend/API behavior changes in packages/server.
fix(server): for backend/API bug fixes.
feat(db): or fix(db): for schema/query/migration behavior in packages/db.
chore(repo): for tooling/config/lockfile/CI/repo maintenance.
refactor(<scope>): for structural code changes without behavior change.
test(<scope>): for test-only changes.
docs(<scope>): for documentation-only changes.
...

When multiple scopes are touched, choose the dominant user impact scope.

PR Body Rules

Use the repository PR template verbatim section structure when it exists.
Prefer concrete, observable outcomes over abstract summaries.
Include exact command lines used for validation.
Explicitly note excluded items (for example: "README unchanged") when relevant.

Commands

# Inspect latest commit

git show --name-only --oneline HEAD

# Format before push

bun run format

# Create PR from template body file

gh pr create --base main --head <branch> --title "<title>" --body-file <body.md>

# Update title/body later

gh pr edit <pr-number-or-url> --title "<title>" --body-file <body.md>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free