prilive-com

go-modernize

Apply Go 1.26 modernization analyzers (`go fix`) to bring a package or module up to current idioms. Mass-rewrites code; only invoke explicitly when the operator asks to modernize.

Review a database migration (SQL, golang-migrate, goose, Flyway, etc.) for safety, reversibility, zero-downtime correctness. DB safety review is high-stakes; only invoke explicitly when reviewing a migration.

postmortem-fix

Turn an escaped defect or production incident into a concrete prevention patch plan (root cause + control gap + multi-layer fix). Declaring an incident is intentional; only invoke explicitly when the operator says this is post-incident or postmortem work.

second-opinion

Reference for the cross-model review runner. The hooks invoke the runner script; the model does not invoke this skill. Documents the Codex CLI contract, the --output-schema conformance fallback, the context-pack contents, and the typed-exception codes.

ops-preflight

Codex deep ops-safety review of a proposed Bash command BEFORE it executes. Invoke MANUALLY (via /ops-preflight) when the ops-risk-triage hook has emitted an `ask` for an infra_mutation, external_read, destructive, or unknown command and you want a second opinion on blast radius / rollback / required post-checks before approving. NOT for code review (use go-code-review). NOT auto-invoked.

go-tdd-bugfix

Use this skill for any request to fix a bug, debug a failure, or address a regression in code paths matching .tdd/tdd-config.json tier1_path_regexes. Reproduces the bug as a failing test BEFORE diagnosing or fixing. Two human approval gates.

go-tdd-feature

Use this skill for any request to implement, add, build, or create new functionality in code paths matching .tdd/tdd-config.json tier1_path_regexes. Drives spec -> APPROVED SPEC -> failing test -> APPROVED GREEN -> implementation -> APPROVED IMPLEMENTATION -> commit -> refactor, with three human approval gates.

Testing & QA Listed

go-test-writer

Write or extend Go tests following team conventions — table-driven, race-enabled, with pgx (testcontainers / pgxmock) and HTTP (httptest) patterns. Use when the user asks to add tests, write a test, write a regression test, write a fuzz/property test, or extend test coverage. Verifies results before reporting done.

new-module-scaffold

Scaffold a new Go service, package, or subsystem following the existing repo conventions (matches existing structure, names, entry points, test layouts). Use when the user asks to scaffold, create, or set up a new package / module / service / binary / worker / handler.

go-code-review

Run a Staff+ Go code review against the current diff (correctness, security, concurrency, AI-bloat, TDD ceremony, tests). Use when the user asks to review, audit, look at, sanity-check, or get a second opinion on the current changes / branch / PR. Applies REVIEW.md and rules in .claude/rules/.

go-debug

Debug Go failures by reproducing the bug as a focused test, tracing root cause, fixing minimally, and verifying with race-enabled tests. Use when the user mentions a bug, panic, deadlock, race, leak, hang, crash, segfault, regression, flaky test, or any Go failure that needs reproducing — for non-Tier-1 paths only (Tier 1 bugs use go-tdd-bugfix).

go-release-check

Pre-release Go checklist for services, libraries, and CLIs (tests + race + lint + govulncheck + allowed-modules + TDD ceremony + CHANGELOG + API docs). Use when the user asks to release, ship, deploy, cut a tag, prepare a release, or do a pre-release / pre-deploy check.

minimal-go-change

Plan and implement the smallest safe Go change with red-before-green where tractable. Use for any routine Go change to non-Tier-1 paths — small features, bug fixes, refactors, lint cleanups, dependency bumps, or any change where the user says "implement", "add", "fix", "update", "change", or "refactor" and the touched paths are NOT covered by .tdd/tdd-config.json tier1_path_regexes.

negative-diff

Post-implementation cleanup pass that explicitly looks for code to delete, inline, or reuse rather than add. Use after any implementation finishes and tests pass — before opening a PR — to remove AI-generated bloat, single-use abstractions, speculative config, dead exports, and tests that mirror implementation. Trigger when the user says "clean up", "simplify", "shrink the diff", "reduce bloat", "prepare PR", or whenever a PR exceeds ~200 lines.

Testing & QA Listed

specify

Spec-driven Layer 0 — capture intent, non-goals, acceptance criteria as a tracked spec under specs/ before writing any non-trivial code. Drives Specify -> Plan -> Tasks -> Implement with three human approval gates. Use whenever the user asks to design, plan, spec out, scope, or implement something that spans more than ~1 hour, touches public API, touches a Tier 1 path, or has non-trivial business invariants.