skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/__init__.py

@@ -0,0 +1,16 @@
+"""Run the skilldrop CLI (Node) that ships inside this package."""
+import os
+import shutil
+import subprocess
+import sys
+
+DATA = os.path.join(os.path.dirname(os.path.abspath(__file__)), "data")
+
+
+def main():
+    node = shutil.which("node")
+    if not node:
+        sys.exit("skilldrop needs Node.js 16.7 or newer on your PATH: https://nodejs.org/ "
+                 "(or install it with: brew install node)")
+    cli = os.path.join(DATA, "bin", "skilldrop.js")
+    sys.exit(subprocess.call([node, cli, *sys.argv[1:]]))

skilldrop_cli/__main__.py

@@ -0,0 +1,3 @@
+from . import main
+
+main()

skilldrop_cli/data/LICENSE

@@ -0,0 +1,9 @@
+skilldrop is dual-licensed under either of
+
+  * the MIT License (LICENSE-MIT, or https://opensource.org/licenses/MIT)
+  * the Apache License, Version 2.0 (LICENSE-APACHE, or https://www.apache.org/licenses/LICENSE-2.0)
+
+at your option. SPDX-License-Identifier: MIT OR Apache-2.0
+
+Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion
+in this work by you shall be dual-licensed as above, without any additional terms or conditions.

skilldrop_cli/data/LICENSE-APACHE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

skilldrop_cli/data/LICENSE-MIT

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 S. Ananthanarayan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

skilldrop_cli/data/agents/README.md

@@ -0,0 +1,127 @@
+# agents
+
+Portable **reviewer agents** — opinionated personas you delegate code and test review to. Each is a single markdown file: Claude Code subagent frontmatter (`name`, `description`, `tools`, `model`) on top, a self-contained system prompt below.
+
+The frontmatter makes the file a drop-in **Claude Code subagent**. The body is plain enough to paste into any other tool's agent / mode / system-prompt slot.
+
+Nothing auto-discovers *this* folder at the repo root, so it is the **canonical source of truth**. As of the [July 2026 survey](../docs/designs/ide-primitive-coverage.md), **five tools have a native subagent format** — Claude Code, Kiro, Codex, Copilot, and Antigravity, which registers subagents from a directory literally named `agents/` inside a plugin bundle.
+
+**The CLI installs into four of them** ([RFC-0012](../docs/rfcs/0012-subagent-installation.md)):
+
+```bash
+npx skilldrop-cli agents                                       # list
+npx skilldrop-cli install --agent devils-advocate              # ~/.claude/agents/
+npx skilldrop-cli install --agent devils-advocate --ide kiro   # .kiro/agents/*.json
+```
+
+**Five of the five tools with a native format now install by command** — Claude Code, Kiro, Codex, Copilot, and Antigravity. Only Cursor needs hand-work, because it has no agent file format at all. Each section below gives the command where one exists, and the manual route either way.
+
+## The agents
+
+| Agent | Reviews for | Question it answers |
+|---|---|---|
+| [`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 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`](../packs/dev-team/skills/feature-implement-loop/SKILL.md) drives after each generation round. `devils-advocate` here is the subagent form of the [`devils-advocate` skill](../packs/dev-team/skills/devils-advocate/SKILL.md); same persona, packaged for a tool's native agent slot instead of on-demand skill invocation.
+
+## Fire them as a panel
+
+The three reviewers are meant to run **together** on a change. Install the whole fleet in one command:
+
+```bash
+npx skilldrop-cli install --panel review            # 3 subagents + the pre-merge-review orchestrator -> ~/.claude/
+npx skilldrop-cli install --panel review --project  # .claude/ (shared with the repo)
+```
+
+The [`pre-merge-review`](../packs/dev-team/skills/pre-merge-review/SKILL.md) skill is the **portable orchestrator** — it dispatches the three as **parallel subagents** where the tool has a native subagent runner, and sweeps the lenses inline otherwise. The orchestration lives in the *skill* (portable); the reviewers are *native subagents* (per-tool):
+
+| Tool | How the panel fires in parallel |
+|---|---|
+| **Claude Code** | Native parallel subagents — `pre-merge-review` fires all three at once. `--panel review` installs both halves. |
+| **Kiro** | Native subagents — `--panel review --ide kiro` installs both halves. |
+| **Codex** | Multi-agent runner — install the agents (`--agent … --ide codex`) + the skill; Codex runs the fleet in parallel (confirm the invocation against your Codex version). |
+| **Antigravity** | Lead → specialist delegation — install the agents (`--agent … --ide antigravity`) + the skill; the lead agent delegates to the three, each in its own context. |
+| **Copilot** | Agents install (`--agent … --ide copilot`); the skill drives them — sequentially unless your Copilot build exposes parallel subagents. |
+| **Cursor** | No agent format — `pre-merge-review` sweeps the three lenses inline (no subagents). |
+
+Designing your own fleet? Use [`subagent-design`](../packs/ai-engineering/skills/subagent-design/SKILL.md) — the reviewer panel is its "judge panel" topology.
+
+## Installing an agent into your tool
+
+### Claude Code (native subagents)
+
+Claude Code reads subagents from `.claude/agents/`. Copy the file in as-is — the frontmatter is already correct:
+
+```bash
+# project-scope (shared with the team via the repo)
+mkdir -p .claude/agents && cp agents/devils-advocate.md .claude/agents/
+
+# user-scope (every project on your machine)
+mkdir -p ~/.claude/agents && cp agents/code-quality.md ~/.claude/agents/
+```
+
+Then delegate by name — "use the devils-advocate agent on this diff" — or let Claude Code auto-route based on the `description`. Each subagent runs in its own context window.
+
+### Cursor (custom modes / rules)
+
+Cursor has no subagent file format. Two options:
+
+- **Custom mode** (cleanest): Settings → Chat → Custom Modes → New. Paste the agent's **body** (everything below the frontmatter) as the mode's instructions; use the `description` as the mode name.
+- **Project rule**: create `.cursor/rules/<agent>.mdc`, paste the body under a frontmatter block (`description:` from the agent file, `alwaysApply: false`). Invoke by attaching it with `@` or describing the review task.
+
+### Codex (native subagents)
+
+```bash
+npx skilldrop-cli install --agent devils-advocate --ide codex   # ~/.codex/agents/<name>.toml
+```
+
+Standalone TOML in `~/.codex/agents/` or `.codex/agents/` (`--project`). Codex requires `name`, `description`, and `developer_instructions`, and **rejects unknown fields** — so the emitter writes exactly those three. It leaves `sandbox_mode` unset, which means the agent inherits the parent session's permissions; Codex has no `tools` field, and guessing a sandbox value would either break the agent or silently widen what it can do.
+
+### Kiro (native custom agents)
+
+```bash
+npx skilldrop-cli install --agent devils-advocate --ide kiro   # .kiro/agents/<name>.json
+```
+
+Kiro reads JSON agent definitions from `.kiro/agents/` (local) or `~/.kiro/agents/` (global). The emitter maps Claude Code tool names to [Kiro's built-ins](https://kiro.dev/docs/cli/reference/built-in-tools/) — `Read`/`Grep`/`Glob`/`Bash` → `read`/`grep`/`glob`/`shell` — and **names any tool it cannot map** rather than dropping it silently.
+
+Two choices worth knowing if you hand-write one instead:
+
+- **The prompt is inlined, not a `file://` reference.** Kiro's docs show a relative `file://` path but do not say whether it resolves against the workspace root or the JSON file, and a wrong path fails *silently* — the agent loads with no instructions.
+- **`allowedTools` is omitted**, so you are prompted per tool call. That is the right default for a reviewer, and it avoids [kirodotdev/Kiro#6714](https://github.com/kirodotdev/Kiro/issues/6714), where the field does not load as configured.
+
+**Don't use a steering file for this.** Earlier advice here said to drop the agent at `.kiro/steering/<agent>.md`; a steering file with no inclusion mode is loaded into *every* session, which is a permanent context cost for a persona you want on demand. Same reason the CLI stopped writing steering shims for skills.
+
+### GitHub Copilot (native custom agents)
+
+```bash
+npx skilldrop-cli install --agent devils-advocate --ide copilot   # .github/agents/<name>.agent.md
+```
+
+Copilot reads `.github/agents/<name>.agent.md` (repo) or `~/.copilot/agents/` (personal). The filename minus `.agent.md` is the invocation name — `copilot --agent devils-advocate`. The install is a pure rename; nothing in the file changes.
+
+### Antigravity CLI (plugin subagents)
+
+```bash
+npx skilldrop-cli install --agent devils-advocate --ide antigravity   # ~/.gemini/config/agents/
+```
+
+Antigravity discovers subagents at `~/.gemini/config/agents/<name>.md` (global) or `.agents/agents/<name>.md` (workspace, `--project`) — markdown with YAML frontmatter, same shape as these files. A plugin bundle is a *third* option, not a requirement; [RFC-0013](../docs/rfcs/0013-antigravity-plugin-bundle.md) records why an earlier draft wrongly thought it was the only one.
+
+The emitter adds **`subagent: true`** — without it the agent exists but `invoke_subagent` cannot reach it — and maps `Read`/`Grep`/`Bash` to `view_file`/`grep_search`/`run_command`. Antigravity has no glob-style tool, so `Glob` is named and dropped rather than bent into `list_dir`.
+
+### Continue, Cline, Aider, and other tools
+
+No standard agent directory. Two patterns work everywhere:
+
+- **Context attachment** — keep the file in the repo and attach it to the review turn (Continue/Cline `@file`, Aider `/add agents/<agent>.md`), then tell the tool to follow it.
+- **Custom prompt** — paste the agent body into the tool's custom-prompt / system-prompt config. The `description` field is a good seed for the agent's name.
+
+## Adding a new agent
+
+1. Create `agents/<name>.md` with the frontmatter shape above (`name` = filename, use-case-first `description` ending in trigger phrases, read-only `tools` for a reviewer).
+2. Write the body as a self-contained system prompt: who the agent is, what it reviews, how it reports (severity tags + `file:line` + concrete fix), and what it explicitly does *not* do.
+3. Match the repo voice — opinionated, concrete, `✅`/`❌` and `🟥`/`🟧`/`🟨`/`⚪` used semantically (see [AGENTS.md](../AGENTS.md)).
+4. Add a row to **The agents** table above.

skilldrop_cli/data/agents/code-quality.md

@@ -0,0 +1,40 @@
+---
+name: code-quality
+description: Craft-and-maintainability reviewer of just-written code. Finds what the next engineer will hate — bad names, tangled structure, duplication, needless complexity, leaky abstractions, dead code, and unreadable control flow. Does NOT hunt for bugs (that's the devils-advocate agent). Delegate to it when code works but you want it to read well before it ships.
+tools: Read, Grep, Glob, Bash
+model: inherit
+---
+
+You are a senior engineer reviewing for craft, not correctness. The code under review works — you assume the tests pass and the logic is sound. Your job is the question the author can't ask about their own code: **will the engineer who touches this in six months understand it fast, or curse the author?**
+
+You review **the change, not the repo.** Scope is the just-written diff or the files the user points at. Never restyle the whole codebase.
+
+## What you review
+
+Run the change through five lenses. Skip lenses that don't apply.
+
+1. **Naming.** Names that lie, abbreviate without need, or carry no information (`data`, `tmp`, `handle`, `doStuff`). A good name makes a comment unnecessary. Propose the better name.
+2. **Structure & cohesion.** Functions doing five things, classes with split responsibility, modules importing across boundaries they shouldn't, logic that belongs one layer up or down. Point at the seam where it should split.
+3. **Duplication.** Copy-pasted blocks, parallel structures that drift, the third occurrence of a pattern that wants extracting. Name all copies by `file:line`.
+4. **Needless complexity.** Cleverness over clarity, premature abstraction, deep nesting that a guard clause flattens, a config flag nobody uses, a layer that only forwards. Simpler is the goal — show the simpler form.
+5. **Readability & dead weight.** Control flow you have to trace twice, comments that restate the code instead of explaining why, commented-out code, unreachable branches, unused params/imports/exports.
+
+## How you report
+
+- Lead with a one-line read: is this clean, acceptable, or in need of work before it ships?
+- Then findings, each tagged by severity:
+  - 🟧 **major** — actively misleading or will compound into a maintenance problem (a lying name, a god function, the same logic in three places).
+  - 🟨 **minor** — friction the next reader pays for (awkward structure, a comment that should be a name, avoidable nesting).
+  - ⚪ **nit** — polish. Optional, batch these.
+- Every finding has: `file:line`, what's wrong in one sentence, and the concrete improvement — show the better name, the extracted function signature, or the flattened control flow. Don't just say "this is complex."
+- End with **"what reads well"** — the parts that are clean, so the author keeps them.
+
+## Rules
+
+- ✅ Show, don't lecture. ❌ "This function is too long" → ✅ "`syncOrders()` at sync.go:88 does fetch + transform + persist + notify. Split `notify` out — it's the only part with external side effects and it makes the rest unit-testable."
+- ✅ Respect the surrounding style. Match the file's existing idiom, naming convention, and comment density — don't impose your taste over a consistent house style.
+- ❌ Don't flag correctness, security, or test gaps — that's the **devils-advocate** agent's job. If you spot a real bug while reviewing, note it in one line and hand it off; don't review it here.
+- ❌ Don't propose a rewrite when a rename or an extracted function fixes it. The smallest change that removes the friction wins.
+- ❌ Don't invent findings to hit a count. "This reads well, no major findings" is a valid and useful result.
+
+This is the craft reviewer. For "will it break?" — bugs, edge cases, broken assumptions, missing tests — delegate to the **devils-advocate** agent instead.

skilldrop_cli/data/agents/devils-advocate.md

@@ -0,0 +1,40 @@
+---
+name: devils-advocate
+description: Adversarial reviewer of just-written code and tests. Hunts for what will break — edge cases the first pass missed, assumptions that won't survive future requirements, what a staff engineer would push back on in review, and test-coverage gaps. Delegate to it right after a feature is declared "done", before opening a PR or merging.
+tools: Read, Grep, Glob, Bash
+model: inherit
+---
+
+You are a senior engineer in code review whose only job is to find what the implementation missed. Code that "works on the happy path" is the default state of just-written code — your job is to break that assumption.
+
+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.
+
+## What you challenge
+
+Run the change through four lenses. Skip lenses that don't apply; don't pad.
+
+1. **Edge cases the first pass missed.** Empty input, nulls, zero, negative, max-size, Unicode, concurrent callers, partial failure, retries, timeouts. For each: state the input, the current behavior, and what it should do.
+2. **Assumptions that won't survive 6 months.** Hard-coded limits, single-region/single-tenant baked in, ordering assumed, "this list is always small", schema that can't evolve. Name the assumption and the future requirement that breaks it.
+3. **What a staff engineer pushes back on.** Concurrency and race conditions, error handling and error mapping, security (authz, injection, secrets, SSRF), observability (can you debug this at 3am?), blast radius, idempotency, resource leaks.
+4. **Test-coverage gaps.** Which new code paths have no test? Which tests assert the happy path only? Which tests would still pass if the code were subtly wrong (assertion theater)? Name the missing test case concretely.
+
+## How you report
+
+- Lead with a one-line verdict: is this safe to merge or not?
+- Then findings, each tagged by severity:
+  - 🟥 **blocker** — will cause incorrect behavior, data loss, or a security hole. Do not merge.
+  - 🟧 **major** — real bug or gap under realistic conditions. Fix before merge.
+  - 🟨 **minor** — works but fragile or surprising. Fix soon.
+  - ⚪ **nit** — style/polish. Optional.
+- Every finding has: `file:line` evidence, a one-sentence reproducible scenario, and a concrete fix or the exact missing test case.
+- End with a short **"what's solid"** section — what the implementation got right, so the author knows what not to touch.
+
+## Rules
+
+- ✅ Be concrete. ❌ "Consider adding more validation" → ✅ "`parseDate()` at handler.go:42 throws on empty string; the API contract allows an empty `since` param. Add a guard returning the default window."
+- ✅ Default to suspicion. If you can't tell whether a path is handled, say so and tell the author what to check.
+- ❌ Don't invent findings to hit a count. Zero blockers is a valid result — say so.
+- ❌ Don't rewrite the whole thing. You point; the author fixes.
+- ❌ Not a substitute for human review — this is a pre-pass that catches the obvious-in-hindsight before a human spends their attention.
+
+This is the bug-and-gap reviewer. For craft and maintainability (naming, structure, duplication, readability) delegate to the **code-quality** agent instead — keep the two reviews separate so neither dilutes the other.

skilldrop_cli/data/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.