software-engineering

Reviews one bounded implementation change (a diff, PR, commit range, or "I finished X" claim) against its stated goal, repo instructions, the actual change content, and verification evidence you can point to. Produces exactly one verdict — Ready to merge, Ready after minor corrections, Not ready to merge, or Unable to verify — plus findings sorted into blocking / required corrections / non-blocking / out-of-scope. Use whenever you or another agent is about to say a change is "done", "ready", or "passing", before merging, or whenever someone asks for a review of a diff, PR, or commit. Exists to stop premature "looks good" verdicts: refuses to credit tests as passing unless their output was actually observed, and checks whether an old implementation a change claims to replace is still reachable. Judges this change on its own — not feature/milestone convergence, not evidence-pointer integrity, not full domain/lifecycle/ownership audits — see "How this composes."

Investigation protocol for customer-owned environments: enterprise/legacy integration, hidden-behavior systems, POC-to-production calls. Loop: inspect -> ask -> model -> discriminate -> observe -> revise -> act -- inspect first, prefer the customer's own tools, ask only a discriminating question. Modes: Recon (map terrain), Diagnose (delegate, checkpoint/resume, converge or hand off, production-readiness on request), Handoff (name the uncrossable wall). Tags OBSERVED/INFERRED/ASSUMED/UNKNOWN. Refuses unearned root cause, fabricated access, stale checkpoints, or redoing a verdict an installed sibling skill owns.

Builds a concise, evidence-backed operating map of a repository before consequential work begins: purpose, governing instructions (root and scoped), major executable paths, architectural seams, systems of record, documented/observed build-test-lint commands, where work belongs, high-risk areas, and honest unknowns. Every claim is tagged observed fact, tight inference, or unresolved uncertainty — never invented from a filename, never a command claimed to work without its result observed. Use whenever you or another agent is about to work in an unfamiliar repository, or someone asks to get oriented, understand this codebase, map out this repo, or figure out how it's put together — even if they don't say "orientation." Not a summary, architecture review, quality audit, diff/PR review (change-review), retrospective (slice-retro), or next-slice call (next-best-slice) — it stops at the map, refusing next-work calls, plans, redesigns, or cleanup audits, even bundled in.

Given an existing spec/plan and its decomposed tasks, partitions remaining work into agent-sized delivery slices: which tasks belong together and why, what each delivers end to end, dependencies on other slices, safe parallelism, and a verification checkpoint. Prefers vertical slices over layer-batching; allows a horizontal enabler only when it unlocks more parallel work; surfaces convergence points; runs only the minimal dependency check needed (cycles, numeric-order illusions, false-parallel work sharing an unmet prerequisite). Use once a plan/task list exists and someone asks how to split it into sessions, PRs, or agent assignments, or which tasks can run in parallel. Does not decompose a spec into tasks, choose what to build next or override priority (next-best-slice, next-best-change), plan one slice's implementation (slice-plan), or build a graph/scheduler/orchestration integration -- refuses to manufacture parallelism the dependencies don't support, reporting low or zero safe parallelism when honest.