treefmt: apply prettier
Pure `nix fmt` output from the commit before this one — no hand edits. 203 files: 52 md, 42 tsx, 32 js, 32 css, 21 ts, 13 html, 8 json, 3 mjs. Reproduce with `nix develop -c nix fmt` on the parent commit; the result should be byte-identical to this tree. None of the 13 `.prettierignore` entries appears here — verified by intersecting the changed-file list against the ignore file, with a control proving the intersection finds a match when one exists.
This commit is contained in:
parent
5d24bedd60
commit
39b95c2ede
203 changed files with 10090 additions and 6085 deletions
|
|
@ -33,7 +33,7 @@ claude --name <memorable> --model <cheaper-than-you> --dangerously-skip-permissi
|
|||
by name for follow-ups.
|
||||
- **`--model <cheaper-than-you>`** - think about which model the task
|
||||
actually needs; don't spend a bigger model's tokens than your own on
|
||||
mechanical work a cheaper one handles fine. Never use a *bigger* model
|
||||
mechanical work a cheaper one handles fine. Never use a _bigger_ model
|
||||
than yourself for a sub-agent - if the task needs that much capability,
|
||||
it's not the "mechanical batch" case this skill is for.
|
||||
- **`--dangerously-skip-permissions`** - required in headless (`-p`)
|
||||
|
|
@ -68,7 +68,7 @@ work while the sub-agent grinds.
|
|||
cases: "leave it as-is where genuinely unclear; do not guess."
|
||||
- **Ask for a report file** - per-item results + anything skipped and
|
||||
why, so you can verify without re-deriving.
|
||||
- **Tune on ONE item first**, eyeball the result, fix the prompt, *then*
|
||||
- **Tune on ONE item first**, eyeball the result, fix the prompt, _then_
|
||||
turn it loose on the full batch. A prompt bug replicated across 100
|
||||
items is 100 cleanups.
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ running at once instead of handing the whole thing to one.
|
|||
loop.
|
||||
- **Mind the container's memory cap before picking N.** Your whole
|
||||
container shares one `MemoryMax` (a few GB by default) with every
|
||||
subagent you spawn *and* your own process. A `claude` process plus its
|
||||
subagent you spawn _and_ your own process. A `claude` process plus its
|
||||
MCP servers can hold several hundred MB to ~1GB depending on the task;
|
||||
spawning a dozen at once on a small container doesn't just slow
|
||||
things down, it can OOM the whole container — taking your own
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ steps in the right order.
|
|||
## 1. Check for a duplicate before filing
|
||||
|
||||
`hive-forge list` has a server-side full-text `--search` flag that covers
|
||||
title *and* body - use it before writing anything:
|
||||
title _and_ body - use it before writing anything:
|
||||
|
||||
```sh
|
||||
hive-forge list --search "keyword or two" --state all
|
||||
|
|
@ -43,8 +43,8 @@ Prefer naming the broken behavior or missing capability over a specific
|
|||
error string or one-off symptom - "hive-forge list has no way to filter by
|
||||
milestone" beats "list command confusing" or "can't find issues for
|
||||
milestone 11 easily". If you're not sure which framing is more durable,
|
||||
lean toward whatever a colleague hitting the *same underlying gap* through
|
||||
a *different* symptom would still recognize.
|
||||
lean toward whatever a colleague hitting the _same underlying gap_ through
|
||||
a _different_ symptom would still recognize.
|
||||
|
||||
## 3. Body: what's wrong, not how to fix it
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ dimension directly.
|
|||
hardcoded, so check `repo-labels` first if you don't already know the
|
||||
scopes in use.
|
||||
- **PRs with no formally requested reviewer** - `hive-forge lint
|
||||
no-reviewer` flags PRs with zero requested reviewers at all; add
|
||||
no-reviewer` flags PRs with zero requested reviewers at all; add
|
||||
`--reviewer <name>` to instead flag PRs where that specific person
|
||||
isn't among the requested reviewers. This checks the forge's actual
|
||||
reviewer-request state, not a text `@name` mention anywhere in the
|
||||
|
|
@ -42,12 +42,13 @@ dimension directly.
|
|||
|
||||
Run the checks relevant to what you're verifying rather than assuming
|
||||
one covers everything - "is triage caught up" usually means unassigned
|
||||
+ unlabeled at minimum, with no-reviewer added if reviews matter for
|
||||
your workflow. Each verb supports `--json` if you want to fold the
|
||||
results into something else instead of reading the human-readable output.
|
||||
|
||||
- unlabeled at minimum, with no-reviewer added if reviews matter for
|
||||
your workflow. Each verb supports `--json` if you want to fold the
|
||||
results into something else instead of reading the human-readable output.
|
||||
|
||||
This is reactive/on-demand coverage checking, not a scheduled rollup or
|
||||
historical trend - if you need to track compliance *over time* (was
|
||||
historical trend - if you need to track compliance _over time_ (was
|
||||
triage worse last week than this week), that's a different, bigger
|
||||
ask than running these checks - don't build that unprompted just
|
||||
because the checks exist.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ description: Take a real screenshot of an HTML/CSS page from inside a container
|
|||
# Headless Screenshot
|
||||
|
||||
"No browser in this container" usually means no browser is
|
||||
*pre-installed*, not that one is unreachable. `nixpkgs#chromium` is a
|
||||
_pre-installed_, not that one is unreachable. `nixpkgs#chromium` is a
|
||||
`nix shell` away, and a single headless invocation renders a page and
|
||||
writes a PNG without a running server, a display, or any scripted
|
||||
interaction library.
|
||||
|
|
@ -65,7 +65,7 @@ peer agent's GUI-testing capability, try rendering it yourself first:
|
|||
This is a static render, not a browser automation tool. Verifying an
|
||||
interaction (a click, a hover state, a form submission) needs
|
||||
puppeteer/playwright or similar - reach for those only when the
|
||||
question is genuinely about *behavior*, not appearance. A missing
|
||||
question is genuinely about _behavior_, not appearance. A missing
|
||||
emoji/glyph rendering as a box in the screenshot is usually a font
|
||||
availability artifact of the headless environment, not a real bug -
|
||||
don't mistake one for the other when reporting results.
|
||||
|
|
@ -80,7 +80,7 @@ judge icon/glyph layout, not just to note "there'd be an icon here").
|
|||
- **Tofu boxes instead of emoji.** Plain `nixpkgs#chromium` has no
|
||||
color-emoji font, so any 🖥/📡/🔨-style glyph renders as an empty
|
||||
box. Add `nixpkgs#noto-fonts-color-emoji` to the `nix shell` - but a
|
||||
`FONTCONFIG_FILE` that lists *only* the emoji dir throws away the
|
||||
`FONTCONFIG_FILE` that lists _only_ the emoji dir throws away the
|
||||
base fonts and blanks all normal text instead, which is its own
|
||||
false alarm. Merge, don't override:
|
||||
```
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ work in your own style. That framing should hold throughout.
|
|||
|
||||
## Before you start
|
||||
|
||||
1. **Read the linked issue/task** - understand *why* the change exists,
|
||||
1. **Read the linked issue/task** - understand _why_ the change exists,
|
||||
not just what it does.
|
||||
2. **Check CI status first.** A failing build or test suite is an
|
||||
automatic block - don't write a detailed review of code that doesn't
|
||||
|
|
|
|||
Loading…
Reference in a new issue