skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/dev-team/loops/build/LOOP.md

@@ -0,0 +1,80 @@
+---
+name: build
+description: Take an agreed requirement to merged code through a capped generate-verify-gate loop, with a mechanical gate that decides and a human who owns the merge. Use when the user wants to implement a story, fix a triaged bug, or ask whether a change is safe to merge.
+---
+
+# build
+
+The repo-scope loop: a requirement enters, merged code leaves, and nothing crosses a stage
+boundary without passing that stage's gate. This loop *sequences* skills — it never contains
+one. Every skill named below stays independently installable and runnable on its own.
+
+## Stages
+
+| # | Stage | Type | Skills | Gate |
+|---|---|---|---|---|
+| 1 | `shape` | generate | [`user-story-splitter`](../../skills/user-story-splitter/SKILL.md), [`bug-triage`](../../skills/bug-triage/SKILL.md) | — |
+| 2 | `implement` | generate | [`feature-implement-loop`](../../skills/feature-implement-loop/SKILL.md) | — |
+| 3 | `verify` | verify | [`pre-merge-review`](../../skills/pre-merge-review/SKILL.md) | **G2** mechanical |
+| 4 | `decide` | gate | [`council-review`](../../../core/skills/council-review/SKILL.md) | **G2.1** human |
+
+## How to run this loop
+
+1. **Establish the unit of work.** New capability → `user-story-splitter`. Reported defect →
+   `bug-triage`. The stage is done when there is one vertical slice with acceptance criteria a
+   test can assert. Vague criteria are the single largest cause of a wasted round 3.
+2. **Implement.** Hand the slice to `feature-implement-loop`, which runs its own capped
+   generate-challenge-gate cycle internally. Do not re-implement its rounds here — this loop's
+   `cap` governs returns from G2, not the inner skill's rounds.
+3. **Verify at G2.** Run `pre-merge-review`. Its script decides and its panel explains:
+   `python3 packs/dev-team/skills/pre-merge-review/scripts/gate.py`. The exit code is the verdict —
+   `READY`, `NOT READY`, or `BLOCKED`.
+4. **Honour the gate.** `NOT READY` returns to `implement`, up to `cap` (3) times. On the
+   third return, stop looping and emit `BLOCKED` naming what did not converge. Never edit the
+   gate to make it pass.
+5. **Decide at G2.1.** The merge is a human's. Escalate design disagreements surfaced at G2 to
+   `council-review` rather than arguing them inside the diff; `RECONSIDER` and `SPLIT` both
+   leave this loop rather than revising within it.
+
+## Verdicts
+
+Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G2 emits
+`READY` / `NOT READY` / `BLOCKED`. G2.1 emits the council vocabulary. A `revise`-class verdict
+returns to the stage named in `revise_to`; a `redirect`-class verdict leaves the loop.
+
+## When a stage's skill is not installed
+
+Skills install à la carte, so a stage may name a skill the target environment does not have.
+Name the missing skill and skilldrop as its source, do the minimal inline version of that
+stage, and record that the stage ran degraded. A missing skill is never a reason to skip a
+**gate** — the gate is the loop's whole value.
+
+## Run log (opt-in)
+
+Only when the environment variable `SKILLDROP_LOOP_LOG` is set to a file path: after each
+gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is
+sent anywhere. When the variable isn't set, or you can't read it, skip this section.
+
+```bash
+printf '%s\n' '{"ts":"2026-10-01T14:03:00Z","loop":"build","stage":"verify","gate":"G2","verdict":"READY","round":1}' >> "$SKILLDROP_LOOP_LOG"
+```
+
+Fields: `ts` (UTC), `loop`, `stage`, `gate` (`null` for a stage without one), `verdict` (the
+gate's exact word), and `round` (1 for the first attempt, counting returns under the cap).
+`skilldrop loop-stats` summarises the file: which gates pass first time, which loop back, and
+which end in `BLOCKED`.
+
+## Quality bar
+
+- **The gate decides, not the agent.** G2's verdict is `gate.py`'s exit code. An agent that reasons its way past a red gate has broken the loop, not passed it.
+- **The cap is honoured.** Three returns to `implement`, then `BLOCKED` with what did not converge. A fourth round is a defect in this loop, not diligence.
+- **Every stage leaves evidence.** Each stage names its skill, its verdict, and its round number, so the run is auditable after the fact rather than asserted.
+- **Acceptance criteria exist before `implement` starts.** A slice whose criteria a test cannot assert is not shaped; return it to `shape`.
+
+## Anti-patterns to avoid
+
+- ❌ **Calling a skill from inside a skill to "continue the loop."** The loop sequences; skills do not chain. This is what keeps every skill portable to Cursor, Kiro, and Aider.
+- ❌ **Editing `gate.py`, its config, or a test to turn G2 green.** That converts a mechanical gate into a decorative one.
+- ❌ **Treating `PROCEED WITH CONDITIONS` as `PROCEED`.** The conditions travel with the artifact; dropping them is how conditional approvals become unconditional ones.
+- ❌ **Running `decide` for every change.** G2.1 exists for escalated disagreement and the merge itself, not as a ceremony on top of a green gate.
+- ❌ **Starting at `implement` because the story "is obvious."** Unshaped work is what produces a diff nobody can review against anything.

skilldrop_cli/data/packs/dev-team/loops/build/evals/eval_queries.json

@@ -0,0 +1,30 @@
+[
+  {
+    "query": "take this story to merged code",
+    "should_trigger": true
+  },
+  {
+    "query": "run the build loop on this ticket",
+    "should_trigger": true
+  },
+  {
+    "query": "implement this and gate it before I merge",
+    "should_trigger": true
+  },
+  {
+    "query": "is this branch safe to merge yet?",
+    "should_trigger": true
+  },
+  {
+    "query": "write me an ADR for this decision",
+    "should_trigger": false
+  },
+  {
+    "query": "design the system for this requirement",
+    "should_trigger": false
+  },
+  {
+    "query": "what should we build next quarter?",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/dev-team/loops/build/evals/evals.json

@@ -0,0 +1,27 @@
+{
+  "loop_name": "build",
+  "evals": [
+    {
+      "id": "red-gate-blocks-the-merge",
+      "prompt": "Run the build loop on this story: add a /export endpoint. `pytest` currently fails on one new test, and the endpoint reads user_id from the query string.",
+      "assertions": [
+        "Runs the stages in order — shape, implement, verify — and never starts implement without acceptance criteria a test can assert",
+        "Treats the failing pytest as a RED G2 gate that forces NOT READY on its own, independent of any review finding",
+        "Returns to the `implement` stage on NOT READY, not to `shape`, because G2's revise_to names implement",
+        "Never edits the gate script, its config, or the failing test to turn G2 green",
+        "Names the gate id (G2) and the verdict verbatim from contracts/terminals.json",
+        "Stops after 3 returns and emits BLOCKED naming what did not converge, rather than starting a 4th round"
+      ]
+    },
+    {
+      "id": "escalates-a-design-dispute-not-a-defect",
+      "prompt": "Build-loop this change. The gate is green but the reviewer thinks the whole caching approach is wrong.",
+      "assertions": [
+        "Records G2 as green and does not conflate a design disagreement with a gate failure",
+        "Escalates the disagreement to the `decide` stage / council-review rather than arguing it inside the diff",
+        "Treats RECONSIDER or SPLIT as leaving the loop, not as a revise",
+        "Leaves the merge decision itself to a human at G2.1"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/loops/build/loop.json

@@ -0,0 +1,48 @@
+{
+  "$comment": "RFC-0028. This loop is docs/code-implement-verify.mmd promoted from a hand-maintained diagram into the machine-readable source that diagram is now generated from.",
+  "name": "build",
+  "version": "0.2.0",
+  "description": "Take an agreed requirement to merged code through a capped generate-verify-gate loop, with a mechanical gate that decides and a human who owns the merge. Use when the user wants to implement a story, fix a triaged bug, or ask whether a change is safe to merge.",
+  "entrypoint": "LOOP.md",
+  "kind": "loop",
+  "cap": 3,
+  "stages": [
+    {
+      "id": "shape",
+      "type": "generate",
+      "intent": "Turn a requirement or defect into one vertically-sliced unit of work with acceptance criteria.",
+      "skills": ["user-story-splitter", "bug-triage"]
+    },
+    {
+      "id": "implement",
+      "type": "generate",
+      "intent": "Write the code and its tests against the acceptance criteria, challenging the result each round.",
+      "skills": ["feature-implement-loop"]
+    },
+    {
+      "id": "verify",
+      "type": "verify",
+      "intent": "Judge the diff that now exists. The script decides; the panel explains.",
+      "skills": ["pre-merge-review"],
+      "gate": {
+        "id": "G2",
+        "kind": "mechanical",
+        "script": "packs/dev-team/skills/pre-merge-review/scripts/gate.py",
+        "verdicts": ["READY", "NOT READY", "BLOCKED"],
+        "revise_to": "implement"
+      }
+    },
+    {
+      "id": "decide",
+      "type": "gate",
+      "intent": "A human merges. Design disagreements surfaced at G2 are adjudicated here, not argued in the diff.",
+      "skills": ["council-review"],
+      "gate": {
+        "id": "G2.1",
+        "kind": "human",
+        "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "RECONSIDER", "SPLIT", "BLOCKED"],
+        "revise_to": "shape"
+      }
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/loops/release/LOOP.md

@@ -0,0 +1,91 @@
+---
+name: release
+description: Take merged code to live users through a planned, reversible rollout — plan the phases and the rollback, judge readiness on evidence, draft the release notes, then a human makes the go/no-go call. Use when the user has merged a change and asks how to roll it out, whether they are ready to launch, or for a go/no-go decision.
+---
+
+# release
+
+This loop covers the step between `build`, which ends when a human merges, and `operate`,
+which assumes the service is already live. A merge can be undone with a revert. A launch that
+has touched users or data often cannot be undone, so this loop gets its own gates instead of
+being folded into either neighbour.
+
+## Stages
+
+| # | Stage | Type | Skills | Gate |
+|---|---|---|---|---|
+| 1 | `plan` | generate | [`migration-plan`](../../skills/migration-plan/SKILL.md) | — |
+| 2 | `ready` | verify | [`launch-readiness`](../../skills/launch-readiness/SKILL.md) | **G2.5** review |
+| 3 | `announce` | generate | [`release-notes`](../../skills/release-notes/SKILL.md) | — |
+| 4 | `go` | gate | [`council-review`](../../../core/skills/council-review/SKILL.md) | **G2.6** human |
+
+## How to run this loop
+
+1. **Plan the rollout and the way back.** `migration-plan` sets out the phases, a tested
+   rollback for each one, and at most one named point of no return. For a code-only change
+   behind a flag, the plan can be short: the flag, the stages and how to turn it off. It still
+   has to exist.
+2. **Judge readiness at G2.5.** `launch-readiness` lists the change's own failure modes, then
+   checks rollback, detection, response, measured targets, data and privacy, comms and
+   exposure, each with evidence. `REVISE` returns to `plan`, and the report names which gap to
+   close and which skill closes it. A missing rollback is `BLOCKED` on its own.
+3. **Announce only once it is ready.** `release-notes` drafts the customer-facing and
+   internal notes from the git range. Writing them before G2.5 risks announcing a launch that
+   then does not happen.
+4. **A human decides at G2.6.** The release owner decides whether to ship *now*, given
+   timing, freeze windows and on-call coverage. When that decision is contested, use
+   `council-review`. `RECONSIDER` means it is ready but this is the wrong time, and the work
+   waits instead of going back to `plan`.
+
+After `PROCEED`, the change is live and the work moves to `operate`. Gaps that G2.5 sent to
+`observability-plan` or `runbook-generator` are the first things `operate` picks up.
+
+## Verdicts
+
+Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G2.5 emits `PROCEED`,
+`PROCEED WITH CONDITIONS`, `REVISE` or `BLOCKED`. G2.6 adds `RECONSIDER`. `PROCEED WITH
+CONDITIONS` at G2.5 is allowed only when the open rows are comms or exposure. A detection or
+response gap is always `REVISE`.
+
+## Non-interactive runs
+
+Never invent evidence such as rehearsal logs, load-test numbers, dashboards or sign-offs.
+When the change being released cannot be identified, emit `BLOCKED: need <the PR, tag, or
+feature name>`. G2.6 is a human gate. A headless run stops after `announce` and reports the
+G2.5 verdict for a person to act on.
+
+## When a stage's skill is not installed
+
+Name the missing skill and skilldrop as its source, do the minimal inline version of that
+stage, and record the stage as degraded. For `ready`, the minimal version is the seven checks
+written as a list, each marked met, not met or n/a with a reason. Skipping it is never the
+minimal version.
+
+## Run log (opt-in)
+
+Only when the environment variable `SKILLDROP_LOOP_LOG` is set to a file path: after each
+gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is
+sent anywhere. When the variable isn't set, or you can't read it, skip this section.
+
+```bash
+printf '%s\n' '{"ts":"2026-10-01T14:03:00Z","loop":"release","stage":"ready","gate":"G2.5","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"
+```
+
+Fields: `ts` (UTC), `loop`, `stage`, `gate` (`null` for a stage without one), `verdict` (the
+gate's exact word), and `round` (1 for the first attempt, counting returns under the cap).
+`skilldrop loop-stats` summarises the file: which gates pass first time, which loop back, and
+which end in `BLOCKED`.
+
+## Quality bar
+
+- **Rollback exists before readiness is judged.** A plan with no way back is the one thing that cannot be fixed after launch.
+- **Readiness rests on evidence.** Every check links to something; "we're good" is `not met`.
+- **Can and should are separate gates.** G2.5 says whether it can ship; G2.6 says whether it should ship now.
+- **Detection gaps leave this loop as hand-offs.** `operate` picks them up first, rather than discovering them during the first incident.
+
+## Anti-patterns to avoid
+
+- ❌ **Jumping from merge to "instrument a running service".** That skips this loop entirely, which is the gap it exists to close.
+- ❌ **Announcing before G2.5.** Customers hear about a launch that is then pulled.
+- ❌ **Treating flag-off as a rollback without a data story.** If dual-write or a backfill has run, turning the flag off does not undo the data.
+- ❌ **Letting G2.6 overrule a G2.5 `BLOCKED`.** A human can delay a ready launch; they cannot make an unready one ready by deciding to go.

skilldrop_cli/data/packs/dev-team/loops/release/loop.json

@@ -0,0 +1,47 @@
+{
+  "$comment": "RFC-0031. Covers the step between build (ends at merge, G2.1) and operate (starts at instrument). The gate ids sit between G2 and G3 to match where the loop sits in the lifecycle.",
+  "name": "release",
+  "version": "0.2.0",
+  "description": "Take merged code to live users through a planned, reversible rollout — plan the phases and the rollback, judge readiness on evidence, draft the release notes, then a human makes the go/no-go call. Use when the user has merged a change and asks how to roll it out, whether they are ready to launch, or for a go/no-go decision.",
+  "entrypoint": "LOOP.md",
+  "kind": "loop",
+  "cap": 3,
+  "stages": [
+    {
+      "id": "plan",
+      "type": "generate",
+      "intent": "Decide the rollout phases, the rollback for each, and the one point of no return, before anything reaches users.",
+      "skills": ["migration-plan"]
+    },
+    {
+      "id": "ready",
+      "type": "verify",
+      "intent": "Judge on evidence whether the change can go live: rollback, detection, response, measured targets, data, comms, exposure.",
+      "skills": ["launch-readiness"],
+      "gate": {
+        "id": "G2.5",
+        "kind": "review",
+        "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "BLOCKED"],
+        "revise_to": "plan"
+      }
+    },
+    {
+      "id": "announce",
+      "type": "generate",
+      "intent": "Write what users and the team are told. Only after readiness, so nobody announces a launch that then fails the check.",
+      "skills": ["release-notes"]
+    },
+    {
+      "id": "go",
+      "type": "gate",
+      "intent": "A human decides whether it should ship now. Readiness says it can; this decides timing, freeze windows, and who is on call.",
+      "skills": ["council-review"],
+      "gate": {
+        "id": "G2.6",
+        "kind": "human",
+        "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "RECONSIDER", "BLOCKED"],
+        "revise_to": "plan"
+      }
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/pack.json

@@ -0,0 +1,56 @@
+{
+  "description": "Build-and-ship: story splitting, implementation with adversarial review, test plans, triage, migrations, launch readiness, release notes, agent-policy files, and code-quality gates.",
+  "display_name": "Dev team",
+  "keywords": ["review", "merge", "testing", "release", "code-quality"],
+  "links": {
+    "documentation": "https://sananthanarayan.github.io/skilldrop/packs/dev-team/"
+  },
+  "maintainers": [
+    {
+      "name": "sananthanarayan"
+    }
+  ],
+  "first-value": {
+    "audience-posture": "technical",
+    "prerequisites": ["A git repository with changes on a branch", "The reviewer subagents, for the full panel: `skilldrop install --panel review` (the Claude plugin includes them)"],
+    "starter-task": "Find out whether your current branch is safe to merge",
+    "starter-prompt": "Is this branch safe to merge? Run a pre-merge review on the current diff.",
+    "verification": "pre-merge-review runs the project's lint, typecheck and tests through its gate script, then the reviewer panel, and ends with READY or NOT READY.",
+    "recovery": "If the gate script cannot find your lint or test commands, tell it what they are. If the panel is skipped, install the reviewer subagents with `skilldrop install --panel review`."
+  },
+  "requires": ["core"],
+  "journey": {
+    "when": "You have an agreed requirement or a triaged bug and want it implemented, verified and ready to merge.",
+    "you_bring": [
+      "the epic, story or bug report",
+      "a repo with working lint, typecheck and test commands",
+      "who owns the merge"
+    ],
+    "steps": [
+      {
+        "skill": "user-story-splitter",
+        "you_do": "Paste the epic or feature request (use bug-triage instead for a defect).",
+        "you_get": "Independently shippable stories with Gherkin acceptance criteria and a recommended build order.",
+        "decide": "Pick the one slice to build now; criteria a test cannot assert send it back to be reshaped."
+      },
+      {
+        "skill": "feature-implement-loop",
+        "you_do": "Hand it the slice and its acceptance criteria.",
+        "you_get": "Code and tests, reviewed for edge cases, security and craft for up to three rounds, with a status (VERIFIED, VERIFIED WITH OPEN ITEMS or BLOCKED), a criteria-to-test table and a round log."
+      },
+      {
+        "skill": "pre-merge-review",
+        "you_do": "Ask whether the current diff is safe to merge.",
+        "you_get": "The gate script's lint, typecheck and test result, then findings from the correctness, security and code-quality reviewers, ending in one verdict.",
+        "decide": "Gate G2 is the script's exit code: READY moves on; NOT READY goes back to implementation, at most three times before BLOCKED."
+      },
+      {
+        "skill": "council-review",
+        "you_do": "Only if the review surfaced a design disagreement, put it to the panel.",
+        "you_get": "Independent positions, the named cruxes, and a Chair's verdict with dissent recorded.",
+        "decide": "Gate G2.1: a human merges. SPLIT and RECONSIDER leave the loop rather than revising in the diff."
+      }
+    ],
+    "you_end_with": "A shaped story, verified code and tests, a READY verdict with the review findings, and a human merge decision."
+  }
+}

skilldrop_cli/data/packs/dev-team/skills/accessibility-audit/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: accessibility-audit
+description: Adversarially audit a UI (component code, page markup, screenshot, or flow) against WCAG 2.2 AA — findings cited to specific success criteria, centered on the user and assistive tech each one blocks, severity-tagged, with a concrete fix and what a scanner would miss. Use when the user wants an accessibility review, a11y audit, WCAG check, or to find what blocks screen-reader / keyboard / low-vision users before shipping.
+---
+
+# accessibility-audit
+
+Finds the barriers that lock real people out of a UI — and cites the exact success criterion, names the assistive tech that hits the wall, and separates what an automated scanner catches from what only a human with a screen reader will. The UI counterpart to `devils-advocate` (code), `doc-critique` (docs), and `threat-model` (designs): one adversarial pass, severity-tagged, evidence-first. Automated tools catch perhaps a third of WCAG issues; this audit is built for the other two thirds.
+
+## How to respond
+
+1. **Establish what's auditable from the input, and say what isn't.** Inputs vary in what they reveal:
+   - **Component/page code or markup** — the richest: roles, labels, semantics, focus management, tab order are all inspectable.
+   - **Screenshot/image** — visual only: contrast, target size, text-as-image, visible focus *if* captured. Keyboard behavior, screen-reader output, and focus order are **not** observable — list them as "must verify with live AT", never guess a pass.
+   - **A described flow** — reason about it, flag the checks that need the real thing.
+   Default standard is **WCAG 2.2 level AA**; note if the user wants A or AAA. State the input's coverage limits up front so a clean section never reads as a guarantee it can't be.
+
+2. **Sweep all four POUR principles** using the success-criterion catalog in [`reference.md`](reference.md) — Perceivable, Operable, Understandable, Robust. Don't transcribe the catalog; run it as a lens and report only what the UI actually fails or can't be verified for. The high-yield manual checks scanners miss, swept explicitly: **keyboard-only operability** (every interactive element reachable and operable, visible focus, no traps, logical order), **screen-reader semantics** (name/role/value, headings, landmarks, alt-text *quality* not just presence), **meaningful sequence and focus order**, **error identification and recovery**, **reflow/zoom to 400%**, **target size (2.2)**, and **motion/animation** preferences.
+
+3. **Center every finding on the user it blocks and the AT involved.** A finding without a victim is abstract. ✅ *"Submit button is a `<div>` with a click handler — keyboard users cannot reach or activate it (Tab skips it, Enter does nothing), and a screen reader announces nothing actionable. Blocks: keyboard-only and screen-reader users from completing checkout."* — ❌ *"Button not accessible."* Name the assistive tech (VoiceOver/NVDA/JAWS, keyboard-only, 400% zoom, switch control, reduced-motion) so the fix is testable.
+
+4. **Cite the specific success criterion** — number, name, level — for every finding: `1.4.3 Contrast (Minimum) [AA]`, `2.1.1 Keyboard [A]`, `4.1.2 Name, Role, Value [A]`, `2.4.7 Focus Visible [AA]`, `2.5.8 Target Size (Minimum) [AA]`. "Make it accessible" is not a finding; a criterion citation is what makes it actionable and arguable.
+
+5. **Severity-tag with the shared markers**, by impact on task completion:
+   - 🟥 **blocker** — a user group cannot complete the task at all (keyboard trap, unlabeled critical control, contrast that renders text unreadable, a form that can't be submitted via keyboard).
+   - 🟧 **major** — significant barrier with a painful workaround (poor focus order, vague link text, missing error association).
+   - 🟨 **minor** — friction, not a wall (redundant alt text, a non-essential decorative image with empty-but-present alt).
+   - ⚪ **nit** — best-practice polish.
+   If everything is a blocker, the severity call failed — calibrate to whether the task can actually be completed.
+
+6. **Compute contrast and sizes where the input allows it.** Given colors, state the actual ratio against the 4.5:1 (normal) / 3:1 (large) threshold: ✅ *"`#767676` on `#fff` = 4.54:1, passes AA for normal text by a hair; fails for the 14px placeholder which needs the same 4.5:1 and gets it — but `#999` on `#fff` = 2.85:1 fails."* Numbers, not eyeballing.
+
+7. **Separate scanner-catchable from human-only**, explicitly, per finding (tag `[auto]` vs `[manual]`). It tells the team what to gate in CI (axe/Lighthouse) and what needs the screen-reader pass that no tool replaces — and it's honest that the audit's manual findings are the ones a pipeline won't keep catching. End with a **"what's solid"** section (the patterns done right, so they're preserved on refactor) and a prioritized fix order.
+
+8. **Emit in one message**: coverage note (input limits), findings grouped by severity with SC citation + affected user/AT + `[auto]`/`[manual]` + concrete fix, contrast/size computations, what's solid, and the must-verify-with-live-AT checklist for anything the input couldn't confirm.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — the WCAG 2.2 AA success-criterion catalog by POUR, the affected-user/assistive-tech map, the severity rubric, and the "what automated tools miss" list
+- [`examples/login-form.md`](examples/login-form.md) — worked example: a login form component audited to severity-tagged findings
+
+## Quality bar
+
+- **Every finding cites a specific success criterion** (number + name + level). Uncited "issues" are opinions.
+- **Every finding names the user group and assistive tech it blocks.** No victim, no finding.
+- **Severity reflects task-completion impact**, calibrated — not everything is a blocker, and a real keyboard trap is never a minor.
+- **Contrast and target-size claims are computed numbers** against the threshold, not visual guesses.
+- **Coverage limits are stated** and unverifiable checks are listed as must-test-with-AT, never silently passed. A screenshot audit never claims keyboard operability is fine.
+- **`[auto]` vs `[manual]` is tagged**, so CI-gateable findings are separated from the human-only ones.
+- **"What's solid" is present**, so good semantics survive the next refactor.
+
+## When to use this skill
+
+- ✅ Auditing a component, page, or flow against WCAG before shipping
+- ✅ "Is this accessible? / find the a11y issues" for real markup, a screenshot, or a flow
+- ✅ Pre-launch accessibility gate, or fixing a failed audit
+- ✅ Reviewing a design/screenshot for the accessibility issues catchable before build
+
+## When NOT to use this skill
+
+- ❌ Setting the accessibility *target* (which WCAG level, on which scope) — that's `nfr-spec`
+- ❌ General code correctness/security review — that's `devils-advocate`
+- ❌ Writing the component — fix findings in your normal build loop, or hand to `feature-implement-loop`
+- ❌ A full certified VPAT/conformance attestation — this audit feeds one, but legal sign-off is a formal process beyond a review
+
+## Anti-patterns to avoid
+
+- ❌ **"Make it accessible" findings.** Uncited, unactionable, unarguable. Every finding pins a success criterion.
+- ❌ **Faulting alt-text presence, not quality.** `alt="image"` passes a scanner and fails a human; `alt="chart"` on a data chart conveys nothing. Audit what the alt *says*.
+- ❌ **Claiming keyboard/SR passes from a screenshot.** You cannot see focus order or AT output in a PNG — list them as must-verify, don't invent a pass.
+- ❌ **Severity inflation.** Tagging a decorative-image nit as a blocker burns the credibility the real keyboard trap needs.
+- ❌ **Eyeballing contrast.** "Looks low" isn't a finding; "2.85:1, fails 4.5:1 AA" is.
+- ❌ **Scanner-only thinking.** Reporting only what axe would catch and calling it an audit — the two-thirds it misses (focus order, label accuracy, meaningful sequence, error recovery) is where users actually get stuck.
+- ❌ **Color as the only signal flagged once.** Reliance on color (1.4.1) shows up in status, charts, form errors, links-in-text — sweep every instance, not the first one.

skilldrop_cli/data/packs/dev-team/skills/accessibility-audit/evals/eval_queries.json

@@ -0,0 +1,30 @@
+[
+  {
+    "query": "Run an a11y audit on this signup page markup",
+    "should_trigger": true
+  },
+  {
+    "query": "Is this component WCAG 2.2 AA compliant? Find what blocks screen-reader users",
+    "should_trigger": true
+  },
+  {
+    "query": "Here's a screenshot of our dashboard — what accessibility issues can you spot before we build it?",
+    "should_trigger": true
+  },
+  {
+    "query": "We failed an accessibility review; check this modal for keyboard traps and focus problems",
+    "should_trigger": true
+  },
+  {
+    "query": "What WCAG level should our new product commit to, and on which scope?",
+    "should_trigger": false
+  },
+  {
+    "query": "Review this PR for correctness bugs and edge cases",
+    "should_trigger": false
+  },
+  {
+    "query": "Implement this date-picker story with tests until the acceptance criteria pass",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/dev-team/skills/accessibility-audit/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "accessibility-audit",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Audit this checkout form component before we ship:\n\n<form>\n  <div class=\"title\">Payment</div>\n  <input placeholder=\"Card number\" style=\"color:#999;background:#fff\">\n  <input placeholder=\"Expiry\">\n  <span class=\"err\" style=\"color:red\">Invalid</span>\n  <img src=\"lock.svg\" alt=\"image\">\n  <div class=\"btn\" onclick=\"submit()\" style=\"width:20px;height:20px\">Pay</div>\n</form>\n\nTarget is WCAG 2.2 AA.",
+      "assertions": [
+        "Opens with a coverage note stating what markup alone can and cannot verify (e.g. actual screen-reader output, live focus order)",
+        "Every finding cites a specific success criterion with number, name, and level (e.g. 2.1.1 Keyboard [A], 4.1.2 Name, Role, Value [A])",
+        "Every finding names the user group and assistive tech it blocks (e.g. keyboard-only, NVDA/VoiceOver users)",
+        "The div-as-button is a blocker for keyboard and screen-reader users; minor issues like the lock icon's alt text are not inflated to blocker",
+        "Contrast for #999 on #fff is given as a computed ratio (about 2.85:1) against the 4.5:1 threshold, and the 20x20 target is checked against 2.5.8's 24x24 minimum",
+        "Each finding is tagged [auto] or [manual] and has a concrete fix",
+        "Ends with a 'what's solid' section and a must-verify-with-live-AT checklist",
+        "Does not claim a pass on any behavior the markup can't show, and does not invent elements not in the snippet"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/skills/accessibility-audit/examples/login-form.md

@@ -0,0 +1,76 @@
+# Worked example — login form component → severity-tagged audit
+
+## Input (React component, verbatim)
+
+```jsx
+function LoginForm() {
+  const [err, setErr] = useState(false);
+  return (
+    <div className="login">
+      <div className="title" style={{fontSize: 22, fontWeight: 700}}>Sign in</div>
+      <input type="text" placeholder="Email" style={{color: '#999'}} />
+      <input type="password" placeholder="Password" />
+      {err && <span style={{color: 'red'}}>✕</span>}
+      <div className="btn" onClick={submit} style={{background:'#5b9', color:'#fff', padding:'6px 10px'}}>
+        Log in
+      </div>
+      <span className="link" onClick={forgot}>Forgot?</span>
+    </div>
+  );
+}
+```
+
+## Output
+
+### Coverage note
+Audited from component code: semantics, labels, roles, keyboard reachability, and contrast (from inline styles) are inspectable. Live focus-order and screen-reader output still need a real AT pass — flagged below.
+
+### 🟥 Blockers
+
+**A11Y-1 — Submit control is a `<div>`, unreachable and unoperable by keyboard** · `2.1.1 Keyboard [A]`, `4.1.2 Name, Role, Value [A]` · `[auto]`+`[manual]`
+A `<div onClick>` is not in the tab order, doesn't fire on Enter/Space, and exposes no button role or name to AT.
+Blocks: keyboard-only and screen-reader users from logging in at all — there is no other submit path.
+Fix: use `<button type="submit">Log in</button>` inside a `<form onSubmit>`. Same for `Forgot?` → `<button>` (or `<a href>` if it navigates).
+
+**A11Y-2 — Inputs have no programmatic label** · `3.3.2 Labels or Instructions [A]`, `1.3.1 Info and Relationships [A]`, `4.1.2 [A]` · `[auto]`
+Placeholders are not labels: they vanish on input and many screen readers don't announce them reliably. A screen-reader user hears "edit text, blank".
+Fix: add `<label htmlFor>` tied to each input (visible label preferred), or at minimum `aria-label`. Placeholders stay as hints, not the only label.
+
+### 🟧 Major
+
+**A11Y-3 — Error is conveyed by color and an icon glyph only, not associated with a field** · `1.4.1 Use of Color [A]`, `3.3.1 Error Identification [A]`, `4.1.3 Status Messages [AA]` · `[manual]`
+A red `✕` with no text tells a blind or color-blind user nothing about what failed or which field. It's also not announced (no live region) and not linked to an input.
+Blocks: blind users get no error info; color-blind users may miss the signal.
+Fix: render text ("Incorrect email or password"), associate via `aria-describedby` on the relevant input, and put the message in `role="alert"` so it's announced.
+
+**A11Y-4 — Email input text contrast fails AA** · `1.4.3 Contrast (Minimum) [AA]` · `[auto]`
+`#999` on `#fff` = **2.85:1**, below the 4.5:1 minimum for normal text. Low-vision users can't read typed input.
+Fix: darken to ≥ `#767676` (4.54:1) or darker.
+
+### 🟨 Minor
+
+**A11Y-5 — Submit button color contrast borderline / unverifiable focus ring** · `1.4.3 [AA]`, `2.4.7 Focus Visible [AA]` · `[auto]`+`[manual]`
+White text `#fff` on `#5b9` (`#55bb99`) = **2.35:1** — fails 4.5:1 for the button label. Also, once it's a real `<button>`, confirm a visible focus indicator exists (can't verify from static code).
+Fix: darken the button background to clear 4.5:1 — e.g. `#1f7a57` = 5.28:1 (`#2e8b6f` is only 4.17:1 and still fails, the classic "looks dark enough" trap) — and ensure a visible `:focus-visible` outline.
+
+### ⚪ Nits
+
+**A11Y-6 — Title is a styled `<div>`, not a heading** · `1.3.1 [A]`, `2.4.6 [AA]`
+Screen-reader users navigate by headings; a visual-only "Sign in" isn't in the outline.
+Fix: `<h1>` (or appropriate level) instead of `<div className="title">`.
+
+### What's solid
+- `type="password"` is correct (masking + manager integration).
+- Touch targets: padding gives the button adequate size once it's a real control — keep ≥ 24×24 (`2.5.8`).
+
+### Must verify with live AT
+- Focus **order** through the form (DOM order looks correct, but confirm).
+- Screen-reader announcement of the error live region after a failed submit.
+- Visible focus indicator on all controls (`2.4.7`) once they're focusable.
+- Behavior at 400% zoom / reflow (`1.4.10`).
+
+### Fix order
+1. A11Y-1, A11Y-2 (blockers — nobody can log in via AT).
+2. A11Y-3 (error semantics).
+3. A11Y-4, A11Y-5 (contrast — quick CSS).
+4. A11Y-6 (heading).

skilldrop_cli/data/packs/dev-team/skills/accessibility-audit/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "accessibility-audit",
+  "version": "0.1.0",
+  "description": "Adversarially audit a UI (component code, page markup, screenshot, or flow) against WCAG 2.2 AA — findings cited to specific success criteria, centered on the user and assistive tech each one blocks, severity-tagged, with a concrete fix and what a scanner would miss. Use when the user wants an accessibility review, a11y audit, WCAG check, or to find what blocks screen-reader / keyboard / low-vision users before shipping.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["devils-advocate", "doc-critique", "feature-implement-loop", "nfr-spec", "threat-model"],
+  "tags": ["accessibility", "a11y", "wcag", "audit", "review", "inclusive-design"],
+  "model": { "tier": "heavy", "rationale": "Adversarial review against WCAG success criteria — cheaper models fault alt-text presence over quality, under-call severity, miss focus-order/name-role-value issues, and claim AT passes from screenshots. Never downgrade." }
+}