pr-message-writer

Name: pr-message-writer
Author: krzysztofsurdy

18installs1forks

How to install pr-message-writer?

krzysztofsurdy/code-virtuoso/pr-message-writer

$npx -y skills add krzysztofsurdy/code-virtuoso --skill pr-message-writer

Installs into the current project.

Summary

Write comprehensive pull request messages with structured technical documentation, testing instructions, and verification queries. Framework-agnostic with customizable templates. Use when writing or generating a PR description, preparing a pull request for review, or documenting

Files · 1

View on GitHub

SKILL.md

1	# PR Message Writer
2
3	Write comprehensive, well-structured pull request descriptions by analyzing code changes and following established best practices for technical documentation.
4
5	## Workflow
6
7	### Step 1: Gather Context
8
9	1. Determine the main branch:
10	```bash
11	git symbolic-ref refs/remotes/origin/HEAD \| sed 's@^refs/remotes/origin/@@'
12	```
13	Falls back to `main` or `master` if not set.
14
15	2. Find the merge base:
16	```bash
17	MAIN_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null \| sed 's@^refs/remotes/origin/@@' \|\| echo "main")
18	MERGE_BASE=$(git merge-base HEAD origin/$MAIN_BRANCH)
19	```
20
21	3. Collect all changes since the branch diverged:
22	```bash
23	git log --oneline $MERGE_BASE..HEAD
24	git diff --stat $MERGE_BASE..HEAD
25	git diff $MERGE_BASE..HEAD
26	```
27
28	4. If a ticket ID or branch name is provided as an argument, include it in the PR title.
29
30	5. Gather ticket context. The ticket content is essential for writing accurate testing instructions and understanding the business requirement. If the ticket content is available in context (e.g., from a previous conversation or your project tracker), use it. If it is NOT available or has fallen out of context, ask the user to provide the ticket content before proceeding. Do not guess or invent requirements.
31
32	### Step 2: Analyze Changes
33
34	Read every changed file and understand:
35	- What was changed (new files, modified logic, deleted code)
36	- Why the change was made (bug fix, new feature, refactoring, performance)
37	- Impact on existing functionality (breaking changes, migrations, cache invalidation)
38	- Dependencies introduced or removed
39
40	### Step 3: Follow the Template
41
42	Use the PR message template for structure: [template](references/template.md)
43
44	Review real-world examples for tone and detail level: [examples](references/examples.md)
45
46	### Step 4: Match Change Type to Categories
47
48	Apply the appropriate sections based on what the PR touches:
49
50	\| Category \| When to Include \|
51	\|----------\|----------------\|
52	\| Database and Entity/Model Changes \| New tables, columns, migrations, schema changes \|
53	\| API Changes (REST/GraphQL) \| New or modified endpoints, query/mutation changes \|
54	\| Admin Interface Changes \| New admin pages, filters, list views, form fields \|
55	\| Caching and Performance \| Cache keys, invalidation, query optimization \|
56	\| Security and Permissions \| Auth rules, role checks, access control changes \|
57	\| Event Handling \| New events, handlers, message queue changes \|
58	\| Testing \| New or modified test cases, fixtures, test utilities \|
59
60	### Step 5: Write Testing Instructions (Optional)
61
62	Before writing testing scenarios, ask the user whether they want testing scenarios included in this PR message. Testing scenarios are optional. If the user declines, skip this step entirely and omit the "Test scenarios" section from the PR message. Still include the "Testing instructions" section with basic verification steps and database queries if applicable.
63
64	If the user wants testing scenarios included:
65
66	Target audience: QA testers with ZERO codebase knowledge. They do not know about internal code structure, classes, services, or any implementation details. Write every instruction as if explaining to someone who has never seen the code and never will.
67
68	Rules for testing instructions:
69	- NEVER reference code - no file paths, class names, method names, variable names, or internal architecture
70	- NEVER use technical implementation terms - no internal framework concepts, no code-level abstractions
71	- If UI exists, provide exact click-by-click navigation: which URL to open, which button to click, which field to fill, what value to enter, what to expect on screen
72	- If no UI exists (API-only or GraphQL-only), provide the exact request to execute - full query/mutation with example variables, which tool to use (GraphQL playground, Postman, curl), and the exact URL/endpoint
73	- Database queries are OK - QA knows how to run SQL. Include queries when there is no other way to verify something through UI or API
74	- Every scenario is checkboxed - use `- [ ] Scenario N: Name` so QA can tick them off
75	- Every scenario ends with "Expected results" - a bullet list of what should be visible/changed after the steps
76	- Every scenario is step-by-step - numbered steps, one action per step
77	- Use plain language - "Go to the admin panel", "Click the 'Users' menu item", "You should see a green success message"
78
79	#### Finding real URLs and UI paths
80
81	When a scenario involves navigating to a page, **search the codebas

People who liked this also viewed

6 picks

Type

pr-message-writer

18installs1forks

View on GitHub

How to install pr-message-writer?

krzysztofsurdy/code-virtuoso/pr-message-writer

$npx -y skills add krzysztofsurdy/code-virtuoso --skill pr-message-writer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# PR Message Writer
2
3	Write comprehensive, well-structured pull request descriptions by analyzing code changes and following established best practices for technical documentation.
4
5	## Workflow
6
7	### Step 1: Gather Context
8
9	1. Determine the main branch:
10	```bash
11	git symbolic-ref refs/remotes/origin/HEAD \| sed 's@^refs/remotes/origin/@@'
12	```
13	Falls back to `main` or `master` if not set.
14
15	2. Find the merge base:
16	```bash
17	MAIN_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null \| sed 's@^refs/remotes/origin/@@' \|\| echo "main")
18	MERGE_BASE=$(git merge-base HEAD origin/$MAIN_BRANCH)
19	```
20
21	3. Collect all changes since the branch diverged:
22	```bash
23	git log --oneline $MERGE_BASE..HEAD
24	git diff --stat $MERGE_BASE..HEAD
25	git diff $MERGE_BASE..HEAD
26	```
27
28	4. If a ticket ID or branch name is provided as an argument, include it in the PR title.
29
30	5. Gather ticket context. The ticket content is essential for writing accurate testing instructions and understanding the business requirement. If the ticket content is available in context (e.g., from a previous conversation or your project tracker), use it. If it is NOT available or has fallen out of context, ask the user to provide the ticket content before proceeding. Do not guess or invent requirements.
31
32	### Step 2: Analyze Changes
33
34	Read every changed file and understand:
35	- What was changed (new files, modified logic, deleted code)
36	- Why the change was made (bug fix, new feature, refactoring, performance)
37	- Impact on existing functionality (breaking changes, migrations, cache invalidation)
38	- Dependencies introduced or removed
39
40	### Step 3: Follow the Template
41
42	Use the PR message template for structure: [template](references/template.md)
43
44	Review real-world examples for tone and detail level: [examples](references/examples.md)
45
46	### Step 4: Match Change Type to Categories
47
48	Apply the appropriate sections based on what the PR touches:
49
50	\| Category \| When to Include \|
51	\|----------\|----------------\|
52	\| Database and Entity/Model Changes \| New tables, columns, migrations, schema changes \|
53	\| API Changes (REST/GraphQL) \| New or modified endpoints, query/mutation changes \|
54	\| Admin Interface Changes \| New admin pages, filters, list views, form fields \|
55	\| Caching and Performance \| Cache keys, invalidation, query optimization \|
56	\| Security and Permissions \| Auth rules, role checks, access control changes \|
57	\| Event Handling \| New events, handlers, message queue changes \|
58	\| Testing \| New or modified test cases, fixtures, test utilities \|
59
60	### Step 5: Write Testing Instructions (Optional)
61
62	Before writing testing scenarios, ask the user whether they want testing scenarios included in this PR message. Testing scenarios are optional. If the user declines, skip this step entirely and omit the "Test scenarios" section from the PR message. Still include the "Testing instructions" section with basic verification steps and database queries if applicable.
63
64	If the user wants testing scenarios included:
65
66	Target audience: QA testers with ZERO codebase knowledge. They do not know about internal code structure, classes, services, or any implementation details. Write every instruction as if explaining to someone who has never seen the code and never will.
67
68	Rules for testing instructions:
69	- NEVER reference code - no file paths, class names, method names, variable names, or internal architecture
70	- NEVER use technical implementation terms - no internal framework concepts, no code-level abstractions
71	- If UI exists, provide exact click-by-click navigation: which URL to open, which button to click, which field to fill, what value to enter, what to expect on screen
72	- If no UI exists (API-only or GraphQL-only), provide the exact request to execute - full query/mutation with example variables, which tool to use (GraphQL playground, Postman, curl), and the exact URL/endpoint
73	- Database queries are OK - QA knows how to run SQL. Include queries when there is no other way to verify something through UI or API
74	- Every scenario is checkboxed - use `- [ ] Scenario N: Name` so QA can tick them off
75	- Every scenario ends with "Expected results" - a bullet list of what should be visible/changed after the steps
76	- Every scenario is step-by-step - numbered steps, one action per step
77	- Use plain language - "Go to the admin panel", "Click the 'Users' menu item", "You should see a green success message"
78
79	#### Finding real URLs and UI paths
80
81	When a scenario involves navigating to a page, **search the codebas

People who liked this also viewed

6 picks

Type