@sjawhar/pi-legion 0.0.0 → 8.0.0

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

@@ -0,0 +1,98 @@
+---
+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.
+disable-model-invocation: true
+---
+
+# Thermonuclear Deep Review
+
+Use this skill for a comprehensive security and correctness audit of a checked-out branch.
+
+## Prompt
+
+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.
+
+# 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.
+
+# Guidelines
+
+## 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.
+
+## 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.
+
+| 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) |
+| `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 |
+
+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.
+
+## 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.
+
+# 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.
+
+
+# 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.

package/package.json

@@ -1 +1,43 @@
-{"name":"@sjawhar/pi-legion","version":"0.0.0","license":"Apache-2.0"}
+{
+  "name": "@sjawhar/pi-legion",
+  "version": "8.0.0",
+  "license": "Apache-2.0",
+  "type": "module",
+  "omp": {
+    "extensions": [
+      "dist/legion.js"
+    ],
+    "skills": [
+      "dist/skills"
+    ]
+  },
+  "legion": {
+    "daemonApiVersion": 14
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/sjawhar/legion"
+  },
+  "files": [
+    "dist",
+    "agents"
+  ],
+  "scripts": {
+    "build": "bun build extensions/legion.ts --outdir dist --target bun --format esm --external @oh-my-pi/pi-coding-agent --external @oh-my-pi/pi-tui --external @oh-my-pi/pi-utils",
+    "prepack": "../../scripts/pi-plugin-prepack.sh",
+    "postpack": "rm -rf dist/skills",
+    "typecheck": "bunx tsc --noEmit",
+    "test": "bun test",
+    "lint": "bunx biome lint extensions/ src/"
+  },
+  "devDependencies": {
+    "@biomejs/biome": "^2.3.14",
+    "@legion/contracts": "0.10.0",
+    "@legion/envoy-client": "0.1.0",
+    "@legion/pi-shared": "0.1.0",
+    "@oh-my-pi/pi-utils": "^18.1.15",
+    "@types/bun": "latest",
+    "typescript": "^5.3.0",
+    "zod": "4.3.6"
+  }
+}