pragent/.opencode/skills/attention-tiering/SKILL.md

name, description

name	description
attention-tiering	Decide how much review effort a PR deserves BEFORE doing expensive work — trivial / lite / full / oversized — and what each tier is allowed to spend. Load this first, right after reading the brief.

Attention tiering

Cost scales with what you read, not with what you report. A lockfile bump and a new auth middleware must not cost the same. Pick a tier from the diff before reading repo files, state it in your summary, and stay inside its budget.

Deterministic rules decide first. Only an ambiguous case needs judgement.

Pick the tier

Read the diff's shape: changed-file count, added+removed lines, and which paths.

Tier	Trigger (first match wins)	Budget
trivial	Only lockfiles (*.lock, package-lock.json, go.sum, poetry.lock), generated/vendored paths, pure docs/comment/whitespace edits, or .md typo fixes	No file reads, no linters, no subagents. One pass over the diff. Usually findings: [].
lite	< 50 changed lines AND < 4 files AND no risk path	≤ 3 file reads, linters on changed files only, no subagents.
full	The default for anything real	≤ 15 file reads, linters, subagents only per the rules below.
oversized	> 1500 changed lines OR > 40 files	Do NOT read the whole thing. Structural pass + deep pass on the hot subset (see below).

Risk paths force at least full regardless of size — a 3-line change here is not lite:

• auth, authz, session, token, crypto, password, secret, key
• SQL / query builders / raw query strings, deserialization, eval/exec
• file upload/download, path handling, subprocess, network egress
• CI/CD config, Dockerfile, .github/, .gitea/, dependency manifests
• migrations, anything touching money, PII, or permissions

Oversized: what "hot subset" means

Rank changed files by risk, then review the top ~10 properly and summarize the rest structurally:

1. risk-path files (above), highest first
2. files with the most logic churn (ignore pure moves, renames, formatting)
3. files with no test file changed alongside them

Say so explicitly in the summary: "reviewed N of M files in depth; the rest are <mechanical rename / generated / config>". A partial review that admits its scope is useful. A silent partial review is not.

Subagent delegation

Subagents are the single biggest cost multiplier — each one is a fresh context that re-reads the diff. Delegate only when both hold:

• the tier is full or oversized, AND
• the lens has real surface: @security when a risk path above is touched, @tests when logic changed and no test file did, @perf when a loop, query, or request-path function changed.

Never fan out on lite. Never spawn a lens with nothing to look at. Two subagents on one PR is normally the ceiling.

Cheap before expensive

In every tier, in this order — stop as soon as findings are grounded:

1. the diff itself (free, already in the brief)
2. grep for a symbol's other uses (cheap, targeted)
3. reading one file around the change (moderate)
4. linters/typecheck on changed files (moderate, high signal)
5. reading callers/tests (expensive)
6. subagents (most expensive)

Prefer grep -n 'symbol' over reading a whole file to answer "is this used elsewhere". Read a range around the hunk, not a 2000-line file, when you only need the enclosing function.

Report the tier

Put it in the summary line so the cost is auditable:

Tier: full (312 changed lines, touches auth/session.go). 9 files read, go vet run, @security delegated.