write-tech-pr-description
Writes or revises a pull request title and description that explain the change, its reason, review boundaries, and verified checks.
Synopsis
User-invoked. Name this skill when you want the agent to apply it. disable-model-invocation is true.
Source file: skills/write-tech-pr-description/SKILL.md.
Front matter
- name
write-tech-pr-description- description
- Writes or revises a pull request title and description that explain the change, its reason, review boundaries, and verified checks.
- disable-model-invocation
true
Full contents
---
name: write-tech-pr-description
description: Writes or revises a pull request title and description that explain the change, its reason, review boundaries, and verified checks.
disable-model-invocation: true
---
# Write a PR description
Read [write-tech-core](../write-tech-core/SKILL.md) first.
A PR description is a review aid and durable change record. It should explain
what changed and why, not narrate every edited file or copy the diff.
## Inspect the change
Establish from the issue, diff, commits, tests, and repository template:
- the problem or goal;
- the externally meaningful before and after behavior;
- implementation choices a reviewer must understand;
- scope boundaries and known consequences;
- the exact checks run and their results;
- verified issue links, rollout needs, and compatibility concerns.
Do not infer motivation from code when an issue or request states it. If the
change and stated goal disagree, surface the mismatch instead of smoothing it
over.
## Output contract
Write a short title that names the concrete outcome. Follow repository title
policy when one exists. Otherwise use plain imperative or scope-first language,
not a Conventional Commits prefix by default.
Use the smallest supported subset:
1. **Summary:** problem, change, and result in a short paragraph.
2. **Changes:** group important changes by intent or behavior.
3. **Testing:** exact checks run and observed results.
4. **Impact, rollout, compatibility, screenshots, or reviewer notes:** only
when the change and evidence make them useful.
5. **Issue references:** only verified links or repository-native identifiers.
Separate facts from follow-up work. Say a check was not run only when that
status matters to review. Distinguish "not assessed" from a verified finding of
no impact.
Do not create empty template sections, placeholder issue links, speculative
risks, generic rollout steps, release promises, invented screenshots, or
unchecked boxes for work nobody requested. Use a checklist only when the
repository requires one, and mark only items supported by evidence.
## Closed-facts mode
When given a closed fact set rather than a repository and diff, output only:
- a title;
- `## Summary`;
- `## Changes`;
- `## Testing` when a check and result were supplied.
Do not add motivation beyond the supplied behavior, implementation mechanics
beyond the supplied facts, or issue, screenshot, rollout, risk, performance,
security, compatibility, reviewer, breaking-change, and checklist sections.
Before returning, inspect every level-two heading. Delete any heading other
than `Summary`, `Changes`, and `Testing`, together with its content.
## Verification gate
Compare the title and every bullet with the diff. Check issue references,
commands, counts, links, screenshots, and test status. Never call CI green when
only a local command passed. Never claim behavior is unchanged unless it was
supplied or verified.
## Example
```markdown
Preserve exit 2 for invalid TTL values
## Summary
Invalid TTL values now remain usage errors.
## Changes
- Wrap `strconv.Atoi` failures with `ErrUsage`.
- Add a CLI regression test for exit `2`.
## Testing
- `go test ./...` passed across 42 packages.
```
Return the title and description only.