Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

demo-day

Étoiles4

Forks0

Mis à jour15 juillet 2026 à 21:24

Hands-on QA in a real browser: the QA Tester clicks through the running app, verifies every acceptance criterion from the spec, explores beyond the happy path and files reproducible bugs. Use after /peer-review passes, or to re-test after fixes. Requires a running app and browser tooling.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

a-lottes

a-lottes/aSPARK

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name	demo-day
description	Hands-on QA in a real browser: the QA Tester clicks through the running app, verifies every acceptance criterion from the spec, explores beyond the happy path and files reproducible bugs. Use after /peer-review passes, or to re-test after fixes. Requires a running app and browser tooling.

/demo-day — Review (QA Tester)

You are running the QA ceremony. The product gets used, not read: every acceptance criterion is clicked through in a real browser.

Input

Argument: the app URL (and optionally the feature name). No URL → ask the user for it, and how to start the app if it isn't running.

Steps

Check the gates and the gear.
- .spark/<feature-name>/review.md must be passed. If not, stop and point to /peer-review. (The user may explicitly override this order — record that in the QA report.)
- Confirm browser tooling is available (Claude in Chrome, Playwright MCP, Chrome DevTools MCP — whatever the session offers) and the app responds at the given URL. If either is missing, STOP and tell the user exactly what to set up or start. Never substitute code reading for testing.
Delegate to the QA Tester. Invoke the qa-tester agent with the app URL, the feature paths, the agreed viewports, any credentials/test data the user provided, the report template from ${CLAUDE_PLUGIN_ROOT}/templates/qa-report.md, and the paths of any active lenses with browser-observable checks (from the constitution's profile — ${CLAUDE_PLUGIN_ROOT}/lenses/ — ux.md, seo.md, security.md, i18n.md).
Relay needs. If the agent reports missing prerequisites (login, seeded data, a second account), get them from the user and re-invoke.
Present the report. The AC verification table (every criterion: pass/fail), exploratory bugs with reproduction steps, console/network findings, and the demo-day verdict — quoted honestly.
Route the outcome with the user:
- failed ACs or open Blockers/Majors → /increment (fix-mode), then /demo-day again. Re-tests cover the fixed bugs and their surrounding flows.
- Minor bugs → the user accepts them (recorded) or sends them to fix.
Close the gate. When the QA GATE checklist is genuinely satisfied, set the report status to passed.

Rules

A QA report without performed browser steps is invalid — reject it and fix the tooling problem instead.
Never mark passed while a Must-story AC is unverified.

Handoff

QA passed → /go-live (release it)
Bugs to fix → /increment

Plus depuis ce dépôt

même dépôt

next-steps

a-lottes/aSPARK

Have the Product Owner survey the project's current state — shipped features, in-flight work, open findings, standing goals — and propose one concrete next feature ready to hand to /story-time or /spark. Use when the user has no idea in hand and asks "what should we build next", when a loop just closed and the next cycle needs a starting point, or when the backlog feels stale and needs a grounded suggestion instead of a guess.

2026-07-174

spark

a-lottes/aSPARK

Run the full SPARK loop end-to-end for one feature: Specify → Plan → Act → Review → Keep, pausing at every gate for the user's decision. Use when the user brings a feature idea and wants the whole agile team to take it from idea to release in one guided session — or wants to resume a feature that is somewhere mid-loop.

2026-07-174

charter

a-lottes/aSPARK

Establish or amend the project constitution — the standing principles and constraints that bind every SPARK phase. Use once at project start to give the team its ground rules, or any time a project-wide decision (stack choice, quality bar, non-negotiable) changes and should apply to all future features.

2026-07-154

look-and-feel

a-lottes/aSPARK

Run the Designer over a spec (design risks, usability heuristics, accessibility) or over an implemented UI (screenshots, running app). Use after /story-time for UI-facing features, or any time the user wants a design critique of a spec, mockup, page or component.

2026-07-154

peer-review

a-lottes/aSPARK

Start the Review phase of the SPARK loop: the Reviewer audits the diff produced by /increment — plan conformance, correctness, edge cases, security, test quality — and writes the review report. Use after /increment reports done, or to re-review after fixes.

2026-07-154

story-time

a-lottes/aSPARK

Start the Specify phase of the SPARK loop: the Product Owner interrogates a product idea and turns it into a spec with user stories and testable acceptance criteria. Use when the user brings a new feature idea, product idea or change request that has no spec yet — or wants an existing spec challenged and reworked.

2026-07-154

name	demo-day
description	Hands-on QA in a real browser: the QA Tester clicks through the running app, verifies every acceptance criterion from the spec, explores beyond the happy path and files reproducible bugs. Use after /peer-review passes, or to re-test after fixes. Requires a running app and browser tooling.

/demo-day — Review (QA Tester)

You are running the QA ceremony. The product gets used, not read: every acceptance criterion is clicked through in a real browser.

Input

Argument: the app URL (and optionally the feature name). No URL → ask the user for it, and how to start the app if it isn't running.

Steps

Check the gates and the gear.
- .spark/<feature-name>/review.md must be passed. If not, stop and point to /peer-review. (The user may explicitly override this order — record that in the QA report.)
- Confirm browser tooling is available (Claude in Chrome, Playwright MCP, Chrome DevTools MCP — whatever the session offers) and the app responds at the given URL. If either is missing, STOP and tell the user exactly what to set up or start. Never substitute code reading for testing.
Delegate to the QA Tester. Invoke the qa-tester agent with the app URL, the feature paths, the agreed viewports, any credentials/test data the user provided, the report template from ${CLAUDE_PLUGIN_ROOT}/templates/qa-report.md, and the paths of any active lenses with browser-observable checks (from the constitution's profile — ${CLAUDE_PLUGIN_ROOT}/lenses/ — ux.md, seo.md, security.md, i18n.md).
Relay needs. If the agent reports missing prerequisites (login, seeded data, a second account), get them from the user and re-invoke.
Present the report. The AC verification table (every criterion: pass/fail), exploratory bugs with reproduction steps, console/network findings, and the demo-day verdict — quoted honestly.
Route the outcome with the user:
- failed ACs or open Blockers/Majors → /increment (fix-mode), then /demo-day again. Re-tests cover the fixed bugs and their surrounding flows.
- Minor bugs → the user accepts them (recorded) or sends them to fix.
Close the gate. When the QA GATE checklist is genuinely satisfied, set the report status to passed.

Rules

A QA report without performed browser steps is invalid — reject it and fix the tooling problem instead.
Never mark passed while a Must-story AC is unverified.

Handoff

QA passed → /go-live (release it)
Bugs to fix → /increment