Menu
Use when creating/raising/opening/submitting a GitHub PR. Produces short, feature-focused descriptions without a test plan.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when asked to review a local diff, a GitHub PR, or a whole codebase. Reports each finding with severity, likelihood, a worth-fixing verdict, and a high-level fix.
Use when asked to trim, clean up, shorten, or remove code comments. Two levels — "normal" (default) shortens verbose comments; "aggressive" deletes nearly every comment, keeping only trimmed unusual-workaround notes.
Use after generating or editing ASCII art, box diagrams, tables, or any monospace text art to ensure all lines, corners, and boxes are properly aligned.
Use when creating a new agent skill. Ensures the skill follows quality guidelines for SKILL.md files.
Use when updating GitHub PR title or body. Works around the gh pr edit GraphQL bug caused by GitHub's Projects Classic deprecation.
Use when the user wants to interact with Linear.app — reading or searching issues/tickets.
| name | gh-create-pr |
| description | Use when creating/raising/opening/submitting a GitHub PR. Produces short, feature-focused descriptions without a test plan. |
| user-invocable | true |
Create PRs with short, feature-focused descriptions. No test plan or co-author lines.
gh pr create with a HEREDOC body:
gh pr create --title "<short title>" --body "$(cat <<'EOF'
[## Context <1–2 sentences — include this section only if rule 3 applies>
]## Summary <bullet points describing the main features/changes, proportional to PR size> EOF )"
2. **Title**: Use imperative mood (e.g., "Add user auth", "Fix pagination bug").
3. **Context section**: Include `## Context` above `## Summary` only when the PR has business/user-facing motivation sourced from a linked issue, ticket, CLAUDE.md, or conversation. Keep it to 1–2 sentences in plain language — what the user or business gets, not how. **Do not invent or speculate**; omit the section entirely for purely technical work (refactor, chore, dep bump) or when no source material exists.
4. **Summary section**: Bullet points proportional to PR size, focused on the changes themselves.
5. **No test plan**: Do not add a test plan, checklist, or QA section.
6. **No co-author**: Do not add "Co-Authored-By" lines.