Claude Skills by oribarilan

`patch-trigger-coverage-gaps` (US-v0.3-council-feedback) decided in v0.3 to **defer** carving a dedicated code-review skill. Reviewing someone else's PR is a real agent situation — increasingly common as agents participate in PR workflows — but `pre-commit-self-review` is self-only and `working-with-users-and-team` (post-prune) keeps PR review at most as a passing reference.

Use when implementing any feature or bugfix, before writing implementation code

**Council confidence:** [Consensus] — all 5 councillors named security as the largest behavioral gap in the bundle.

The current bundle has **no skill for observability**. The 2010s+ canon (Google's *Site Reliability Engineering*, Honeycomb-era distributed tracing, structured-logging best practices, the OpenTelemetry project) has produced a body of agent-actionable practice that is currently squeezed into `error-and-correctness-traps` (logging only) and the operational shape implied by 12-factor logs (in `build-deploy-and-tooling`).

Use when designing or reviewing a public API, exported function signature, module boundary, exported type/interface, or any contract other code depends on

Use when considering, evaluating, or performing a refactor, restructure, cross-file rename, or cleanup

Use when writing, reviewing, or changing build scripts, CI workflows, deploy pipelines, repo setup, or evaluating a new tool/dependency

Use when writing or reviewing functions, classes, naming, or non-trivial logic (≥3 lines)

Use when writing or reviewing error handling, floating-point math, concurrent code, remote calls, singletons/globals, hot-path data structures, or high-volume log statements

Use when introducing, reviewing, or renaming a top-level type, table, or domain concept; or choosing where state lives (in-memory vs persistent)

Use when writing or reviewing request handlers, RPCs, or background jobs for production; adding tracing, metrics, or structured-log calls; or making diagnosability decisions

Use when writing or reviewing code that parses user input, builds SQL/shell commands, handles secrets/credentials, hashes passwords, changes auth checks, deserializes untrusted data, or constructs paths/URLs from input

Use when about to commit, finish a task, open a PR, summarize work for the user, or when the user asks for a review or summary — NOT just on autonomous commits, which are rare in OpenCode usage

Use when writing or reviewing tests, designing test data, naming a test, choosing what to assert, or writing test helpers/mocks/fixtures

Use when starting any coding task — establishes the 97 trigger map so principles fire when relevant

Use when gathering or interpreting requirements, estimating effort, or communicating with stakeholders/customers about what to build