Agent skill
creating-pr
Use when asked to create a pull request, open a PR, or submit changes for review. Handles branch verification, change analysis, title and description generation, and gh pr create. Do NOT use for committing (use git-commit), pushing without PR, or reviewing existing PRs.
Install this agent skill to your Project
npx add-skill https://github.com/sortie-ai/sortie/tree/main/.github/skills/creating-pr
Metadata
Additional technical details for this skill
- version
- 1775952000
SKILL.md
Creating a Pull Request
Workflow
Step 1: Verify branch state
CURRENT=$(git branch --show-current)
DEFAULT=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')
- If
$CURRENTequals$DEFAULTor isdevelop/release/*/hotfix/*: inform user they are on a protected branch, cannot create PR from here - If uncommitted changes exist: commit first (use git-commit skill)
- If branch not pushed:
git push -u origin $CURRENT
Step 2: Analyze changes
DEFAULT=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')
git log --format="%s%n%b" "$DEFAULT..HEAD"
git diff --name-only "$DEFAULT..HEAD"
git diff --stat "$DEFAULT..HEAD"
From the diff and commits, identify:
- Type: primary change type (feat, fix, refactor, chore, perf)
- Intent: business/technical goal (1-2 sentences)
- Entry point: most critical changed file for reviewer
- Sensitive areas: files needing extra scrutiny (auth, payments, data)
- Breaking changes:
!in commits or BREAKING CHANGE footer - Migrations: database or schema changes
Step 3: Generate title
Conventional Commits format: <type>[scope]: <description>
- Imperative mood, under 72 chars, no period, English only
- Match the project's commit style (check
git log --format="%s" -20)
Step 4: Generate description
Use the template from assets/pull_request_template.md. Three sections:
- Scope & Context — Type, Intent, Related Issues
- Reviewer Guide — Complexity (Low/Medium/High), Entry Point, Sensitive Areas
- Risk Assessment — Breaking Changes, Migrations/State
Formatting rules:
- No fluff intros ("This PR updates...")
- Filenames in backticks: `path/to/file.ts`
- Use " - " (hyphen), not "—" (em-dash)
- All sections required, sub-sections only when relevant data exists
Do not reference docs/architecture.md, docs/decisions/, section numbers,
or ADR numbers in pull request descriptions. Those belong in specs and
plans, not in the git history.
Complexity guide:
| Level | Criteria |
|---|---|
| Low | Single file, config, docs, simple fix |
| Medium | Multiple related files, new feature with tests |
| High | Cross-cutting, migrations, breaking changes, security |
Step 5: Create PR
DEFAULT=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')
gh pr create \
--title '<title>' \
--body '<description>' \
--base "$DEFAULT"
For drafts, add --draft.
MANDATORY: Use single quotes for --body to avoid shell interpolation. NEVER use double quotes, which can cause variables or special characters in the description to be misinterpreted by the shell.
Step 6: Verify
gh pr view --web
Report: PR number, URL, title, base/head branches.
Error Recovery
| Error | Fix |
|---|---|
| "pull request already exists" | gh pr view to see existing |
| "no commits between" | Verify branch has commits ahead of base |
| Auth failure | gh auth login --web |
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
managing-adrs
Create, update, and validate Architecture Decision Records (ADRs) following MADR 4.0 format. Use when the user mentions ADR, architecture decision, decision record, or asks to document a technical decision. Also use when creating new files in docs/decisions/. Handles numbering, frontmatter, section structure, and README index updates. Do NOT use for general documentation or non-architectural decisions.
context-files
Create or validate project context files (AGENTS.md, CLAUDE.md, GEMINI.md). Use when bootstrapping a new project, initializing agent configuration, writing a context file, or when asked to create, review, audit, or validate an existing context file. Handles codebase archaeology, user interviews, golden-rule validation, and platform-specific formatting. Do NOT use for creating Agent Skills (use creating-agent-skills instead) or .instructions.md files (use agent-customization instead).
jira-syntax
Use when writing Jira issue descriptions, comments, or work logs. Also use when converting Markdown to Jira wiki markup, when the user says "format for Jira", "Jira markup", "wiki notation", or asks to create, update, or validate Jira ticket content. Handles bug report and feature request templates. Do NOT use for Jira API operations, JQL queries, or workflow transitions.
creating-agent-skills
Use when creating, improving, comparing, evaluating or packaging Agent Skills following the agentskills.io specification. Also use when deciding whether a skill is the right solution vs MCP servers, custom instructions, AGENTS.md, or Cursor Rules. Handles SKILL.md authoring, frontmatter optimization, description writing, progressive disclosure, cross-platform compatibility, and distribution.
git-commit
Use when asked to commit, save, or persist changes to Git. Handles atomic commits, branch safety, Conventional Commits format, and project style matching. Do NOT use for pushing, creating PRs, or branch management beyond safety checks.
diataxis-documentation
Create, edit, and validate technical documentation using the Diataxis framework. Use when writing tutorials, how-to guides, reference docs, or explanations. Use when reviewing or auditing existing documentation for structural correctness. Use when deciding what type of document to write. Also use when the user mentions Diataxis, documentation quality, documentation types, or asks to write 'deep dive' articles, onboarding guides, API docs, or architectural explanations. Do NOT use for code comments, commit messages, changelogs, or README generation.
Didn't find tool you were looking for?