pr-writing git:20260930.19be338A

Immutable. This exact content never changes and is served at /api/v1/blob/8b55c4e2b3c822dd.

---
name: pr-writing
description: Write or update PR and MR titles and descriptions when creating or editing a pull request or merge request, including when the agent reaches that step during implementation. Use for requested drafts too, not review-only requests or standalone commit messages.
---

# Hope PR Writing

Apply when preparing a PR or MR title and description, whether the person asks
directly or the current authorized workflow reaches creation or update. Explicit
invocation is also supported. Work in the current conversation under the
surrounding task's authority to publish, push, or merge.

## Ground the description

Read applicable repository instructions, including `AGENTS.md` and
`CONTRIBUTING.md` when present, and the relevant PR or MR template. Check hidden
template locations such as `.github` and `.gitlab/merge_request_templates`;
an empty file-search result does not establish that these known paths are absent.
Honor the person's language, scope, and project conventions. Without a project
rule, use a descriptive title and proportionate prose; do not impose Conventional
Commits, a character limit, or mandatory headings. Do not create project settings
just to apply this skill.

Identify the actual proposed change against its target branch. Use the current
diff, relevant code, conversation decisions, and observed verification results.
Distinguish committed changes from local work that will not be submitted. Use
existing PR or MR text as context, then reconcile it with the final change.
Resolve scope from available evidence; ask only if remaining ambiguity changes
what the description would claim.

Ground the explanation in the concrete problem or purpose, resulting behavior,
and evidence a reviewer needs. Include reasoning the diff cannot show and
material verification limits. Select further context for the change: before/after
evidence, measurements, compatibility or rollout implications, related links,
or review focus. Do not infer intent, successful tests, performance gains, or
compatibility guarantees from code alone. Use issue-closing keywords only when
the submitted change resolves that issue.

## Write with Hope Write

Use Hope Write for drafting or editing the title and body through its public
contract at [Write](../write/SKILL.md). Load that skill and follow it in this
conversation; use the host's skill invocation mechanism when available. This
handoff is permitted without a separate user command. Provide the grounded
change, repository format, language, verification evidence, and any review focus.
PR Writing owns factual scope and completeness; Write owns clear expression
without changing those facts. Do not substitute reading only Write's shared
standard for using the skill.

The title should identify the changed behavior or repository result on its own.
Describe the final implementation with detail proportional to the review needs.
Preserve required template fields and meaningful links; leave wording and
structure to Write within those constraints.

## Return to the task

Check the title and body against the final diff and evidence once. Refresh them
if the implementation changes before submission. Return the requested draft or
use it in the already-authorized creation or update flow. Preserve the existing
target and publication state; do not open a duplicate request or add a separate
approval step merely because this skill was selected.

The adapted sources and their limits are in [Sources](references/sources.md).