wordbricks/onequery · Archived

gh-pr-writing

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.

Installation

$ npx skills add wordbricks/onequery --skill gh-pr-writing

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from wordbricks/onequery · top by installs.

npx skills add wordbricks/onequery

Browse all from wordbricks/onequery

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 17
License LICENSE
Default branch main
Open issues 0
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,470 B
  • docs SUMMARY.md 276 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

GH PR Writing

Workflow

  1. Inspect changed files (git show --name-only --oneline HEAD or git diff --name-only).
  2. Choose title type and scope from the mapping below.
  3. Build title in Conventional Commit PR style.
  4. Run bun run format manually before commit/push to avoid push-time formatter diffs.
  5. Load PR template from .github/pullrequesttemplate.md when present.
  6. Fill the template with concrete user-facing behavior, implementation details, and executed validation commands.
  7. 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>