Menu
Prompt template that builds a local demo test stand and QA-tests a converged project to production quality.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when dispatching one or more reviewer agents for an adversarial second opinion on any artifact — code, a design, a document, a plan, a research report, a deck. Especially when a prior review felt like a rubber-stamp or parroted the prompt's framing, when findings were vague with no locations, when tempted to tell the reviewer what to expect or where to look, or when reviewing something assembled from multiple sources (a merge, a consolidation). Any domain.
A prompt template that turns module boundaries into executable architecture — linter, import-graph, and filesystem checks enforced in CI.
Use when iterating on any artifact — code, design, document, process, analysis — through repeated review-and-fix passes toward a hardened state, or when running long unsupervised improvement that continues until a human stop signal. Also when "a few more passes" gets hand-waved, when something is called done after one clean review, or when rounds only add and never cut. Triggers: "iterate until it converges", "harden this", "run a review loop", "keep polishing until I say stop". Any domain.
Use when the user wants to build, deliver, or orchestrate an MVP, prototype, demo, or v1 of ANY project (software or not), wants multi-agent fan-out over a task board, mentions "delivering-mvp-fleet" or "deliver an MVP" or "orchestrate this build", or drops a vague product idea and asks to make it real. Do NOT use for single small features or bugfixes inside an existing plan.
Use when designing a feature, system, refactor, process, protocol, or decision before implementing it; when expanding a vague spec, RFC, or ticket into an implementable design; when writing or reorganizing design docs; when the user mentions "7w3", the seven Ws, "wishes / functions / decision flows", or wants a design "like BDD or user-story-driven development but fuller"; or when the user says "design X" or "write this up properly" — prefer this over ad-hoc design notes or a phase/Gantt plan.
An ordered, gated pipeline — a router of Yes/No gates over the eleven Disruptor skills that carry a project from idea to running server.
| name | qa-demo-stand |
| description | Prompt template that builds a local demo test stand and QA-tests a converged project to production quality. |
| disable-model-invocation | true |
FIX_MODE), tested to
production quality; a running defect/timeline record.setup-server skill.[PLACEHOLDERS] and hand the whole
thing to a fresh executor agent; don't paraphrase it. This is also the entry point for the
bug on-ramp (a defect report enters the flow here).You are a senior QA/Security engineer. Build a local test stand (a "demo stand") for the project [PROJECT_DIR] and test it to production quality: find, reproduce, and record defects, with a focus on infrastructure stability, data isolation, and resilience to failures. Work autonomously and thoroughly; don't spare time or tokens.
demostand/ folder, excluded from git via .git/info/exclude
(don't touch the shared .gitignore; verify with git check-ignore demostand/). Commit nothing
from the stand.demostand/spec/ (scenarios, flows,
edge cases, security, infra). Scripts and browser agents merely EXECUTE what is described.docker compose up -d); health endpoints; container statuses; backend logs.agent-browser/Playwright), DB and container access, how to run tests.Build a structured map of the application (may be parallelized across explorer agents by domain). For each domain: capabilities, user actions, settings, API routes + error codes, edge cases (including rare "once in 10 years" races), failure modes (self-heal / needs restart / broken-state), security concerns, existing test coverage (treated as unverified). Domains (adapt to the project):
demostand/spec/00-system-map.json.Write documents (markdown), each item with a stable ID, real file paths, risk, probability, and a verification method (a browser step or an API call + expected error code):
01-test-data — test accounts/organizations/data, credentials, profiles.02-feature-surface — the full surface: capabilities/settings/routes.03-user-flow-matrix — end-to-end user flows and their INTERSECTIONS (chaotic orderings,
parallel actions, context/tab switching, attachments, editing/opening entities).04-edge-cases — a consolidated ranked catalog (races, time/timezone boundaries,
malformed/huge/empty inputs).05-security — tenant isolation/IDOR, authz, tokens/TTL, XSS/injections, path traversal,
secret leakage, rate limit/lockout. [If there is an agent — a separate adversarial catalog
of boundaries.]06-infra-resilience — environment map + a "self-recovery vs wedging" matrix + a chaos
injection plan (kill/restart containers, network cut/slowdown, corrupted/missing configs,
cold start) with exact commands and expected post-conditions.08-candidate-findings — RANKED reproducible defect hypotheses (severity × confidence)
with exact repro steps: the bridge to the run.Your own idempotent script that creates DISPOSABLE marked (demostand-*)
accounts/orgs/data through the application's REAL mechanism (registration/bootstrap/admin
API or its data layer), with a guard (local only, explicit confirmation flag). Credentials
manifest — in demostand/reports/ (local). A separate cleanup script. Verify that the new
entities are actually usable (required modules/access enabled).
Categories (adapt):
If [FIX_MODE] = fix: via TDD (RED→fix→GREEN→run adjacent tests→typecheck/lint), log to the
timeline; for significant changes — an external code review at the end; a mandatory self-review
always.
If = accumulate: fix nothing, file into the registry; at the end write REMEDIATION.md — for
each finding: where, cause, the concrete fix (files/code/SQL/config, layer), a TDD plan,
regression risks, contentious decisions for discussion, how to re-verify via the stand, effort
estimate.
demostand/TIMELINE.md — chronology: time · operation · findings · fixes.demostand/reports/FINDINGS.md — a ranked registry of findings with repro and statuses.demostand/reports/SUMMARY.md — executive summary: verdict by area + findings table.demostand/{spec,scripts,reports,artifacts,logs}/.Restore the environment to a working/healthy state (check health and containers). Close browser sessions, delete temporary artifacts. Deliver a final report: what was covered, verdict by priority (infra stability / data isolation / [agent boundaries, if present]), the list of findings, what was fixed, what remains.
Source: Pukh (@aostrikov_agents_chat), Demo stand testing. Translated from Russian.