How do I get Claude Code or Cursor to write PR descriptions in my style?

Give the agent two or three PR descriptions you wrote and a few rules. Put them somewhere it reads every session: CLAUDE.md or a skill in Claude Code, a rule or AGENTS.md in Cursor. That's free and enough for many people. If you want the style to hold across every PR, review comment and message, and to improve from what you post, connect an MCP server such as Ownhand. Have the agent send each description through it with the pr_description occasion.

By Jordan Gibbs, founder of Ownhand at Thalient Labs. Updated 2 October 2026.

Your style in a PR description is mostly shape: how long it runs, whether you use headings, how you say what you tested, and how you link the issue. Agents default to a long, formal summary of every file.

Show the agent your own descriptions. Describing your tone in adjectives does less.

What agents get wrong by default

A coding agent knows the diff well. It doesn't know that you write three lines for a three line fix, or that you never use a heading. So it pads: a summary of each file, a section for testing even when there was none, and the same handful of inflated words. Real drafts, and what two demo writers made of them:

These examples are real output from the live API. Each AI draft was rewritten by a demo Hand: a fictional writer (an engineer, a founder, an ops lead, a designer or a consultant) built from a handful of samples.

Both rewrites keep every fact, including the issue number and the retry limit. They drop the filler. Review comments have the same problem, usually a hedge and a compliment before the point:

Option 1: examples in a file the agent reads (free)

This is the best free fix. Anthropic's prompting guide says examples are one of the most reliable ways to steer format, tone and structure. It suggests 3 to 5 of them. Pick two or three PR descriptions you wrote yourself, ideally one small fix and one larger change, and save them in one file.

Claude Code

1. Save your examples as ~/.claude/pr-examples.md.
2. Open ~/.claude/CLAUDE.md, your user file that loads in every project, and add a section like the one below. The @ line imports the examples file.
3. Run /context in a session and check that both files are listed under memory files.

## Pull request descriptions

Write PR descriptions the way I do. Copy the length and layout of my examples.
- First line: what changed, in one sentence. No greeting.
- Then why, then how I tested it. Skip a part if there is nothing to say.
- Link the issue as "Fixes #123".
- No headings for a change under 50 lines.
- Do not list every file.

My past descriptions:
@~/.claude/pr-examples.md

If you only want the examples loaded when you ask for a PR, make a skill instead. Put a SKILL.md with the rules in ~/.claude/skills/pr-description/. Put the examples in a file next to it. Then type /pr-description when you open a pull request. Supporting files in a skill only load when the skill runs, so they stay out of other sessions.

Cursor

1. For every project: open Customize, then Rules, and add a User Rule with your rules and one short example. User Rules apply in Agent chat. Inline edits do not use them.
2. For one repository: save your examples as docs/pr-examples.md and add .cursor/rules/pr-style.mdc with frontmatter, as below. Cursor ignores a plain .md file in that folder because it has no frontmatter.
3. Or put the same section in AGENTS.md at the project root. Cursor, Claude Code and Copilot's agent all read it.

---
description: Writing pull request descriptions
alwaysApply: false
---
Write PR descriptions the way I do. Match the examples in @docs/pr-examples.md.

GitHub Copilot

Copilot reads .github/copilot-instructions.md in Copilot Chat, the cloud agent, code review, and the CLI. GitHub's support table doesn't list pull request summaries among the features that read custom instructions. So if the cloud agent opens your PRs, the file helps. For the Summary button on GitHub, it may not.

When this is enough

If you open a few PRs a week in one or two repositories and only care about PR descriptions, stop here. It costs nothing and takes ten minutes. The limits show up over time. Claude Code's docs say Claude treats CLAUDE.md as context and does not enforce it, so a long session can drift back to the default. The rules never learn from your edits. They cover PRs, not your review comments, Slack messages or emails, unless you write more rules.

Option 2: a pull request template (free, for structure)

A template sets the structure for everyone in the repository. It does nothing for voice. Save it as pull_request_template.md in the root, in docs/, or in .github/. GitHub fills new PR descriptions with it. Keep it short: three headings at most, like what changed, why, and how to test. Tell your agent to fill the template and delete sections it has nothing for. If you don't, it will write a line under each one.

Option 3: Copilot's built-in summary

On GitHub, click in the description field, pick the Copilot icon in the field's header, then Summary. Copilot writes a paragraph and a list of key changes linked to the code. It's quick and neutral, fine for many teams. GitHub's docs say it ignores what's already in the description, so start with a blank field. It writes in Copilot's voice, so edit it into yours.

Option 4: an MCP server that rewrites in your voice

Ownhand is the paid option. Your agent still writes the content, what changed, why, and how it was tested, and sends that draft to Ownhand's write tool. The write tool rewrites it in your Hand, a profile built from 5 to 10 things you wrote, and gives it back for you to check.

1. Connect it. In Claude Code, run the command under Install, then /mcp, pick ownhand and sign in. In Cursor, use the button on Connect or add this to ~/.cursor/mcp.json:

{ "mcpServers": { "ownhand": { "url": "https://ownhand.dev/mcp" } } }

2. Build your Hand. Say "set up my Ownhand Hand" and paste 5 to 10 things you wrote, with two or three PR descriptions among them.
3. Paste the agent blurb from the docs into CLAUDE.md, AGENTS.md or a Cursor rule, so the agent uses the tool for every PR without being asked.
4. Ask for the PR as usual: "open a PR for this branch and write the description as me". You read the draft, and the agent posts it once you say so.

The pr_description occasion has its own rules. There's no greeting or sign-off, and Markdown headings and lists are allowed. The order is what changed, why, and how to test, using only the parts the draft has. It stays under 250 words unless you ask for longer. Review comments use review_comment: one point, phrased as a suggestion or a question, under 80 words.

After you post it, the agent reports the exact text you posted with send_feedback. If you cut the testing section or changed a word, your Hand learns that. See how Ownhand learns from what you send.

It's worth it if you write a lot of PRs and review comments, or if you want the same voice in Slack, email and status updates. One Hand covers all 12 occasions. If a rules file already gets your PRs close enough, skip it.

The options side by side

See how to make Claude write like you for the general version of this question. See Ownhand vs custom instructions for a side by side with plain rules files.

Follow-up questions

Will the rewrite change my file names, issue numbers or links?

It shouldn't lose anything. After the rewrite, Ownhand checks that every name, number, link and email address in the draft is still there. If one is missing, it tries again. Anything it still cannot fix comes back to your agent as unresolved. Read the draft before it is posted either way.

Does this work for GitLab merge requests?

Yes. The pr_description occasion covers pull requests and merge requests. Your agent posts it, through the GitHub or GitLab command line tool or an MCP server for your code host.

Why does Copilot's PR summary ignore my template?

GitHub's docs say Copilot ignores existing content in the description. Start with a blank description. Generate the summary first, then paste your template sections around it, or edit it into your own words.

Does Ownhand read my code?

No. It only sees the text your agent sends to the write tool, usually the draft description. Your agent reads the diff and writes the content. Ownhand stores the draft and the text it returned so you can see your history, as the privacy policy describes.

Can my whole team share one style?

A team style goes in a pull request template and a shared project rule. A Hand is one person's voice, and learning from feedback only changes that person's Hand. Each person on the team connects their own Hand.

Sources

Checked on 2 October 2026. If something here is out of date, email hi@thalientlabs.ai and we will fix it.

• Claude Code docs: How Claude remembers your project: CLAUDE.md locations, @ imports, and how Claude treats CLAUDE.md as context
• Claude Code docs: Skills: personal and project skill folders, supporting files, invoking with a slash command
• Claude Code docs: MCP: claude mcp add, scopes, and signing in with /mcp
• Cursor docs: Rules: project rules in .cursor/rules as .mdc files, AGENTS.md, User Rules
• Cursor docs: MCP: ~/.cursor/mcp.json and .cursor/mcp.json
• GitHub docs: Support for different types of custom instructions: which Copilot features read copilot-instructions.md and AGENTS.md
• GitHub docs: Creating a pull request summary with GitHub Copilot: steps, and that existing description content is not taken into account
• GitHub docs: Creating a pull request template: where pull_request_template.md can live
• Claude docs: Prompting best practices: examples steer format, tone and structure; 3 to 5 examples work best
• Ownhand source code: the pr_description and review_comment occasions and the fact check