How do I install the Write Pr skill?

Run npx skillmds@latest add majiayu000/write-pr in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Write Pr safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Write Pr?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Write Pr free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Write Pr?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Write Pr by majiayu000 — Agent Skill

Name: Write Pr
Rating: 4.2 (5 reviews)
Author: majiayu000

File contents

Writing pull requests

Standards for PR titles and descriptions in tldraw/tldraw.

PR title

Use semantic PR titles (Conventional Commits format):

<type>(<scope>): <description>

Types

feat - New feature
fix - Bug fix
docs - Documentation only
refactor - Code change that neither fixes a bug nor adds a feature
perf - Performance improvement
test - Adding or fixing tests
chore - Maintenance tasks

Scope (optional)

A noun describing the affected area: fix(editor):, feat(sync):, docs(examples):

Examples

feat(editor): add snap threshold configuration option
fix(arrows): correct binding behavior with rotated shapes
docs: update sync documentation
refactor(store): simplify migration system

PR body

Use this template:

<description paragraph>

### Change type

- [x] `bugfix` | `improvement` | `feature` | `api` | `other`

### Test plan

1. Step to test...
2. Another step...

- [ ] Unit tests
- [ ] End to end tests

### Release notes

- Brief description of changes for users

Description paragraph

Start with: "In order to X, this PR does Y."

Keep it specific - avoid vague phrases like "improve user experience"
Link related issues in the first paragraph
Don't expect readers to also read the linked issue

Change type

Tick exactly one type with [x]
Delete unticked items

Test plan

List manual testing steps if applicable
Remove the numbered list if changes cannot be manually tested
Tick checkboxes for included test types

Release notes

Write brief notes describing user-facing changes
Use imperative mood: "Add...", "Fix...", "Remove..."
Omit this section entirely for internal work (CI, tooling, tests, etc.) that has no user-facing impact

API changes section

Include when changes affect api-report.md:

### API changes

- Added `Editor.newMethod()` for X
- Breaking! Removed `Editor.oldMethod()`
- Changed `Editor.method()` to accept optional `options` parameter

Related issues

Search for and link relevant issues that this PR addresses.

Important

Never include "Generated with Claude Code" unless the PR directly relates to Claude Code
Never use title case for descriptions - use sentence case

---name: write-prdescription: Writing pull request titles and descriptions for the tldraw repository. Use when creating a new PR, updating an existing PR's title or body, or when the /pr command needs PR content guidance.--- # Writing pull requests Standards for PR titles and descriptions in tldraw/tldraw. ## PR title Use semantic PR titles (Conventional Commits format): ``` <type>(<scope>): <description> ``` ### Types - `feat` - New feature - `fix` - Bug fix - `docs` - Documentation only - `refactor` - Code change that neither fixes a bug nor adds a feature - `perf` - Performance improvement - `test` - Adding or fixing tests - `chore` - Maintenance tasks ### Scope (optional) A noun describing the affected area: `fix(editor):`, `feat(sync):`, `docs(examples):` ### Examples - `feat(editor): add snap threshold configuration option` - `fix(arrows): correct binding behavior with rotated shapes` - `docs: update sync documentation` - `refactor(store): simplify migration system` ## PR body Use this template: ```md <description paragraph> ### Change type - [x] `bugfix` | `improvement` | `feature` | `api` | `other` ### Test plan 1. Step to test... 2. Another step... - [ ] Unit tests - [ ] End to end tests ### Release notes - Brief description of changes for users ``` ### Description paragraph Start with: "In order to X, this PR does Y." - Keep it specific - avoid vague phrases like "improve user experience" - Link related issues in the first paragraph - Don't expect readers to also read the linked issue ### Change type - Tick exactly one type with `[x]` - Delete unticked items ### Test plan - List manual testing steps if applicable - Remove the numbered list if changes cannot be manually tested - Tick checkboxes for included test types ### Release notes - Write brief notes describing user-facing changes - Use imperative mood: "Add...", "Fix...", "Remove..." - Omit this section entirely for internal work (CI, tooling, tests, etc.) that has no user-facing impact ## API changes section Include when changes affect `api-report.md`: ```md ### API changes - Added `Editor.newMethod()` for X - Breaking! Removed `Editor.oldMethod()` - Changed `Editor.method()` to accept optional `options` parameter ``` ## Related issues Search for and link relevant issues that this PR addresses. ## Important - Never include "Generated with Claude Code" unless the PR directly relates to Claude Code - Never use title case for descriptions - use sentence case

Frequently asked questions

Write Pr