git commit code changes with clear messages
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.
Create, list, and tear down per-issue git worktrees, each with an isolated Neon database branch and a portless dev URL, so multiple issues can be worked in parallel without DB or dev-server collisions. Use when the user says "spin up / create a worktree for issue N", "clean up the worktree", "list worktrees", invokes /worktree, or wants parallel isolated dev environments per GitHub issue.