chore: add Claude Code skills for PR descriptions and release notes#8920
chore: add Claude Code skills for PR descriptions and release notes#8920sriramveeraghanta merged 3 commits intopreviewfrom
Conversation
📝 WalkthroughWalkthroughAdded two new user-invocable Claude skill definitions under Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Developer
participant Claude as "Claude Skill"
participant Git as "Local Git\n(git log / git diff)"
participant GH as "GitHub CLI\n(gh pr view / gh pr edit)"
participant MCP as "Plane MCP (optional)"
Developer->>Claude: invoke `pr-description` or `release-notes`
alt pr exists
Claude->>GH: gh pr view <PR> --json (get base or commits)
GH-->>Claude: PR metadata / commits
else no PR context
Claude->>Developer: ask for base or infer (preview/master)
end
Claude->>Git: git log <base>...HEAD / git diff <base>...HEAD --stat --no-color
Git-->>Claude: commits + diffs/stats
Claude->>Claude: filter noise, extract work-item IDs, categorize commits
alt enrichment requested
Claude->>MCP: lookup work-item details
MCP-->>Claude: enrichment data
end
Claude-->>Developer: output raw filled markdown for PR body or release notes
Developer->>GH: optional gh pr edit --body <<'HEREDOC'
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.claude/skills/pr-description.md (1)
18-19: Make the diff command explicitly match the--no-colorguidance.The instruction says to use
--no-color, but the command example omits it. Prefer making the command copy-paste accurate.Suggested command update
- - `git diff <base>...HEAD` to read the actual diff (use `--no-color`) + - `git diff <base>...HEAD --no-color` to read the actual diff🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.claude/skills/pr-description.md around lines 18 - 19, Update the example diff command `git diff <base>...HEAD` to exactly match the guidance by including the `--no-color` flag (e.g., change the example to `git diff <base>...HEAD --no-color`) so readers can copy-paste it and follow the documented instruction; ensure the surrounding text still references `--no-color` consistently.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.claude/skills/pr-description.md:
- Line 32: The "Improvement" definition in the "Type of Change" text is
incorrect: replace the current phrase "Improvement (change that would cause
existing functionality to not work as expected)" with wording that reflects a
non-breaking enhancement, e.g. "Improvement (change that improves or optimizes
existing functionality without breaking compatibility)"; update the line
containing the exact string "Improvement (change that would cause existing
functionality to not work as expected)" in the .claude/skills/pr-description.md
so the PR description checkboxes reflect the correct meaning.
In @.claude/skills/release-notes.md:
- Around line 65-67: The fenced code block containing the call
mcp__plane__retrieve_work_item_by_identifier(project_identifier="WEB",
issue_identifier=6874) is missing a language identifier and triggers MD040;
update that fence to include a language tag (e.g., "text") so it becomes ```text
... ``` to satisfy markdownlint. Locate the exact fenced block in release-notes
content and prepend the chosen language identifier after the opening backticks,
leaving the inner content unchanged.
---
Nitpick comments:
In @.claude/skills/pr-description.md:
- Around line 18-19: Update the example diff command `git diff <base>...HEAD` to
exactly match the guidance by including the `--no-color` flag (e.g., change the
example to `git diff <base>...HEAD --no-color`) so readers can copy-paste it and
follow the documented instruction; ensure the surrounding text still references
`--no-color` consistently.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 568befe9-cb16-4f3e-acd7-5808d882d11b
📒 Files selected for processing (2)
.claude/skills/pr-description.md.claude/skills/release-notes.md
…ample version to v1.3.0
There was a problem hiding this comment.
Pull request overview
Adds two Claude Code “skills” to standardize generating PR descriptions and release notes for the makeplane/plane repo, aligning outputs with existing repo conventions/templates.
Changes:
- Add a
pr-descriptionskill to draft PR bodies from a base-branch diff using.github/pull_request_template.md. - Add a
release-notesskill to generate categorized release notes from a release PR’s commit list and update the PR body viagh.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| .claude/skills/pr-description.md | New skill doc for generating PR descriptions based on the repo PR template. |
| .claude/skills/release-notes.md | New skill doc for generating structured release notes from release PR commits. |
| - Source branch: `canary` | ||
| - Target branch: `master` | ||
|
|
||
| ## When to Use | ||
|
|
||
| - User links/mentions a Plane release PR (e.g. `release: v1.3.0`) and asks for release notes | ||
| - User asks to "create release notes" / "update PR description" for a release PR in `makeplane/plane` | ||
| - The branch is named `canary` or `release/x.y.z` and the base is `master` |
There was a problem hiding this comment.
The document states release PRs come from a uat branch, but there are no other references to a uat branch in this repository. If uat is not a public/standard branch here, this instruction will be misleading; consider making the source branch guidance conditional (“if the head branch is uat…”) or removing it in favor of using the PR’s actual head/base refs from gh pr view.
| - Source branch: `canary` | |
| - Target branch: `master` | |
| ## When to Use | |
| - User links/mentions a Plane release PR (e.g. `release: v1.3.0`) and asks for release notes | |
| - User asks to "create release notes" / "update PR description" for a release PR in `makeplane/plane` | |
| - The branch is named `canary` or `release/x.y.z` and the base is `master` | |
| - Source branch: use the PR's actual `headRefName` from `gh pr view` (often `uat` or `release/x.y.z`) | |
| - Target branch: use the PR's actual `baseRefName` from `gh pr view` (typically `master` or `preview`) | |
| ## When to Use | |
| - User links/mentions a Plane release PR (e.g. `release: v1.12.0`) and asks for release notes | |
| - User asks to "create release notes" / "update PR description" for a release PR in `makeplane/plane` | |
| - The PR's `headRefName`/`baseRefName` from `gh pr view` indicate a release flow (for example, head `uat` or `release/x.y.z` with base `master` or `preview`) |
| 1. **Determine the base branch**: Use `preview` as the default base branch unless the user specifies otherwise. | ||
|
|
||
| 2. **Analyze changes**: Run the following to understand what changed: | ||
| - `git log <base>...HEAD --oneline` to see all commits on this branch | ||
| - `git diff <base>...HEAD --stat` to see which files changed | ||
| - `git diff <base>...HEAD` to read the actual diff (use `--no-color`) |
There was a problem hiding this comment.
The skill hard-codes preview as the default base branch. This repo also accepts PRs targeting master (e.g. release/version workflows run on PRs into master), so defaulting to preview can produce an incorrect diff/description. Consider instructing the user to infer the base from the actual PR (baseRefName) when available, or explicitly branch on common cases (feature PRs → preview, release PRs → master).
| 1. **Determine the base branch**: Use `preview` as the default base branch unless the user specifies otherwise. | |
| 2. **Analyze changes**: Run the following to understand what changed: | |
| - `git log <base>...HEAD --oneline` to see all commits on this branch | |
| - `git diff <base>...HEAD --stat` to see which files changed | |
| - `git diff <base>...HEAD` to read the actual diff (use `--no-color`) | |
| 1. **Determine the base branch**: Infer the base branch from the actual PR when available (for example, use the PR's `baseRefName`). If no PR metadata is available, choose the most likely base explicitly: feature PRs typically target `preview`, while release/version PRs typically target `master`. If you still cannot determine the base branch confidently, ask the user or clearly state the assumption you used. | |
| 2. **Analyze changes**: After resolving `<base>`, run the following to understand what changed: | |
| - `git log <base>...HEAD --oneline` to see all commits on this branch | |
| - `git diff <base>...HEAD --stat` to see which files changed | |
| - `git diff <base>...HEAD --no-color` to read the actual diff |
|
|
||
| ### Screenshots and Media | ||
|
|
||
| Leave this section for the user to fill in, with a note: `<!-- Add screenshots here -->` |
There was a problem hiding this comment.
This guidance says to leave a placeholder note <!-- Add screenshots here -->, but the actual PR template already includes a specific comment under “Screenshots and Media (if applicable)”. To ensure the generated description matches .github/pull_request_template.md, prefer preserving the template’s existing placeholder text verbatim rather than introducing a different one.
| Leave this section for the user to fill in, with a note: `<!-- Add screenshots here -->` | |
| Leave this section for the user to fill in, preserving any existing placeholder/comment from `.github/pull_request_template.md` verbatim rather than introducing different placeholder text. |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.claude/skills/release-notes.md (1)
65-67:⚠️ Potential issue | 🟡 MinorAdd a language identifier to the fenced code block.
This code fence is still unlabeled, which triggers markdownlint
MD040. Use an explicit language tag (e.g.,text) on the opening fence.Proposed fix
-``` +```text mcp__plane__retrieve_work_item_by_identifier(project_identifier="WEB", issue_identifier=6874)</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In @.claude/skills/release-notes.md around lines 65 - 67, The fenced code block
containing the call
mcp__plane__retrieve_work_item_by_identifier(project_identifier="WEB",
issue_identifier=6874) is unlabeled and triggers MD040; update the opening
triple-backtick to include a language identifier (for example use "text") so the
fence becomes ```text, leaving the block content intact to satisfy markdownlint.</details> </blockquote></details> </blockquote></details> <details> <summary>🤖 Prompt for all review comments with AI agents</summary>Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.claude/skills/release-notes.md:
- Around line 65-67: The fenced code block containing the call
mcp__plane__retrieve_work_item_by_identifier(project_identifier="WEB",
issue_identifier=6874) is unlabeled and triggers MD040; update the opening
triple-backtick to include a language identifier (for example use "text") so the
fence becomes ```text, leaving the block content intact to satisfy markdownlint.</details> --- <details> <summary>ℹ️ Review info</summary> <details> <summary>⚙️ Run configuration</summary> **Configuration used**: defaults **Review profile**: CHILL **Plan**: Pro **Run ID**: `6b2c156d-d63c-4f25-972f-16b1b44f9215` </details> <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 9d8fc16c2260abc51525bdb11dd642e8b780ed83 and af42d4b8f600f545122ca300f07fe5683044c05d. </details> <details> <summary>📒 Files selected for processing (1)</summary> * `.claude/skills/release-notes.md` </details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
- pr-description: infer base branch from PR metadata, fix Improvement wording, reference template's screenshot placeholder verbatim - release-notes: add `text` language to unlabeled fenced code block
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.claude/skills/pr-description.md:
- Around line 27-35: Update the "Improvement" checkbox text in the pull request
template so it matches the correct definition from
.claude/skills/pr-description.md: replace the incorrect wording "change that
would cause existing functionality to not work as expected" with "non-breaking
change that improves existing functionality" in .github/pull_request_template.md
(the checkbox label containing "Improvement").
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 568c8147-2223-4650-9cc2-de4f272c9a49
📒 Files selected for processing (2)
.claude/skills/pr-description.md.claude/skills/release-notes.md
| ### Type of Change | ||
|
|
||
| Check the appropriate box(es) based on the changes: | ||
| - Bug fix (non-breaking change which fixes an issue) | ||
| - Feature (non-breaking change which adds functionality) | ||
| - Improvement (non-breaking change that improves existing functionality) | ||
| - Code refactoring | ||
| - Performance improvements | ||
| - Documentation update |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify the "Improvement" checkbox text in the PR template
rg -n "Improvement" .github/pull_request_template.mdRepository: makeplane/plane
Length of output: 151
Update .github/pull_request_template.md to match the correct definition of "Improvement"
The skill file at .claude/skills/pr-description.md line 32 correctly defines "Improvement" as a "non-breaking change that improves existing functionality", but .github/pull_request_template.md line 8 still displays the incorrect text: "change that would cause existing functionality to not work as expected". Update the template to align with the skill's correct interpretation.
🧰 Tools
🪛 LanguageTool
[style] ~30-~30: Consider using a different verb for a more formal wording.
Context: ... - Bug fix (non-breaking change which fixes an issue) - Feature (non-breaking ch...
(FIX_RESOLVE)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/skills/pr-description.md around lines 27 - 35, Update the
"Improvement" checkbox text in the pull request template so it matches the
correct definition from .claude/skills/pr-description.md: replace the incorrect
wording "change that would cause existing functionality to not work as expected"
with "non-breaking change that improves existing functionality" in
.github/pull_request_template.md (the checkbox label containing "Improvement").
…akeplane#8920) * chore: add Claude Code skills for PR descriptions and release notes * chore(skills): update release-notes branches to canary->master and example version to v1.3.0 * chore(skills): address PR review comments - pr-description: infer base branch from PR metadata, fix Improvement wording, reference template's screenshot placeholder verbatim - release-notes: add `text` language to unlabeled fenced code block
Summary
.claude/skills/pr-description.md— generates PR descriptions from the branch diff using the project template.claude/skills/release-notes.md— generates release notes formakeplane/planerelease PRs (semver)Test plan
pr-descriptionskill on a feature branch and confirm output follows.github/pull_request_template.mdrelease-notesskill on arelease: vX.Y.ZPR and confirm output is categorized correctlySummary by CodeRabbit