From Che Armstrong Skills
Use when asked to find bugs, audit an existing repository or scoped path, review a branch or pull request for correctness, investigate a suspected defect, or assess security/data-integrity risks without making speculative findings.
How this skill is triggered — by the user, by Claude, or both
Slash command
/chearmstrong-skills:bug-huntingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill to find real defects with evidence. Prefer a narrow, verified finding over a broad checklist result. Do not make code changes unless the user explicitly asks for fixes.
Use this skill to find real defects with evidence. Prefer a narrow, verified finding over a broad checklist result. Do not make code changes unless the user explicitly asks for fixes.
Start by naming the mode and scope:
| Mode | Use when | Primary evidence |
|---|---|---|
| Known bug | There is a symptom, failing test, incident, or report | Reproduction, trace, regression test |
| Diff review | There is a branch, PR, or patch | Full changed behaviour plus caller/context checks |
| Scoped audit | The user asks to find latent bugs in a repo, package, or directory | Risk-led source-to-sink review |
| Domain audit | The scope involves DynamoDB, CDK/IaC, auth, queues, payments, data integrity, or retries | Invariant checks plus targeted tests or traces |
If the requested scope is too broad, do not pretend to audit everything. Create a risk map, select the highest-risk flows, and state what was and was not covered.
Use this table to decide where to spend attention before deep reading:
| Scope | Start with | Then inspect |
|---|---|---|
| Broad repo | Recent or high-churn files, entry points, and state writes | Shared abstractions, auth boundaries, queues/jobs, persistence code |
| Diff or PR | Changed behaviour, changed contracts, and modified tests | Callers, downstream consumers, migrations, backwards compatibility |
| DynamoDB | Pagination, idempotency, retry paths, and GSI mutation flows | Token round-trips, PK/SK availability, conditional writes, multi-page tests |
| CDK/IaC | Logical IDs, replacements, IAM, and stateful resources | cdk diff, encryption, retention, alarms, DLQs, public exposure |
| Auth or tenancy | Object lookup plus ownership checks | Middleware/framework guards, cache keys, service/admin bypass paths |
Gather first-pass context
git status, current branch, changed files, requested path, or PR/diff target.AGENTS.md, CLAUDE.md, or repo-specific review guidance when present.Map the surface
Prioritise risky flows
Trace source to sink
Validate before reporting
MANDATORY: after risk mapping, read references/bug-heuristics.md before deep inspection. MANDATORY: before finalising findings, read references/validation-and-reporting.md. Do not load all references at the start when context is tight.
LastEvaluatedKey or equivalent cursor data is preserved.cdk diff evidence.Good finding:
File: src/jobs/processOrder.ts:84
Problem: SQS retry can charge the same order twice.
Why this is real: The handler creates a new payment intent before recording a deterministic idempotency key. A timeout after the external call but before `orders.update` lets the same message retry and repeat the charge path. No conditional write or duplicate-delivery test covers this.
Fix or verification step: Use order ID as the payment idempotency key and add a duplicate-message regression test.
Suppressed false positive:
Do not report: "userId may be null".
Reason: The route is wrapped by `requireUser`, `RequestWithUser` marks `user` as non-null after middleware, and existing tests cover unauthenticated requests returning 401 before the handler runs.
master.Apply the repo's local instructions first. For this environment, pay special attention to:
LastEvaluatedKey exactly; never rebuild partial tokens.ConditionExpression; retry-safe under at-least-once delivery.cdk diff.Lead with findings, ordered by severity. For each finding include:
File:LineSeverity: Critical, High, Medium, or LowProblemWhy this is realFix or verification stepIf no significant bugs were found, say that plainly and include the reviewed scope plus residual risk. Never say a broad repo is "clean"; say no findings were found in the reviewed scope.
npx claudepluginhub chearmstrong/skills --plugin chearmstrong-skillsGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.