Positron Pr Helper
- 54 installs
- 4.2k repo stars
- Updated August 5, 2026
- posit-dev/positron
positron-pr-helper is a Claude Code skill for ai & agent building.
About
positron-pr-helper is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted coding.
- positron-pr-helper
- AI & Agent Building
- AI-coding skill
Positron Pr Helper by the numbers
- 54 all-time installs (skills.sh)
- +1 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #6,877 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/posit-dev/positron --skill positron-pr-helperAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 54 |
|---|---|
| repo stars | ★ 4.2k |
| Last updated | August 5, 2026 |
| Repository | posit-dev/positron ↗ |
How do I helps with ai & agent building tasks during AI-assisted development.?
Helps with ai & agent building tasks during AI-assisted development.
Who is it for?
Best when you're working on ai & agent building and need structured help with positron pr helper.
Skip if: Teams with no ai & agent building needs, or anyone wanting a generic chat assistant without this specific workflow.
When should I use this skill?
When you need to helps with ai & agent building tasks during AI-assisted development., or when positron-pr-helper is a claude code skill for ai & agent building.
What you get
Structured output aligned to positron-pr-helper: positron-pr-helper, AI & Agent Building.
Files
Positron PR Helper
This skill helps you create comprehensive PR bodies for the posit-dev/positron repository with up-to-date e2e test tags fetched directly from the source of truth.
When to Use This Skill
Use this skill when:
- Creating a new PR and need a well-structured body
- Updating an existing PR body with the correct format
- You need the current list of e2e test tags for validation steps
- You want to ensure your PR body follows Positron conventions
Prerequisites
- GitHub CLI (
gh) installed and authenticated - Working in the Positron repository
- Access to the repository's test-tags.ts file
Workflow
I'll guide you through creating a comprehensive PR body:
Step 1: Gather Context
First, I'll ask you: 1. Issue number (if this PR addresses a specific issue) 2. PR type (bug fix, feature, UI change, maintenance, etc.) 3. Summary of what the PR does 4. Screenshots needed? (for UI changes) 5. Related PRs (e.g., in ark repository)
If you provide an issue number, I'll use gh issue view to fetch details and understand the context better.
Step 2: Fetch Current Test Tags
I'll dynamically fetch the current e2e test tags from test/e2e/infra/test-runner/test-tags.ts using our extraction script. This ensures we always have the complete, up-to-date list of tags including:
- Feature tags (functionality-specific)
- Platform tags (OS/environment control)
- Performance tags
- Special tags (critical, soft-fail)
Step 3: Generate PR Body
Based on the PR type and context, I'll create a structured PR body with:
1. Opening Line
- "Fixes #[issue]" if applicable, using a GitHub closing keyword (
Fixes,Closes,Resolves) so the issue auto-closes when the PR is merged - Brief statement of what the PR does otherwise
2. Description/Summary
- Concise explanation of changes
- Technical context if needed
- Related PRs referenced
3. Screenshots (for UI changes only)
- Placeholder text or actual URLs if provided
4. Release Notes
- New Features (if applicable)
- Bug Fixes (if applicable)
- User-facing descriptions
5. Validation Steps
- Relevant e2e test tags based on affected areas
- Testing instructions
- Code examples if helpful
Step 4: Output Options
Once the PR body is ready, you can choose: 1. Copy to clipboard (Mac only) - I'll use pbcopy 2. Update existing PR - I'll use gh pr edit 3. Save to file - I'll write to a file of your choice 4. Display only - I'll show it for manual copying
Helper Scripts
fetch-test-tags.sh
This script extracts and categorizes all test tags from the TypeScript enum:
# Usage:
./scripts/fetch-test-tags.sh [format]
# format: markdown (default), json, or listThe script:
- Parses
test-tags.tswithout needing TypeScript compilation - Categorizes tags automatically (feature, platform, performance, special)
- Outputs in multiple formats for different use cases
- Runs quickly (<1 second)
PR Body Templates
I use different templates based on PR type:
Bug Fix Template
Fixes #[issue]
[2-3 sentences explaining the fix]
### Release Notes
#### New Features
- N/A
#### Bug Fixes
- [User-facing description] (#[issue])
### Validation Steps
[relevant tags]
[Simple test instructions]New Feature Template
Fixes #[issue]
### Summary
[1-2 paragraphs explaining the feature]
[Technical implementation notes if relevant]
[Related PRs if applicable]
### Release Notes
#### New Features
- [User-facing description] (#[issue])
#### Bug Fixes
- N/A
### Validation Steps
[relevant tags]
[Detailed test steps with code examples]Examples
Example 1: Bug Fix PR
Fixes #8930
This PR fixes the Data Explorer scrollbars snapping back to 0 on Safari. The issue was caused by incorrect event handling in the virtual scrolling implementation.
### Release Notes
#### New Features
- N/A
#### Bug Fixes
- Fix Data Explorer scrollbars snapping back to 0 on Safari (#8930)
### Validation Steps
@:data-explorer
Open a large data frame in Data Explorer on Safari and verify scrollbars can be dragged without snapping back.Example 2: New Feature PR
Fixes #8484
### Summary
Adds support for native DuckDB connections in the Connections Pane. Users can now inspect DuckDB databases directly without needing external tools. This implementation uses the native DuckDB Python API for better performance.
Related PR: posit-dev/ark#456 (adds DuckDB kernel support)
### Release Notes
#### New Features
- Added support for inspecting native DuckDB connections in the Connections Pane (#8484)
#### Bug Fixes
- N/A
### Validation Steps
@:connections @:duck-db
1. Install DuckDB: `pip install duckdb`
2. Create a new DuckDB connection using the modal
3. Run the following to create test data:
conn.execute(""" CREATE TABLE employees ( id INTEGER, name VARCHAR, salary INTEGER ) """) conn.execute("INSERT INTO employees VALUES (1, 'Alice', 75000)")
4. Verify tables appear in the Connections paneTips
- Be concise but complete - no flowery language
- Use present tense ("fixes", "adds", "enables")
- Include issue references in parentheses in release notes
- Always include at least one e2e test tag in validation steps
- For complex changes, numbered test steps are better
- Keep release notes user-facing (avoid implementation details)
PR Body Templates Reference
This document contains templates and examples for different types of PRs in the Positron repository.
Template Components
Opening Line Patterns
With Issue:
Fixes #[issue_number]Use a GitHub closing keyword (Fixes, Closes, Resolves) so the issue auto-closes when the PR is merged.
Without Issue:
[Brief statement of what the PR does].Multiple Issues:
Fixes #[issue1], fixes #[issue2], and fixes #[issue3]Each issue needs its own closing keyword for GitHub to link and close all of them.
Description Patterns
Simple (2-3 sentences):
This PR [what it does]. The [root cause/reason]. [Any important implementation detail].Complex (with header):
### Summary
[Paragraph explaining the changes]
[Technical context paragraph if needed]
Related PRs:
- posit-dev/ark#[number] - [description]
- posit-dev/positron-python#[number] - [description]PR Type Templates
1. Bug Fix
Fixes #[issue]
This PR fixes [the problem]. The issue was caused by [root cause]. [Implementation approach if non-obvious].
### Release Notes
#### New Features
- N/A
#### Bug Fixes
- [User-facing description of fix] (#[issue])
### Validation Steps
[relevant tags]
[Simple reproduction steps and verification]2. New Feature
Fixes #[issue]
### Summary
This PR adds [feature description]. Users can now [what they can do].
[Technical implementation paragraph]
[Related PRs if any]
### Release Notes
#### New Features
- [User-facing feature description] (#[issue])
#### Bug Fixes
- N/A
### Validation Steps
[relevant tags]
[Numbered steps for testing]:
1. [Setup step]
2. [Action step]
3. [Verification step]
[Code example if helpful]
3. UI/UX Change
Fixes #[issue]
This PR [describes the UI change]. The change improves [what it improves].
[Screenshot: Description of what the screenshot shows]
### Release Notes
#### New Features
- [User-visible UI change] (#[issue])
#### Bug Fixes
- N/A
### Validation Steps
[relevant tags including UI-specific ones]
1. [Navigate to the UI element]
2. [Perform the action]
3. [Verify the new behavior]4. Performance Improvement
Fixes #[issue]
### Summary
This PR optimizes [what was optimized]. Performance improves by [metrics/percentage] for [use case].
**Before:** [performance characteristic]
**After:** [improved characteristic]
### Release Notes
#### New Features
- N/A
#### Bug Fixes
- N/A
#### Performance
- [User-facing performance improvement] (#[issue])
### Validation Steps
@:performance [other relevant tags]
[Steps to verify performance improvement]5. Maintenance/Refactoring
[Brief description of maintenance work].
### Summary
This PR [refactoring description]. No user-facing changes.
[Technical justification]
### Release Notes
#### New Features
- N/A
#### Bug Fixes
- N/A
### Validation Steps
[relevant tags]
Verify existing functionality still works:
1. [Test area 1]
2. [Test area 2]6. E2E Test Addition
Adds e2e tests for [feature/area].
This PR adds comprehensive test coverage for [what's being tested]. The tests verify [key behaviors].
### Validation Steps
[tags for the areas being tested]
Run the new tests:npx playwright test [test-file-name] --project e2e-electron
Release Notes Guidelines
Good Examples
Features:
- ✅ "Added support for Python 3.12 virtual environments"
- ✅ "Jupyter notebooks now support collapsible cell outputs"
- ✅ "New keyboard shortcut <kbd>Cmd+Shift+P</kbd> opens command palette"
Bug Fixes:
- ✅ "Fixed Data Explorer scrolling on Safari"
- ✅ "Resolved console output truncation for long lines"
- ✅ "Connections pane now correctly displays schema names with spaces"
Bad Examples
Too Technical:
- ❌ "Refactored AbstractKernelManager to use dependency injection"
- ❌ "Fixed race condition in async state machine"
Too Vague:
- ❌ "Improved performance"
- ❌ "Fixed various bugs"
- ❌ "Updated UI"
Validation Steps Best Practices
Tag Selection
Choose tags based on the primary area affected:
- Use feature tags for functionality changes
- Add platform tags if platform-specific testing needed
- Include
@:criticalonly for critical path features - Don't over-tag - focus on primary areas
Testing Instructions
Simple Fix:
@:console
Run any Python code in the console and verify output appears correctly.Complex Feature:
@:connections @:duck-db
1. Install DuckDB: `pip install duckdb`
2. Create connection via File > New Connection > DuckDB
3. Select "In-memory database" option
4. Run the test script:
import duckdb conn = duckdb.connect() conn.execute("CREATE TABLE test (id INT, name VARCHAR)") conn.execute("INSERT INTO test VALUES (1, 'test')")
5. Verify table appears in Connections pane
6. Double-click table to preview dataCommon Patterns
Paired PRs
When PRs depend on changes in other repos:
Related PRs (merge in order):
1. posit-dev/ark#123 - Kernel support (merge first)
2. This PR - UI integration
3. posit-dev/positron-python#456 - Language server support (optional)Breaking Changes
Include migration notes:
### ⚠️ Breaking Changes
This PR changes [what changes]. Users will need to [migration steps].
**Before:** `old_api_call()`
**After:** `new_api_call(param)`Documentation Updates
Reference documentation PRs:
Documentation: posit-dev/positron-docs#789Style Guidelines
Language
- Present tense for descriptions: "Fixes", "Adds", "Enables"
- Active voice: "This PR fixes..." not "The bug is fixed by..."
- Concise: Remove unnecessary words
- User-facing: Focus on impact, not implementation
Formatting
- Use
backticksfor code, commands, file names - Use bold for emphasis sparingly
- Use
<kbd>tags for keyboard shortcuts - Link issues with
#[number]format - Use code blocks with language hints
What to Avoid
- 🚫 Flowery language or unnecessary context
- 🚫 Implementation details in release notes
- 🚫 Apologizing or self-deprecation
- 🚫 Commit message lists (PR body should summarize)
- 🚫 TODO items (these belong in issues)
- 🚫 Questions (resolve before creating PR)
#!/bin/bash
# Script to extract e2e test tags from test-tags.ts
# Parses the TypeScript enum and outputs categorized tags
set -e
# Navigate to repository root
REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || echo ".")"
TAGS_FILE="$REPO_ROOT/test/e2e/infra/test-runner/test-tags.ts"
# Check if file exists
if [ ! -f "$TAGS_FILE" ]; then
echo "Error: test-tags.ts not found at $TAGS_FILE" >&2
exit 1
fi
# Parse command line arguments
OUTPUT_FORMAT="${1:-markdown}" # markdown (default), json, or list
# Function to extract all tags
extract_all_tags() {
grep -E "^\s*[A-Z_]+\s*=\s*'@:" "$TAGS_FILE" | \
sed -E "s/^[[:space:]]*[A-Z_]+[[:space:]]*=[[:space:]]*'(@:[^']+)'.*/\1/" | \
sort
}
# Function to categorize tags based on their names
categorize_tags() {
local tag="$1"
# Platform tags
if [[ "$tag" == "@:web" ]] || [[ "$tag" == "@:web-only" ]] || [[ "$tag" == "@:win" ]] || \
[[ "$tag" == "@:workbench" ]] || [[ "$tag" == "@:rhel-electron" ]] || \
[[ "$tag" == "@:rhel-web" ]] || [[ "$tag" == "@:remote-ssh" ]]; then
echo "platform"
# Performance tags
elif [[ "$tag" == "@:performance" ]]; then
echo "performance"
# Special tags
elif [[ "$tag" == "@:soft-fail" ]] || [[ "$tag" == "@:critical" ]]; then
echo "special"
# Everything else is a feature tag
else
echo "feature"
fi
}
# Function to output in markdown format
output_markdown() {
echo "## Available E2E Test Tags"
echo ""
# Temporary files to store categorized tags
local feature_tags=$(mktemp)
local performance_tags=$(mktemp)
local platform_tags=$(mktemp)
local special_tags=$(mktemp)
# Categorize all tags
while IFS= read -r tag; do
category=$(categorize_tags "$tag")
case "$category" in
feature)
echo "$tag" >> "$feature_tags"
;;
performance)
echo "$tag" >> "$performance_tags"
;;
platform)
echo "$tag" >> "$platform_tags"
;;
special)
echo "$tag" >> "$special_tags"
;;
esac
done < <(extract_all_tags)
echo "### Feature Tags"
echo "Tags for specific functionality areas:"
echo '```'
cat "$feature_tags"
echo '```'
echo ""
echo "### Performance Tags"
echo "Tags for performance testing:"
echo '```'
cat "$performance_tags"
echo '```'
echo ""
echo "### Platform Tags"
echo "Tags for controlling which platforms run tests:"
echo '```'
cat "$platform_tags"
echo '```'
echo ""
echo "### Special Tags"
echo "Tags with special behavior:"
echo '```'
cat "$special_tags"
echo '```'
echo ""
echo "**Notes:**"
echo "- PRs run Linux/Electron tests by default"
echo "- Add platform tags to enable additional platforms"
echo "- \`@:critical\` tag always runs on all PRs"
echo "- \`@:soft-fail\` tests won't fail merge to main"
# Clean up temp files
rm -f "$feature_tags" "$performance_tags" "$platform_tags" "$special_tags"
}
# Function to output in JSON format
output_json() {
# Arrays to store categorized tags
declare -a feature_array
declare -a performance_array
declare -a platform_array
declare -a special_array
# Categorize all tags
while IFS= read -r tag; do
category=$(categorize_tags "$tag")
case "$category" in
feature)
feature_array+=("\"$tag\"")
;;
performance)
performance_array+=("\"$tag\"")
;;
platform)
platform_array+=("\"$tag\"")
;;
special)
special_array+=("\"$tag\"")
;;
esac
done < <(extract_all_tags)
echo "{"
echo ' "feature": ['
IFS=$','; echo " ${feature_array[*]}"
echo ' ],'
echo ' "performance": ['
IFS=$','; echo " ${performance_array[*]}"
echo ' ],'
echo ' "platform": ['
IFS=$','; echo " ${platform_array[*]}"
echo ' ],'
echo ' "special": ['
IFS=$','; echo " ${special_array[*]}"
echo ' ]'
echo "}"
}
# Function to output simple list
output_list() {
extract_all_tags
}
# Main execution
case "$OUTPUT_FORMAT" in
markdown|md)
output_markdown
;;
json)
output_json
;;
list)
output_list
;;
*)
echo "Error: Unknown format '$OUTPUT_FORMAT'. Use 'markdown', 'json', or 'list'" >&2
exit 1
;;
esacRelated skills
Setup Matt Pocock SkillsScaffold the per-repo configuration that Matt Pocock’s engineering agent skills rely on so they understand the issue tracker, triage labels, and domain documentation la495k196k
Lark AppsConnect Claude, Cursor or custom agents directly to Lark (Feishu) for messaging, document automation, approval workflows and enterprise data access.402k
CavemanSlash token usage by roughly 75% while keeping every technical detail intact when working with Claude Code, Cursor or similar agents.391k94.7k
Lark Skill MakerQuickly turn any Lark/Feishu OpenAPI call or multi-step workflow into a reusable agent skill with its own SKILL.md.386k16k
Running Claude Code Via Litellm CopilotRun Claude Code at a fraction of the cost by routing requests through LiteLLM to the GitHub Copilot Chat API.270k72
Codex PetGenerate a complete Codex Pet spritesheet and metadata from one reference image without needing an OpenAI key or Codex Pro.246k10FAQ
What does positron-pr-helper do?
positron-pr-helper is a Claude Code skill for ai & agent building.
When should I use positron-pr-helper?
When you need to helps with ai & agent building tasks during AI-assisted development., or when positron-pr-helper is a claude code skill for ai & agent building.
What are the main capabilities?
positron-pr-helper; AI & Agent Building; AI-coding skill.
AI & Agent Buildingagents