Menu
Create a pull request with proper title, description, test plan, and linked issues. Use when ready to submit changes for review.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | pr |
| description | Create a pull request with proper title, description, test plan, and linked issues. Use when ready to submit changes for review. |
| model | haiku |
| argument-hint | [base-branch] |
Create well-structured pull requests following project standards.
Ask via dialog: When this skill needs a decision, preference, or clarification, call
AskUserQuestion(ToolSearch select:AskUserQuestionif the schema isn't loaded). Don't embed questions in prose. See~/.claude/CLAUDE.md§ "Asking the User Questions" for the full rule.
git status
git log --oneline main..HEAD
git diff main...HEAD --stat
Before creating PR, verify:
Title: Short, descriptive, under 70 characters
Body: Use this structure:
## Summary
- [1-3 bullet points describing the change]
## Changes
- [List of specific changes made]
## Test plan
- [ ] [How to verify this works]
- [ ] [Edge cases tested]
## Related
- Fixes #[issue]
- Related to #[issue]
gh pr create --title "..." --body "..."
Return the PR URL and a brief summary of what was submitted.
Audit Ansible playbooks, roles, collections, and inventories for production readiness. Use when reviewing an Ansible repo, before merging IaC PRs, before promoting a role to a collection, or when the user mentions ansible-lint, idempotency, vault, or molecule.
Enter planning mode — interview the user, design a phased approach, and produce an implementation plan before writing code.
Execute an approved /plan unattended — phases, agents, commits — stopping only on hard safety failures (hook exit 2, sandbox/network deny, repeated test failures). Use after /plan when the user wants hands-off execution.
Run a full read-only audit of the current project — code review, security analysis, and documentation freshness check. Use to assess project health without making changes.
Start implementing a feature with user story validation, phased execution, and quality gates. Use after planning is complete.
Take a project from "it works" to "it's shippable." Runs audit, fixes findings, walks the Definition of Done checklist, and generates a release readiness score. Use before releasing, after feature-complete, or when quality feels prototype-y.