pi-dev-team 0.2.0

package/knowledge/exploratory-testing-field-guide.md

@@ -0,0 +1,122 @@
+# Exploratory Testing Field Guide
+
+Source: *Explore It!* by Elisabeth Hendrickson (Pragmatic Programmers, 2013).
+Reference for `skills/exploratory-testing/SKILL.md`. Protocol lives in the skill; frameworks live here.
+
+---
+
+## 1. Charter Quality (§2.3–2.4)
+
+**Format**: `Explore [target] with [approach] to discover [concern]`
+
+**Anti-patterns**:
+
+| Anti-pattern | Example |
+|-------------|---------|
+| Too specific — becomes a test case | "Explore editing with value O'Malley to check apostrophe handling" |
+| Too broad — infinite scope, never done | "Explore system security with all hacking tools to find any holes" |
+| Missing "with" — no approach specified | "Explore /payments to find bugs" |
+| Missing "to discover" — no risk hypothesis | "Explore auth with boundary inputs" |
+
+Fix for too-broad charters: split into multiple focused charters, one area or concern each.
+
+**Charter generation sources**:
+
+| Source | Signal | Example |
+|--------|--------|---------|
+| Requirements discussions | Ambiguity, "I'll have to think about that" | "Explore username editing with invalid characters to discover if constraints are enforced" |
+| Implicit expectations | Security model, performance, reliability — never stated | "Explore the new feature with high-volume inputs to discover performance regressions" |
+| Stakeholder questions | Risk questions raised during design | "Explore billing with sequence variations to discover double-billing conditions" |
+| Existing artifacts | Code comments, bug database, support logs | "Explore the payment flow with bug #4231 edge cases to discover if the fix holds" |
+| Mid-session discoveries | Off-charter temptations — each is a new charter | "Explore /api/orders with the same error-format probe to discover cross-endpoint inconsistency" |
+
+---
+
+## 2. Exploration Without a GUI (Ch. 10)
+
+All techniques apply to APIs, CLIs, batch programs, libraries — any interface.
+
+**Variable identification (pre-probe)**:
+
+| Dimension | What to vary |
+|-----------|-------------|
+| Parameters | Count, names, order |
+| Values | Boundary, null/empty/zero, special characters |
+| Data types | String, number, boolean, null, object, array, mixed |
+| Sizes | Short, typical, very long, maximum |
+| Character sets | ASCII, Unicode, accented, CJK, nonprinting, whitespace variants |
+| Combinations | Valid × invalid, valid × boundary, multiple invalid at once |
+
+**Type variation probes** (extends Goldilocks):
+
+| Input | Finds |
+|-------|-------|
+| `null` | Missing null checks, NPE |
+| `""` (empty string) | Empty-string handling distinct from null |
+| `0` / `[]` / `{}` | Zero-value edge cases |
+| Wrong type | Type coercion bugs, implicit conversion surprises |
+| Very large value / long string | Performance degradation (O(n²)), buffer issues, truncation → triggers Telemetry Deepening |
+| `Infinity`, `NaN`, `-0` | Numeric edge cases in calculations |
+| Unicode / accented / CJK | Encoding bugs, collation issues |
+| Nonprinting / whitespace variants | Trim/strip inconsistencies |
+
+---
+
+## 3. State Modeling (Ch. 8)
+
+**State detection — Jorgensen's 3 questions** (ask after each probe):
+
+1. Are there things I could do now that I could not do before?
+2. Are there things I cannot do now that I could do before?
+3. Do my actions have different results now than before?
+
+**"While" language cue**: any sentence using *while* in requirements or comments identifies a state.
+Examples: "while the account is suspended", "while the system is importing data".
+
+**Event taxonomy**:
+
+| Type | Description | Why it matters |
+|------|-------------|----------------|
+| User action | Explicit input triggering a transition | Most obvious; usually already tested |
+| System-generated | Background activity completing (auth, data load, job) | Creates interstitial states — narrow windows of vulnerability |
+| Time-based | Timeouts, expiry, scheduled operations | Hard to reproduce; race-condition source |
+
+**State model strategies**:
+
+| Strategy | Rule |
+|----------|------|
+| Narrow your focus | One target; if you can't name it simply, split it |
+| Identify a perspective | User vs. system perspective → different states |
+| Dial abstraction | Small target → map substates; large target → lump into one named state |
+
+**Transition probe set** (Slice 2):
+
+- Valid forward transitions
+- Reverse transitions
+- Skipped transitions (A → C, bypassing B)
+- Invalid transitions (action valid only in another state)
+- Time-based transitions (trigger timeout; probe during interstitial)
+
+---
+
+## 4. Iterative Probe-Learn-Probe
+
+1. Identify variables — what can vary in this target?
+2. Start obvious — confirm happy path before diverging
+3. Follow surprises — vary the parameters that produced unexpected results
+4. Off-charter temptations — record as new charters; stay in current session
+5. Budget awareness — allocate remaining probes to highest-risk variables
+
+---
+
+## 5. Implicit Expectations
+
+Stakeholders never state these because they assume they're obvious — highest-value adversarial targets:
+
+| Implicit expectation | Adversarial lens |
+|---------------------|-----------------|
+| Security model applies to all features | Authorization bypass |
+| Data operations must not corrupt state | Data integrity |
+| System safe under concurrent use | Timing / ordering |
+| Performance acceptable at scale | Size variation → Telemetry Deepening |
+| Crashes never acceptable | Null / type variation |

package/knowledge/failure-routing.md

@@ -0,0 +1,28 @@
+# Failure-Class Routing
+
+Read at the start of each repair iteration in `/build` step 4 (per-behavior
+cycle, review-fix loop) and `/apply-fixes` step 4 (per-fix validation).
+Classify the failing output/exit code by regex — deterministic, no LLM call,
+no extra dispatch. Only the route changes; iteration caps never rise and a
+route switch never resets the shared budget.
+
+## Classification Table
+
+| Signature pattern | Class | Route | Escalation |
+|---|---|---|---|
+| `SyntaxError\|error TS\d+\|cannot find symbol\|ParseError\|unexpected token`; compiler exit 2 | `compile-syntax` | inline fix | Stays inline on repeat — no ambiguity left to diagnose. |
+| Named test fails again after one inline attempt; `AssertionError\|expect\(.*\)\.to\|FAILED .*::test_` | `behavioral-test` | inline fix (1st time) | Same test fails again → systematic-debugging, not another blind retry. |
+| `coverage.*below threshold\|Statements.*% \(< \|branch coverage .* below` | `coverage-gap` | test-generation (qa-engineer / test-improve-style) | Repeats → escalate to human (threshold may be miscalibrated). |
+| `eslint\|prettier\|black --check\|ruff\|gofmt` non-zero, style-only diagnostics | `lint-format` | inline fix | Repeats → generic fall-through (likely config, not code). |
+| Security-review finding (secrets, injection, auth bypass) surfaces during validation | `security-finding` | security-engineer (`/build`: dispatch, effort high; `/apply-fixes`: annotate only — no Agent/Skill grant) | Never downgrades to inline; unresolved after dispatch → human arbitration. |
+| Two+ reviewers disagree on the same finding/fix | `reviewer-conflict` | human arbitration (existing escalation: interactive ask; non-interactive hard stop to `.claude/memory/build-escalation-<slug>.md`) | Never auto-resolved by picking a side. |
+| No pattern matches | `unclassified` | generic loop (fall-through, unchanged) | None — identical to pre-routing behavior. |
+
+## Notes
+
+- `/build`: classification *is* the diagnosis step orchestrator constraint 7
+  already requires — not an added step.
+- `/apply-fixes` has no `Agent`/`Skill` grant: non-inline routes annotate the
+  Fix Summary with class + recommended route and move on — never dispatch.
+- A route switch (e.g. inline → systematic-debugging) spends from the same
+  5-iteration cap / 2-correction-iteration checkpoint — never extends or resets it.

package/knowledge/fixture-construction.md

@@ -0,0 +1,56 @@
+# Fixture Construction
+
+Reference file for `test-review`, `test-smell-review`, and the `test-design-advisor` skill. Where `test-strategy.md` decides *which* fixture (lifecycle Fresh/Shared, design Minimal/Standard), this file covers *how* the fixture is built and disposed — the construction mechanics that realize that strategy and fix fixture smells at the root.
+
+Source: Gerard Meszaros, *xUnit Test Patterns* (xunitpatterns.com) — Fixture Setup + Fixture Teardown pattern families. Language- and framework-agnostic — described by role, not any library's API.
+
+Core principle: **build only what this test needs, through intent-revealing construction, and release everything the test created.** Hide irrelevant detail; surface what matters to the behavior under test.
+
+---
+
+## 1. Construction patterns (how the fixture object is built)
+
+| Pattern | What it is | Use when | Cost / risk |
+|---|---|---|---|
+| **Creation Method** | An intent-revealing factory that builds *and returns* the fixture (`anOverdueAccount()`), hiding irrelevant constructor detail | **Default.** Removes Irrelevant Information and Test Code Duplication | — (the safe first move) |
+| **Test Data Builder** | A fluent builder with sensible defaults; each test overrides only the attribute that matters (`anAccount().overdrawn().build()`) | Objects with many attributes, where tests vary one or two | Slightly more code than a Creation Method; worth it past a few variations |
+| **Object Mother** | A library of *named canonical* fixtures shared across tests (`Customers.goldTier()`) | A small set of genuinely shared, well-understood standard cases | Tends to grow into a **General Fixture** — each test gets more than it needs; keep it minimal |
+
+**Decision:** Creation Method by default → Test Data Builder when attributes vary per test → Object Mother only for a few genuinely canonical cases. Prefer building through the SUT's public API; if the fixture cannot be constructed that way, that is a **production-code** problem — introduce a seam per `testability-patterns.md`, never reflection or `InternalsVisibleTo`.
+
+---
+
+## 2. Setup location (where construction runs)
+
+| Location | What it is | Trade-off vs Fresh Fixture isolation |
+|---|---|---|
+| **In-line Setup** | Each test builds its own fixture in the test body | Maximum clarity & isolation; duplication if many tests share shape → extract a Creation Method |
+| **Delegated Setup** | Tests call shared Creation Methods, but from the test body | Removes duplication while keeping each test's setup explicit — usually the sweet spot |
+| **Implicit Setup** | A per-test hook (`setUp`/`beforeEach`) builds the fixture for every test in the class | Concise, but can drift into **General Fixture**/**Mystery Guest** if it builds more than some tests use |
+| **Lazy Setup** | The fixture is created on first use and memoized | Useful for an expensive read-only fixture; risks shared mutable state if not truly read-only |
+| **SuiteFixture Setup** | One fixture built once per *suite* of classes | Last resort for very expensive setup; couples tests across classes — pairs with an Immutable Shared Fixture only |
+
+Keep setup **Fresh + Minimal** by default (`test-strategy.md`); each step toward Implicit/Lazy/SuiteFixture trades isolation for speed and must be justified.
+
+---
+
+## 3. Teardown (releasing what the test created)
+
+| Pattern | What it is | Use when |
+|---|---|---|
+| **In-line Teardown** | The test releases its own resources at the end | Few resources, simple lifetimes |
+| **Implicit Teardown** | A per-test hook (`tearDown`/`afterEach`) releases the fixture | Several tests share the same cleanup shape |
+| **Automated Teardown** | The fixture layer *registers* everything created and releases it automatically after each test | **Persistent fixtures** (DB rows, files, queues) — prevents resource leakage / **Erratic Test** without per-test cleanup code |
+
+For any fixture that touches persistent state, recommend **Automated Teardown** (or equivalent) so a failing test can't leak state into the next — the root fix for the resource-leakage form of the Erratic Test smell.
+
+---
+
+## How this connects to the rest of the toolkit
+
+- **`test-strategy.md`** — *which* fixture (lifecycle/design); this file is *how* it's constructed.
+- **`test-smells.md`** — the smells these fix: Mystery Guest & General Fixture & Irrelevant Information & Test Code Duplication (construction), resource-leakage Erratic Test (teardown).
+- **`testability-patterns.md`** — the production seams (DI, interface extraction) that let a built fixture be injected without back doors.
+- **`test-doubles.md`** — a Fake (in-memory repo/DB) is itself a constructed fixture; choose the double there.
+- **`test-organization.md`** — Setup and Teardown are the first and last of the Four-Phase Test.
+- **`test-refactoring.md`** — the behavior-preserving moves (Extract Creation Method, Introduce Test Data Builder, Replace General Fixture with Minimal Fixture) that get an existing test here.

package/knowledge/frontend-component-architecture.md

@@ -0,0 +1,139 @@
+# Frontend Component Architecture
+
+Reference catalog for reviewing how reusable UI components are factored as a
+frontend evolves. The goal is to keep duplication from accreting: when the same
+rendering, layout, or interaction logic appears in several places, it should be
+extracted into one reusable component with a deliberate prop/slot contract —
+without over-abstracting incidental similarity into the wrong shared component.
+
+Framework-agnostic. Map each pattern to the local framework's idiom (see
+[Framework mapping](#framework-mapping)) rather than pattern-matching one
+framework's syntax.
+
+## When to extract (and when not to)
+
+- **Rule of three.** Two occurrences are not yet duplication — they may diverge.
+  At the **third** copy of the same UI structure + behavior, extract a reusable
+  component. Flag the third occurrence, not the second.
+- **Semantic vs incidental similarity.** Before flagging, apply the test: *if the
+  visual or behavioral rule changes, must every copy change together?* If yes →
+  semantic duplication (extract it). If the copies look alike today but answer to
+  different product concepts that will diverge → incidental similarity (leave it).
+  Two unrelated forms that happen to have a name + email field are not the same
+  component.
+- **Cost of the wrong abstraction.** A premature shared component that accumulates
+  boolean flags (`isAdmin`, `compact`, `variant`, `mode`) to serve divergent
+  callers is worse than the duplication it replaced. Prefer composition over a
+  flag-laden mega-component.
+
+## Detection categories
+
+### Duplicate render logic
+
+The same JSX/template subtree (markup structure + class/style + bindings) is
+repeated across components or files with only data substituted. Three+ near-copies
+of a card, list row, modal, empty-state, or table is an extraction candidate.
+Severity `warning` (third copy) → `error` when a behavioral rule (validation,
+formatting, accessibility wiring) is duplicated and would force multi-site edits.
+
+### Reusable-primitive extraction candidates
+
+Repeated *patterns* that the codebase keeps re-implementing inline instead of
+calling a shared primitive: form-field + label + error wrapper, button variants,
+input groups, loading/skeleton states, pagination, toast/alert. If the project
+already has such a primitive, an inline reimplementation should call it instead
+(name the existing component). If it does not, recommend extracting one.
+
+### Component granularity
+
+- **God component**: one component mixing data fetching, business logic, layout,
+  and several unrelated UI regions (a 300-line `Dashboard` rendering header +
+  sidebar + table + modal inline). Recommend splitting along the seams.
+- **Over-fragmentation**: a separate component per trivial wrapper (`<NameField>`,
+  `<EmailField>`, `<PhoneField>` that each only render one labeled input) where a
+  single parameterized component would do. Recommend collapsing.
+
+### Prop drilling
+
+State or callbacks threaded through intermediate components that do not use them,
+purely to reach a deep descendant (three+ levels of pass-through). Signals that
+the state should be lifted to a context/provider, store, or that the subtree
+should be composed via `children`/slots so the owner passes the node directly.
+Severity `warning`; `suggestion` at two levels.
+
+### Inconsistent component APIs
+
+Sibling components that do the same job expose different contracts: event-handler
+naming drift (`onClick` vs `onPress` vs `handleClick`), boolean vs enum for the
+same concept (`isPrimary` in one, `variant="primary"` in another), inconsistent
+prop shapes (`{user}` object here, `userName`/`userId` scalars there). Inconsistent
+public APIs across reusable components block reuse and invite copy-paste. Recommend
+one convention and align the outliers.
+
+### Composition over configuration
+
+- A component accumulating mode/variant flags that switch large rendering branches
+  is usually better split or recomposed via slots/`children`/compound components.
+- Prefer exposing a `children`/default slot for caller-supplied content over a
+  `renderX`/`content` prop that re-implements composition the framework gives free.
+- Compound-component / named-slot patterns (`<Menu><Menu.Item/></Menu>`) suit
+  families of parts that share implicit state; recommend them over prop-configured
+  monoliths when the family keeps growing.
+
+### Cross-feature / design-system reuse
+
+The same visual primitive reimplemented independently in two feature folders
+(two hand-rolled `Modal`s, two date pickers). As a frontend grows these drift in
+behavior and accessibility. Recommend promoting one into the shared component
+layer (`components/`, `ui/`, design system) and deleting the duplicate.
+
+### Library barrel / public exports
+
+A shared component library needs **one public entry point** — an `index`
+barrel (`index.ts`/`index.js`/`index.tsx`) that re-exports the components callers
+are meant to use. Flag:
+
+- A shared component directory (`components/`, `ui/`, `lib/components`, a
+  design-system package) that has **no index barrel** re-exporting its
+  components, so consumers must reach into file paths to import them.
+- A barrel that exists but is **stale** — newly added reusable components are not
+  re-exported from it, so they are effectively private and get copy-pasted instead
+  of reused.
+- Consumers **deep-importing internals** (`import { Button } from
+  "ui/components/button/Button"`) when a barrel entry exists (`import { Button }
+  from "ui"`); deep imports couple callers to internal layout and discourage reuse.
+
+A single, stable public surface makes the library's components discoverable and
+keeps internal file moves from breaking consumers. Recommend adding/updating the
+`index` barrel and importing through it. This is `warning` for a missing/stale
+barrel in an established shared layer, `suggestion` for deep-import drift.
+
+## Framework mapping
+
+Recognize the *concept*, then express the fix in the project's framework:
+
+- **React/JSX** — extract a function component; lift state to Context or a store;
+  use `children`/render-as-children; compound components via `Component.Sub`;
+  custom hooks for duplicated stateful logic (not just markup).
+- **Vue (SFC)** — extract a `.vue` component; `provide`/`inject` or a Pinia store
+  for drilling; default + named `<slot>`s; composables for shared logic.
+- **Svelte** — extract a `.svelte` component; context API (`setContext`/
+  `getContext`) or a store for drilling; default + named slots / snippets.
+- **Angular** — extract a component; a shared service (DI) instead of `@Input`
+  chains; content projection via `<ng-content>`; structural directives for
+  repeated template fragments.
+
+## What NOT to flag
+
+- Two occurrences (below the rule-of-three threshold) with no shared behavioral
+  rule — wait for the third.
+- Structurally similar markup serving genuinely different product concepts that
+  are expected to diverge (incidental similarity).
+- Framework-idiomatic prop passing one level deep (that is not drilling).
+- One-off layout markup that is intentionally unique to a single screen.
+- A single component or a feature-local folder that is not a reusable library —
+  don't demand a barrel for components that aren't meant to be shared.
+- Pure styling/className concerns with no structural duplication (defer to design
+  tokens / CSS review, not component extraction).
+- Business-logic duplication that is not UI-shaped — that belongs to
+  structure-review / refactor-opportunity-review, not this review.

package/knowledge/gherkin-quality-review-dispatch.md

@@ -0,0 +1,135 @@
+# Adversarial Gherkin Quality Review — Dispatch & Aggregation
+
+Shared procedure `/gherkin-derive` (Step 5b) and `/gherkin-public` (Step 4b)
+both cite, so the dispatch/aggregation mechanics live in exactly one place
+instead of being re-derived near-verbatim in two `SKILL.md` files (issue
+#1452). Each calling step states only what's specific to it (when it fires,
+what input it passes); everything below is common to both.
+
+## Dispatch
+
+Spawn **two** independent instances of the `gherkin-quality-critic` agent as
+parallel subagents in a single message, using the `Agent` tool — the same
+"Spawn agents as parallel subagents in a single message using the Agent
+tool" convention `../skills/code-review/SKILL.md` already documents. Both instances
+receive the identical input (the `.feature` file(s) plus each surface's cited
+source); neither instance's prompt may contain the other's output — that is
+the entire point of running two, and it is a structural property of the
+dispatch (one message, two calls, read neither result until both are issued),
+not a runtime check.
+
+**Why two instances of the same agent, not two distinct critics?** Every
+other multi-agent review point in this fleet (`/plan` step 5b's five
+plan-review-* critics, `/code-review`'s reviewer panel) dispatches **distinct**
+agents with distinct scopes. This is deliberately different: `gaps` and
+`balance_issues` are two facets of one judgment call (does this scenario set
+adequately exercise the cited source?), not two independent concerns that
+split cleanly across separate personas the way plan-review's acceptance/
+design/parallelization/strategic/ux critics do. Running two instances of the
+*same* narrow agent gets ensemble/self-consistency corroboration on that one
+judgment call for the cost of a second call, instead of building a second
+persona with an artificial scope boundary. Splitting `gaps` and
+`balance_issues` into two distinct critics remains the fallback if the two
+checks are ever shown to need materially different review lenses.
+
+## Aggregation
+
+The calling skill performs the fold itself — no third agent, mirroring how
+`/code-review` aggregates its panel's JSON without a meta-agent. Match each
+instance's `gaps`/`balance_issues` entries by the key
+**`(feature_file, title)`**:
+
+- A finding present for the same key in **both** instances' output is
+  **agreed** — even if the two instances worded the `rationale` differently,
+  the same `(feature_file, title)` pair is what makes it agreed.
+- A finding present in only **one** instance's output for a given key is
+  **single-source (unconfirmed)**.
+
+The fold is exact-string, not fuzzy — its accuracy depends on both instances
+wording a shared finding's `title` identically. The agent is instructed to
+word `title` to match the cited `Feature:`/`Scenario:` heading text
+**verbatim** wherever possible, which keeps the common case (the finding is
+about a specific, already-named scenario) exact. The accepted, known gap:
+two instances phrasing the same *novel* finding (e.g. a missing scenario that
+has no existing heading to anchor to) with slightly different wording will
+fold as two single-source findings rather than one agreed finding — this is
+a false negative on "agreed," not a false positive, so it only ever
+under-promotes confidence, never over-promotes it.
+
+## Failure handling
+
+If either `Agent` call errors, times out, or returns output that cannot be
+parsed as the agent's documented JSON schema:
+
+- Treat that instance's `gaps`/`balance_issues` as empty — never crash the
+  skill run over one instance's failure.
+- Never promote the absence of a matching finding from the failed instance
+  into a false "agreed" classification, and never silently drop the note
+  that a failure happened.
+- The report must state explicitly: *"one review instance did not return
+  usable output — findings below are single-source only."*
+- If **both** instances fail, both new report sections print
+  `Both review instances failed to return usable output — no Gherkin quality
+  findings available for this run.` instead of the two per-finding sections.
+
+## Zero-findings state
+
+Both report sections — "Agreed Gherkin quality findings" and "Single-source
+(unconfirmed) Gherkin quality findings" — **always print**, even when a
+bucket is empty, so the section's presence in a report is predictable for
+tooling/tests, not conditional on there being something to say:
+
+```
+Agreed Gherkin quality findings
+  None — both instances raised no findings.
+
+Single-source (unconfirmed) Gherkin quality findings
+  None — both instances raised no findings.
+```
+
+## Report section format
+
+Each calling skill's report step prints two sections, distinct from every
+other callout in that step — this is semantic gap/balance judgment from an
+independent reviewer, never folded into a structural-presence check:
+
+- **"Agreed Gherkin quality findings"** — every `(feature_file, title)` pair
+  both `gherkin-quality-critic` instances raised, one line each:
+  `<feature_file>:<title> — <rationale>`. Per the zero-findings state above,
+  print `None — both instances raised no findings.` when this bucket is
+  empty — never omit the section itself.
+- **"Single-source (unconfirmed) Gherkin quality findings"** — every pair
+  only one instance raised, same line format, explicitly labeled unconfirmed
+  (never elevated to the same confidence as an agreed finding). Same
+  zero-findings rule applies. If either review instance failed or returned
+  unparseable output, state that here per the failure-handling rule above,
+  rather than silently treating it as "no findings."
+
+## Runtime isolation check
+
+The mutual-blindness property above — "one message, two calls, read neither
+result until both are issued" — is asserted only in this doc's prose and in
+content-guards that check the markdown *says* the right thing; nothing runs
+two real dispatches and checks isolation held at runtime.
+`${CLAUDE_PLUGIN_ROOT}/scripts/verify_gherkin_quality_critic_isolation.py` closes that gap: it
+dispatches the real `gherkin-quality-critic` agent twice via two fully
+independent `claude -p` subprocess calls, each against a fixture carrying its
+own randomly-generated canary marker, and fails if either transcript contains
+the *other* dispatch's canary. Like `evals/README.md`'s live eval gate, it is
+**opt-in and paid** (needs the `claude` CLI + `ANTHROPIC_API_KEY`) and
+**fails open** — missing credentials print a skip message and exit 0, never a
+failure. It is not wired into any CI workflow by default. Run it locally:
+
+```bash
+ANTHROPIC_API_KEY=sk-... python3 "${CLAUDE_PLUGIN_ROOT}/scripts/verify_gherkin_quality_critic_isolation.py"
+```
+
+## Scope of this doc
+
+This doc owns the dispatch/aggregation/failure/zero-findings mechanics and
+the report section format above. It does not own: when a calling skill
+decides to dispatch at all, or what a calling skill's report step must
+distinguish these sections from (each `SKILL.md`'s own Step 5b/4b states its
+skip conditions; each report step names the other callouts these sections
+must stay distinct from — `gherkin-derive`'s characterization/possibly-stale
+callouts, `gherkin-public`'s hand-authoring-flagged-components callout).