Menu
git commit code changes with clear messages
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
Interview a developer to produce a living feature doc at docs/feature/{slug}.md, capturing user value, architecture (with ADR links), and data/user flow with at least one Mermaid diagram. Use when the user says "document this feature", "write a feature doc", "create docs/feature/X", "explain feature X for new devs", or asks to onboard future engineers onto a shipped feature. Different from /create_plan (forward-looking design) and Epics (scope/sprint planning) — this is the present-tense "what does this thing do today" doc for engineers reading the codebase cold.
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
Create or update a Pull Request with a description tailored to its conventional-commit type (feat, fix, refactor, chore, perf, or trivial). Auto-detects whether to create or update based on branch state, detects type from branch/commits/issues, fills the matching bundled template, and runs verification only for what CI does not cover. Use when invoking /pull-request, when the user asks to open or update a PR, or after pushing work that needs a PR.
Apply writing rules to ANY prose humans will read — documentation, commit messages, error messages, explanations, reports, or UI text. Makes your writing clearer, stronger, and more professional.
Single entry point for turning a design, plan, PRD, or in-chat spec into either a single GitHub Issue or a parent epic with child issues. Use when the user wants to create, review, or improve any ticket destined for a coding agent or another developer to pick up. Covers atomic issues, bug reports, technical tasks, spikes, and epic breakdowns using tracer-bullet vertical slices. Output is AFK-ready by default — written so a coding agent days later can produce the right work without the original chat context.
Collaborative review, grooming, and scheduling of GitHub Project issues for pre-PMF startups. Use to reassess priorities, restructure milestones, close stale or superseded issues, judge whether an issue is ready to plan, or (re)build the roadmap timeline — Start/Target dates, implementation order, and developer capacity — on the board. Especially useful when capacity changes, strategy shifts, or after completing major work.
| name | commit |
| description | git commit code changes with clear messages |
| model | sonnet |
| effort | medium |
Review the current working tree and create well-structured git commits.
See "Conventional Commits 1.0.0" message specification here: https://raw.githubusercontent.com/conventional-commits/conventionalcommits.org/refs/heads/master/content/v1.0.0/index.md
The type describes the category of change, not what the change does. The scope (in parentheses) narrows within a type — it does not replace it.
ci — CI/CD configuration and workflows (.github/workflows/, Vercel config)fix — bug fixes to application code (src/)feat — new features or user-facing functionalitytest — adding or updating tests (e2e/, __tests__/, test utilities) — even if the change fixes a bug in a test, the category is still test because the file lives in test infrastructurechore — maintenance tasks, dependency updates, toolingrefactor — code restructuring with no behavior changedocs — documentation onlyUnderstand what changed:
git status to see current changesgit diff to understand the modificationsPlan your commit(s):
Present your plan:
Execute upon confirmation:
git add with specific files (never use -A or .)git check-ignore -v <file> if unsure whether a file is ignored; skip any file that is ignoredgit log --oneline -n [number]