메뉴
Use in a Wakeflow Test window to design a risk-based validation plan for a controller test card, real-project scenario, release check, runtime observation, or cross-repository integration question.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use in a Wakeflow Design window to turn a clarified and confirmed requirement into a controller-intake-ready requirement design with user stories, decisions, tests, non-goals, and acceptance criteria.
Use in a Wakeflow Design window to prepare a compact handoff for controller intake from clarified requirements, option plans, requirement designs, and Design signals.
Use in a Wakeflow Design window when a clarified requirement needs multiple implementation, architecture, sequencing, or rollout options before controller or user confirmation.
Use in a Wakeflow Design window when a user idea, controller request, handoff candidate, or product change needs clarification before it can become an original plan, requirement design, TODO candidate, or controller decision.
Use in a Wakeflow Design window to break a confirmed requirement design into vertical-slice TODO or task-package candidates for controller intake.
Use when Test needs to run or monitor reusable Alembic test routes: environment readiness, BiliDili/AlembicWorkspace cold-start, resident service, multi-root ProjectScope, or explicitly assigned Codex Plugin / host MCP evidence. Follow verified routes and collect evidence instead of inventing new paths.
| name | test-strategy |
| description | Use in a Wakeflow Test window to design a risk-based validation plan for a controller test card, real-project scenario, release check, runtime observation, or cross-repository integration question. |
Design the smallest real validation plan that answers the controller's question with credible evidence. This skill belongs to Test windows. It plans and collects evidence; it does not accept product work or dispatch follow-up implementation.
senior-qa: risky user journeys, test layer choice, must-pass automated
tests, focused manual checklist, and flakiness as a product bug.code-reviewer: evidence should cover correctness, safety, maintainability,
performance, and tests when relevant.Use this skill only when Test is justified by one of these:
Do not use Test to rediscover defects already known to the controller or to run general QA without a boundary.
If those inputs are missing, stop and report missing test boundary evidence.
## Test Strategy
- Question:
- Target:
- Why Test is needed:
- Risk focus:
- Test layer:
- Commands or observations:
- Expected success signal:
- Failure signal:
- Invalid conclusions:
- Stop conditions:
- Evidence paths:
Treat flakiness as evidence degradation, not as "mostly passing". If a result is flaky:
A good strategy names the exact question, risk, chosen layer, evidence, success meaning, failure meaning, invalid conclusion, and stop condition. It fails if it just says "run tests" or expands beyond the controller's test boundary.
Before committing to a test approach, ask: is this chosen because it fits THIS demand's risk, or because it is what was done last time? Path-dependent reuse is the common way a wrong test approach slips in. The approach should come from the Design-stage testing decision (recorded as the test card's strategySource); if it is improvised, say so and justify it against the risk. Prefer the lowest test level that proves the behavior; escalate to real-scenario only when user-visible or environment evidence is required.