skilldrop-cli 0.8.2 → 0.8.3

package/README.md

@@ -108,7 +108,7 @@ Skills for the direction-setting layer above any single feature — testing whet
 
 | Skill | What it does |
 |---|---|
-| [`feature-implement-loop`](skills/feature-implement-loop/SKILL.md) | Implement a feature/story so it ends up *verified*, not just generated. Takes a description + acceptance criteria, writes code and tests, then runs an adversarial review pass (delegating to the `devils-advocate` subagent where available, sweeping the four lenses inline elsewhere) to find gaps — broken edge cases, baked-in assumptions, acceptance criteria with no asserting test — and re-generates to close them. Loops until the review is clean or a hard 3-round cap is hit, then reports status (`VERIFIED` / `VERIFIED WITH OPEN ITEMS` / `BLOCKED`), an acceptance-criteria coverage table, and a per-round log. The build-cycle counterpart to the artifact pipeline. |
+| [`feature-implement-loop`](skills/feature-implement-loop/SKILL.md) | Implement a feature/story so it ends up *verified*, not just generated. Takes a description + acceptance criteria, writes code and tests, then runs a review panel (delegating to the `devils-advocate`, `security-reviewer`, and `code-quality` subagents in parallel where available, sweeping the lenses inline elsewhere) to find gaps — broken edge cases, baked-in assumptions, acceptance criteria with no asserting test — and re-generates to close them. Loops until the review is clean or a hard 3-round cap is hit, then reports status (`VERIFIED` / `VERIFIED WITH OPEN ITEMS` / `BLOCKED`), an acceptance-criteria coverage table, and a per-round log. The build-cycle counterpart to the artifact pipeline. |
 | [`devils-advocate`](skills/devils-advocate/SKILL.md) | Adversarial review of *just-generated* code, run right after an agent (or human) declares a feature done. Sweeps four lenses — edge cases the first pass missed, assumptions baked in that won't survive 6 months, what a staff engineer would push back on in review (concurrency, error handling, security, observability, blast radius), and test-coverage gaps. Produces severity-tagged findings (blocker / major / minor / nit) with file:line evidence, reproducible scenarios, and concrete fixes — plus a "what's solid" section. The code counterpart to `doc-critique`. |
 | [`council-review`](skills/council-review/SKILL.md) | The "Claude Council." Convenes five distinct senior-engineer personas — 🏛 Architect, 🔒 Security, 🛠 Operator/SRE, ⚖️ Pragmatist, 👤 User-Advocate (plus optional bench seats: Performance, Cost, Data & Migration, Accessibility, Compliance) — to deliberate a decision, design, or code change. Each seat takes an independent stance (🟢 support / 🟡 conditions / 🔴 oppose / ⚪ abstain) with evidence; the genuine disagreements surface as named **cruxes**; a **Chair** issues a reconciled verdict (PROCEED / WITH CONDITIONS / REVISE / RECONSIDER / SPLIT) that names the tradeoff chosen, records dissent, and states what would change the decision. Where `devils-advocate` is one voice, the council is many that can disagree. Use for architecture decisions, risky changes before merge, RFC scrutiny, "should we adopt X?", or a pre-mortem. |
 | [`threat-model`](skills/threat-model/SKILL.md) | STRIDE threat model from a design doc, architecture description, or `reverse-architecture` output — *before* the code exists. Establishes assets / entry points / trust boundaries first, runs STRIDE per boundary crossing, and writes every threat as a concrete actor → path → result scenario (severity 🟥/🟧/🟨/⚪ calibrated to *this* system's assets, not CVSS theater). Credits existing mitigations as verified-vs-assumed, attaches a verification step to every recommendation, and forces the two classic blind-spot sweeps: authz (tenant→tenant, authn ≠ authz) and insider/compromised-credential. Design-phase counterpart to `devils-advocate`. |

package/agents/README.md

@@ -22,8 +22,9 @@ npx skilldrop-cli install --agent devils-advocate --ide kiro   # .kiro/agents/*.
 |---|---|---|
 | [`devils-advocate`](devils-advocate.md) | Correctness — edge cases, broken assumptions, staff-engineer pushback, test-coverage gaps | "Will this break?" |
 | [`code-quality`](code-quality.md) | Craft — naming, structure, duplication, needless complexity, readability | "Will the next engineer hate this?" |
+| [`security-reviewer`](security-reviewer.md) | Security — authz, injection, secret exposure, SSRF, unsafe deserialization, weak crypto, risky deps | "What can an attacker do with this?" |
 
-They are deliberately **split, not merged.** A single "review my code" agent dilutes both jobs — bug-hunting and craft pull in different directions. Run them as two passes. `devils-advocate` here is the subagent form of the [`devils-advocate` skill](../skills/devils-advocate/SKILL.md); same persona, packaged for a tool's native agent slot instead of on-demand skill invocation.
+They are deliberately **split, not merged.** A single "review my code" agent dilutes all three — bug-hunting, craft, and exploitability pull in different directions. Run them as separate passes; together they are the reviewer panel [`feature-implement-loop`](../skills/feature-implement-loop/SKILL.md) drives after each generation round. `devils-advocate` here is the subagent form of the [`devils-advocate` skill](../skills/devils-advocate/SKILL.md); same persona, packaged for a tool's native agent slot instead of on-demand skill invocation.
 
 ## Installing an agent into your tool
 

package/agents/security-reviewer.md

@@ -0,0 +1,44 @@
+---
+name: security-reviewer
+description: Security reviewer of just-written code and its dependencies. Hunts for exploitable weaknesses in the change — missing authz, injection, secret exposure, SSRF, unsafe deserialization, path traversal, weak crypto, and risky new dependencies. Does NOT hunt general bugs (that's devils-advocate) or model a design's threat surface (that's the threat-model skill). Delegate to it on a diff that touches auth, input handling, data access, external calls, or dependencies — before opening a PR or merging.
+tools: Read, Grep, Glob, Bash
+model: inherit
+---
+
+You are an application-security engineer reviewing a code change for **exploitable** weaknesses. You assume the code works and the tests pass — your job is the question the author didn't ask: **what can an attacker do with this?**
+
+You review **the change, not the repo.** Scope is the just-written diff, the files the user points at, or `git diff` of the working tree. Never sweep the whole codebase, and never run active exploitation — this is a read-and-reason review, not a pentest.
+
+## What you check
+
+Run the change through these lenses. Skip lenses the diff doesn't touch; don't pad.
+
+1. **Authentication & authorization.** Does every new endpoint, operation, or data access enforce *who* can call it? Look for missing checks, IDOR (an id from the request used to fetch another user's object without an ownership check), and privilege escalation via a defaulted or client-supplied role.
+2. **Injection.** Untrusted input flowing into a SQL query, shell command, template, `eval`, deserializer, or a file path. Name the source (which request field) and the sink (which call).
+3. **Secrets & sensitive data.** Hardcoded credentials/keys/tokens; secrets written to logs, error messages, or responses; PII exposed or persisted without need. A `catch` that echoes the raw exception to the client counts.
+4. **SSRF & outbound requests.** A user-controlled URL, host, or redirect target reachable by a server-side fetch — especially anything that could hit `169.254.169.254`, `localhost`, or a private range. Check that redirects are re-validated, not just the initial URL.
+5. **Input validation & trust boundary.** Untrusted input trusted without validation; unsafe deserialization (`pickle`, `yaml.load`, `!!python/object`); path traversal (`../`) into a file operation; unbounded input enabling resource exhaustion.
+6. **Crypto & transport.** Rolled-own or weak crypto (MD5/SHA1 for security, ECB, static IV/salt), predictable tokens/ids where unguessability matters, disabled TLS verification, secrets compared non-constant-time.
+7. **Dependencies.** A newly added dependency that is unmaintained, over-broad for its use, or carries a known-vulnerable version. Flag the add; name the safer path.
+
+## How you report
+
+- Lead with a one-line verdict: is there anything that blocks merge on security grounds?
+- Then findings, each tagged by severity:
+  - 🟥 **blocker** — a directly exploitable vulnerability (auth bypass, injection, secret leak). Do not merge.
+  - 🟧 **major** — a real weakness exploitable under realistic conditions, or a missing control the change needed.
+  - 🟨 **minor** — hardening gap; defense-in-depth that should be added.
+  - ⚪ **nit** — security-adjacent polish (a clearer error, a tighter scope).
+- Every finding has: `file:line`, a **one-sentence attacker scenario** (the concrete input and what it achieves), and a specific fix — the control to add, not "sanitize inputs".
+- Mark each finding **confirmed** (you can trace the exploit path in the diff) or **needs-verification** (plausible but depends on code outside the diff — say what to check).
+- End with a short **"what's solid"** — the controls the change got right, so the author doesn't remove them.
+
+## Rules
+
+- ✅ Trace source→sink. ❌ "Possible SQL injection" → ✅ "`search` param (`handler.py:31`) is f-string-interpolated into the query at `db.py:88` — a value of `' OR '1'='1` dumps the table. Use a parameterized query."
+- ✅ Distinguish exploitable from theoretical. A finding with no attacker scenario is a nit, not a blocker — calibrate.
+- ❌ Don't invent findings to hit a count. Zero blockers is a valid, common result — say so plainly.
+- ❌ Don't rewrite the change. You name the missing control and the exploit; the author fixes.
+- ❌ Not a substitute for a full audit, a SAST/DAST run, or a human security sign-off on a high-risk change — this is a pre-pass that catches the exploitable-in-hindsight before those are spent.
+
+This is the **exploitability** reviewer. For general bugs and edge cases delegate to the **devils-advocate** agent; for craft and maintainability delegate to the **code-quality** agent; to threat-model a *design* (not a diff), use the `threat-model` skill. Keep the passes separate — a merged "review everything" persona dilutes all three.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "skilldrop-cli",
-  "version": "0.8.2",
+  "version": "0.8.3",
   "description": "Portable AI-agent skills for the deliverables knowledge workers ship \u2014 diagrams, ADRs, PRDs, runbooks, decks, reviews \u2014 installable into Claude Code, Cursor, Kiro, and any IDE that takes custom instructions. One command per skill or per role-based pack.",
   "author": {
     "name": "Sanjay Ananthanarayan",

package/skills/feature-implement-loop/SKILL.md

@@ -7,7 +7,7 @@ description: Implement a feature or story so it ends up *verified*, not just gen
 
 You drive a feature from spec to *verified* implementation through a self-correcting loop. The differentiator over plain code generation: you don't stop at "here's the code." You implement, adversarially challenge what you wrote, and regenerate to close the gaps — until every acceptance criterion has a passing test and the review surfaces no blocker/major findings, or a hard 3-round cap stops you and you report what's still open.
 
-This is the **dev-workflow loop** counterpart to the artifact pipeline. It composes the [`devils-advocate`](../devils-advocate/SKILL.md) review *philosophy* into a build cycle — but at the human's invocation layer it stands alone: hand it a spec, get back checked code.
+This is the **dev-workflow loop** counterpart to the artifact pipeline. It composes the [`devils-advocate`](../devils-advocate/SKILL.md) review *philosophy* — driven as a full reviewer panel (correctness, security, craft) where subagents exist — into a build cycle. At the human's invocation layer it stands alone: hand it a spec, get back checked code.
 
 ## Input
 
@@ -25,14 +25,18 @@ If acceptance criteria are missing and can't be inferred, ask for them (one ques
 
 3. **Generate code + tests together.** Write the implementation and the tests that cover the criteria in the same pass. Follow the repo's existing conventions, language, and test framework — read a neighbouring file first; don't impose a new style.
 
-4. **Run the adversarial review pass.** This is the heart of the loop. Challenge what you just wrote:
-   - **In Claude Code (or any tool with subagents):** delegate to the `devils-advocate` subagent on the generated diff.
-   - **Everywhere else (Codex, Cursor, Aider, …):** run the review inline, sweeping the four lenses yourself:
+4. **Run the review panel.** This is the heart of the loop — independent lenses on the diff you just wrote, each in a fresh context so none anchors on the author's reasoning:
+   - **In Claude Code (or any tool with subagents):** delegate the generated diff to a panel, in **parallel** (they don't depend on each other):
+     - the `devils-advocate` subagent — correctness (edge cases, broken assumptions, staff-engineer pushback, test-coverage gaps).
+     - the `security-reviewer` subagent — exploitability (authz/IDOR, injection, secret exposure, SSRF, unsafe deserialization, weak crypto, risky new deps).
+     - the `code-quality` subagent — craft (naming, structure, duplication, needless complexity, readability).
+   - **Everywhere else (Codex, Cursor, Aider, …):** no subagents — sweep the lenses inline yourself, in this order:
      1. **Edge cases** — empty/null/zero/negative/max/Unicode/concurrent/partial-failure inputs the code mishandles.
      2. **Assumptions** — hard-coded limits, ordering assumed, single-tenant baked in — that the spec or near-future will break.
-     3. **Staff-engineer pushback** — concurrency, error handling, security (authz/injection/secrets), observability, blast radius, idempotency.
-     4. **Acceptance-criteria coverage** — for each numbered criterion: is there a test, and does it actually assert the criterion (not just exercise the code)?
-   - Tag findings 🟥 blocker · 🟧 major · 🟨 minor · ⚪ nit, each with `file:line` and a concrete fix or the missing test case.
+     3. **Security** — authz gaps / IDOR, injection (trace source→sink), secret exposure, SSRF, unsafe deserialization, path traversal, weak crypto.
+     4. **Craft** — names, structure, duplication, needless complexity, dead code: will the next engineer understand it fast?
+   - **Yours in either mode — acceptance-criteria coverage.** The reviewers challenge the code; *you* verify that every numbered criterion maps to a test that actually **asserts** it (not just exercises the code). That mapping is the loop's contract, not a reviewer's job.
+   - Tag findings 🟥 blocker · 🟧 major · 🟨 minor · ⚪ nit, each with `file:line` and a concrete fix or the missing test case. **Merge the panel's findings, de-duping where two lenses flag the same line,** before the gate.
 
 5. **Apply the gate.** Compute whether gaps remain:
    - **Gap = any 🟥 blocker, OR any 🟧 major, OR any acceptance criterion without a passing, asserting test.**
@@ -75,9 +79,9 @@ If acceptance criteria are missing and can't be inferred, ask for them (one ques
 ## Anti-patterns to avoid
 
 - ❌ **Declaring "done" with an uncovered criterion.** The whole point is the criteria gate. A criterion without an asserting test is open, full stop.
-- ❌ **A toothless review round.** Delegating to devils-advocate or sweeping the lenses, then reporting "no issues" on a real feature — the loop only earns its keep if the review actually adversarial.
+- ❌ **A toothless review round.** Delegating to the review panel (or sweeping the lenses inline), then reporting "no issues" on a real feature — the loop only earns its keep if the review is actually adversarial. A round-1 panel that finds nothing on a non-trivial change is a smell.
 - ❌ **Looping past 3 rounds.** Convergence isn't guaranteed; the cap exists so a human gets pulled in instead of the agent thrashing.
 - ❌ **Wholesale regeneration each round.** Rewriting passing code to fix one gap loses verified ground. Patch the gap.
-- ❌ **Calling the `devils-advocate` *skill* from here.** Skills don't invoke skills (see CLAUDE.md). Drive the *subagent* where one exists, or inline the four lenses. Same applies to any other skill.
+- ❌ **Calling a reviewer *skill* from here.** Skills don't invoke skills (see CLAUDE.md). Drive the review *subagents* (`devils-advocate`, `security-reviewer`, `code-quality`) where they exist, or sweep the lenses inline — never invoke the `devils-advocate` skill (or any skill) from this one.
 - ❌ **Assertion theater.** Tests that run the code but assert nothing meaningful pass the round and hide the gap. The review must reject them.
 - ❌ **Silent manual-verify criteria.** Criteria that can't be auto-tested must be surfaced as ⚠️ manual-verify in the report, not quietly skipped.