pr-description-writer

Name: pr-description-writer
Author: Varnan-Tech

21installs59forks

How to install pr-description-writer?

varnan-tech/opendirectory/pr-description-writer

$npx -y skills add Varnan-Tech/opendirectory --skill pr-description-writer

Installs into the current project.

Summary

Use when the user asks to write, draft, generate, or update a GitHub pull request description for the current branch. Reads the branch diff and commit messages, writes a structured PR body (summary, changes, testing), and optionally creates or updates the PR via the gh CLI.

Files · 1

View on GitHub

SKILL.md

1	# PR Description Writer
2
3	Read the current branch diff and write a complete GitHub pull request description. Create or update the PR with one command.
4
5	## Writing Style
6
7	Apply to all generated PR descriptions:
8
9	- Active voice. "Adds X" not "X has been added."
10	- Present tense for summary ("Adds caching layer"), past tense for context ("The old approach caused N requests per render")
11	- Short sentences, one idea per bullet
12	- No em dashes — use a comma or period instead
13	- No filler: "this PR", "this commit", "as per the discussion"
14	- Specifics beat generalities: "reduces p95 latency from 800ms to 90ms" beats "improves performance"
15
16	---
17
18	## Step 1: Check Setup
19
20	Confirm `gh` is authenticated:
21
22	```bash
23	gh auth status
24	```
25
26	If not authenticated: `gh auth login` and follow the prompts.
27
28	Confirm the current directory is a git repo with an active branch:
29
30	```bash
31	git branch --show-current
32	```
33
34	If detached HEAD or no branch, stop and ask the user which branch they want to describe.
35
36	---
37
38	## Step 2: Gather Diff Context
39
40	Run all three commands to build context:
41
42	File summary (what changed):
43	```bash
44	git diff main...HEAD --stat
45	```
46
47	Commit messages (why it changed):
48	```bash
49	git log main...HEAD --oneline
50	```
51
52	Full diff (how it changed):
53
54	Use `origin/main` first (always up to date), fall back to local `main`, then `master`:
55	```bash
56	if git rev-parse origin/main &>/dev/null 2>&1; then
57	BASE=origin/main
58	elif git rev-parse main &>/dev/null 2>&1; then
59	BASE=main
60	else
61	BASE=master
62	fi
63	git diff $BASE...HEAD
64	```
65
66	If the diff is very large (over 500 lines), read the `--stat` summary and the commit messages only. Also read the first 200 lines of the diff to understand the primary changes without processing the entire output.
67
68	Also check for an existing PR and read its current title/body:
69	```bash
70	gh pr view --json title,body,baseRefName 2>/dev/null
71	```
72
73	---
74
75	## Step 3: Read the Format Guide
76
77	Read `references/pr-format-guide.md` in full before writing anything. Internalize:
78	- Required sections and their order
79	- How to write each section
80	- What to include vs omit
81	- The testing section format
82
83	---
84
85	## Step 4: Generate the Description
86
87	Write the PR description using the format from `references/pr-format-guide.md`.
88
89	Rules:
90	- Every bullet in the Changes section must trace to something in the diff
91	- Do not invent testing steps that are not implied by the code changes
92	- If a section has no relevant content, omit it entirely (do not write "N/A" or leave it empty)
93	- Screenshots section: only include if there are UI changes visible in the diff
94	- If commit messages explain the "why", use that context in the Summary
95
96	QA checkpoint: Before presenting, verify:
97	- [ ] Summary is 1-2 sentences, active voice, no filler
98	- [ ] Every change bullet is specific and traces to the diff
99	- [ ] No invented metrics or outcomes
100	- [ ] Testing steps are actionable (someone could follow them)
101	- [ ] No em dashes in any line
102
103	---
104
105	## Step 5: Create or Update the PR
106
107	Present the description to the user and ask: "Ready to create the PR, update the existing one, or output only?"
108
109	Create a new PR:
110
111	Pass the body via stdin to handle backticks, quotes, and newlines safely:
112	```bash
113	gh pr create --title "TITLE_HERE" --body-file - << 'EOF'
114	BODY_HERE
115	EOF
116	```
117
118	Suggest a title based on the commit messages and diff summary. The title should be imperative mood, under 72 characters: "Add Redis caching for user session lookups" not "Added caching".
119
120	Update an existing PR:
121	```bash
122	gh pr edit --body-file - << 'EOF'
123	BODY_HERE
124	EOF
125	```
126
127	Output only: Present the title and body in a code block for manual copy-paste.
128
129	After creating or updating, confirm: "PR description updated. View it at: [URL]"

People who liked this also viewed

6 picks

Type

pr-description-writer

21installs59forks

View on GitHub

How to install pr-description-writer?

varnan-tech/opendirectory/pr-description-writer

$npx -y skills add Varnan-Tech/opendirectory --skill pr-description-writer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# PR Description Writer
2
3	Read the current branch diff and write a complete GitHub pull request description. Create or update the PR with one command.
4
5	## Writing Style
6
7	Apply to all generated PR descriptions:
8
9	- Active voice. "Adds X" not "X has been added."
10	- Present tense for summary ("Adds caching layer"), past tense for context ("The old approach caused N requests per render")
11	- Short sentences, one idea per bullet
12	- No em dashes — use a comma or period instead
13	- No filler: "this PR", "this commit", "as per the discussion"
14	- Specifics beat generalities: "reduces p95 latency from 800ms to 90ms" beats "improves performance"
15
16	---
17
18	## Step 1: Check Setup
19
20	Confirm `gh` is authenticated:
21
22	```bash
23	gh auth status
24	```
25
26	If not authenticated: `gh auth login` and follow the prompts.
27
28	Confirm the current directory is a git repo with an active branch:
29
30	```bash
31	git branch --show-current
32	```
33
34	If detached HEAD or no branch, stop and ask the user which branch they want to describe.
35
36	---
37
38	## Step 2: Gather Diff Context
39
40	Run all three commands to build context:
41
42	File summary (what changed):
43	```bash
44	git diff main...HEAD --stat
45	```
46
47	Commit messages (why it changed):
48	```bash
49	git log main...HEAD --oneline
50	```
51
52	Full diff (how it changed):
53
54	Use `origin/main` first (always up to date), fall back to local `main`, then `master`:
55	```bash
56	if git rev-parse origin/main &>/dev/null 2>&1; then
57	BASE=origin/main
58	elif git rev-parse main &>/dev/null 2>&1; then
59	BASE=main
60	else
61	BASE=master
62	fi
63	git diff $BASE...HEAD
64	```
65
66	If the diff is very large (over 500 lines), read the `--stat` summary and the commit messages only. Also read the first 200 lines of the diff to understand the primary changes without processing the entire output.
67
68	Also check for an existing PR and read its current title/body:
69	```bash
70	gh pr view --json title,body,baseRefName 2>/dev/null
71	```
72
73	---
74
75	## Step 3: Read the Format Guide
76
77	Read `references/pr-format-guide.md` in full before writing anything. Internalize:
78	- Required sections and their order
79	- How to write each section
80	- What to include vs omit
81	- The testing section format
82
83	---
84
85	## Step 4: Generate the Description
86
87	Write the PR description using the format from `references/pr-format-guide.md`.
88
89	Rules:
90	- Every bullet in the Changes section must trace to something in the diff
91	- Do not invent testing steps that are not implied by the code changes
92	- If a section has no relevant content, omit it entirely (do not write "N/A" or leave it empty)
93	- Screenshots section: only include if there are UI changes visible in the diff
94	- If commit messages explain the "why", use that context in the Summary
95
96	QA checkpoint: Before presenting, verify:
97	- [ ] Summary is 1-2 sentences, active voice, no filler
98	- [ ] Every change bullet is specific and traces to the diff
99	- [ ] No invented metrics or outcomes
100	- [ ] Testing steps are actionable (someone could follow them)
101	- [ ] No em dashes in any line
102
103	---
104
105	## Step 5: Create or Update the PR
106
107	Present the description to the user and ask: "Ready to create the PR, update the existing one, or output only?"
108
109	Create a new PR:
110
111	Pass the body via stdin to handle backticks, quotes, and newlines safely:
112	```bash
113	gh pr create --title "TITLE_HERE" --body-file - << 'EOF'
114	BODY_HERE
115	EOF
116	```
117
118	Suggest a title based on the commit messages and diff summary. The title should be imperative mood, under 72 characters: "Add Redis caching for user session lookups" not "Added caching".
119
120	Update an existing PR:
121	```bash
122	gh pr edit --body-file - << 'EOF'
123	BODY_HERE
124	EOF
125	```
126
127	Output only: Present the title and body in a code block for manual copy-paste.
128
129	After creating or updating, confirm: "PR description updated. View it at: [URL]"

People who liked this also viewed

6 picks

Type