create-pr
Creates pull requests with bilingual documentation checks. Use when user asks to create PR, make a pull request, or submit changes for review. Ensures English and Chinese README files stay in sync when user-facing skill catalog changes require it.
Works with
Claude CodeCursorCodex CLIGitHub CopilotGemini CLI
--- name: create-pr description: Creates pull requests with bilingual documentation checks. Use when user asks to create PR, make a pull request, or submit changes for review. Ensures English and Chinese README files stay in sync when user-facing skill catalog changes require it. license: MIT --- # Create PR A skill for creating pull requests with bilingual documentation checks. This skill ensures that English and Chinese documentation stay in sync before code changes are submitted. ## When This Skill Activates This skill activates when you: - Ask to create a pull request or PR - Say "submit my changes" or "push and create PR" - Mention "make a PR" or "open a pull request" - Want to submit code for review ## PR Creation Workflow ### Step 1: Analyze Changes Examine all changes in the current branch: ```bash git status git diff git log --oneline main..HEAD ``` Identify: - **Modified files**: What was changed? - **New files**: What was added? - **Deleted files**: What was removed? - **Impact area**: Which skills or features are affected? ### Step 2: Determine Documentation Updates ### Check for Skill Changes First, detect if any skills were changed: ```bash # Check if skills/ directory has changes git diff --name-only main..HEAD | grep "^skills/" ``` ### Decision Matrix | Change Type | Documentation Action | |-------------|---------------------| | New skill added | Add to skills table in both EN and CN README | | Skill description changed | Update description in skills table | | Skill removed | Remove from skills table | | Skill hooks changed | Update Auto-Trigger column in skills table | | Internal skill logic only | Skip README update | | Bug fix with no user impact | Skip README update | ### Auto-Trigger Changes Require Update If a skill's `metadata.hooks` front matter was modified, the **Auto-Trigger** column in the Skills Catalog must be updated: ```bash # Check if hooks were modified git diff main..HEAD -- skills/*/SKILL.md | grep -E "^\+.*metadata:|^\+.*hooks:|^\+.*trigger:" ``` If hooks changed → Update README.md and README.zh-CN.md Auto-Trigger column. ### Step 3: Draft Commit Message Use the `commit-helper` format: ``` <type>(<scope>): <subject> <body> <footer> ``` Types: - `feat`: New skill or feature - `fix`: Bug fix or correction - `docs`: Documentation only changes - `refactor`: Code refactoring - `chore`: Maintenance tasks ### Step 4: Create the Pull Request Run the following sequence: ```bash # 1. Stage only the intended files git add <changed-files> git commit -m "commit message" # 2. Push to remote git push -u origin <branch-name> # 3: Create PR using gh CLI gh pr create \ --title "PR title" \ --body "PR description" ``` ### Step 5: Update Documentation (If Required) Before committing or creating the PR, update both README files when the change affects user-facing skill catalog, installation, or workflow behavior: **README.md** (English): - Add new skills to appropriate category table - Update project structure if needed - Keep language switch link at top **README.zh-CN.md** (Chinese): - Mirror all English changes - Translate skill descriptions - Maintain same structure and formatting ### Step 6: Update Changelog (Optional) For significant changes, add to CHANGELOG.md: ```markdown ## [Version] - YYYY-MM-DD ### Added - New skill: skill-name ### Fixed - Fixed issue in skill-name ### Changed - Updated skill-name with new features ``` ## Documentation Update Guidelines ### Skills Catalog Update Template When adding or modifying skills, use this format for the Skills Catalog: **English (README.md):** ```markdown ### Category Name | Skill | Description | Follow-up | |-------|-------------|--------------| | **[skill-name](./skills/skill-name/)** | Brief description | Manual / Auto / Background / (keyword: "...") | ``` **Chinese (README.zh-CN.md):** ```markdown ### 类别名称 | 技能 | 描述 | 后续动作 | |------|------|----------| | **[skill-name](./skills/skill-name/)** | 简短描述 | 手动 / 自动 / 后台 / (关键词："...") | ``` ### Auto-Trigger Column Values | Value | Meaning | Example | |-------|---------|---------| | `Manual` | User must invoke | Most development skills | | `Auto` | Triggers automatically after any skill | session-logger | | `Background` | Runs non-blocking after related skill | self-improving-agent | | `After skill updates` | Only triggers when skills are modified | create-pr | | `(keyword: "...")` | Activates on specific keyword | prd-planner (keyword: "PRD") | ### When to Update README **Always update when:** - Adding a new skill - Removing a skill - Changing skill names or descriptions - Restructuring the skills directory **Consider updating when:** - Adding significant features to existing skills - Changing installation instructions - Modifying project structure **Skip updating when:** - Internal code refactoring with no user impact - Minor typo fixes - Test file changes ### Bilingual Update Format When adding a new skill to the skills table: **English (README.md):** ```markdown | **[skill-name](./skills/skill-name/)** | Brief skill description | ``` **Chinese (README.zh-CN.md):** ```markdown | **[skill-name](./skills/skill-name/)** | 技能简短描述 | ``` ### Language Switch Link Both README files must have the language switch at the top: **README.md:** ```markdown English | [简体中文](./README.zh-CN.md) ``` **README.zh-CN.md:** ```markdown [English](./README.md) | 简体中文 ``` ## PR Description Template When creating a PR, use this template: ```markdown ## Summary <Brief description of what this PR does> ## Changes - [ ] New skill added - [ ] Existing skill modified - [ ] Documentation updated - [ ] Tests added/updated ## Skills Affected - `skill-name`: Description of change ## Documentation - [x] README.md updated - [x] README.zh-CN.md updated - [ ] CHANGELOG.md updated (if applicable) ## Test Plan - [ ] Skill tested in Claude Code - [ ] Documentation links verified - [ ] Bilingual translations checked ``` ## Common Scenarios ### Scenario 1: Adding a New Skill ```bash # 1. Create skill files mkdir -p skills/new-skill touch skills/new-skill/SKILL.md touch skills/new-skill/README.md # 2. Install or link through the package CLI when possible apb skills add ./skills/new-skill --scope project --target all --link # 3. Update README.md (add to skills table) # 4. Update README.zh-CN.md (add to skills table with translation) # 5. Commit and push git add skills/new-skill/ README.md README.zh-CN.md git commit -m "feat: add new-skill for ..." git push -u origin feature/add-new-skill # 6. Create PR gh pr create --title "feat: add new-skill" --body "..." ``` ### Scenario 2: Modifying an Existing Skill ```bash # 1. Make changes to skill vim skills/existing-skill/SKILL.md # 2. Check if description changed git diff skills/existing-skill/SKILL.md # 3. If description changed, update README files # 4. Commit, push, create PR ``` ### Scenario 3: Bug Fix Only ```bash # 1. Fix the bug vim skills/some-skill/SKILL.md # 2. Commit and push (no README update needed) git add skills/some-skill/SKILL.md git commit -m "fix: correct typo in some-skill" git push # 3. Create PR gh pr create --title "fix: correct typo in some-skill" ``` ## Verification Checklist Before creating the PR, verify: - [ ] All changes are committed - [ ] Branch is pushed to remote - [ ] Commit messages follow Conventional Commits - [ ] README.md is updated if needed - [ ] README.zh-CN.md is updated if needed - [ ] Language switch links are present in both READMEs - [ ] New skills have symlinks created - [ ] PR title is clear and descriptive - [ ] PR description includes summary and changes ## Quick Reference | Command | Purpose | |---------|---------| | `git status` | Check current state | | `git diff` | See unstaged changes | | `git log main..HEAD` | See branch commits | | `git add <changed-files>` | Stage only intended files | | `git commit -m "msg"` | Commit with message | | `git push -u origin branch` | Push to remote | | `gh pr create` | Create pull request | ## Tips 1. **Commit first, PR later**: Always commit changes before creating PR 2. **Small PRs**: Keep PRs focused on a single change 3. **Clear titles**: Use Conventional Commits in PR titles 4. **Bilingual sync**: Always update both README files together 5. **Test skills**: Verify skills work before submitting PR
More Code Review skills
pr-to-video
heygen-com/hyperframes
Turn a GitHub pull request (a PR URL, owner/repo#N, or 'this PR' in a checked-out repo) into a code-change explainer video — changelog, feature reveal, fix, or refactor walkthrough built from the diff, commits, and files: the input is a code change, not a website. Not a product promo (/product-launch-video) or a no-PR topic explainer (/faceless-explainer). Unclear → /hyperframes.
178.9k
receiving-code-review
obra/superpowers
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
178.0k
public-relations
coreyhaines31/marketingskills
When the user wants help with public relations, earned media, press coverage, journalist outreach, or media strategy (not pull requests). Also use when the user mentions 'PR,' 'public relations,' 'press,' 'press release,' 'press coverage,' 'media outreach,' 'pitch a journalist,' 'get featured,' 'media list,' 'media kit,' 'press kit,' 'newsjacking,' 'news hijack,' 'HARO,' 'Qwoted,' 'Featured,' 'Help A Reporter,' 'reporter request,' 'tech press,' 'TechCrunch,' 'earned media,' 'thought leadership placement,' 'op-ed,' 'guest article,' 'press contacts,' 'podcast prep,' 'going on a podcast,' 'podcast guest,' 'prep me for this podcast,' or 'how do I get press.' Use this for earned media work — finding journalists, pitching stories, newsjacking, prepping podcast appearances, and responding to press requests. For startup/SaaS/AI directory submissions, see directory-submissions. For product launches, see launch. For social-media engagement, see social. For cold-email outreach to prospects, see cold-email.
33.1k
