qa

Plugin qa from marketplace truecast in wastedcode/truecast. Commands read from the repo's manifest — 27 days ago.

Skills (17)

• accept-against-reality

  Use at the acceptance gate — verify the build by doing the user's flow yourself end-to-end and confirming persisted state, not by checking that "the parts exist per spec" or that a green suite ran.

• attack-like-a-real-user

  Use during the runtime adversarial pass — attack the build the way real users (and bad actors) actually behave: malformed input, concurrency, network failure, refresh/back, permissions you shouldn't have, and the second time, not just the first.

• audit-the-journeys

  Use before you run anything — statically walk every user journey end-to-end (happy path plus the error, empty, returning-user, and cancel states) by reading flow + spec + code, to find where it's incomplete or breaks. A missing journey is a defect.

• beat-the-frontier

  Use before any test plan or ship verdict and as the last pass before handing it over — your version of the engine's "beat the frontier" loop. Name who tests this kind of system best today, set the bar above them, pre-empt every ask a demanding reviewer would make (proof in prod, real rows vs an exte

• design-the-test-strategy

  Use when scoping what to test on a non-trivial build — model coverage across the product's real dimensions (Structure, Function, Data, Integrations, Platform, Operations, Time) so you test what the author's unit tests skipped, not 20 variants of one thing.

• explore-with-charters

  Use when investigating a build or a suspicious area where a fixed script won't find the unknown — run time-boxed exploratory sessions guided by a charter (a mission), learning, designing, and executing tests at once, and following the smell.

• guard-against-regression

  Use when protecting working behavior across changes — keep a fast, risk-prioritized regression gate on the highest-value journeys, and quarantine-and-own a flaky test instead of retrying past it.

• investigate-the-real-trace

  Use the moment observed ≠ expected and especially when a result seems impossible (a deleted thing still appears, a fix has no effect, state lingers after teardown) — distrust your own environment first. Are you hitting the live build? a stale cache or old artifact? a zombie/leftover process? did tea

• model-the-state-machine

  Use before attacking a build that has any lifecycle, phases, or persisted progress — enumerate the states, transitions, and guards, then probe every transition under crash / kill / resume / double-send (the transition × interrupt matrix) to find where an interrupted transition corrupts or strands st

• reconstruct-the-oracle

  Use before you test anything — build your own model of "correct" from the brief, spec, and user journeys so you have a basis to call something a bug, and state which expectation each finding violates.

• render-the-ship-verdict

  Use to close the audit — render an honest ship / don't-ship verdict with the blocker list, what you tested and didn't, the residual risk, and the routing of every finding to the right owner.

• reproduce-and-grade

  Use the moment you think you've found a bug — reproduce it yourself with exact steps (never theorize from reading code), make an intermittent failure deterministic, and grade its severity honestly (P0 data loss/auth … P3 cosmetic).

• shift-left-on-the-story

  Use BEFORE code is written — when a story, spec, or design is being shaped — to prevent the bug instead of catching it later: question the story, surface the missing examples and edge cases, demand testable acceptance criteria, and require the build to be observable/testable by design.

• target-the-risk

  Use to decide where to spend a finite testing budget — prioritize by risk (likelihood × impact), hammering data loss, auth, the core flow, and money first, and right-size the audit to this build's blast radius.

• test-the-non-deterministic

  Use when a verdict rests on a measured quantity rather than a single deterministic assertion — a noisy/probabilistic output, a performance number, an accuracy or conversion rate. "It ran" or one lucky sample is not a verdict; bring experimental rigor (labelled reference set, a baseline/control, save

• verify-non-functional

  Use when the build implies quality beyond "it works" — sweep the non-functional surface: performance under load, accessibility, the obvious security holes, and reliability/recovery. Find the obvious failures; escalate the deep ones.

• write-the-bug-to-get-it-fixed

  Use when filing a finding — write the bug report as a persuasive document that gets it fixed (Kaner's bug advocacy): exact repro, expected vs actual, severity, and the expectation it violates — not a vague "it's broken.

Subagents (1)

• qa

  An independent adversarial check who assumes it's broken and finds it before a user does — shifts left to question the story and demand testability before code exists, reconstructs the oracle, models the lifecycle as a state machine and probes its transitions under crash/kill/resume/double-send, tar