메뉴
Produce 3 thin comparable variants of a proposed design with a comparison artifact and mandatory Human Validation Plan
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when executing implementation plans with 3+ independent, file-disjoint tasks that benefit from parallel specialist agents with shared contracts and reviewer-gated completion
Use when verifying an implementation still matches its spec or plan — during REVIEW or SHIP, or on demand to check drift, confirm you are still on plan, or run a spec check — surfacing spec deviations, unvalidated assumptions, and untested code paths against Intent Truth
Use when mining the repo for improvement proposals in the LEARN phase — manually sweeping eval baselines, gate-status output, memory feedback, and parked revival criteria into a ranked, evidence-graded proposal report with in-session approve/reject and a GitHub-issue queue
Use when you need to run the repo's own declared test/lint/type gate locally and emit pass/fail evidence — during REVIEW, before requesting code review, or on a request to run the tests or verify the build — discovering the gate from CLAUDE.md, Makefile, pyproject, or .verify.yml
Use when you need to prove a change actually works through its real interfaces — during REVIEW or on requests like validate the feature, does it work, run e2e, or smoke test — covering browser E2E, API smoke, CLI checks, and a11y, perf (Lighthouse), and visual-regression audits with graceful tool-degradation
Use when starting a new feature or initiative and you need problem context, prior art, and acceptance criteria before design — the DISCOVER phase entry point — pulling Jira/Confluence context and synthesizing a discovery brief to validate problem framing
| name | prototype-lab |
| description | Produce 3 thin comparable variants of a proposed design with a comparison artifact and mandatory Human Validation Plan |
Build exactly 3 thin, comparable variants of a proposed design so the user can evaluate concrete alternatives before committing to a direction.
During DESIGN phase when competing approaches are identified. Fires on trigger match alongside brainstorming (which remains the process driver). The user or DESIGN phase guidance may suggest prototyping; this skill does not depend on brainstorming internally escalating to it.
Relationship to design-debate:
Determine what "a variant" means for this project:
| Project type | Variant contents |
|---|---|
| New skill | SKILL.md draft + routing entry + one behavioral test |
| New hook | Script draft + config entry + one syntax test |
| New feature | Implementation sketch + one test |
| Architecture decision | Thin proof-of-concept code + one integration test |
Default: 3 variants. User can override ("just compare these 2").
For each variant (A, B, C):
Save to docs/plans/YYYY-MM-DD-<topic>-prototype-lab.md:
# Prototype Comparison: <Topic>
**Date:** YYYY-MM-DD
**Variants:** 3
## Variant A: <Name>
**Approach:** <1-2 sentences>
**Trade-offs:** <pros and cons>
**Artifact:** <path or inline>
## Variant B: <Name>
**Approach:** <1-2 sentences>
**Trade-offs:** <pros and cons>
**Artifact:** <path or inline>
## Variant C: <Name>
**Approach:** <1-2 sentences>
**Trade-offs:** <pros and cons>
**Artifact:** <path or inline>
## Recommendation
**Chosen:** Variant <X>
**Reasoning:** <why this over the others>
## Human Validation Plan
<REQUIRED — how the user will test the chosen option with real usage>
<AI-simulated testing may inform the draft but never replaces this section>
<Describe: who tests, what they test, what success looks like>
## Success Signals
<What to measure after shipping to confirm the choice was right>
Show the comparison artifact. Ask the user to choose a variant. Only the chosen variant proceeds to writing-plans. The others are archived in the comparison artifact.