nadiwerk/trust-no-agent

Stop execution like a debugger breakpoint — relentlessly interview the user about a plan, decision, or idea until shared understanding is reached, before any code runs. Use when the user wants to stress-test their thinking, before starting any large feature, or when the user says "interview me", "stress-test this plan", or asks to be grilled.

Test-driven development — write the failing expectation first, then make it pass. Use when the user asks to write tests, verify behavior, or prove something is correct.

Use when a spec is ready and work needs to be broken down — forks it into tracer-bullet tickets (vertical slices), each declaring its blocking edges.

Use when tickets are approved and it is time to build — test-first at agreed seams, layered verification, closed with roast-my-code and ship-log.

Use when receiving review feedback from anyone — before implementing, verify each claim with evidence and push back when wrong; never perform agreement.

Use when the user claims work is done, fixed, passing, shipped, or asks to log/commit/PR it — before accepting any success claim. Trigger words: "done", "shipped", "it works", "log it", "commit", "PR", "finished", "it's ready". Requires running verification commands (typecheck, tests, lint, build) and confirming output before making any success claim. Receipts or it didn't happen. Failure handling lives in the make-it-so repair-receipt contract; this skill governs success claims only.

Review changes since a fixed point (commit, branch, tag, or merge-base) along three axes — Standards (does the code follow the repo's documented standards?), Spec (does the code match the originating spec/ticket?), and Security (does the change introduce a vulnerability?). Runs all three reviews as parallel subagents. Use when the user wants to review a branch, a PR, work-in-progress changes, or says "review since X".

Debugging — find the root cause before proposing any fix. Use when the user reports a bug, error, failure, or unexpected behavior — trigger words: "broken", "500", "error", "sometimes fails", "just add a try/catch", "fix it", "why is this happening", "it doesn't work". Especially under time pressure, after a previous fix failed, or when the issue isn't fully understood.

Use when the conversation has converged and a written spec is needed — pure synthesis of what was already discussed, no new questions.

Use when a large feature is about to start and decisions should be recorded — an interview that writes ADRs and the domain glossary as it goes.

Append a log entry of completed work to the private project ledger (typically .trust/progress.txt, gitignored). Use after finishing any file change, refactor, task, or bug fix, before moving to the next item.