메뉴
Generate contract test cases from feature requirements (RFs/RNs) and technical contracts. Use when add.plan needs to produce plan-test-spec.md mapping each requirement to testable cases before implementation.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Consolidated view of the add-pro ecosystem - commands, skills, relationships and dependencies. Loaded by /add as source of truth.
Source of truth for ADD doc rules, depth floors, IDs, refs, validation gate. Load before any doc write.
Use when running agent-judged QA validation (read-PNG by default; the playwright plugin adds live driving) — the Level C judge rubric, severity taxonomy, dual-judge (@ux-agent review ∥ @qa-agent) method, report schema/template, and the config.json/screens.json formats. Consumed by /add.qa and both judges.
Use when a state-materializing command starts or is asked to upgrade — reads the setup receipt, compares the recorded contract against the shipped one, executes the declared upgrade deltas sequentially, and rewrites the receipt even on a verified-current no-op. Consumed by /add.qa-setup STEP 1.5 and STEP 11.
Internal skill for developing ADD framework artefacts (commands, skills, agents, scripts). Use when add-framework--plan analyzes viability of new framework features, when add-framework--build implements framework artefacts, or when creating/modifying commands, skills, or agents. Always use this skill before proposing or implementing changes to the framework itself.
Use when building, styling, or theming UI components, pages, layouts, dashboards, charts, tables, or forms for SaaS products.
SOC 직업 분류 기준
| name | add-test-specification |
| description | Generate contract test cases from feature requirements (RFs/RNs) and technical contracts. Use when add.plan needs to produce plan-test-spec.md mapping each requirement to testable cases before implementation. |
LANG: Respond in user's native language. Tech terms in English.
Derive contract test cases (input → expected output) from about.md requirements (RFs/RNs) plus technical contracts in plan-*.md. Tests validate the contract, never internal implementation.
[area]-[RF/RN]-[scenario].Write to docs/features/${FEATURE_ID}/plan-test-spec.md:
| ID | Test Case | Area | RF/RN | Input | Expected Output | Verify |
|---|---|---|---|---|---|---|
| T01 | [max 10 words] | [backend/frontend/database] | [RF/RN ID] | [request/action] | [response/result] | [assertion] |
| Area | Test File | Test IDs |
|---|---|---|
| [area] | [path] | [T01, T02...] |
| RF/RN | Test Cases | Covered? |
|---|---|---|
| [RF01] | [T01, T03] | ✅ |
These specs become the RED phase in add-tdd: each row is one failing test to write first. The implementer writes the test from the contract, confirms it fails for the right reason, then implements minimal GREEN code.