# cap

Adopt this skill: https://proskills.md/skills/other/samuelishida-hawk-skills-md-skills-cap

Page: https://proskills.md/skills/other/samuelishida-hawk-skills-md-skills-cap
This document is the public skill bundle for that page. It contains SKILL.md and every helper file the catalog carries. No login is required.

## File: skills/cap/SKILL.md
size: 4218
sha: 7be45db52d2ea4b00bce5f4ac9dd029c9227d3a1
upstream: https://github.com/samuelishida/hawk-skills-md/blob/main/skills/cap/SKILL.md

```text
---
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".
```

## File: README.md
upstream: https://github.com/samuelishida/hawk-skills-md/blob/main/README.md

````text
<div align="start">

```
   _                    _          _    _ _ _
  | |                  | |        | |  (_) | |
  | |__   __ ___      _| | __  ___| | ___| | |___
  | '_ \ / _` \ \ /\ / / |/ / / __| |/ / | | / __|
  | | | | (_| |\ V  V /|   <  \__ \   <| | | \__ \
  |_| |_|\__,_| \_/\_/ |_|\_\ |___/_|\_\_|_|_|___/
```

**blind · parallel · independent**
Opinionated [Claude Code](https://claude.com/claude-code) skills for shipping real software with AI.

[Install](#install) ·
[Skills](#skills) ·
[The idea](#the-idea-blind-parallel-independent-subagents) ·
[Conventions](#conventions)

</div>

---

## Install

One line:

```bash
curl -fsSL https://gitlab.com/samuelishida/hawk-skills-md/-/raw/main/install.sh | bash
```

Or pick which skills you want:

```bash
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`](skills/coding-process/SKILL.md) | Entry point. Reads the task, routes to the right skill below.                                                                                                                                                                                |
| [`plan-small`](skills/plan-small/SKILL.md)         | 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`](skills/plan-large/SKILL.md)         | Multi-PR feature. Same code-search-first question gate, plus an increment DAG and explicit ordering review.                                                                                                                                  |
| [`review-plan`](skills/review-plan/SKILL.md)       | Adversarial review of a plan file.                                                                                                                                                                                                           |

### Execution

| Skill                                                              | Job                                                                                                                                              |
| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| [`implement-plan`](skills/implement-plan/SKILL.md
````
