원클릭으로 Manus에서 모든 스킬 실행

demo-day

스타4

포크0

업데이트2026년 7월 15일 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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

a-lottes

a-lottes/aSPARK

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

/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

이 저장소의 다른 Skills

같은 저장소

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