skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/dev-team/skills/devils-advocate/lenses/edge-cases.md

@@ -0,0 +1,95 @@
+# Lens 1: Edge cases the first pass missed
+
+The question this lens asks: **what inputs, states, or timings break this code?**
+
+Apply the relevant subsection based on what the change is. Don't enumerate every check — pick the ones that *match the change shape* and have a real chance of biting.
+
+---
+
+## Universal (always check)
+
+- **Null / undefined / missing.** For each parameter and field accessed: what happens when it's missing, null, undefined, `None`, `nil`, empty string, empty array, empty object, zero, `NaN`?
+- **Boundary values.** Min, max, min−1, max+1, 0, −1, exactly-the-limit. For collections: empty, one, max-size, max-size+1.
+- **Type confusion.** Number as string, string as number, ISO date as Unix timestamp, array as object. If the language is dynamically typed, this matters more.
+- **Encoding.** Unicode (emoji, RTL, combining chars), URL-encoded vs decoded, base64, escaped vs raw, BOM in input files, mixed line endings.
+- **Locale.** Comma vs period for decimals, timezone-naive dates, day-of-week assumptions, ordering by locale-aware sort.
+- **Concurrency.** Two calls at once, the same call twice (idempotency), read-modify-write without a lock, optimistic locking ignored.
+- **Time.** DST transitions, leap seconds (rare), clock skew, monotonic vs wall clock, "now()" called twice in same operation giving different values, expiry that crosses a boundary.
+- **Partial failure.** What if the first half of the operation succeeds and the second fails? Where's the rollback / retry / dead-letter?
+
+## HTTP / RPC endpoint
+
+- **Auth.** Missing token, expired token, valid-but-wrong-user token, malformed header, token for a different tenant.
+- **Authorization.** User authenticated but not authorized (different question from "logged in").
+- **Input validation.** Body too large, body empty, body with extra fields, missing required field, wrong content-type, malformed JSON, deeply nested JSON, JSON with `__proto__` / prototype pollution.
+- **Method / route.** What if called with GET when POST expected? Trailing slash. Path traversal in path params.
+- **Concurrency.** Same user makes 10 identical requests in parallel.
+- **Idempotency.** If this can be retried by a client or proxy, is the second call safe?
+- **Rate-limit / DoS.** Unbounded loop on user input, unbounded recursion, unbounded resource allocation tied to a request param.
+
+## Async handler / queue consumer
+
+- **At-least-once semantics.** Same message twice. Is the operation idempotent on a key?
+- **Out-of-order delivery.** Message B arrives before message A. Does logic still hold?
+- **Poison messages.** Malformed payload that throws inside the handler — does the system DLQ it or retry forever?
+- **Retry storms.** Failure causes immediate retry causes cascading retries causes thundering herd.
+- **Backpressure.** Slow downstream. Queue grows unbounded. Does the handler shed load?
+
+## Database / migration
+
+- **Locking.** `ALTER TABLE` on a large table without `CONCURRENTLY` (Postgres) or equivalent — locks reads/writes during deploy.
+- **Backfill.** `ADD COLUMN NOT NULL` without a default on an existing populated table — fails or locks.
+- **Rollback.** Is the migration reversible? If not, is that explicit and documented?
+- **Online-safety.** Will old app code break against the new schema during the rolling deploy? (Add column → backfill → switch reads → drop old column — multi-step migrations.)
+- **Index creation.** Without `CONCURRENTLY` — locks writes.
+- **FK constraints added after data exists.** Will scan the whole table.
+
+## Parser / data transformation
+
+- **Huge inputs.** 1GB file, 1M-row CSV, deeply nested JSON, malicious zip (zip bomb).
+- **Malformed inputs.** Truncated, corrupted, wrong encoding, mixed encodings within one file.
+- **Untrusted inputs.** Input is from a user — what if it's hostile? Path traversal, command injection, format-string attacks.
+- **Streaming vs batch.** Does the code load everything into memory? Should it stream?
+- **Numeric precision.** Float arithmetic on money, large integers in JSON (JavaScript loses precision past 2^53), trailing zeros stripped.
+
+## State machine / workflow
+
+- **Impossible transitions.** Can the state graph reach state X from state Y in a single hop? Should it? What if it does?
+- **Concurrent updates to the same entity.** Two callers move it from A → B and A → C simultaneously.
+- **Skipped intermediate states.** Cleanup hooks that depend on visiting state Z get skipped.
+- **Terminal states.** Once in `cancelled` / `failed`, can the entity be re-opened? Should it?
+- **Replay.** What happens if the workflow is re-triggered from the beginning?
+
+## UI component
+
+- **Loading state.** Is there one, and does it appear before the data?
+- **Empty state.** Zero items — does the UI break or show something useful?
+- **Error state.** API call fails — does the user see a message or a blank page?
+- **Slow state.** API takes 8 seconds — does the UI lock up, or stay responsive?
+- **Long content.** Names with 80 characters, descriptions with 5,000. Does layout break?
+- **Internationalization.** RTL languages flipping the layout, longer translations overflowing buttons.
+- **Accessibility.** Keyboard nav, screen reader labels, focus traps, contrast.
+- **Mobile / small viewport.** Below 320px wide.
+
+## Background job / cron
+
+- **Overlap.** Job takes longer than its interval — does it overlap with the next run?
+- **Missed runs.** System down at scheduled time — does the next run catch up, or skip?
+- **Partial completion.** Crash halfway through — is the next run idempotent?
+- **Time zone.** "Run at midnight" — whose midnight?
+- **Drift.** Long-running periodic that takes longer over time as data grows.
+
+## CLI tool / script
+
+- **Missing args.** Required flag not passed.
+- **Stdin not a TTY** (running in CI, piped from another command).
+- **Env var missing or empty string.**
+- **Partial run interrupted by Ctrl-C.** Is the file half-written? Is there a cleanup?
+- **Non-zero exit codes** for each error path (CI scripts depend on these).
+
+## Library / pure function
+
+- **API stability.** Public surface change — does it break callers?
+- **Default values.** Sensible? Or surprising?
+- **Side effects.** Pure function actually pure? Or does it mutate inputs / hit the network / read the clock?
+- **Thread safety.** If callable from multiple threads, is shared state protected?

skilldrop_cli/data/packs/dev-team/skills/devils-advocate/lenses/future-proofing.md

@@ -0,0 +1,75 @@
+# Lens 2: Future-proofing — assumptions that won't survive 6 months
+
+The question this lens asks: **what assumptions are baked into this code that will hurt when something predictable changes?**
+
+This is not "design for every hypothetical." It's "the obvious next requirements will break this." Flag only assumptions whose violation is *likely* within a year — not theoretical.
+
+---
+
+## Scale assumptions
+
+- **Hard-coded limits.** `LIMIT 100`, `for (i = 0; i < 1000; i++)`, `maxResults = 50`. What happens at 2× current scale? 10×?
+- **In-memory accumulation.** Loading the whole result set into a list, holding it, then processing. Will it OOM at next year's data volume?
+- **Unbounded growth.** A list / map / queue with no eviction. Will memory grow forever?
+- **N+1 queries.** Loop calls the DB per iteration. Fine at 10 items, dead at 10,000.
+- **Synchronous calls in a hot path.** Add three more downstream services and the latency stacks.
+
+## Tenancy assumptions
+
+- **Single-tenant baked in.** No `tenant_id` / `org_id` / `workspace_id` threaded through. Will be a multi-week refactor when multi-tenancy lands.
+- **Global state.** Caches keyed only by user/id, no tenant scope.
+- **Per-user limits where per-tenant is needed** (or vice versa).
+- **Email / username uniqueness assumed globally** rather than per-tenant.
+
+## Identity / ownership assumptions
+
+- **Hard-coded user / account / org IDs.** `if (orgId === 'acme-corp')`. Will rot the moment Acme renames.
+- **"Admin" as a single role** when next year wants RBAC with custom roles.
+- **API keys with no rotation path.** What's the story when one leaks?
+- **Auth provider baked into business logic.** Migrating providers means rewriting business code.
+
+## Data / schema assumptions
+
+- **Enum hard-coded in code** when next year wants user-configurable values.
+- **Boolean flag** that becomes a tri-state (`yes / no / pending`) or n-state.
+- **JSONB blob** with no versioning — when its shape evolves, old rows can't be read or written without compat shims.
+- **Foreign key to a "single source of truth"** that's about to become federated.
+- **Timestamps without timezone** (`TIMESTAMP` instead of `TIMESTAMPTZ`).
+- **Money as float** instead of integer cents or arbitrary-precision decimal.
+- **Strings where structured data belongs** (comma-separated IDs in a single column).
+
+## Integration assumptions
+
+- **Sync calls to an external API** that has a documented async option (webhooks, batch).
+- **No retry / no circuit breaker** around external calls.
+- **No timeout** on external calls (default is "wait forever").
+- **Tight coupling to a vendor's response shape** with no anti-corruption layer.
+- **Tight coupling to a vendor's identifier scheme** (using Stripe customer ID as primary key).
+
+## Configurability / observability
+
+- **Magic constants** that should be configurable (`100ms timeout`, `5 retries`, `7 days expiry`). At minimum, named constants; better, env-driven.
+- **Hard-coded environment** (`if (process.env.NODE_ENV === 'production')` scattered in business logic).
+- **No structured logging** on the new path — when this code misbehaves in prod, how will you debug?
+- **No metric / no trace** for a load-bearing operation. Future you will be flying blind.
+- **Errors logged but not categorized** — can't alert on the dangerous ones without alerting on every error.
+
+## Compatibility / migration
+
+- **Breaking change to a public API** without a deprecation path.
+- **No versioning** on an external interface (REST endpoint, event schema, gRPC service).
+- **Removed field still referenced by callers** — coordinate with consumers or stage the change.
+- **Migration that's not safe to run on both old and new app code** during a rolling deploy.
+
+## Lifecycle / cleanup
+
+- **Resource created without a cleanup path.** New S3 bucket, new DB record, new background job — what removes them?
+- **TTL not set on cache entries.** They live forever, including stale data.
+- **Soft-delete column added but no compaction strategy.** Table grows forever.
+- **Cron job with no off-switch.** Disabling requires a deploy.
+
+## What this lens is NOT for
+
+- ❌ "Design for 100M users when we have 100." Flag what's *likely* to change, not what's *possible* to change.
+- ❌ "Add an interface in case we want to swap implementations." YAGNI applies; only flag if the swap is on the roadmap.
+- ❌ Aesthetic refactors. If it's not going to break under foreseeable load / change, it's not in scope here.

skilldrop_cli/data/packs/dev-team/skills/devils-advocate/lenses/test-coverage.md

@@ -0,0 +1,90 @@
+# Lens 4: Test-coverage gap analysis
+
+The question this lens asks: **for the code paths just introduced, which scenarios have no test?**
+
+This is not about hitting a coverage percentage. It's about which *new* branches, error paths, and edge cases ship with no automated check that future changes don't regress them.
+
+---
+
+## Scope rule
+
+- Test the **new code paths only.** Don't demand tests for previously-untested neighbouring code.
+- Test the **error and edge branches**, not just the happy path. The happy path is usually the one already tested.
+- Test the **boundaries**, not the interior. (Empty list and one-item list catch more than 5-item list.)
+
+## How to read the change
+
+1. **Identify the new branches.** Every `if`, `switch`, `try`, `?.`, default param, conditional return introduced in the diff is a branch. Each one is a coverage candidate.
+2. **Identify the new error paths.** Every `throw`, `return Err(…)`, `panic`, every `catch` block. Each is a candidate.
+3. **Identify the new public surface.** New function exported, new endpoint, new event handler, new CLI flag. Each public entry point needs at least one test from outside.
+4. **Identify the new integration points.** New external API call, new DB query, new file I/O. Each needs either an integration test or a mocked unit test with realistic responses (including failure responses).
+
+## What to flag as a missing test
+
+For each missed scenario, write a finding like:
+
+> **Missing test:** `applyDiscount(null)` — assert returns 0 (or skips) without throwing.
+> **Suggested location:** `src/checkout/__tests__/applyDiscount.test.ts` (same dir pattern as siblings).
+> **Severity:** 🟧 major — null input is reachable from the public endpoint (`api/checkout.ts:47`).
+
+### Default checklist of "must-have" scenarios
+
+For every new function with parameters:
+
+- **Happy path** — at least one test exists. (Usually it does. If not, that's a blocker.)
+- **Empty input** — empty string, empty list, empty object, null, undefined.
+- **Boundary** — min, max, off-by-one.
+- **Error path** — explicit error / exception cases, each.
+
+For every new endpoint:
+
+- 200 happy path.
+- 4xx for missing required field.
+- 4xx for invalid auth (if endpoint requires auth).
+- 4xx for valid auth + wrong user (authorization).
+- 5xx response shape if downstream fails (or graceful degradation, whichever the design specifies).
+
+For every new async handler / queue consumer:
+
+- Successful processing of a valid message.
+- Idempotency — same message processed twice produces same outcome.
+- Malformed message — DLQ'd, not retried infinitely.
+
+For every new migration:
+
+- Forward migration applied on a non-empty seed DB.
+- Backward migration restores schema (if reversible).
+- Behaviour against *both* old and new app code if doing a multi-stage migration.
+
+For every new state-machine transition:
+
+- The valid transition itself.
+- The invalid-transition rejection (state A → state Z when not allowed).
+
+For every new UI component:
+
+- Renders with realistic props.
+- Renders with empty data.
+- Renders with error state.
+- Renders with loading state.
+- (Interaction tests where the component has interactive behaviour.)
+
+## What to flag as a test SMELL (not missing — wrong)
+
+- **Asserts nothing.** Calls the function but doesn't check the return value or side effect.
+- **Mocks itself out of the test.** All collaborators mocked including the unit under test, or the mock makes the test pass trivially.
+- **Tautological assertion.** `expect(x).toEqual(x)` — happens when an agent fabricates a test.
+- **Asserts the implementation, not the behaviour.** Test reads private fields or counts internal calls; brittle to refactor.
+- **Hard-codes a date that will fail in the future.** `expect(date).toEqual('2025-12-31')` baked into a test that runs every day.
+- **Flaky due to timing / ordering.** `setTimeout(…, 0)` to "let the event loop settle" — works locally, flakes in CI.
+- **Snapshot test on a noisy structure.** Snapshot includes timestamps, random IDs, or auto-generated keys — fails on every run.
+
+Flag a smelly test the same way you flag a missing one — note that the test exists but doesn't earn its keep, and suggest what it should actually assert.
+
+## What this lens is NOT for
+
+- ❌ Demanding tests for refactor-only changes that didn't add new behaviour.
+- ❌ Demanding tests in code that already lacks them (out of scope — only the diff).
+- ❌ Requiring 100% line coverage. Branches and edges matter; uncovered straightforward lines don't.
+- ❌ Insisting on a specific test framework / style.
+- ❌ Generating tests yourself. This lens *flags gaps* — the user (or the next agent in the loop) writes the tests, possibly by feeding the gap list back into a code-gen step.

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

@@ -0,0 +1,14 @@
+{
+  "name": "devils-advocate",
+  "version": "0.1.1",
+  "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.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["design-doc", "doc-critique"],
+  "hooks": [
+    { "event": "pre-commit-review", "action": "devils-advocate", "description": "adversarially review staged changes before they land" }
+  ],
+  "tags": ["review", "code-review", "adversarial", "edge-cases", "future-proofing", "test-coverage", "dev-workflow"],
+  "model": { "tier": "heavy", "rationale": "Adversarial code review across four lenses. Cheaper models miss edge cases and under-call severity. Never downgrade." }
+}

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

@@ -0,0 +1,118 @@
+# Devil's advocate: {feature name or PR title}
+
+_Scope: {N files, M lines changed in the diff under review}_
+_Reviewed: {YYYY-MM-DD}_
+_Code shape(s): {endpoint | async handler | migration | state machine | parser | CLI | UI | background job | library | config}_
+
+## Verdict
+**{SHIP IT | SHIP WITH FIXES | DO NOT MERGE | RECONSIDER APPROACH}** — {N} blocker · {N} major · {N} minor · {N} nit
+
+{3-sentence summary. Lead with the worst finding. Name the lens(es) that surfaced the most issues. If the verdict is `RECONSIDER APPROACH`, say *why* — what's the structural problem the findings point to.}
+
+---
+
+## Findings by lens
+
+### 1. 🔍 Edge cases the first pass missed
+
+#### 🟥 Blockers
+1. **Where:** `{file:line}` — *`{≤15 char quoted snippet}`*
+   **What:** {one sentence — which check from the edge-cases lens fired}
+   **Scenario:** {concrete reproducible case, e.g. "POST /checkout with `body = {}` → `applyDiscount(undefined)` → TypeError at line 47"}
+   **Fix:** {one or two sentences, concrete and paste-able where possible}
+
+#### 🟧 Major
+1. **Where:** `{file:line}` — *`{snippet}`*
+   **What:** {…}
+   **Scenario:** {…}
+   **Fix:** {…}
+
+#### 🟨 Minor
+1. {…}
+
+#### ⚪ Nits
+- {…}
+
+---
+
+### 2. 🔭 Future-proofing — assumptions baked in
+
+#### 🟥 Blockers
+1. **Where:** `{file:line}` — *`{snippet}`*
+   **What:** {assumption that will break — e.g. "Hard-coded 100ms timeout"}
+   **When it bites:** {realistic timeframe — e.g. "p99 latency from `payments-svc` already at 80ms; one more downstream hop and the deploy fails"}
+   **Fix:** {…}
+
+#### 🟧 Major
+1. {…}
+
+#### 🟨 Minor
+1. {…}
+
+---
+
+### 3. ⚔️ Adversarial — what a staff engineer would push back on
+
+#### 🟥 Blockers
+1. **Where:** `{file:line}` — *`{snippet}`*
+   **What:** {category — concurrency / error handling / security / observability / blast radius}
+   **Scenario:** {how it actually fails — "two callers run `incrementBalance` in parallel, both read balance=100, both write balance=101 → $10 lost"}
+   **Fix:** {…}
+
+#### 🟧 Major
+1. {…}
+
+#### 🟨 Minor
+1. {…}
+
+#### ⚪ Nits
+- {…}
+
+---
+
+### 4. 🧪 Test-coverage gaps
+
+For each gap: scenario → suggested location → severity.
+
+#### 🟥 Blockers
+1. **Missing test:** {scenario, e.g. "POST /checkout with missing auth header — expect 401"}
+   **Suggested location:** `{path/to/test/file}`
+   **Why blocker:** {e.g. "auth check is the only thing between this endpoint and arbitrary user data; no test guards against future refactors removing it"}
+
+#### 🟧 Major
+1. **Missing test:** {scenario}
+   **Suggested location:** `{path}`
+   **Why major:** {…}
+
+#### 🟨 Minor (additional cases worth adding)
+- {one-liner per case}
+
+#### Test smells (existing tests that don't earn their keep)
+- **`{test file:line}`** — *`{snippet of the test}`* — {smell, e.g. "asserts nothing — calls `applyDiscount(10)` but doesn't check the return value"} — **Fix:** {what it should assert}
+
+---
+
+## ✅ What's solid
+
+Things the implementation got right — worth preserving in any rewrite, and worth re-using as patterns elsewhere in the change.
+
+- **{Strength 1}** — `{file:line}` — {why this is a real strength, not flattery}
+- **{Strength 2}** — `{file:line}` — {…}
+- **{Strength 3}** — `{file:line}` — {…}
+
+---
+
+## 🛠 Suggested order to address
+
+1. **Fix blockers first.** {Specifically: {finding refs}}
+2. **Add the missing tests in §4.** They double as regression catches for the fixes above.
+3. **Major findings in priority order:** {finding refs, ordered by likelihood-of-biting × cost-to-fix-later}
+4. **Minor + nits:** {batch into a follow-up commit or punt to a separate cleanup PR — don't gate the merge}
+
+---
+
+## 🚦 Re-review trigger
+
+After fixes land, the changes most likely to *introduce new findings* are:
+- {e.g. "The retry logic added to address Blocker #2 needs a fresh sweep of Lens 1 (edge cases) for retry storm + idempotency."}
+- {e.g. "The new feature flag added per the 'blast radius' finding needs a Lens 2 check that the flag has an off-switch and an expiry."}

skilldrop_cli/data/packs/dev-team/skills/feature-implement-loop/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: feature-implement-loop
+description: Implement a feature or story so it ends up *verified*, not just generated. Takes a description + acceptance criteria, writes code and tests, then runs an adversarial review pass that hunts for gaps (broken edge cases, baked-in assumptions, uncovered acceptance criteria), and re-generates to close them — looping until the review is clean or a 3-round cap is hit. Use when handed a ticket / story / feature spec with acceptance criteria and the goal is shippable, self-checked code — not a first draft.
+---
+
+# feature-implement-loop
+
+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* — 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
+
+A feature/story with two parts:
+- **Description** — what to build and why.
+- **Acceptance criteria** — the conditions that define "done." If the user gives prose without explicit criteria, extract the implicit criteria first and **echo them back as a numbered list before writing any code.** No criteria, no loop — the criteria are the gate.
+
+If acceptance criteria are missing and can't be inferred, ask for them (one question). Don't invent a gate the user didn't agree to.
+
+## How to respond
+
+1. **Restate the spec as a criteria checklist.** Number every acceptance criterion. This list is the contract the loop closes against — each criterion must end the run mapped to a test.
+
+2. **Plan the verification first.** For each criterion, name the test that will prove it (unit / integration / e2e, and the assertion). Surface criteria that *can't* be tested automatically (e.g. "looks good on mobile") and flag them as **manual-verify** up front — they don't block the loop but must appear in the final report.
+
+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 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. **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 — mechanical first, then findings.**
+   - **Mechanical (un-bypassable):** *run* the project's verify — the tests you wrote **plus** its lint/typecheck — and honor the exit code. A non-zero result is an automatic gap, not a judgment call; you may not report `VERIFIED` while any command is red. The pass/fail is the command's exit code, not your read of the diff. (This is the deterministic half; the review is the judgment half. For a standalone gate on an existing change, `pre-merge-review` wraps this in a script.)
+   - **Findings gap = any 🟥 blocker, OR any 🟧 major, OR any acceptance criterion without a passing, asserting test.**
+   - 🟨 minor / ⚪ nit findings do **not** force another round — list them, don't loop on them.
+
+6. **Loop or stop.**
+   - **Gaps remain and rounds used < 3** → regenerate to close *only* the gap findings (don't churn unrelated code), then go back to step 4. Increment the round counter.
+   - **No gaps** → stop: the implementation is verified. Go to the report.
+   - **Gaps remain and rounds == 3** → stop anyway. Do **not** loop further. Report the remaining gaps explicitly as open — never silently declare done.
+
+7. **Report.** Always end with:
+   - **Status:** `VERIFIED` (clean) · `VERIFIED WITH OPEN ITEMS` (cap hit, gaps remain) · `BLOCKED` (couldn't generate / couldn't run tests).
+   - **Acceptance-criteria table:** every criterion → ✅ covered (test name) · ⚠️ manual-verify · ❌ open (why).
+   - **Round log:** what each round found and fixed (1 → 2 → 3). This is the proof of work — it shows the loop did something.
+   - **Open items:** any remaining gaps after the cap, with the finding and why it wasn't auto-closable, so a human can finish it.
+
+## Quality bar
+
+- **Every acceptance criterion maps to a test by the final report.** A criterion with no asserting test is an ❌ open item — not a pass. This is the rule that makes the skill more than codegen.
+- **The review challenges the code; it doesn't rubber-stamp it.** A round-1 review that finds nothing on a non-trivial feature is a smell — re-run it adversarially, assuming the first pass missed something (it usually did).
+- **Tests assert behavior, not just execution.** ❌ a test that calls the function and checks it didn't throw. ✅ a test that asserts the criterion's expected output. Catch assertion theater in the review.
+- **Regeneration is targeted.** Each round fixes the named gaps and leaves passing code alone. Don't rewrite the whole feature every round — that loses ground and never converges.
+- **The cap is real.** 3 rounds, then stop and report. A loop that "just one more round"s past 3 is a bug. If it can't converge in 3, a human needs to see why.
+- **The round log is honest.** If round 2 found nothing new, say so. If a gap was downgraded rather than fixed, say why. The log is the audit trail.
+
+## When to use this skill
+
+- ✅ A ticket / story / feature spec arrives **with acceptance criteria** and the goal is shippable, self-checked code.
+- ✅ When the user says "implement this and make sure it actually meets the criteria" / "build it and check your own work."
+- ✅ Net-new features and well-scoped enhancements where the criteria are concrete.
+
+## When NOT to use this skill
+
+- ❌ One-line fixes / trivial changes — the loop is overhead; just make the change.
+- ❌ Greenfield spikes / throwaway prototypes — verifying code you'll delete wastes rounds.
+- ❌ Specs with no acceptance criteria and none inferable — there's no gate to close. Get criteria first.
+- ❌ Pure code *review* of code you didn't generate — that's [`devils-advocate`](../devils-advocate/SKILL.md) standalone.
+- ❌ Open-ended design questions ("should we use Postgres or Dynamo?") — that's `design-doc` + `doc-critique`.
+
+## 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 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 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.

skilldrop_cli/data/packs/dev-team/skills/feature-implement-loop/evals/eval_queries.json

@@ -0,0 +1,30 @@
+[
+  {
+    "query": "Implement this ticket and make sure every acceptance criterion actually has a test",
+    "should_trigger": true
+  },
+  {
+    "query": "Build this story, review your own code adversarially, and fix the gaps",
+    "should_trigger": true
+  },
+  {
+    "query": "Here's a feature spec with acceptance criteria — give me shippable, self-checked code",
+    "should_trigger": true
+  },
+  {
+    "query": "Implement the password-reset flow per these criteria and loop until the review is clean",
+    "should_trigger": true
+  },
+  {
+    "query": "Review this PR I wrote for edge cases and broken assumptions",
+    "should_trigger": false
+  },
+  {
+    "query": "Should we use Postgres or DynamoDB for the new service? Write it up for review",
+    "should_trigger": false
+  },
+  {
+    "query": "Run the pre-merge gate on my branch before I open the PR",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/dev-team/skills/feature-implement-loop/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "feature-implement-loop",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Implement this story in our Python/FastAPI service (pytest, ruff, mypy already set up):\n\nAs an admin, I can export the audit log for a date range as CSV.\nAcceptance criteria:\n1. GET /admin/audit/export?from=YYYY-MM-DD&to=YYYY-MM-DD returns text/csv.\n2. Non-admins get 403.\n3. from after to returns 400 with a clear message.\n4. Ranges over 90 days return 400.\n5. The CSV opens cleanly in Excel.\n\nBuild it and check your own work.",
+      "assertions": [
+        "Restates the five acceptance criteria as a numbered checklist before writing code",
+        "Plans a named test per criterion up front and flags criterion 5 (opens cleanly in Excel) as manual-verify",
+        "Runs the project's tests plus ruff and mypy, and does not report VERIFIED while any command is red",
+        "Review findings are tagged blocker/major/minor/nit with file:line and a concrete fix, covering edge cases, security (e.g. authz on the admin route, CSV formula injection), and craft",
+        "Tests assert the criterion's expected output (status codes, content type, messages), not just that the call didn't throw",
+        "Stops at or before 3 rounds, and later rounds patch only the named gaps rather than regenerating the whole feature",
+        "Final report has a status (VERIFIED, VERIFIED WITH OPEN ITEMS, or BLOCKED), an acceptance-criteria table mapping each criterion to a test, manual-verify, or open item, an honest round log, and open items",
+        "Does not add criteria the user did not give without echoing them back first"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/skills/feature-implement-loop/manifest.json

@@ -0,0 +1,14 @@
+{
+  "name": "feature-implement-loop",
+  "version": "0.1.0",
+  "description": "Implement a feature or story so it ends up *verified*, not just generated. Takes a description + acceptance criteria, writes code and tests, then runs an adversarial review pass that hunts for gaps (broken edge cases, baked-in assumptions, uncovered acceptance criteria), and re-generates to close them — looping until the review is clean or a 3-round cap is hit. Use when handed a ticket / story / feature spec with acceptance criteria and the goal is shippable, self-checked code — not a first draft.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["design-doc", "devils-advocate", "doc-critique", "pre-merge-review"],
+  "handoff": [
+    { "to": "pre-merge-review", "when": "the code exists and the question is whether it can merge", "purpose": "Judge the diff that now exists against a mechanical gate.", "fallback": "If pre-merge-review is absent, run the repo's own lint and tests and honour the exit code; do not self-certify." }
+  ],
+  "tags": ["dev-workflow", "implementation", "tdd", "acceptance-criteria", "adversarial", "self-correcting", "code-generation"],
+  "model": { "tier": "standard", "rationale": "Code + test generation against acceptance criteria. The adversarial pass delegates to devils-advocate (heavy) where available; the loop itself is generation." }
+}