⏳ This skill is pending AI review.
Scores will appear once the review pipeline completes.
cap
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.
Choose how to use this skill
You do not need every option. Choose the path your AI client supports. The stable page stays the same; versioned files are immutable.
1. Native installer
This listing has no registered native installer command. Use the complete package or source fallback below, depending on what your client supports.
Do not guess an installer command or replace an existing version without reviewing the diff.
2. Complete package recommended
Download the ZIP when available. It includes SKILL.md plus the references, security notes and version metadata.
No complete ProSkills package is published for this listing yet.3. Prompt-only
Copy the prompt above when the agent can read the stable page or when you want to adopt the workflow without installing a skill.
Need only the instruction file?
Download SKILL.md only if your client requires a single file. The complete ZIP is safer for a full installation because it preserves the references and release context.
No path installs or executes anything by itself. Your agent still needs access to the project files. Before updating, compare the installed version and review the diff.
// RATINGS
Not yet listed on ClawHub or SkillsMP
// README
_ _ _ _ _ _
| | | | | | (_) | |
| |__ __ ___ _| | __ ___| | ___| | |___
| '_ \ / _` \ \ /\ / / |/ / / __| |/ / | | / __|
| | | | (_| |\ V V /| < \__ \ <| | | \__ \
|_| |_|\__,_| \_/\_/ |_|\_\ |___/_|\_\_|_|_|___/
blind · parallel · independent Opinionated Claude Code skills for shipping real software with AI.
Install · Skills · The idea · Conventions
Install
One line:
curl -fsSL https://gitlab.com/samuelishida/hawk-skills-md/-/raw/main/install.sh | bash
Or pick which skills you want:
curl -fsSL https://gitlab.com/samuelishida/hawk-skills-md/-/raw/main/install.sh | bash -s -- --select
❯ [✓] code-audit
[✓] code-audit-hardcore
[✓] coding-process
[ ] design-master
[✓] fix-bug
...
↑/↓ move · space toggle · a all · n none · enter confirm
The installer drops every selected skill into ~/.claude/skills/. Re-run any time to refresh.
The interactive flow also offers to install the hawk statusline (statusline/statusline.sh) — a compact project · branch · context-% line for Claude Code. It's optional. From a one-liner, pass --statusline to opt in or --no-statusline to skip the prompt. The script is copied to ~/.claude/hawk-statusline.sh and ~/.claude/settings.json is updated to point at it (jq required for safe in-place edits; otherwise the snippet is printed).
To remove what you installed, run ./uninstall.sh from a checkout — interactive picker, with --dry-run, --all, --prefix <p>, and --statusline / --no-statusline flags. It only touches directories whose SKILL.md description matches what we ship, so unrelated skills with colliding names are left alone.
The idea: blind, parallel, independent subagents
Most of the heavy skills here review with a deterministic main path: rg anti-pattern checks over the diff, run first and always, which own the findings. The audit-* subagents are optional context gatherers that work in parallel, with a deliberately narrow brief, and no context on the overall goal. They don't read the plan. They don't know what feature this is. They see only the code, the standards, and their specialist brief, and report raw observations back to the orchestrator.
A reviewer who knows the goal will rationalize the implementation toward the goal. A reviewer who only has the diff and a specialist brief evaluates the code on its own merits.
┌──────────────────┐
│ diff / files │
└────────┬─────────┘
│
▼
┌─────────────────┐
│ audit-triage │ ← haiku, ~1-2s
│ (light/std/deep)│ classifies scope, picks domains
└────────┬────────┘
│
▼
┌──────────────────────────────┐
│ deterministic `rg` checks │ ← main path, always runs,
│ (logic/security/simp/arch) │ owns the findings
└────────┬─────────────────────┘
│
┌────────┬───────┼───────┬────────┐ (optional context
▼ ▼ ▼ ▼ ▼ gatherers, parallel)
┌───────┐ ┌──────┐ ┌─────┐ ┌──────┐ ┌──────┐
│ logic │ │ sec │ │simp │ │rsrch │ │ arch │ ← sonnet, fresh sessions,
└───┬───┘ └──┬───┘ └──┬──┘ └──┬───┘ └──┬───┘ no plan, no goal
│ │ │ │ │
└────────┴────────┼────────┴────────┘
▼
┌───────────┐
│ merged │
│ FIX/NOTE │ → applied (cleanup) or reported (report)
└───────────┘
Each specialist is its own audit-* subagent file under
agents/, defined once and called from every audit-using skill:
| Specialist | Looks for | |
|---|---|---|
| 1 | audit-logic | off-by-one, null/NaN, empty inputs, concurrency, ordering, error paths, boundary values |
| 2 | audit-security | input validation, authn/authz, injection, XSS, SSRF, prompt injection, trust boundaries |
| 3 | audit-simplification | long functions, deep nesting, dead code, duplication, names that don't match behavior |
| 4 | audit-research | verifies third-party APIs against current docs via WebSearch + WebFetch — flags deprecated APIs and version-specific gotchas |
| 5 | audit-architecture | layer separation, file placement, import direction, type-safety, public API stability |
Plus audit-triage — a haiku-powered classifier that reads the
diff and picks the domain subset for the job. Light tasks get 2
domains; risky ones get all five. The triage decision is
internal — you don't see it unless you ask.
The same pattern is reused by code-audit-hardcore,
implement-plan-audited, and review-large-pr. The plan skills
(plan-small, plan-large) use a separate plan-reviewer
agent for their self-review pass — same shape, plan-shaped brief.
Skills
Planning
| Skill | Job |
|---|---|
coding-process | Entry point. Reads the task, routes to the right skill below. |
plan-small | One-PR change. Searches the code before asking questions, surfaces assumptions/decisions alongside questions, writes .plans/<slug>/plan.md, then runs an independent self-review subagent that improves the plan before showing it to you. |
plan-large | Multi-PR feature. Same code-search-first question gate, plus an increment DAG and explicit ordering review. |
review-plan | Adversarial review of a plan file. |
Execution
| Skill | Job |
|---|---|
[implement-plan](skills/implement-plan/SKILL.md |
// HOW IT'S BUILT
// FILES
2 files shipped with this skill. Inline text is the catalog copy. The upstream link is the source repository.
skills/cap/SKILL.md4.1 KB7be45db52d2eupstream ↗
--- 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. --- # Cap Commit and push the current working tree in one shot. ## Process 1. **Read the state** — run in parallel: - `git status` to see what's changed and untracked - `git 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 style If 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. 2. **Match the repo's voice**: - Mirror tense, casing, length, and prefix conventions from recent commits - If recent commits are lowercase imperative ("fix banner alignment"), do that - If they use Conventional Commits ("feat: ..."), do that - If they're terse one-liners, stay terse — do not pad 3. **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. 4. **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. 5. **Sanity check before committing**: - If staged files include anything that smells like a secret (`.env*`, `*.pem`, `credentials*`, `*.key`), stop and ask - If the working tree is clean, say so and exit — do not create empty commits 6. **Commit and push**: - Commit with the drafted message - If the branch has no upstream, push with `-u origin <branch>`; otherwise plain `git push` - If pre-commit hooks fail, fix the issue and create a new commit (never `--amend`, never `--no-verify`) 7. **Handle non-fast-forward rejections** — if push is rejected because the remote moved ahead: - Run `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. - If the rebase hits conflicts: stop, surface the conflicting paths, and let the user resolve. Do not auto-resolve. - After a clean rebase, retry `git push`. - Do **not** fall back to a merge pull (`git pull` without `--rebase`) — that creates noisy `Merge branch 'main' of origin/...` commits, which is exactly what we're avoiding. - Do **not** force-push to recover from a rejection. 8. **Report**: the short SHA, the message, and the push destination. One line. ## Rules - Never push to `main`/`master` with `--force` or `--force-with-lease` - Never skip hooks (`--no-verify`, `--no-gpg-sign`) - Never amend a commit that's already been pushed - If the user is mid-rebase, mid-merge, or has conflicts, stop and surface the state instead of committing through it - **Big-output discipline.** Heavy command output (project check, full `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. ## Calling models via Ollama Always set `num_predict` in `/api/chat` options — too small → empty `content`; uncapped → runaway. Recommended: `temperature: 0.7`, `top_p: 0.9`, `num_batch: 512`, `repeat_penalty: 1.1`, `repeat_last_n: 64`. Empty content + long thinking → raise `num_predict`; huge output → cap missing. Prefer 4-bit quants for tool calling. Full detail: README → "Calling models via Ollama".README.mdupstream ↗
Contents are not inlined in the catalog. Open the upstream file.
Plain-text copy, no login: /skill-bundles/samuelishida-hawk-skills-md-skills-cap.md