branch-pr
PR creation workflow for Agent Teams Lite following the issue-first enforcement system. Trigger: When creating a pull request, opening a PR, or preparing changes for review.
Best use case
branch-pr is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
PR creation workflow for Agent Teams Lite following the issue-first enforcement system. Trigger: When creating a pull request, opening a PR, or preparing changes for review.
Teams using branch-pr should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/branch-pr/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How branch-pr Compares
| Feature / Agent | branch-pr | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
PR creation workflow for Agent Teams Lite following the issue-first enforcement system. Trigger: When creating a pull request, opening a PR, or preparing changes for review.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
Best AI Skills for Claude
Explore the best AI skills for Claude and Claude Code across coding, research, workflow automation, documentation, and agent operations.
Cursor vs Codex for AI Workflows
Compare Cursor and Codex for AI coding workflows, repository assistance, debugging, refactoring, and reusable developer skills.
SKILL.md Source
## When to Use Use this skill when: - Creating a pull request for any change - Preparing a branch for submission - Helping a contributor open a PR --- ## Critical Rules 1. **Every PR MUST link an approved issue** — no exceptions 2. **Every PR MUST have exactly one `type:*` label** 3. **Automated checks must pass** before merge is possible 4. **Blank PRs without issue linkage will be blocked** by GitHub Actions --- ## Workflow ``` 1. Verify issue has `status:approved` label 2. Create branch: type/description (see Branch Naming below) 3. Implement changes with conventional commits 4. Run shellcheck on modified scripts 5. Open PR using the template 6. Add exactly one type:* label 7. Wait for automated checks to pass ``` --- ## Branch Naming Branch names MUST match this regex: ``` ^(feat|fix|chore|docs|style|refactor|perf|test|build|ci|revert)\/[a-z0-9._-]+$ ``` **Format:** `type/description` — lowercase, no spaces, only `a-z0-9._-` in description. | Type | Branch pattern | Example | |------|---------------|---------| | Feature | `feat/<description>` | `feat/user-login` | | Bug fix | `fix/<description>` | `fix/zsh-glob-error` | | Chore | `chore/<description>` | `chore/update-ci-actions` | | Docs | `docs/<description>` | `docs/installation-guide` | | Style | `style/<description>` | `style/format-scripts` | | Refactor | `refactor/<description>` | `refactor/extract-shared-logic` | | Performance | `perf/<description>` | `perf/reduce-startup-time` | | Test | `test/<description>` | `test/add-setup-coverage` | | Build | `build/<description>` | `build/update-shellcheck` | | CI | `ci/<description>` | `ci/add-branch-validation` | | Revert | `revert/<description>` | `revert/broken-setup-change` | --- ## PR Body Format The PR template is at `.github/PULL_REQUEST_TEMPLATE.md`. Every PR body MUST contain: ### 1. Linked Issue (REQUIRED) ```markdown Closes #<issue-number> ``` Valid keywords: `Closes #N`, `Fixes #N`, `Resolves #N` (case insensitive). The linked issue MUST have the `status:approved` label. ### 2. PR Type (REQUIRED) Check exactly ONE in the template and add the matching label: | Checkbox | Label to add | |----------|-------------| | Bug fix | `type:bug` | | New feature | `type:feature` | | Documentation only | `type:docs` | | Code refactoring | `type:refactor` | | Maintenance/tooling | `type:chore` | | Breaking change | `type:breaking-change` | ### 3. Summary 1-3 bullet points of what the PR does. ### 4. Changes Table ```markdown | File | Change | |------|--------| | `path/to/file` | What changed | ``` ### 5. Test Plan ```markdown - [x] Scripts run without errors: `shellcheck scripts/*.sh` - [x] Manually tested the affected functionality - [x] Skills load correctly in target agent ``` ### 6. Contributor Checklist All boxes must be checked: - Linked an approved issue - Added exactly one `type:*` label - Ran shellcheck on modified scripts - Skills tested in at least one agent - Docs updated if behavior changed - Conventional commit format - No `Co-Authored-By` trailers --- ## Automated Checks (all must pass) | Check | Job name | What it verifies | |-------|----------|-----------------| | PR Validation | `Check Issue Reference` | Body contains `Closes/Fixes/Resolves #N` | | PR Validation | `Check Issue Has status:approved` | Linked issue has `status:approved` | | PR Validation | `Check PR Has type:* Label` | PR has exactly one `type:*` label | | CI | `Shellcheck` | Shell scripts pass `shellcheck` | --- ## Conventional Commits Commit messages MUST match this regex: ``` ^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(\([a-z0-9\._-]+\))?!?: .+ ``` **Format:** `type(scope): description` or `type: description` - `type` — required, one of: `build`, `chore`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `revert`, `style`, `test` - `(scope)` — optional, lowercase with `a-z0-9._-` - `!` — optional, indicates breaking change - `description` — required, starts after `: ` Type-to-label mapping: | Commit type | PR label | |-------------|----------| | `feat` | `type:feature` | | `fix` | `type:bug` | | `docs` | `type:docs` | | `refactor` | `type:refactor` | | `chore` | `type:chore` | | `style` | `type:chore` | | `perf` | `type:feature` | | `test` | `type:chore` | | `build` | `type:chore` | | `ci` | `type:chore` | | `revert` | `type:bug` | | `feat!` / `fix!` | `type:breaking-change` | Examples: ``` feat(scripts): add Codex support to setup.sh fix(skills): correct topic key format in sdd-apply docs(readme): update multi-model configuration guide refactor(skills): extract shared persistence logic chore(ci): add shellcheck to PR validation workflow perf(scripts): reduce setup.sh execution time style(skills): fix markdown formatting test(scripts): add setup.sh integration tests ci(workflows): add branch name validation revert: undo broken setup change feat!: redesign skill loading system ``` --- ## Commands ```bash # Create branch git checkout -b feat/my-feature main # Run shellcheck before pushing shellcheck scripts/*.sh # Push and create PR git push -u origin feat/my-feature gh pr create --title "feat(scope): description" --body "Closes #N" # Add type label to PR gh pr edit <pr-number> --add-label "type:feature" ```
Related Skills
skill-registry
Create or update the skill registry for the current project. Scans user skills and project conventions, writes .atl/skill-registry.md, and saves to engram if available. Trigger: When user says "update skills", "skill registry", "actualizar skills", "update registry", or after installing/removing skills.
skill-creator
Creates new AI agent skills following the Agent Skills spec. Trigger: When user asks to create a new skill, add agent instructions, or document patterns for AI.
sdd-verify
Validate that implementation matches specs, design, and tasks. Trigger: When the orchestrator launches you to verify a completed (or partially completed) change.
sdd-tasks
Break down a change into an implementation task checklist. Trigger: When the orchestrator launches you to create or update the task breakdown for a change.
sdd-spec
Write specifications with requirements and scenarios (delta specs for changes). Trigger: When the orchestrator launches you to write or update specs for a change.
sdd-propose
Create a change proposal with intent, scope, and approach. Trigger: When the orchestrator launches you to create or update a proposal for a change.
sdd-init
Initialize Spec-Driven Development context in any project. Detects stack, conventions, testing capabilities, and bootstraps the active persistence backend. Trigger: When user wants to initialize SDD in a project, or says "sdd init", "iniciar sdd", "openspec init".
sdd-explore
Explore and investigate ideas before committing to a change. Trigger: When the orchestrator launches you to think through a feature, investigate the codebase, or clarify requirements.
sdd-design
Create technical design document with architecture decisions and approach. Trigger: When the orchestrator launches you to write or update the technical design for a change.
sdd-archive
Sync delta specs to main specs and archive a completed change. Trigger: When the orchestrator launches you to archive a change after implementation and verification.
sdd-apply
Implement tasks from the change, writing actual code following the specs and design. Trigger: When the orchestrator launches you to implement one or more tasks from a change.
judgment-day
Parallel adversarial review protocol that launches two independent blind judge sub-agents simultaneously to review the same target, synthesizes their findings, applies fixes, and re-judges until both pass or escalates after 2 iterations. Trigger: When user says "judgment day", "judgment-day", "review adversarial", "dual review", "doble review", "juzgar", "que lo juzguen".