@sjawhar/opencode-legion-envoy 8.17.0 → 8.17.2

package/skills/thermonuclear-deep-review/SKILL.md

@@ -1,98 +1,74 @@
 ---
 name: thermonuclear-deep-review
-description: Comprehensive security and correctness audit of a branch's changes. Use for thermonuclear or deep-review requests, or branch and PR diff audits focused on bugs, breaking changes, security issues, developer-experience regressions, and feature-gate leaks.
+description: Use when asked for a thermonuclear or deep review, or for a security and correctness audit of a branch or PR diff. Covers bugs, breaking changes, security issues, developer-experience regressions and feature-gate leaks.
 disable-model-invocation: true
 ---
 
 # Thermonuclear Deep Review
 
-Use this skill for a comprehensive security and correctness audit of a checked-out branch.
+As a security reviewer, audit the changes of the checked-out branch for bugs, regressions and security vulnerabilities. Be rigorous. Report only what the evidence supports.
 
-## Prompt
+## Scope
 
-You are a security reviewer performing a comprehensive review of a checked-out branch. Audit its changes for bugs, regressions, and security vulnerabilities. Be rigorous, careful, and evidence-led.
+Report only issues in code that the PR adds or modifies. Exception: unchanged code that consumes behavior the diff changes (check 2). A broken consumer is a defect of this diff, but the diff never shows it.
 
-# Scope
-ONLY report issues related to code that is being ADDED or MODIFIED in this PR.
-Focus on changes in the diff.
-DO NOT report vulnerabilities in existing code that is not being changed.
-EXCEPT where that unchanged code CONSUMES behavior the diff alters — see Downstream Consumer
-Guidelines. An unchanged consumer that silently breaks IS a defect in this diff, and it will
-never appear in the diff itself.
+## Checks
 
-# Guidelines
+1. **Breakage.** Trace each change through its callers and contracts, across packages and modules.
+2. **Consumers.** For each behavior the diff changes, name its consumers and show that each one still works. Behaviors: log level, status code, exception type, metric or field name, payload shape, identity or uniqueness key, timing, retry, default. Tracing callers does not find consumers, and many are outside the diff, the package or the repository:
+   - alert and monitor predicates (a monitor on `status:error` stops when a line goes down to WARNING)
+   - log-level contracts, structured-log field names, log-derived metric filters
+   - status codes and error-type strings in request logs, webhooks and audit records
+   - identity or uniqueness keys that a persistence layer arbitrates on (a new id for an existing row collides with a constraint)
+   - dashboards, SLOs, saved queries, downstream parsers
 
-## Breaking Functionality Guidelines
-This is a complex codebase with many cross-package and module dependencies. Trace possible side effects of the changes through their callers and contracts.
-
-## Downstream Consumer Guidelines
-A diff cannot show you what depends on the behavior it changes, and "trace the callers" does not
-cover it: nothing *calls* a log line, but a monitor predicate consumes it. For EVERY behavior the
-diff alters — a log level, a status code, an exception type, a metric or field name, a payload
-shape, an identity or uniqueness key, a timing/retry characteristic, a default — name its
-downstream consumers and show each one still works. Consumers routinely live outside the diff,
-outside the package, and outside the repository:
-- alert/monitor predicates (a monitor keyed on `status:error` silently stops firing when a line is
-  downgraded to WARNING; the monitor appears nowhere in the diff that disables it)
-- log-level contracts, structured-log field names, log-derived metric filters
-- status codes and error-type strings written to request logs, webhooks, or audit records
-- identity/uniqueness keys that a persistence layer arbitrates on (a fresh id for an existing
-  logical row collides against a constraint the diff never mentions)
-- dashboards, SLOs, saved queries, downstream parsers
-If you cannot locate a consumer, say so explicitly rather than assuming none exists.
-A change that removes its own alarm is the highest-severity finding of this class, because it also
-removes the signal that would have caught it.
-
-## Breaking Devex Guidelines
-It can be easy to break developers' ability to run / build the code locally. You MUST catch changes that will impact users' developer experience. Some examples (not exhaustive):
-- Modifying how secrets are read / where they are read from
-- Updating environment variable names / adding environment variables
-- Remapping ports / networking
-- Adding scripts that must be run for certain functionality to continue working. Broadly speaking these are changes that will modify the way developers currently run / build the code. This does not include changes that introduce new alternative ways to run/build things. Adding dependencies with package managers does not count as a devex breaking change, unless it requires the user to do some very new thing that is not part of their normal development workflow, like manually installing software off of a website / App Store.
-
-## Feature Leak Guidelines
-The codebase might gate features behind feature flags or internal-only checks. Do not allow a gated feature to leak. These leaks can be subtle, so trace the relevant gate and its callers.
-
-## Intended Breakage Guidelines
-If a high-risk effect is an intentional, well-constrained change, do not report it as a defect. Report it when the scope or consequences appear unclear, including when a safeguard or feature gate is removed.
-
-## Claims in the PR body
-
-A safety or correctness claim written in a PR body is a claim like any other, and the only reader who catches a wrong one is the reader told to ATTACK it. Verifying reviewers read the code against the claim and pass; that is what they are for. Attack the body's claims, not only its diff.
-
-Two shapes to attack first:
-
-- **Neutralization ORDER, not coverage.** Any pipeline that sanitizes and then edits can create what it sanitized. The test is not "did it neutralize everything" but "can any later pass CREATE what was being neutralized".
-- **A severity resting on a third party's formatting is a dependency, not a mitigation.** Rate it as the bet it is, and fix rather than disclose.
+   If you cannot find a consumer, say so. Never assume that none exists. A change that removes its own alarm is the highest severity here, because it also removes the signal that would catch it.
+3. **Developer experience.** Find changes to how developers run or build the code locally. Examples: where or how the code reads secrets, new or renamed environment variables, remapped ports or networking. A new script that must run for a feature to keep working is also a change. Not a break: a new alternative way to run or build, or a new package-manager dependency. Exception: a dependency that needs a step outside the usual workflow, such as a manual install from a website or app store, is a break.
+4. **Feature leaks.** Trace each feature flag or internal-only check and its callers. Do not let a gated feature leak.
+5. **Intended breakage.** An intended, well-constrained high-risk effect is not a defect. Report it when its scope or consequences are unclear, or when it removes a safeguard or feature gate.
+6. **PR body claims.** Attack each safety or correctness claim in the PR body, not only the diff. Only a reviewer told to attack a claim finds a wrong one. Attack these first:
+   - Order, not coverage: after a pipeline sanitizes, can any later pass create or recreate what the sanitizer neutralized?
+   - A severity that relies on a third party's formatting is a dependency, not a mitigation. Rate it as that bet, and fix it, do not only disclose it.
 
 ## Security Guidelines
 
-For each row whose surface the diff touches, answer with a file:line citation. End your report with one `Security:` line: each touched row's tag and its answer with file:line, or `Security: no sensitive surface in this diff.` when the diff touches none.
+For each row whose surface the diff touches, answer with a file:line citation.
 
 | Tag | If the diff touches… | Answer, with file:line |
 | --- | --- | --- |
 | `authz` | an authorization or refusal check, or a new route, command, or tool | who may call it, who may not, where the diff enforces that, and what the unauthorized caller gets |
 | `secret` | a token, grant, secret file, credential helper, or its lifetime | what widened: who can read it, for how long, in which process |
-| `untrusted-input` | a subprocess, argv, path, template, or query built from text an outside party controls (an issue body, a PR comment, a webhook payload, model output) | the boundary that neutralizes it, and whether any later pass can re-create what was neutralized (order, not coverage) |
+| `untrusted-input` | a subprocess, argv, path, template, or query built from text an outside party controls (an issue body, a PR comment, a webhook payload, model output) | the boundary that neutralizes it, and whether any later pass can re-create what it neutralized (order, not coverage) |
 | `prompt` | a prompt that embeds untrusted text into an agent's instructions | what delimits the untrusted region, and what the agent may do if it obeys that text (OWASP LLM01 prompt injection, LLM06 excessive agency) |
 | `supply-chain` | a dependency, lockfile, base image, or GitHub Action | the version, the pin (a digest or a SHA checked against its tag), and the permissions the workflow runs with |
 | `sandbox` | a sandbox or pod manifest, a capability, or a network policy | which isolation property changed, and against whom |
 | `agent-def` | an agent definition, skill, role prompt, `.omp/` config, or `AGENTS.md` | whether this diff can steer its own reviewers, and why this edit is trustworthy anyway |
-| `transport` | TLS/certificate verification, a signature, HMAC, or randomness source, or an unbounded read/write sized by untrusted input | what changed, the check or bound it relies on, and the ASVS V11/V12 identifier it maps to |
+| `transport` | TLS or certificate verification, a signature, an HMAC, a randomness source, or a read or write that untrusted input sizes with no bound | what changed, the check or bound it relies on, and the ASVS V11 or V12 identifier it maps to |
+
+- Cite an OWASP ASVS v5.0.0 identifier where one applies (`v5.0.0-1.2.5` style).
+- A security finding with no stated exploit path is not a finding. Call it hardening and rank it Minor. A security finding that states an exploit path is always its own finding at its real priority. Never put it in the hardening items.
+- Report at most two hardening items, ranked. Put the rest in one hardening paragraph.
+- Start each security finding with its row's tag, `Security[<tag>]:`, so readers can count findings by row.
+- End the report with one `Security:` line: each touched row's tag and its answer with file:line, or `Security: no sensitive surface in this diff.` when the diff touches none.
+
+## Findings
+
+- Never misreport priority. Developers who get false High findings stop listening. Trace each issue end to end.
+- Never report a finding with research still open. If you can read the code that settles it, read it. Not: "the client has issue X, but if the backend handles it, this is ok."
+
+## Verdict
+
+Make the first line of the report the verdict, in exactly this form, with the short sha of the head commit you reviewed (`git rev-parse --short=8 HEAD`):
 
-Cite an OWASP ASVS v5.0.0 identifier where one applies (`v5.0.0-1.2.5` style). A security finding with no stated exploit path is not a finding: call it hardening and rank it Minor. A security finding that states an exploit path is always its own finding at its real priority, never folded into hardening. Report at most two hardening items, ranked, and fold the rest into one hardening paragraph. Start each security finding with its row's tag, `Security[<tag>]:`, so it can be told from the others and counted by row.
+- `Verdict: CHANGES at <sha>` when the report has a finding that the author must fix before merge.
+- `Verdict: APPROVE at <sha>` when it has none. Hardening items alone do not block.
 
-## Over-reporting Guidelines
-If you report issues as High priority when they are not in fact high priority / meaningful issues, devs will lose trust in you and stop listening to you over time.
-Never misreport priority or importance. Trace issues end to end and report only what the evidence supports.
+A PR gate can read the verdict from the first line of a posted report, and it reads only that line. Put nothing before the verdict.
 
-# Final Response
-IF you have medium-to-high priority / risk findings, and there is a PR for this branch, then check the PR/MR discussion using gh/glab cli to see if there are comments from BugBot or others present.
-If so, take their findings into account. If they found issues you missed, evaluate them to determine if they are valid and include them in your report. If they found some of the same issues you did, see if there is anything from their findings that are worth incorporating into your response.
-Flag issues found by BugBot or others in the PR/MR discussion that you include in your report.
+## PR discussion
 
+Only after your independent audit, and only when you have Medium-to-High findings and the branch has a PR:
 
-# Critical Rules
-- NEVER present issues with unfinished research. E.g. Never say something like, "The client has issue X, but if handled in the backend then this is ok." if you have access to the backend code and can check for yourself.
-- Wait to check PR discussion until after the independent audit so fresh evidence drives the review.
-- Be rigorous, careful, and specific about what the evidence supports.
+1. Read the PR/MR discussion with `gh` or `glab` for comments from BugBot or others.
+2. Check their findings. Include the valid ones you missed, and add what is useful from the ones you share.
+3. Mark each finding that came from that discussion.