// Create a pull request with conventional format. Use when asked to create a PR, open a pull request, or push changes for review.
| name | pr |
| description | Create a pull request with conventional format. Use when asked to create a PR, open a pull request, or push changes for review. |
| argument-hint | [PR title] |
Create a pull request for the current branch.
Before creating the PR, run the Schema L probe (see docs/patterns.md § Tracker Mode Probe). If CLAUDE.md has no ## Task Tracking section, mode is none and the rest of this skill runs unchanged. If a tracker mode is active:
docs/ticket-binding.md before any MCP write. Decline exits cleanly with zero side effects.transition_status(ticket, in_review) and optionally upsert_ticket_metadata to add the PR URL to the ticket description (NFR-8 ≤ 2 MCP calls). Capability-missing cases degrade with a canonical-shape warning + proceed.See docs/pr-tracker-mode.md for the full tracker-mode flow.
git status and git log to understand what's being submittedmain, create a new branch from the changes:
feat/short-description, fix/short-description, or chore/short-description-u flaggh pr create:
<type>(<scope>): <title>, ≤ 72 characters. Use ! for breaking changes (feat(api)!: drop legacy endpoint). When the branch carries multiple commits, pick the type/scope of the dominant change (the merge commit or release commit on a release branch). The PR title and the squash-merge subject must both validate against the commit-msg hook.## Summary
<1-3 bullet points describing what changed and why>
## Test plan
- [ ] Testing steps or verification notes
main$ARGUMENTS contains a PR title, use itRun the project gate checks and report results. Use after completing any feature, before creating a PR, or to verify project health.
Implement a feature or fix end-to-end. Analyzes the request, builds in TDD order, runs gate checks, self-reviews with bounded loops, and reports for human approval before committing.
Guide the user through writing or completing spec files (requirements, technical spec, testing spec, plan). Use after /setup to fill in specs before implementation, or to update existing specs.
Drive `/smoke-test` against both trackers in parallel and aggregate the per-tracker findings files into one deduplicated report. Default `capture-only` mode honors `/smoke-test`'s "Capture, don't fix" rule unchanged. Opt-in `--auto-fix` mode walks the deduplicated high-severity findings list and dispatches `/dev-process-toolkit:spec-write` + `/dev-process-toolkit:implement` per finding, then re-iterates until termination. Project-local skill, not plugin.
Review implementation against specs to find deviations, missing features, or inconsistencies. Delegates to the `spec-review-audit` fork + `spec-reviewer` subagent.
Bundle the Release Checklist + /docs --commit --full into one atomic, human-approved release commit. Reads specs/plan/M<N>.md, bumps the four release files, regenerates docs, prompts once for approval, commits on `y`, does not push.