skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/dev-team/skills/bug-triage/templates/bug-ticket.md

@@ -0,0 +1,86 @@
+# Bug-ticket template
+
+Every claim carries a tag: `[reported]` (the reporter says so), `[verified]` (confirmed by log/screenshot/own repro), `[assumption]` (triager's default). Untagged statements are the anti-pattern.
+
+```markdown
+# {Symptom + condition — searchable: "Checkout button stays disabled after removing expired coupon (Safari 17, guest cart)"}
+
+**Severity:** S{1–4} — {one line: worst plausible user impact}
+**Priority:** P{1–3} — {one line: business urgency, judged separately}
+**Blast radius:** {all users | segment | one tenant} `[reported|verified|assumption]`
+**Component (best guess):** {area} `[assumption]`
+
+## Summary
+
+{2–3 sentences: who hits it, doing what, with what result. No cause claims.}
+
+## Environment
+
+| Field | Value | Tag |
+|---|---|---|
+| App version / commit | … | `[verified]` |
+| OS / browser / device | … | `[reported]` |
+| Account / tenant type | … | `[reported]` |
+| First seen / last worked | … | `[reported]` |
+
+## Reproduction
+
+{Pick exactly one of the two blocks:}
+
+**Steps (from clean state):**
+1. {fresh session, named test account, starting URL}
+2. {observable action}
+3. {observable action → failure}
+**Reproduces:** {n/n attempts} `[verified]`
+
+**— or — No repro yet.** Collect:
+- Verbatim error text / screenshot of the exact moment
+- Console or server logs for {window} around {timestamp}
+- HAR capture / request ID of the failing call
+- Screen recording if UI-state dependent
+
+## Expected vs actual
+
+**Expected:** {concrete, one line}
+**Actual:** {concrete, one line}
+**Error (verbatim):** `{exact string, or "none shown"}`
+
+## Hypotheses (≤3 — each with a 5-minute check; none of these is a conclusion)
+
+| # | Hypothesis | Quick check |
+|---|---|---|
+| H1 | … | … |
+
+## Questions for reporter (≤3, ranked by diagnostic value)
+
+1. …
+
+## Duplicate-search hints
+
+`{error code}` · `{symptom phrase}` · `{component + verb}`
+
+## Split out (if the report contained more than one issue)
+
+- {symptom} → {new ticket ref / to be filed}
+```
+
+## Severity / priority matrix
+
+**Severity — worst plausible user impact (not who reported it):**
+
+| | Definition | Examples |
+|---|---|---|
+| S1 | Data loss, security exposure, payments broken | double-charge; cross-tenant read; corrupted saves |
+| S2 | Core flow broken, no workaround | can't log in; checkout dead-ends |
+| S3 | Degraded, workaround exists | export fails but copy-paste works; retry succeeds |
+| S4 | Cosmetic / minor friction | misalignment; typo; flicker |
+
+**Priority — business urgency (judged independently):**
+
+| | Definition |
+|---|---|
+| P1 | Drop current work; fix and ship now |
+| P2 | This sprint |
+| P3 | Backlog, batch with related work |
+
+Legitimate mismatches prove the separation: S4/P1 (typo in the price during launch week), S2/P3 (core flow of a feature being sunset next month).

skilldrop_cli/data/packs/dev-team/skills/contribution-wizard/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: contribution-wizard
+description: Guides an author through creating a new skilldrop skill from scratch — generates the manifest, SKILL.md, eval cases, and skill-catalogue entry from a plain-language description of the skill's purpose. Use when authoring a new skill for this repo or a private fork, ensuring a new skill meets the schema and validation requirements before submission.
+---
+
+# contribution-wizard
+
+Walks an author through the full arc of creating a new skilldrop skill: intake → manifest + SKILL.md + evals + skill-catalogue entry. The output is copy-paste-ready — the author drops the files into `packs/<pack>/skills/<name>/` and runs `python3 validate.py` to confirm before opening a PR.
+
+## How to respond
+
+### Step 1 — Intake (ask all at once)
+
+Ask these questions in a single block — not one at a time:
+
+> **New skill intake**
+>
+> 1. **Purpose**: what does this skill do in one sentence?
+> 2. **Input**: what does the agent receive? (paste, file, structured data, conversational context)
+> 3. **Output**: what does the agent produce? (artifact type, format, length)
+> 4. **Pack**: which role pack does it belong to? (solution-architect / product-manager / dev-team / sre-oncall / stakeholder-comms / ai-engineering / api-builder / new pack)
+> 5. **Is it a gate?** Does it emit a pass/fail verdict, or generate an artifact?
+> 6. **Related skills**: which existing skills does it complement or hand off to?
+> 7. **External deps**: does it need API keys, npm packages, or pip libraries?
+
+### Step 2 — Generate all artifacts in one response
+
+After intake, produce the following in a single response, each in its own fenced code block:
+
+#### `manifest.json`
+
+```json
+{
+  "name": "<kebab-case-name>",
+  "version": "1.0.0",
+  "description": "<use-case-first description — what it does, then trigger phrases>",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["<related-skill-1>", "<related-skill-2>"],
+  "tags": ["<tag1>", "<tag2>"],
+  "model": {
+    "tier": "<light|standard|heavy>",
+    "rationale": "<one sentence: why this tier fits what the skill does>"
+  }
+}
+```
+
+If the skill ships `scripts/`, add a `permissions` block before `model`: the hosts the scripts contact, the external programs they run, and where they write (`"none"`, `"named-paths"`, `"project"` or `"anywhere"`). For example: `"permissions": { "network": [], "commands": ["pdftotext"], "files": "named-paths" }`. Validation fails a script skill without it, and fails one whose code does something it doesn't declare.
+
+Tier guidance:
+- **light**: pattern matching, formatting, extraction with no judgment calls
+- **standard**: synthesis, judgment calls, structured output requiring reasoning (most skills)
+- **heavy**: multi-step reasoning with high stakes or adversarial review (gates, threat models)
+
+#### `SKILL.md`
+
+```markdown
+---
+name: <skill-name>
+description: <same as manifest description>
+---
+
+# <skill-name>
+
+<One paragraph: what this skill does and why it's useful. Name the problem it solves.>
+
+## How to respond
+
+<Numbered steps. Each step is an observable action. No vague "reason about X" steps.>
+
+## Quality bar
+
+<Three to five bullet points: what a good output includes and what it never does. Name anti-patterns explicitly.>
+```
+
+#### `evals/cases.json`
+
+Eight eval cases covering: 2 happy-path, 2 minimal/edge input, 2 anti-pattern (the quality bar failures), 2 refusal or boundary cases. Format:
+
+```json
+[
+  {
+    "id": "happy-path-standard",
+    "trigger": "<realistic input>",
+    "expected_shape": ["<checkable criterion 1>", "<checkable criterion 2>"],
+    "must_not_include": ["<anti-pattern from quality bar>"],
+    "verdict_class": "pass",
+    "notes": "<one sentence on what this tests>"
+  }
+]
+```
+
+#### Skill catalogue entry
+
+One row for `guides/reference/skill-catalogue.md`, under the right category, matching the format of existing rows:
+
+```
+| [`<skill-name>`](../../packs/<pack>/skills/<skill-name>/SKILL.md) | <One sentence describing what the skill does and the output it produces.> |
+```
+
+#### Pack and outcome
+
+State which one pack the skill belongs in (`core` only if every role needs it) — its folder goes at `packs/<pack>/skills/<skill-name>/` — and which `outcomes` entry in `catalogue.json` to add it to.
+
+### Step 3 — Install check reminder
+
+After generating, tell the author:
+
+```
+Next steps:
+1. mkdir -p packs/<pack>/skills/<skill-name> && cd packs/<pack>/skills/<skill-name>
+2. Drop in manifest.json, SKILL.md, and evals/cases.json
+3. python3 validate.py    # must pass before opening a PR
+4. Add the row to guides/reference/skill-catalogue.md under the correct category
+5. Add the skill to an outcome in catalogue.json
+6. If the skill has a how-to guide, add it to guides/how-to/ and guides/README.md
+```
+
+## Anti-patterns
+
+- **Generating manifests without checking the schema.** The most common contribution failure is a manifest missing a required field. Always instruct the author to run `python3 validate.py` before opening a PR.
+- **Generating eval triggers that test nothing.** "Run this skill" is not an eval case. Insist on realistic triggers that would expose a specific failure mode if the model got it wrong.
+- **Listing related skills that don't exist.** A manifest that references a non-existent skill fails validation. Instruct the author to run `ls skills/` before finalizing the `related` array.
+
+After generating eval cases, the author can use `eval-harness-generator` to add more coverage or to regenerate cases after modifying the SKILL.md.
+
+## Quality bar
+
+- **Manifests must be schema-valid.** Every field required by `contracts/skill.schema.json` must be present. Use `python3 validate.py` as the check — not a visual review.
+- **Eval triggers are realistic.** A trigger of "use this skill" is not an eval case. Each trigger should be a plausible user input, not a test harness artifact.
+- **SKILL.md has observable steps.** Every step in "How to respond" must describe an action the agent takes — never "think about X" or "consider Y".
+- **The quality bar names anti-patterns.** A quality bar that only says what good looks like doesn't help the agent avoid common failures. Name at least two things the output must never do.
+- **Related skills are real.** Every skill listed in `related` must exist in the skills directory. Run `ls skills/` to check before outputting.

skilldrop_cli/data/packs/dev-team/skills/contribution-wizard/evals/eval_queries.json

@@ -0,0 +1,30 @@
+[
+  {
+    "query": "Help me create a new skilldrop skill from scratch",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate the manifest, SKILL.md, and evals for a skill I want to contribute",
+    "should_trigger": true
+  },
+  {
+    "query": "I have an idea for a skill in the dev-team pack — walk me through authoring it",
+    "should_trigger": true
+  },
+  {
+    "query": "Scaffold a new skill for our private fork so it passes validate.py",
+    "should_trigger": true
+  },
+  {
+    "query": "I edited the bug-triage SKILL.md — regenerate its eval cases",
+    "should_trigger": false
+  },
+  {
+    "query": "Add more eval coverage to an existing skill's evals folder",
+    "should_trigger": false
+  },
+  {
+    "query": "Generate an AGENTS.md for this repository",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/dev-team/skills/contribution-wizard/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "contribution-wizard",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I want to add a new skill to skilldrop called `sla-credit-calculator`. It takes a customer contract's SLA terms plus a month of uptime data and outputs the service credit owed, with the calculation shown. It belongs in the sre-oncall pack, it generates an artifact (not a gate), it relates to runbook-generator and incident-comms, and it needs no external deps. Generate everything I need to submit it.",
+      "assertions": [
+        "Produces manifest.json, SKILL.md, evals/cases.json, and a skill-catalogue row, each in its own fenced code block, in a single response",
+        "The manifest includes every required field (name, version, description, entrypoint, deps, env, related, tags, model with tier and rationale)",
+        "The related array lists only skills that exist (runbook-generator, incident-comms) and tells the author to check the skills directory before finalizing",
+        "SKILL.md's How to respond steps are observable actions — none read 'think about X' or 'consider Y'",
+        "The quality bar names at least two things the output must never do (e.g. never invent uptime figures not in the input)",
+        "evals/cases.json has eight cases with realistic triggers, covering happy-path, edge, anti-pattern, and boundary cases",
+        "Ends with next steps that place files under packs/sre-oncall/skills/sla-credit-calculator/ and require python3 validate.py to pass before opening a PR",
+        "Does not invent inputs, deps, or related skills the author did not give"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/skills/contribution-wizard/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "contribution-wizard",
+  "version": "1.0.4",
+  "description": "Guides an author through creating a new skilldrop skill from scratch — generates the manifest, SKILL.md, eval cases, and skill-catalogue entry from a plain-language description of the skill's purpose. Use when authoring a new skill for this repo or a private fork, ensuring a new skill meets the schema and validation requirements before submission.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["eval-harness-generator"],
+  "tags": ["meta", "authoring", "contribution", "skilldrop-meta"],
+  "model": { "tier": "standard", "rationale": "Intake + structured generation — standard tier covers the template-filling and schema-adherence judgment this requires." }
+}

skilldrop_cli/data/packs/dev-team/skills/devils-advocate/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: devils-advocate
+description: Adversarial review of just-generated code, run *after* an agent (or human) declares a feature done. Challenges the implementation through four lenses — edge cases the first pass missed, baked-in assumptions that won't survive future requirements, what a staff engineer would push back on in code review, and test-coverage gaps for the new code paths. Produces severity-tagged findings (blocker / major / minor / nit) with file:line evidence and concrete fixes or missing test cases. Use immediately after a feature implementation or generation pass — before merging, before declaring "done", before moving to the next ticket.
+---
+
+# devils-advocate
+
+You play the role of a **senior engineer in code review who is trying to find what the implementation missed**. Code that "works on the happy path" is the default state of newly-generated code — your job is to challenge it through four lenses and surface what the first pass didn't think about.
+
+This skill is the **code counterpart to [`doc-critique`](../../../core/skills/doc-critique/SKILL.md)** — same adversarial framing, applied to code instead of artifacts.
+
+## When this skill runs
+
+The trigger is **right after an agent (or human) has declared a feature done**. The implementation exists, the happy path likely works, tests may even pass — and that's exactly the moment the skill is most useful, because that's the moment everyone stops looking.
+
+Specifically:
+- ✅ After AI code generation for a feature ("here's the implementation")
+- ✅ Before opening a PR / before requesting human review
+- ✅ Before merging
+- ✅ When the user asks "anything I might have missed?" or "is this ready to ship?"
+- ❌ For a one-line fix or trivial change — overkill
+- ❌ For greenfield exploration / spikes — adversarial review wastes effort on code that will be thrown away
+- ❌ As a substitute for actual code review by a human — this is a *pre-pass*, not a replacement
+
+## How to respond
+
+1. **Identify the change under review.** In order of preference:
+   - The agent / user has just shown you a diff — review that diff.
+   - Git working tree has unstaged changes — `git diff` is the scope.
+   - User points to specific files / a PR / a recent commit — that's the scope.
+   - User says "the feature I just built" with no diff — ask which files, or run `git diff HEAD~1` if a commit was just made.
+
+   **Don't review the whole repo.** The scope is the *just-generated* code. Touched files only.
+
+2. **Classify the code shape.** What you challenge depends on what was built. Map to one or more:
+
+   | Shape | Lens emphasis |
+   |---|---|
+   | HTTP / RPC endpoint, API handler | edge-cases (input validation, auth), adversarial (rate limit, error mapping) |
+   | Async handler / queue consumer | edge-cases (retries, idempotency, poison messages), future-proofing (ordering) |
+   | DB migration / schema change | future-proofing (rollback, online-safe), adversarial (locking, big-table risk) |
+   | State machine / workflow | edge-cases (impossible transitions, concurrent updates) |
+   | Parser / data transformation | edge-cases (malformed, encoding, huge inputs) |
+   | CLI tool / script | edge-cases (missing flags, env, partial runs) |
+   | UI component | edge-cases (loading/empty/error states, a11y) |
+   | Background job / cron | edge-cases (overlap, missed runs, partial completion) |
+   | Library / pure function | edge-cases (boundary inputs), future-proofing (API stability) |
+   | Config / infra change | adversarial (blast radius), future-proofing (drift) |
+
+   Multiple shapes is common — a PR can be "endpoint + migration + UI." Apply each lens to the right slice.
+
+3. **Sweep the four lenses in order.** Each lens has its own checklist — read it, apply it, write findings. Don't merge lenses; each surfaces a different category of risk.
+
+   | Lens | File | Asks |
+   |---|---|---|
+   | 1. Edge cases | [`lenses/edge-cases.md`](lenses/edge-cases.md) | What inputs / states / timings break this? |
+   | 2. Future-proofing | [`lenses/future-proofing.md`](lenses/future-proofing.md) | What assumptions won't survive the next 6 months? |
+   | 3. Adversarial review | [`lenses/adversarial-review.md`](lenses/adversarial-review.md) | What would a staff engineer push back on in review? |
+   | 4. Test coverage | [`lenses/test-coverage.md`](lenses/test-coverage.md) | Which new code paths have no test, and which scenarios are missing tests? |
+
+4. **Categorize every finding by severity:**
+
+   | Severity | Meaning |
+   |---|---|
+   | 🟥 **Blocker** | This will ship a bug or a security issue. Examples: SQL injection, unhandled `null`, race condition on shared state, migration that locks a 10M-row table, missing auth check, infinite retry loop. |
+   | 🟧 **Major** | This will hurt within months. Examples: hard-coded limits that 2× growth will hit, no idempotency on a retryable operation, error swallowed silently, no observability for a load-bearing path, magic constants. |
+   | 🟨 **Minor** | Good craft. Examples: missing edge-case test, suboptimal log level, naming that won't age well, a comment that explains *what* instead of *why*. |
+   | ⚪ **Nit** | Style, formatting, micro-preference. Optional. |
+
+   When in doubt between two severities, **downgrade**. Inflated severity makes the report unreadable. If your output has more blockers than major findings, you're inflating.
+
+5. **For every finding, write four parts:**
+
+   - **Where:** `file:line` (e.g. `src/api/checkout.ts:47`) — and quote 5–15 chars of the offending line.
+   - **What's wrong:** one sentence — which lens fired and why.
+   - **Concrete scenario:** ✅ "When `discount=null` reaches line 47, `applyDiscount` throws `TypeError`." — ❌ "Doesn't handle null." A scenario the first pass can reproduce.
+   - **Fix:** ✅ "Add `if (discount == null) return 0;` at the top of `applyDiscount` — or thread the null through to skip the line item entirely (preferred — see how `applyTax` handles it at line 102)." — ❌ "Add null handling."
+
+6. **Open with a verdict, not the findings.** First thing the user sees:
+
+   ```
+   Verdict: SHIP WITH FIXES — 2 blockers, 5 major, 4 minor, 3 nits.
+
+   The endpoint validates auth and the happy path but doesn't bound the request body (blocker — DoS via 1GB payload), and the new migration adds a NOT NULL column without a default on a table the migration script doesn't backfill (blocker — will fail on first deploy). Of the 5 major findings, 3 are around idempotency on the retry path. Test coverage misses the new error branches at api/checkout.ts:71–88 entirely.
+   ```
+
+   Verdicts: `SHIP IT` · `SHIP WITH FIXES` · `DO NOT MERGE` · `RECONSIDER APPROACH`. The last is for when the implementation works but solved the wrong problem (e.g. building a custom retry queue when the framework already has one).
+
+7. **Output structure** — use [`templates/challenge.md`](templates/challenge.md):
+
+   ```markdown
+   # Devil's advocate: {feature name / PR title}
+   _Scope: {N files, M lines changed} · Reviewed: {YYYY-MM-DD}_
+
+   ## Verdict
+   {one-liner} — {N} blocker · {N} major · {N} minor · {N} nit
+   {3-sentence summary, lead with the worst}
+
+   ## Findings by lens
+
+   ### 1. Edge cases
+   ### 2. Future-proofing
+   ### 3. Adversarial review
+   ### 4. Test coverage
+
+   ## What's solid
+   - {2–4 things the implementation got right — not flattery, real patterns to preserve}
+
+   ## Suggested order to address
+   1. Fix blockers
+   2. Add the missing tests in §4 (they double as regression catches)
+   3. Major findings in priority order
+   ```
+
+8. **End with "what's solid"**, not more criticism. The user (or the next agent) often needs to know what to *keep* and what *patterns to reuse* elsewhere in the change.
+
+## Quality bar
+
+- **Every finding has a reproducible scenario.** A senior engineer reading the finding should be able to reproduce the bug or violation in their head. "Doesn't handle null" is not a finding; "When `discount=null` reaches line 47, …" is.
+- **Severity is calibrated.** More blockers than major ⇒ inflating ⇒ demote.
+- **Findings cite `file:line`.** Reviewers must be able to jump to the spot. Section names aren't enough for code.
+- **Fixes are concrete and paste-able where possible.** When you can suggest a one-line patch, do; when you can't, suggest the *approach* in one sentence — not "improve error handling."
+- **Don't redesign.** This isn't your chance to push a different architecture. Stay in the lane of "given this approach, what's missing." If the approach itself is wrong, that's a single `RECONSIDER APPROACH` verdict, not a wholesale rewrite suggestion.
+- **Test-coverage findings reference scenarios, not files.** ❌ "No test for `applyDiscount`." ✅ "No test covers `applyDiscount(null)` — add a case that asserts the function returns 0 (or skips) without throwing."
+
+## When NOT to use this skill
+
+- ❌ For greenfield prototype / spike code that's about to be thrown away.
+- ❌ For one-line / trivial changes — overkill, and the noise drowns out real signal.
+- ❌ As a substitute for human code review — it's a pre-pass, not a replacement.
+- ❌ For *evaluating the choice of approach* before code exists. That's a design conversation, not a code challenge. Use `design-doc` + `doc-critique` for that loop.
+- ❌ For generated code in a language you can't reason about line-by-line. Better to refuse than fabricate findings.
+
+## Anti-patterns to avoid
+
+- ❌ **Severity inflation.** If everything is a blocker, the report is unreadable. Most findings are major or minor.
+- ❌ **Vague findings.** "Handle errors better" / "Consider edge cases" — the whole point of this skill is to *name* the missed cases. If you can't name a specific scenario, drop the finding.
+- ❌ **Restating the lens.** ❌ "Code should be future-proof." ✅ "Hard-coded 100ms timeout on line 53 won't survive p99 growth — make it configurable."
+- ❌ **Lecturing on style** when there's a real bug to flag. Style notes go in the Nits section, not on top.
+- ❌ **Reviewing untouched code.** Out-of-scope. The skill challenges the *change*, not the codebase.
+- ❌ **Demanding tests for *everything* the change touches.** Only the new logic and new error paths. Don't insist on backfilling tests for previously-untested neighbouring code.
+- ❌ **Skipping "what's solid".** Trains the user (or downstream agent) to dread the skill. End on signal that's actionable in the other direction.
+- ❌ **Showing the machinery.** The reply and the artifact are for the person who asked. Don't mention this skill, its files, templates, caps or internal terms, or that the run is non-interactive. Name another skill once, at the end, as a suggested next step, never inside the artifact.

skilldrop_cli/data/packs/dev-team/skills/devils-advocate/evals/eval_queries.json

@@ -0,0 +1,38 @@
+[
+  {
+    "query": "Review this code I just wrote before I merge it",
+    "should_trigger": true
+  },
+  {
+    "query": "Anything I might have missed in this implementation?",
+    "should_trigger": true
+  },
+  {
+    "query": "Adversarially review this diff for edge cases and broken assumptions",
+    "should_trigger": true
+  },
+  {
+    "query": "I just finished the feature and the tests pass — is it ready to ship?",
+    "should_trigger": true
+  },
+  {
+    "query": "Find the bugs a staff engineer would push back on in review",
+    "should_trigger": true
+  },
+  {
+    "query": "Critique this design document",
+    "should_trigger": false
+  },
+  {
+    "query": "Convene multiple senior personas to deliberate this architecture decision",
+    "should_trigger": false
+  },
+  {
+    "query": "Implement this ticket from its acceptance criteria",
+    "should_trigger": false
+  },
+  {
+    "query": "Run the full gate and reviewers and tell me if this is safe to merge",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/dev-team/skills/devils-advocate/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "devils-advocate",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Here's the payment-retry handler I just finished — it retries failed charges up to 3 times with exponential backoff, and the tests pass. Review it before I open the PR.",
+      "assertions": [
+        "Every finding has a reproducible scenario a senior engineer can replay mentally — named input, current behavior, expected behavior",
+        "Every finding cites file:line, not just a section or function name",
+        "Severity is calibrated — blockers do not outnumber majors; inflated findings are demoted",
+        "Findings are grouped by the four lenses (edge cases, assumptions, staff-engineer pushback, test-coverage gaps), skipping lenses that do not apply rather than padding",
+        "Test-coverage gaps name the concrete missing test case, not 'add more tests'",
+        "Assertion theater is called out — tests that execute the code without asserting the behavior",
+        "Output ends with a 'what's solid' section so the author knows what not to touch",
+        "The review scopes to the change under review, never sweeping the whole codebase"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/skills/devils-advocate/examples/rate-limiter-review.md

@@ -0,0 +1,46 @@
+# Worked example — adversarial review of a just-written rate limiter
+
+Input → output oracle for `devils-advocate`. Shows the four-lens sweep producing
+severity-calibrated findings with `file:line` evidence and paste-able fixes — not a
+generic "looks good, consider tests" pass.
+
+## Input (the "done" implementation)
+
+> "Implemented the per-user rate limiter, tests pass, ready for review."
+
+```python
+# ratelimit.py
+_buckets: dict[str, tuple[float, float]] = {}   # user_id -> (tokens, last_refill)
+
+def allow(user_id: str, rate: float, burst: float) -> bool:
+    now = time.time()
+    tokens, last = _buckets.get(user_id, (burst, now))
+    tokens = min(burst, tokens + (now - last) * rate)
+    if tokens >= 1:
+        _buckets[user_id] = (tokens - 1, now)
+        return True
+    _buckets[user_id] = (tokens, now)
+    return False
+```
+
+## Output (the review)
+
+**Verdict: not ready — 1 blocker, 1 major.** Four lenses swept; happy path is fine, the concurrency and growth paths are not.
+
+🟥 **Blocker — race on the shared dict (assumptions lens).** `ratelimit.py:6-11` reads then writes `_buckets[user_id]` with no lock. Two concurrent requests for the same user both read `tokens=1.0`, both pass, both write back `0.0` — the limiter leaks one token per race, so a burst of N parallel requests admits ~2× the intended rate. The "tests pass" because they're single-threaded. *Fix:* guard the read-modify-write with a per-user lock, or move to an atomic backend (Redis `INCR`+TTL). A dict-of-locks keyed by `user_id` is the minimal change.
+
+🟧 **Major — unbounded memory growth (edge-case lens).** `_buckets` never evicts (`:1`). Every distinct `user_id` ever seen stays forever; a service facing the open internet (or spoofable user ids) OOMs over time. *Fix:* cap with an LRU (`functools.lru_cache` won't fit the mutable value — use `cachetools.TTLCache(maxsize=…, ttl=…)`), evicting idle buckets.
+
+🟨 **Minor — first call gets a free full burst (edge-case lens).** A never-seen `user_id` starts at `(burst, now)` (`:6`), so a brand-new user can immediately spend the whole burst. If the intent is "warm up", seed at `min(burst, rate*window)` instead — flag for product, don't silently change.
+
+⚪ **Nit — `rate`/`burst` unvalidated (staff-engineer lens).** `rate<=0` freezes every user out; `burst<1` makes `allow` always false. Assert `rate>0 and burst>=1` at the boundary.
+
+**Test-coverage gaps (the "tests pass" were happy-path only):**
+- Concurrency: two threads hammering one `user_id` must not exceed `burst + rate*elapsed` admits.
+- Refill: after exhausting tokens, `allow` returns True again only after `1/rate` seconds.
+- Eviction: memory stays bounded under 10k distinct ids.
+- Boundary: `tokens` sitting at exactly `1.0` admits; at `0.999…` denies.
+
+## Why this passes the quality bar
+
+Severity is calibrated (one blocker, demoted the rest); every finding cites `file:line`, names the *lens* it came from, and gives a concrete fix or a specific missing test — not "add more tests."

skilldrop_cli/data/packs/dev-team/skills/devils-advocate/lenses/adversarial-review.md

@@ -0,0 +1,88 @@
+# Lens 3: Adversarial — what would a staff engineer push back on?
+
+The question this lens asks: **if a senior engineer who didn't write this code reviewed it cold, what would they object to — even if it works today?**
+
+This is the lens for the things that don't fail tests but fail in practice. Concurrency, error handling, security, observability, blast radius.
+
+---
+
+## Concurrency & ordering
+
+- **Read-modify-write without a lock or compare-and-swap.** Two callers, both read X, both increment, both write — one update is lost.
+- **Critical section that spans an `await` / I/O.** Lock not held across the await, or lock held *during* a slow I/O call (blocks everyone else).
+- **Shared mutable state in a request-handler scope** (e.g. a module-level dict that handlers mutate).
+- **Ordering assumption between async operations** with no explicit synchronization. "It works in my testing" because the race window is small.
+- **Cancellation not propagated.** Context cancelled but downstream call still runs to completion, holding resources.
+- **Goroutine / task leak.** Spawned, never awaited, never cancelled.
+
+## Error handling
+
+- **Caught and swallowed.** `try { … } catch {}` with no log, no rethrow. Errors disappear into the void.
+- **Logged and continued** when the operation should have failed. The user sees success; the system did nothing.
+- **Generic catch hiding specific errors.** Catching `Exception` / `error` when only one specific case is recoverable.
+- **Error message leaks internals** to the user (stack trace, SQL, file paths).
+- **Wrong abstraction in the error.** Internal `RecordNotFound` surfaces as 500 instead of 404. Or vice versa.
+- **No distinction between retriable and terminal errors.** Caller can't tell whether to back off and retry, or to give up.
+- **Cleanup not in `finally`.** Resource leaked when an exception fires partway through.
+
+## Security
+
+- **Input concatenated into SQL / shell / URL** instead of parameterized. Even if the input "shouldn't be untrusted."
+- **Authorization check missing or in the wrong layer.** Authn ≠ Authz. A logged-in user accessing another user's resource by changing an ID.
+- **Insecure direct object reference.** IDs in URLs / payloads accepted at face value with no ownership check.
+- **Secrets in code, in config, in logs.** Including ones that look "innocent" — internal hostnames, employee names.
+- **TLS verification disabled** (`rejectUnauthorized: false`, `verify=False`) — usually a copy-paste from a debug session.
+- **Cryptographic primitives used wrong.** MD5/SHA1 for password hashing, ECB mode, IV reused, randomness from a non-CSPRNG.
+- **Open redirect.** User-controlled URL passed to a redirect with no allowlist.
+- **No CSRF protection** on a state-changing endpoint, in a session-cookie-auth app.
+- **Logging PII / secrets.** Email, name, token, API key, full request body in an info-level log.
+
+## Observability
+
+- **Load-bearing path with no log.** When this fails in prod, nothing in the logs will explain why.
+- **Log without correlation.** No request ID, no trace ID, no tenant ID — can't tie events together.
+- **Wrong log level.** Recoverable error at `error` (alerts), or unrecoverable at `info` (lost in noise).
+- **No metric on the new operation.** Latency, count, error rate. If you can't measure it, you can't run it.
+- **Span / trace doesn't cover the new code.** Distributed tracing has a hole.
+- **Alert without a runbook entry.** When this fires, the on-caller has no documented response.
+
+## Blast radius
+
+- **Change touches a shared utility** without considering all callers.
+- **Migration / change applies to all rows / tenants** when it should be gated by feature flag.
+- **No feature flag** when the change is risky and a rollback would otherwise require a redeploy.
+- **Big bang deploy** of a multi-system change instead of staged.
+- **Backwards-incompatible event / API change** with no consumer coordination.
+
+## Build, dependency, and supply chain
+
+- **New dependency added.** Is it maintained? License compatible? Subdependency tree audited? Pinned to a major version?
+- **Pinned to a vulnerable version** of an existing dependency.
+- **`postinstall` script** in a new dependency that runs arbitrary code.
+- **`curl | bash` install steps** in a Dockerfile or CI config.
+
+## Test smells
+
+- **Test that doesn't actually assert.** Calls the function and checks nothing.
+- **Test that mocks the thing under test.** Mocks itself out of any real verification.
+- **Test that's coupled to the implementation** rather than the behaviour — fragile and slows down refactoring.
+- **Test that's flaky** — passes locally, fails in CI 1 in 10 runs. Disable + ticket, don't ignore.
+- **Test data with hard-coded "today"** — fails on a specific future date.
+
+## Naming, comments, and structure
+
+- **Name that lies.** `getUser` that also creates one if missing. `parse` that also mutates the input. `validate` that also sanitizes.
+- **Comment that explains what the code does** (the code already does that) instead of *why*.
+- **Comment that's now wrong** because the code changed but the comment didn't.
+- **Dead code committed.** `// TODO: remove this` from 2022.
+- **Function that's doing two unrelated things** stitched together by a flag parameter.
+
+## Reconsider-approach signals
+
+When you see *several* of these together, the verdict isn't "fix these findings" — it's `RECONSIDER APPROACH`:
+
+- Reimplementing a primitive the framework / language provides (custom retry, custom cache, custom thread pool).
+- Manual concurrency primitives where a higher-level abstraction exists (raw goroutines + channels when the language has `errgroup`; `setTimeout` polling when a proper queue would do).
+- Several `if (env === 'X')` branches in business logic.
+- Rolling your own auth / crypto / parsing for a well-known format.
+- Code that essentially re-implements what a vendor library already does.