[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M754AWSR8HB8RP7FY0B4F8WN":3,"skill-same:01M754AWSR8HB8RP7FY0B4F8WN":57},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":35,"ownerDescription":36,"updatedAt":37,"install":38,"resources":50},"01M754AWSR8HB8RP7FY0B4F8WN","x-plan-tests",null,"Generates a Double-Loop TDD test plan with TPP-ordered scenarios before implementation. Delegates KP reading to a context-gathering subagent, then produces structured Acceptance Tests (outer loop) and Unit Tests in Transformation Priority Premise order (inner loop).","review-bench\u002Federcnj_ia-dev-environment","review-bench","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F286778065?v=4","01M7517F9NTEPDZDAXJBR30FWT","ReviewBench","01M7517FAC9F4P7TGWCNJ8VYVW",0,"MIT","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-event-driven\u002F.claude\u002Fskills\u002Fx-plan-tests\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: x-plan-tests\ndescription: \"Generates a Double-Loop TDD test plan with TPP-ordered scenarios before implementation. Delegates KP reading to a context-gathering subagent, then produces structured Acceptance Tests (outer loop) and Unit Tests in Transformation Priority Premise order (inner loop).\"\nuser-invocable: true\nallowed-tools: Read, Grep, Glob\nargument-hint: \"[STORY-ID]\"\ncontext-budget: medium\nrequires-capabilities: []\n---\n\n## Global Output Policy\n\n- **Language**: English ONLY.\n- **Tone**: Technical, Direct, and Concise.\n- **Efficiency**: Remove all conversational fillers and greetings to save tokens.\n\n# Skill: Plan Tests\n\n## Purpose\n\nProduces a Double-Loop TDD test plan that drives implementation order. With 95% line \u002F 90% branch coverage enforced, the plan serves as the implementation roadmap — each test scenario maps to one Red-Green-Refactor cycle, ordered by Transformation Priority Premise (TPP).\n\n## Triggers\n\n- `\u002Fx-plan-tests STORY-ID` — generate test plan for a specific story\n\n## Parameters\n\n| Parameter | Required | Description |\n|-----------|----------|-------------|\n| `STORY-ID` | Yes | Story identifier to plan tests for. If not provided, prompt for it. |\n\n## Workflow\n\n```\n0. PRE-CHECK       -> Verify existing plan freshness (mtime comparison)\n1. GATHER CONTEXT  -> Subagent (model: opus) reads testing + architecture KPs, story, template, existing code\n2. PLAN TESTS      -> Generate Double-Loop + TPP-ordered scenarios (inline)\n3. ESTIMATE        -> Estimate coverage and validate completeness (inline)\n```\n\n### Step 0 — Pre-Check: Idempotency (RULE-002 — Idempotency via Staleness Check)\n\nBefore generating a test plan, verify whether a valid plan already exists:\n\n1. **Resolve paths:** Extract epic ID (XXXX) and story sequence (YYYY) from the story ID. Compute:\n   - Story path: the story file provided as input\n   - Plan path: `ai\u002Fepics\u002Fepic-XXXX\u002Fplans\u002Ftests-story-XXXX-YYYY.md`\n\n2. **Check existence:** If the plan file does NOT exist, proceed to generation (Step 1).\n\n3. **Compare modification times:** If the plan file exists:\n   - If `mtime(story file) \u003C= mtime(plan file)` — the plan is **fresh**. Log: `\"Reusing existing test plan from {date}\"` (where `{date}` is the plan file's last modified date). Return the existing plan. **Do NOT invoke any subagent.**\n   - If `mtime(story file) > mtime(plan file)` — the plan is **stale**. Log: `\"Regenerating stale test plan for {story-id}\"`. Proceed to generation (Step 1).\n\n4. **First generation:** If the plan file does not exist at all, log: `\"Generating test plan for {story-id}\"`. Proceed to generation (Step 1).\n\n### Step 1 — Gather Context (Subagent via Task, model: opus)\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-plan-tests Phase-1-KP-Read`\n\nLaunch a **single** `general-purpose` subagent with explicit `model: \"opus\"` (Rule 23 RULE-002 — deep test planning quality for Double-Loop TDD + TPP):\n\n    Agent(\n      subagent_type: \"general-purpose\",\n      model: \"opus\",\n      description: \"Test Planning Assistant gathers context for test plan generation\",\n      prompt: \"\u003Csee the blockquote below>\"\n    )\n\n> You are a **Test Planning Assistant** gathering context for test plan generation.\n>\n> **Read the template for required output format (RULE-007):**\n> - Read template at `.claude\u002Ftemplates\u002F_TEMPLATE-TEST-PLAN.md` for required output format.\n> - If the template file does NOT exist, log: `\"Template not found, using inline format\"` and continue without it (RULE-012 — graceful fallback for projects without templates).\n>\n> **Read these knowledge packs:**\n> - `knowledge\u002Ftesting\u002Ftesting-philosophy.md` — 8 test categories, fixture patterns, data uniqueness, async handling, real vs in-memory DB decisions\n> - `knowledge\u002Ftesting\u002Ftesting-conventions.md` — {{LANGUAGE}}-specific test frameworks, naming conventions, directory structure, assertion libraries\n> - `knowledge\u002Farchitecture\u002Farchitecture-principles.md` — exception hierarchy, layer boundaries (unit vs integration), dependency direction\n>\n> **Read testing knowledge pack for {{LANGUAGE}}-specific patterns:**\n> - Read `knowledge\u002Ftesting.md` for {{LANGUAGE}}-specific test frameworks, conventions, and patterns\n>\n> **Read the story:** `{STORY_PATH}`\n> Extract: acceptance criteria, sub-tasks, business rules, dependencies.\n>\n> **Scan existing code:**\n> - List existing classes in target packages\n> - List existing test classes and patterns established\n>\n> **Return a structured context summary:**\n> 1. **Test categories applicable** to this story (from the 8 categories in testing-philosophy)\n> 2. **Naming convention:** `[method]_[scenario]_[expected]` pattern with {{LANGUAGE}}-specific format\n> 3. **Test frameworks and assertion libraries** to use (from testing-conventions)\n> 4. **Fixture pattern:** `final class` + `private constructor` + `static methods`, naming `a{Entity}()`\n> 5. **Acceptance criteria** extracted from story (each becomes ≥1 test)\n> 6. **Business rules** extracted (each maps to parametrized tests)\n> 7. **Exception types** in scope (each needs error path test)\n> 8. **Layer boundaries** — which classes need unit vs integration tests\n> 9. **Existing patterns** found in current test codebase\n> 10. **Contract tests applicable** (if testing.contract_tests == true)\n> 11. **Chaos tests applicable** (if testing.chaos_tests == true)\n> 12. **Template sections** — if template was found, list the 8 mandatory sections to populate\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-plan-tests Phase-1-KP-Read ok`\n\n### Step 2 — Generate Test Scenarios (Inline)\n\nUsing the context returned by the subagent, generate a Double-Loop TDD test plan.\nOrganize scenarios by implementation order (TPP), NOT by test category.\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-plan-tests Phase-2-Acceptance-Tests`\n\n#### 2.1 — Acceptance Tests (Outer Loop)\n\nFor each Gherkin scenario in the story, generate an acceptance test entry:\n\n| Field | Description |\n|-------|-------------|\n| ID | `AT-N` (sequential) |\n| Gherkin | Reference to the original scenario |\n| Status | RED until all unit tests for this acceptance criteria complete |\n| Components | List of classes\u002Fmodules under test |\n| Test Type | Integration, API, or E2E (depending on story scope) |\n| Depends on | UT\u002FIT IDs that must pass for this AT to go GREEN, or `--` |\n| Parallel | `yes` if independent of other ATs |\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-plan-tests Phase-2-Acceptance-Tests ok`\n\n#### 2.2 — Unit Tests (Inner Loop, TPP Order)\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-plan-tests Phase-3-Unit-Tests-TPP`\n\nGenerate unit test scenarios in strict TPP order. Each scenario represents one\nRed-Green-Refactor cycle.\n\n##### TPP Level 1 — Degenerate Cases\n- Null, empty, zero inputs — return default\u002Ferror\n- Transform: `{}→nil` or `nil→constant`\n\n##### TPP Level 2 — Unconditional Paths\n- Single valid input — direct output (no branching)\n- Transform: `constant→variable`\n\n##### TPP Level 3 — Simple Conditions\n- Single if\u002Felse branching\n- Transform: `unconditional→conditional`\n\n##### TPP Level 4 — Complex Conditions\n- Multiple branches, switch\u002Fmatch, compound boolean\n- Transform: deeper conditional logic\n\n##### TPP Level 5 — Iterations\n- Collection processing, loops, map\u002Ffilter\u002Freduce\n- Transform: `scalar→collection`, `statement→recursion\u002Fiteration`\n\n##### TPP Level 6 — Edge Cases\n- Boundary values (at-min, at-max, past-max)\n- Transform: `value→mutated value`\n\nFor each unit test entry, include:\n\n| Field | Required | Description |\n|-------|----------|-------------|\n| ID | M | `UT-N` (sequential within TPP order) |\n| Test | M | What to test (method + scenario + expected) |\n| Implementation | O | Minimum code to pass this test |\n| Transform | M | TPP transformation applied |\n| TPP Level | M | 1-6 |\n| Components | M | Classes\u002Fmodules needed |\n| Depends on | M | Previous test IDs that are prerequisites, or `--` |\n| Parallel | M | `yes` if independent of other tests at same level |\n\n#### 2.3 — Integration Tests (Cross-Component)\n\nPosition AFTER the unit tests of the components involved.\nInclude only when multiple components interact (DB, HTTP, messaging).\n\n| Field | Required | Description |\n|-------|----------|-------------|\n| ID | M | `IT-N` (sequential) |\n| Test | M | What to test |\n| Components | M | Interacting components |\n| Depends on | M | UT IDs that must pass first |\n| Parallel | M | `yes`\u002F`no` |\n\n#### 2.4 — CRUD-Only Story Optimization\n\nWhen a story describes a purely CRUD operation without branching logic:\n- UTs should cover: degenerate (Level 1) — constant (Level 1) — variable (Level 2)\n- Do NOT generate conditional or iteration UTs unless the business rules demand them\n- Acceptance tests should focus on the full CRUD flow\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-plan-tests Phase-3-Unit-Tests-TPP ok`\n\n### Step 3 — Estimate and Validate (Inline)\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-plan-tests Phase-4-Report`\n\n#### 3.1 — Coverage Estimation Table\n\n| Class | Public Methods | Branches | Est. Tests | Line % | Branch % |\n|-------|---------------|----------|-----------|--------|----------|\n| [Name] | [count] | [count] | [count] | [%] | [%] |\n\nFlag any class where estimated coverage \u003C 95% line \u002F 90% branch.\n\n#### 3.2 — Quality Checks\n\n1. Every Gherkin scenario maps to ≥1 acceptance test (AT)\n2. Every acceptance criterion maps to ≥1 unit test chain (UT)\n3. UT-1 is ALWAYS a degenerate case (TPP Level 1)\n4. UTs follow non-decreasing TPP level order\n5. Every exception has ≥1 error path test\n6. Boundary values use triplet pattern (at-min, at-max, past-max)\n7. Dependency markers are complete (no orphan UTs)\n8. Estimated coverage meets thresholds (≥ 95% line, ≥ 90% branch)\n9. Test naming follows convention: `[method]_[scenario]_[expected]`\n10. No unnecessary UTs for CRUD-only stories (max Level 3 unless justified)\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-plan-tests Phase-4-Report ok`\n\n### Output\n\nSave to: `ai\u002Fepics\u002Fepic-XXXX\u002Fplans\u002Ftests-story-XXXX-YYYY.md` (extract epic ID XXXX and story sequence YYYY from the story ID). Ensure directory exists: `mkdir -p ai\u002Fepics\u002Fepic-XXXX\u002Fplans`.\n\n#### Origin Marker (EPIC-0059 — mandatory)\n\nBefore writing the test plan file, prepend the YAML frontmatter block at the very top:\n\n```yaml\n---\ngenerated-by: x-plan-tests@$(git rev-parse HEAD 2>\u002Fdev\u002Fnull || echo \"unknown\")\ngenerated-at: $(date -u +%Y-%m-%dT%H:%M:%SZ)\nstory-id: ${STORY_ID}\n---\n```\n\nThis frontmatter is required by `audit-execution-integrity.sh` Phase-1 validation (EPIC-0059, Rule 24).\nArtifacts without this block fail the CI audit with `EIE_EVIDENCE_MISSING`.\n\n```markdown\n# Test Plan — STORY-ID: [Title]\n\n## Summary\n- Acceptance tests: X (from Y Gherkin scenarios)\n- Unit tests: ~Z (in TPP order)\n- Integration tests: ~W\n- Estimated line coverage: ~P%\n- Estimated branch coverage: ~Q%\n\n## Acceptance Tests (Outer Loop)\n\n### AT-1: [Gherkin scenario name]\n- **Gherkin**: [reference to story scenario]\n- **Status**: RED until all unit tests complete\n- **Components**: [list of components under test]\n- **Acceptance Criteria**: [what must be true for this AT to pass]\n- **Depends on**: UT-1, UT-2, ... (UTs that must pass)\n- **Parallel**: yes\u002Fno\n\n## Unit Tests (Inner Loop — TPP Order)\n\n### UT-1: [degenerate case description] — TPP Level 1\n- **Test**: [methodUnderTest]_[scenario]_[expectedBehavior]\n- **Implementation**: [minimum code to pass]\n- **Transform**: {}→nil\n- **Components**: [class\u002Fmodule]\n- **Depends on**: --\n- **Parallel**: yes\n\n### UT-2: [next case description] — TPP Level 2\n- **Test**: [methodUnderTest]_[scenario]_[expectedBehavior]\n- **Implementation**: [minimum code to pass]\n- **Transform**: constant→variable\n- **Components**: [class\u002Fmodule]\n- **Depends on**: UT-1\n- **Parallel**: no\n\n...\n\n## Integration Tests (Cross-Component)\n\n### IT-1: [integration scenario]\n- **Test**: [description]\n- **Components**: [interacting components]\n- **Depends on**: UT-3, UT-7\n- **Parallel**: no\n\n## Coverage Estimation\n[table]\n\n## Risks and Gaps\n- [Hard-to-test scenarios]\n- [Coverage gaps needing attention]\n```\n\n## Anti-Patterns\n\n- Do NOT write test code — only plan scenarios\n- Do NOT organize test plan by category (Happy Path, Error Path, etc.) — use TPP ordering\n- Do NOT skip error paths\n- Do NOT forget boundary values (0, -1, max, empty, null)\n- Do NOT plan tests for trivial getters\u002Fsetters\n- Do NOT ignore existing test patterns\n- Do NOT create redundant tests covering the same branch\n\n## Error Handling\n\n| Scenario | Action |\n|----------|--------|\n| No story ID provided | Prompt user for story identifier |\n| Story file not found | Abort with file-not-found message |\n| Existing plan is fresh (RULE-002) | Return existing plan, skip generation |\n| Template not found (RULE-012) | Log warning, use inline format, continue |\n| No Gherkin scenarios in story | Generate tests from acceptance criteria text |\n| No acceptance criteria found | Abort with warning, request story refinement |\n\n## Template Fallback (RULE-012)\n\nWhen `.claude\u002Ftemplates\u002F_TEMPLATE-TEST-PLAN.md` is **not available** (projects predating EPIC-0024):\n\n1. Log warning: `\"Template not found, using inline format\"`\n2. Generate the test plan using the inline output format defined in the **Output** section above\n3. Execution continues normally — no interruption, no error\n4. The inline format produces the same 8 conceptual sections but without the template's strict structure\n\nThis ensures backward compatibility with projects that have not yet adopted template-based generation.\n\n## Knowledge Pack References\n\n| Pack | Files | Purpose |\n|------|-------|---------|\n| testing | `knowledge\u002Ftesting\u002Ftesting-philosophy.md` | 8 test categories, fixture patterns, data uniqueness |\n| testing | `knowledge\u002Ftesting\u002Ftesting-conventions.md` | {{LANGUAGE}}-specific test frameworks, naming, assertions |\n| testing | `knowledge\u002Ftesting.md` | {{LANGUAGE}}-specific test patterns |\n| architecture | `knowledge\u002Farchitecture\u002Farchitecture-principles.md` | Exception hierarchy, layer boundaries |\n\n## Integration Notes\n\n| Skill | Relationship | Context |\n|-------|-------------|---------|\n| `x-implement-story` | called-by | Invoked during Phase 1B |\n| `x-implement-task` | reads | Output consumed as TDD roadmap |\n\n- Pre-check (RULE-002) prevents redundant regeneration when story has not changed\n- Template reference (RULE-007) ensures consistent 8-section output format when available\n- Subagent uses explicit `model: \"opus\"` (Rule 23 RULE-002) for deep test planning quality\n- Output uses Double-Loop TDD format with TPP-ordered scenarios\n- Output consumed by Phase 2 (developers) and Phase 3 (QA engineer validates coverage)\n- Can be used standalone before any implementation task\n\n## Planning Status Propagation (Rule 22 \u002F EPIC-0046)\n\n> V2-gated: only runs when `SchemaVersionResolver.resolve(ai\u002Fepics\u002Fepic-XXXX\u002Fexecution-state.json) == V2`. v1 epics: skip silently (Rule 19).\n\nAfter writing `tests-story-XXXX-YYYY.md`, check the associated story's lifecycle status. The test plan, like the architecture plan, is a secondary writer — the primary transition `Pendente → Planejada` is owned by `x-plan-story`. When `x-plan-tests` runs standalone (without `x-plan-story`), it promotes the story from `Pendente` to `Planejada` so the source artifact reflects that the test plan is in place.\n\n**Steps (end of test-plan generation, BEFORE the final commit):**\n\n1. Detect v2 via SchemaVersionResolver. If v1: skip.\n2. Read current story status:\n   ```bash\n   CURRENT=$(java -cp $CLAUDE_PROJECT_DIR\u002Fjava\u002Ftarget\u002Fclasses \\\n       dev.iadev.adapter.inbound.cli.StatusFieldParserCli \\\n       read ai\u002Fepics\u002Fepic-XXXX\u002Fstory-XXXX-YYYY.md)\n   ```\n3. If `CURRENT == \"Pendente\"` → `write Planejada`. Idempotent when already `Planejada`.\n4. Stage and commit:\n   ```bash\n   git add ai\u002Fepics\u002Fepic-XXXX\u002Fstory-XXXX-YYYY.md ai\u002Fepics\u002Fepic-XXXX\u002Fplans\u002Ftests-story-XXXX-YYYY.md\n   ```\n\n       Skill(skill: \"x-commit-changes\", args: \"docs(story-XXXX-YYYY): add test plan + update status to Planejada\")\n\n**Fail-loud:** non-zero CLI exit aborts the skill (RULE-046-08).\n","## Global Output Policy\n\n- **Language**: English ONLY.\n- **Tone**: Technical, Direct, and Concise.\n- **Efficiency**: Remove all conversational fillers and greetings to save tokens.\n\n# Skill: Plan Tests\n\n## Purpose\n\nProduces a Double-Loop TDD test plan that drives implementation order. With 95% line \u002F 90% branch coverage enforced, the plan serves as the implementation roadmap — each test scenario maps to one Red-Green-Refactor cycle, ordered by Transformation Priority Premise (TPP).\n\n## Triggers\n\n- `\u002Fx-plan-tests STORY-ID` — generate test plan for a specific story\n\n## Parameters\n\n| Parameter | Required | Description |\n|-----------|----------|-------------|\n| `STORY-ID` | Yes | Story identifier to plan tests for. If not provided, prompt for it. |\n\n## Workflow\n\n```\n0. PRE-CHECK       -> Verify existing plan freshness (mtime comparison)\n1. GATHER CONTEXT  -> Subagent (model: opus) reads testing + architecture KPs, story, template, existing code\n2. PLAN TESTS      -> Generate Double-Loop + TPP-ordered scenarios (inline)\n3. ESTIMATE        -> Estimate coverage and validate completeness (inline)\n```\n\n### Step 0 — Pre-Check: Idempotency (RULE-002 — Idempotency via Staleness Check)\n\nBefore generating a test plan, verify whether a valid plan already exists:\n\n1. **Resolve paths:** Extract epic ID (XXXX) and story sequence (YYYY) from the story ID. Compute:\n   - Story path: the story file provided as input\n   - Plan path: `ai\u002Fepics\u002Fepic-XXXX\u002Fplans\u002Ftests-story-XXXX-YYYY.md`\n\n2. **Check existence:** If the plan file does NOT exist, proceed to generation (Step 1).\n\n3. **Compare modification times:** If the plan file exists:\n   - If `mtime(story file) \u003C= mtime(plan file)` — the plan is **fresh**. Log: `\"Reusing existing test plan from {date}\"` (where `{date}` is the plan file's last modified date). Return the existing plan. **Do NOT invoke any subagent.**\n   - If `mtime(story file) > mtime(plan file)` — the plan is **stale**. Log: `\"Regenerating stale test plan for {story-id}\"`. Proceed to generation (Step 1).\n\n4. **First generation:** If the plan file does not exist at all, log: `\"Generating test plan for {story-id}\"`. Proceed to generation (Step 1).\n\n### Step 1 — Gather Context (Subagent via Task, model: opus)\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-plan-tests Phase-1-KP-Read`\n\nLaunch a **single** `general-purpose` subagent with explicit `model: \"opus\"` (Rule 23 RULE-002 — deep test planning quality for Double-Loop TDD + TPP):\n\n    Agent(\n      subagent_type: \"general-purpose\",\n      model: \"opus\",\n      description: \"Test Planning Assistant gathers context for test plan generation\",\n      prompt: \"\u003Csee the blockquote below>\"\n    )\n\n> You are a **Test Planning Assistant** gathering context for test plan generation.\n>\n> **Read the template for required output format (RULE-007):**\n> - Read template at `.claude\u002Ftemplates\u002F_TEMPLATE-TEST-PLAN.md` for required output format.\n> - If the template file does NOT exist, log: `\"Template not found, using inline format\"` and continue without it (RULE-012 — graceful fallback for projects without templates).\n>\n> **Read these knowledge packs:**\n> - `knowledge\u002Ftesting\u002Ftesting-philosophy.md` — 8 test categories, fixture patterns, data uniqueness, async handling, real vs in-memory DB decisions\n> - `knowledge\u002Ftesting\u002Ftesting-conventions.md` — {{LANGUAGE}}-specific test frameworks, naming conventions, directory structure, assertion libraries\n> - `knowledge\u002Farchitecture\u002Farchitecture-principles.md` — exception hierarchy, layer boundaries (unit vs integration), dependency direction\n>\n> **Read testing knowledge pack for {{LANGUAGE}}-specific patterns:**\n> - Read `knowledge\u002Ftesting.md` for {{LANGUAGE}}-specific test frameworks, conventions, and patterns\n>\n> **Read the story:** `{STORY_PATH}`\n> Extract: acceptance criteria, sub-tasks, business rules, dependencies.\n>\n> **Scan existing code:**\n> - List existing classes in target packages\n> - List existing test classes and patterns established\n>\n> **Return a structured context summary:**\n> 1. **Test categories applicable** to this story (from the 8 categories in testing-philosophy)\n> 2. **Naming convention:** `[method]_[scenario]_[expected]` pattern with {{LANGUAGE}}-specific format\n> 3. **Test frameworks and assertion libraries** to use (from testing-conventions)\n> 4. **Fixture pattern:** `final class` + `private constructor` + `static methods`, naming `a{Entity}()`\n> 5. **Acceptance criteria** extracted from story (each becomes ≥1 test)\n> 6. **Business rules** extracted (each maps to parametrized tests)\n> 7. **Exception types** in scope (each needs error path test)\n> 8. **Layer boundaries** — which classes need unit vs integration tests\n> 9. **Existing patterns** found in current test codebase\n> 10. **Contract tests applicable** (if testing.contract_tests == true)\n> 11. **Chaos tests applicable** (if testing.chaos_tests == true)\n> 12. **Template sections** — if template was found, list the 8 mandatory sections to populate\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-plan-tests Phase-1-KP-Read ok`\n\n### Step 2 — Generate Test Scenarios (Inline)\n\nUsing the context returned by the subagent, generate a Double-Loop TDD test plan.\nOrganize scenarios by implementation order (TPP), NOT by test category.\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-plan-tests Phase-2-Acceptance-Tests`\n\n#### 2.1 — Acceptance Tests (Outer Loop)\n\nFor each Gherkin scenario in the story, generate an acceptance test entry:\n\n| Field | Description |\n|-------|-------------|\n| ID | `AT-N` (sequential) |\n| Gherkin | Reference to the original scenario |\n| Status | RED until all unit tests for this acceptance criteria complete |\n| Components | List of classes\u002Fmodules under test |\n| Test Type | Integration, API, or E2E (depending on story scope) |\n| Depends on | UT\u002FIT IDs that must pass for this AT to go GREEN, or `--` |\n| Parallel | `yes` if independent of other ATs |\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-plan-tests Phase-2-Acceptance-Tests ok`\n\n#### 2.2 — Unit Tests (Inner Loop, TPP Order)\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-plan-tests Phase-3-Unit-Tests-TPP`\n\nGenerate unit test scenarios in strict TPP order. Each scenario represents one\nRed-Green-Refactor cycle.\n\n##### TPP Level 1 — Degenerate Cases\n- Null, empty, zero inputs — return default\u002Ferror\n- Transform: `{}→nil` or `nil→constant`\n\n##### TPP Level 2 — Unconditional Paths\n- Single valid input — direct output (no branching)\n- Transform: `constant→variable`\n\n##### TPP Level 3 — Simple Conditions\n- Single if\u002Felse branching\n- Transform: `unconditional→conditional`\n\n##### TPP Level 4 — Complex Conditions\n- Multiple branches, switch\u002Fmatch, compound boolean\n- Transform: deeper conditional logic\n\n##### TPP Level 5 — Iterations\n- Collection processing, loops, map\u002Ffilter\u002Freduce\n- Transform: `scalar→collection`, `statement→recursion\u002Fiteration`\n\n##### TPP Level 6 — Edge Cases\n- Boundary values (at-min, at-max, past-max)\n- Transform: `value→mutated value`\n\nFor each unit test entry, include:\n\n| Field | Required | Description |\n|-------|----------|-------------|\n| ID | M | `UT-N` (sequential within TPP order) |\n| Test | M | What to test (method + scenario + expected) |\n| Implementation | O | Minimum code to pass this test |\n| Transform | M | TPP transformation applied |\n| TPP Level | M | 1-6 |\n| Components | M | Classes\u002Fmodules needed |\n| Depends on | M | Previous test IDs that are prerequisites, or `--` |\n| Parallel | M | `yes` if independent of other tests at same level |\n\n#### 2.3 — Integration Tests (Cross-Component)\n\nPosition AFTER the unit tests of the components involved.\nInclude only when multiple components interact (DB, HTTP, messaging).\n\n| Field | Required | Description |\n|-------|----------|-------------|\n| ID | M | `IT-N` (sequential) |\n| Test | M | What to test |\n| Components | M | Interacting components |\n| Depends on | M | UT IDs that must pass first |\n| Parallel | M | `yes`\u002F`no` |\n\n#### 2.4 — CRUD-Only Story Optimization\n\nWhen a story describes a purely CRUD operation without branching logic:\n- UTs should cover: degenerate (Level 1) — constant (Level 1) — variable (Level 2)\n- Do NOT generate conditional or iteration UTs unless the business rules demand them\n- Acceptance tests should focus on the full CRUD flow\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-plan-tests Phase-3-Unit-Tests-TPP ok`\n\n### Step 3 — Estimate and Validate (Inline)\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-plan-tests Phase-4-Report`\n\n#### 3.1 — Coverage Estimation Table\n\n| Class | Public Methods | Branches | Est. Tests | Line % | Branch % |\n|-------|---------------|----------|-----------|--------|----------|\n| [Name] | [count] | [count] | [count] | [%] | [%] |\n\nFlag any class where estimated coverage \u003C 95% line \u002F 90% branch.\n\n#### 3.2 — Quality Checks\n\n1. Every Gherkin scenario maps to ≥1 acceptance test (AT)\n2. Every acceptance criterion maps to ≥1 unit test chain (UT)\n3. UT-1 is ALWAYS a degenerate case (TPP Level 1)\n4. UTs follow non-decreasing TPP level order\n5. Every exception has ≥1 error path test\n6. Boundary values use triplet pattern (at-min, at-max, past-max)\n7. Dependency markers are complete (no orphan UTs)\n8. Estimated coverage meets thresholds (≥ 95% line, ≥ 90% branch)\n9. Test naming follows convention: `[method]_[scenario]_[expected]`\n10. No unnecessary UTs for CRUD-only stories (max Level 3 unless justified)\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-plan-tests Phase-4-Report ok`\n\n### Output\n\nSave to: `ai\u002Fepics\u002Fepic-XXXX\u002Fplans\u002Ftests-story-XXXX-YYYY.md` (extract epic ID XXXX and story sequence YYYY from the story ID). Ensure directory exists: `mkdir -p ai\u002Fepics\u002Fepic-XXXX\u002Fplans`.\n\n#### Origin Marker (EPIC-0059 — mandatory)\n\nBefore writing the test plan file, prepend the YAML frontmatter block at the very top:\n\n```yaml\n---\ngenerated-by: x-plan-tests@$(git rev-parse HEAD 2>\u002Fdev\u002Fnull || echo \"unknown\")\ngenerated-at: $(date -u +%Y-%m-%dT%H:%M:%SZ)\nstory-id: ${STORY_ID}\n---\n```\n\nThis frontmatter is required by `audit-execution-integrity.sh` Phase-1 validation (EPIC-0059, Rule 24).\nArtifacts without this block fail the CI audit with `EIE_EVIDENCE_MISSING`.\n\n```markdown\n# Test Plan — STORY-ID: [Title]\n\n## Summary\n- Acceptance tests: X (from Y Gherkin scenarios)\n- Unit tests: ~Z (in TPP order)\n- Integration tests: ~W\n- Estimated line coverage: ~P%\n- Estimated branch coverage: ~Q%\n\n## Acceptance Tests (Outer Loop)\n\n### AT-1: [Gherkin scenario name]\n- **Gherkin**: [reference to story scenario]\n- **Status**: RED until all unit tests complete\n- **Components**: [list of components under test]\n- **Acceptance Criteria**: [what must be true for this AT to pass]\n- **Depends on**: UT-1, UT-2, ... (UTs that must pass)\n- **Parallel**: yes\u002Fno\n\n## Unit Tests (Inner Loop — TPP Order)\n\n### UT-1: [degenerate case description] — TPP Level 1\n- **Test**: [methodUnderTest]_[scenario]_[expectedBehavior]\n- **Implementation**: [minimum code to pass]\n- **Transform**: {}→nil\n- **Components**: [class\u002Fmodule]\n- **Depends on**: --\n- **Parallel**: yes\n\n### UT-2: [next case description] — TPP Level 2\n- **Test**: [methodUnderTest]_[scenario]_[expectedBehavior]\n- **Implementation**: [minimum code to pass]\n- **Transform**: constant→variable\n- **Components**: [class\u002Fmodule]\n- **Depends on**: UT-1\n- **Parallel**: no\n\n...\n\n## Integration Tests (Cross-Component)\n\n### IT-1: [integration scenario]\n- **Test**: [description]\n- **Components**: [interacting components]\n- **Depends on**: UT-3, UT-7\n- **Parallel**: no\n\n## Coverage Estimation\n[table]\n\n## Risks and Gaps\n- [Hard-to-test scenarios]\n- [Coverage gaps needing attention]\n```\n\n## Anti-Patterns\n\n- Do NOT write test code — only plan scenarios\n- Do NOT organize test plan by category (Happy Path, Error Path, etc.) — use TPP ordering\n- Do NOT skip error paths\n- Do NOT forget boundary values (0, -1, max, empty, null)\n- Do NOT plan tests for trivial getters\u002Fsetters\n- Do NOT ignore existing test patterns\n- Do NOT create redundant tests covering the same branch\n\n## Error Handling\n\n| Scenario | Action |\n|----------|--------|\n| No story ID provided | Prompt user for story identifier |\n| Story file not found | Abort with file-not-found message |\n| Existing plan is fresh (RULE-002) | Return existing plan, skip generation |\n| Template not found (RULE-012) | Log warning, use inline format, continue |\n| No Gherkin scenarios in story | Generate tests from acceptance criteria text |\n| No acceptance criteria found | Abort with warning, request story refinement |\n\n## Template Fallback (RULE-012)\n\nWhen `.claude\u002Ftemplates\u002F_TEMPLATE-TEST-PLAN.md` is **not available** (projects predating EPIC-0024):\n\n1. Log warning: `\"Template not found, using inline format\"`\n2. Generate the test plan using the inline output format defined in the **Output** section above\n3. Execution continues normally — no interruption, no error\n4. The inline format produces the same 8 conceptual sections but without the template's strict structure\n\nThis ensures backward compatibility with projects that have not yet adopted template-based generation.\n\n## Knowledge Pack References\n\n| Pack | Files | Purpose |\n|------|-------|---------|\n| testing | `knowledge\u002Ftesting\u002Ftesting-philosophy.md` | 8 test categories, fixture patterns, data uniqueness |\n| testing | `knowledge\u002Ftesting\u002Ftesting-conventions.md` | {{LANGUAGE}}-specific test frameworks, naming, assertions |\n| testing | `knowledge\u002Ftesting.md` | {{LANGUAGE}}-specific test patterns |\n| architecture | `knowledge\u002Farchitecture\u002Farchitecture-principles.md` | Exception hierarchy, layer boundaries |\n\n## Integration Notes\n\n| Skill | Relationship | Context |\n|-------|-------------|---------|\n| `x-implement-story` | called-by | Invoked during Phase 1B |\n| `x-implement-task` | reads | Output consumed as TDD roadmap |\n\n- Pre-check (RULE-002) prevents redundant regeneration when story has not changed\n- Template reference (RULE-007) ensures consistent 8-section output format when available\n- Subagent uses explicit `model: \"opus\"` (Rule 23 RULE-002) for deep test planning quality\n- Output uses Double-Loop TDD format with TPP-ordered scenarios\n- Output consumed by Phase 2 (developers) and Phase 3 (QA engineer validates coverage)\n- Can be used standalone before any implementation task\n\n## Planning Status Propagation (Rule 22 \u002F EPIC-0046)\n\n> V2-gated: only runs when `SchemaVersionResolver.resolve(ai\u002Fepics\u002Fepic-XXXX\u002Fexecution-state.json) == V2`. v1 epics: skip silently (Rule 19).\n\nAfter writing `tests-story-XXXX-YYYY.md`, check the associated story's lifecycle status. The test plan, like the architecture plan, is a secondary writer — the primary transition `Pendente → Planejada` is owned by `x-plan-story`. When `x-plan-tests` runs standalone (without `x-plan-story`), it promotes the story from `Pendente` to `Planejada` so the source artifact reflects that the test plan is in place.\n\n**Steps (end of test-plan generation, BEFORE the final commit):**\n\n1. Detect v2 via SchemaVersionResolver. If v1: skip.\n2. Read current story status:\n   ```bash\n   CURRENT=$(java -cp $CLAUDE_PROJECT_DIR\u002Fjava\u002Ftarget\u002Fclasses \\\n       dev.iadev.adapter.inbound.cli.StatusFieldParserCli \\\n       read ai\u002Fepics\u002Fepic-XXXX\u002Fstory-XXXX-YYYY.md)\n   ```\n3. If `CURRENT == \"Pendente\"` → `write Planejada`. Idempotent when already `Planejada`.\n4. Stage and commit:\n   ```bash\n   git add ai\u002Fepics\u002Fepic-XXXX\u002Fstory-XXXX-YYYY.md ai\u002Fepics\u002Fepic-XXXX\u002Fplans\u002Ftests-story-XXXX-YYYY.md\n   ```\n\n       Skill(skill: \"x-commit-changes\", args: \"docs(story-XXXX-YYYY): add test plan + update status to Planejada\")\n\n**Fail-loud:** non-zero CLI exit aborts the skill (RULE-046-08).\n",{"name":5,"description":7,"allowed-tools":24,"argument-hint":25,"context-budget":26,"user-invocable":27,"requires-capabilities":28},"Read, Grep, Glob","[STORY-ID]","medium",true,[],"main","952a630c6f38d193a349d86fa18db1de8843e837","src\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-event-driven\u002F.claude\u002Fskills\u002Fx-plan-tests",1,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment","https:\u002F\u002Fgithub.com\u002Freview-bench","https:\u002F\u002Freview-bench.ai","An open benchmark for AI code review.","2026-10-27 06:56:37",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":27},[40,43,46],{"tool":41,"command":42},"npx","npx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-plan-tests",{"tool":44,"command":45},"bunx","bunx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-plan-tests",{"tool":47,"command":48},"pnpm","pnpm dlx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-plan-tests","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-event-driven\u002F.claude\u002Fskills\u002Fx-plan-tests\u002FSKILL.md",[51],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"README.md","REFERENCE","参考文档",1781,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-event-driven\u002F.claude\u002Fskills\u002Fx-plan-tests\u002FREADME.md",[58,65,72,79,86,93],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"01M757M8J48TQ1Y3X25GSJBXAS","x-parallel-eval","Detects and classifies file-collision risks between work units (tasks, stories, or epic phases) before parallel execution. Reads ## File Footprint blocks produced by x-task-plan \u002F x-story-plan, applies the parallelism-heuristics knowledge pack (hard \u002F regen \u002F soft categories + hotspot overrides), and emits a collision matrix + serialization recommendation in Markdown (default) or JSON.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fx-parallel-eval\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M757M57XMR9546S69466HDWT","parallelism-heuristics","Canonical catalog of file-collision heuristics for parallel task, story, and epic execution. Defines the File Footprint block format, the three Conflict Categories (hard \u002F regen \u002F soft), a hotspot list of high-contention paths, and the degrade-with-warning policy. Consumed by x-task-plan, x-story-plan, x-epic-map, x-parallel-eval, and x-dev-*-implement.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fparallelism-heuristics\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":19},"01M757M11SZ8P1VCQABT08QVYA","x-watch-pr-ci","Polls a PR's CI checks and Copilot review status, blocking until checks complete or timeout. Returns one of 8 stable exit codes (SUCCESS=0, CI_PENDING_PROCEED=10, CI_FAILED=20, TIMEOUT=30, PR_ALREADY_MERGED=40, NO_CI_CONFIGURED=50, PR_CLOSED=60, PR_NOT_FOUND=70). Writes a versioned state-file for session resume.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-watch-pr-ci\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":19},"01M757KW53K8KFPGADFB4PH949","x-validate-docs","Documentation freshness gate: validates 6 dimensions (readme, api-specs, grpc-proto, adr, skill-docs, system-architecture) against code changes in a PR. Stack-aware — only validates targets declared\u002Fauto-detected from ProjectConfig.documentation.targets. Returns exit non-zero on staleness; produces structured report.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-validate-docs\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":19},"01M757KQZHSA10MKC0CR571D60","x-update-system-architecture","Incrementally updates docs\u002Farchitecture\u002Fsystem.md after an epic completes. Appends new entries to the Decision Log (§11) using x-internal-write-report --append (dedup by ## ID: marker) and surgically inserts component\u002Fintegration changes into sections 1-10 via Edit. Idempotent: re-running with the same epic produces a byte-identical system.md.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-update-system-architecture\u002FSKILL.md",[],[],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":19},"01M757KKBT5Q1SVF8DMJBVF46M","x-update-architecture","Incrementally updates the service architecture document with changes from architecture plans. Adds new components, integrations, flows, and ADR references without rewriting existing content. Use after implementation to keep architecture documentation current.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-update-architecture\u002FSKILL.md",[],[]]