菜单
Stage all changes, commit with a short message that matches the repo's existing commit style, and push. Use when the user wants to ship the current diff with no fuss.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Plan a multi-PR feature, migration, or architectural change before writing code. Writes a `.plans/<slug>/` directory of HTML documents (with inline UI mockups and a review-tracking layer) — a 1-page `overview.html` for human review, a mandatory `data-model.html` that locks the schema before anything else, a terse `plan.html` of dependency-ordered increments, an ADR-style `decisions.html`, and a `verification.html` acceptance script. Use whenever the user says "plan this feature", "scope out the migration", "/plan-large", "architect this rollout", "I need a plan covering schema and API", "design this across multiple PRs", or "break this work up". Also use whenever the work touches a database migration, even if it's only two PRs — schema-first is the gate. Runs a blind self-review subagent before presenting. Do NOT use for single-PR changes — bail to `plan-small` at Step 0. Do NOT use to start implementing — that's `/implement-plan` after the plan is approved.
Plan a single-PR change end-to-end before writing code. Writes a terse `.plans/<slug>/plan.html` (HTML, with inline UI mockups where a screen changes, rendered through the shared design system) covering files to touch, data-model changes, edge cases, verification, and decisions/assumptions sourced to code or user. Use whenever the user says "plan this", "scope this out", "write up a plan for X", "/plan-small", "let's plan the new flag", or "plan before we start". Also use whenever the user describes a small feature without explicitly asking to plan — propose a plan before coding. Asks only what code can't answer (in-repo PRDs count), surfaces planned assumptions alongside questions, then runs a blind self-review subagent before presenting. Do NOT use for multi-PR work, schema migrations beyond adding a nullable column, or sequenced increments — bail to `plan-large` at Step 0. Do NOT use to start implementing — that's `/implement-plan` after the plan is approved.
Aggressive cleanup audit scoped to the user's specified changes plus tangibly-relevant surrounding code. Same blind audit-* specialists as code-audit, with a maximum-improvement posture — any code in the expanded review scope that can be cleaner WILL be made cleaner. Small fixes applied inline; big fixes (>5 files, schema, public API, redesigns) routed through `/plan-small` or `/plan-large`. Plan-overrides — when the audit reveals the original plan was wrong — route through `/plan-large` by default. Always improve over preserve.
Execute a plan increment-by-increment with the audit-* specialists running independently at strategic checkpoints. Use whenever the user says "implement the plan with audits", "audited implementation", "run with audits", "implement with cleanup checkpoints", "audit as you go", or invokes /implement-plan-audited. Inherits the full per-increment verification loop from `implement-plan` (done-criteria evidence, layered retry ladder, file-divergence check, outcome records) and adds checkpoint annotation, blind parallel audits, audit-fix verification (each FIX closes its own loop), plan-override propagation, and BEHAVIOR_CHANGE.md artifacts. Two modes — `manual` stops between increments for user review; `auto` applies audit fixes and proceeds without interruption, designed for hours of unattended execution. Specialists are blind to the plan and the goal. Do NOT use for unaudited plan execution — use `implement-plan`. Do NOT use for one-shot audits of existing code — use `code-audit`. Do NOT use for planning or repl
Execute an approved plan increment-by-increment with deterministic verification at each step. Use whenever the user says "implement the plan", "run the plan", "execute the plan", "work through the increments", "do the plan", or invokes /implement-plan. Done-criteria are checked against evidence on disk, not asserted from memory; failures escalate through a layered ladder rather than repeated identical attempts; existing code gets behavior-preservation tests before modification; file divergence (touched vs declared) is reconciled before each commit; structured outcome records land in the plan file. Designed for fresh sessions with no prior context. Do NOT use for planning itself — use `plan-small` or `plan-large`. Do NOT use for unplanned coding without a plan file — use `coding-process`. Do NOT use when the user wants audits in the loop — use `implement-plan-audited`.
Stress-test a plan file before committing to implementation. Catches architectural mistakes, convention violations, and missing dependencies while changes are still cheap. Invoked directly, not routed from coding-process.
| name | cap |
| description | Stage all changes, commit with a short message that matches the repo's existing commit style, and push. Use when the user wants to ship the current diff with no fuss. |
Commit and push the current working tree in one shot.
Read the state — run in parallel:
git status to see what's changed and untrackedgit diff --stat and git diff --staged --stat for the size pre-check (always inline)git log -10 --oneline to learn the repo's commit message styleIf the stat shows the diff is small (≲200 lines), read it inline with git diff / git diff --staged. If it's large, redirect: git diff > /tmp/hawk-cap-diff.patch 2>&1 and git diff --staged > /tmp/hawk-cap-diff-staged.patch 2>&1. Build the commit-message draft from rg -n '^(diff --git|@@|^\+|^-)' /tmp/hawk-cap-diff.patch | head -50 slices, not the whole capture.
Match the repo's voice:
Draft a commit message: one short line, summarizes the why of the change. No body unless the diff genuinely needs one.
Never include AI attribution. No "Generated with Claude", no "🤖", no Co-Authored-By: Claude ... trailer, no mention of Anthropic, AI, or any model — not in the subject, not in the body, not in a trailer. Even if the repo's history contains such trailers, do not add them. The commit must read as if a human wrote it.
Stage explicitly: add the specific files you intend to commit by name. Never git add -A or git add . — that risks sweeping in .env, credentials, or other untracked files the user did not mean to commit.
Sanity check before committing:
.env*, *.pem, credentials*, *.key), stop and askCommit and push:
-u origin <branch>; otherwise plain git push--amend, never --no-verify)Handle non-fast-forward rejections — if push is rejected because the remote moved ahead:
git pull --rebase to replay your local commits on top of the remote tip. This is safe — you're only rebasing your unpushed commits, which no one else has.git push.git pull without --rebase) — that creates noisy Merge branch 'main' of origin/... commits, which is exactly what we're avoiding.Report: the short SHA, the message, and the push destination. One line.
main/master with --force or --force-with-lease--no-verify, --no-gpg-sign)git diff, repo-wide search, long log, large fetch) goes to /tmp/hawk-cap-<step>.log, then rg -n '<pattern>' /tmp/hawk-cap-<step>.log | head -50 extracts what you need. Read the file only with offset/limit. See README → Big-output discipline.