Skip to main content

PR description and title from branch changes

Update an existing GitHub PR title/body from the current branch diff using .github/pull_request_template.md. Use when the user asks to sync, refresh, or improve PR metadata; if no PR exists, draft the PR and ask before creating it unless the user already explicitly asked to create or open a PR.

Source: .agents/skills/pr-description/SKILL.md

Metadata​

  • name: pr-description

Content​

PR description and title from branch changes

When this skill runs, update the open pull request for the current branch so its title and description match .github/pull_request_template.md, with sections filled from this branch’s actual changes versus the repository default base branch.

If no PR exists, prepare the title/body as a draft and ask before creating the PR unless the user already explicitly asked to create or open a PR in the current request.

Prerequisites​

  • GitHub CLI gh installed and authenticated (gh auth status).
  • Run from the repo root (or cd there first).

1. Resolve context​

  1. Repo root: ensure you are in the git root of nasio-nextjs.
  2. Current branch: git branch --show-current
  3. Base branch (for diffs): prefer
    gh repo view --json defaultBranchRef --jq .defaultBranchRef.name
    If that fails, use git symbolic-ref refs/remotes/origin/HEAD → take the short name (e.g. develop).
  4. Scope of changes (use for “Changes” and for inferring Problems/Solutions):
    • git log --oneline <base>..HEAD
    • git diff --stat <base>...HEAD
    • git diff <base>...HEAD (spot-check important files; do not paste huge blobs into the PR body—summarize)
  5. Feature context: when the diff touches a documented domain, read the relevant .agents/references/features/*.md file so PR Problems/Solutions use the product vocabulary and do not miss related routes, services, or gotchas. Keep the PR grounded in the actual diff.

2. Load the PR template (required shape)​

Read and follow the exact section headings and order from:

/.github/pull_request_template.md

Do not remove required headings. Preserve HTML comments from the template where they still help authors (e.g. <!-- Optional -->).

Fill sections as follows:

SectionWhat to write
Ticket / Meegle / LarkIf the branch name or commits reference a task ID, fill links; otherwise keep the template’s link pattern and use a clear placeholder like taskId or ask the user once for real IDs/links. Never invent real URLs.
ProblemsShort, concrete problem statement inferred from commits + diff (what was broken, missing, or needed).
SolutionsHow this PR addresses those problems (approach-level; optional if Problems + Changes alone are enough).
ChangesBullet list grounded in git diff <base>...HEAD (files/features touched). Accurate > exhaustive.
Environment variablesList additions/changes only if the diff touches config, docs, or code that introduces new vars; otherwise note “None” or leave the template hint.
Screenshots or RecordingsOptional; say “N/A” or omit detail if none.
PartnersOptional; only tag if evident from commits or user context.

3. PR title​

  • One line, imperative mood, concise (aim ≤ ~72 characters).
  • Summarize the main outcome of the branch (not the ticket template).
  • If the team uses a ticket prefix in branch names (e.g. DEV-1234), include it when present.

4. Apply to GitHub​

  1. Detect PR for this head branch
    gh pr view --json number,title,url 2>/dev/null
    If that fails:
    gh pr list --head "$(git branch --show-current)" --json number --jq '.[0].number'

  2. Write body to a temp file (keeps markdown reliable):
    e.g. write the filled template to .git/pr-body-tmp.md (or another temp path), then:

    • PR exists:
      gh pr edit <NUMBER> --title "<TITLE>" --body-file .git/pr-body-tmp.md

    • No PR and user already asked to create/open a PR: gh pr create --base <BASE> --head "$(git branch --show-current)" --title "<TITLE>" --body-file .git/pr-body-tmp.md

    • No PR and user did not explicitly ask to create/open a PR: Stop before gh pr create. Show the proposed base branch, head branch, title, and body summary, then ask for approval to create the PR.

  3. Confirm: gh pr view <NUMBER> --web or print the PR URL for the user.

  4. Cleanup: remove the temp body file if you created it under .git/.

5. Quality bar​

  • Accuracy: Description must reflect real diffs; do not claim changes not present in git diff <base>...HEAD.
  • Context: Feature references can inform wording, but the PR body must still be based on commits and diffs.
  • Tone: Clear, complete sentences; match a strong internal PR style.
  • Template fidelity: Same top-level structure as .github/pull_request_template.md (headings and placeholder sections preserved).
  • If gh or auth is missing, stop and tell the user what to install or run—do not fake an update.

Reference path​

  • Template: .github/pull_request_template.md