test

name	test
version	1.0.0
description	[Testing] Use when you need to run tests locally and analyze the summary report.

[BLOCKING] Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. [BLOCKING] Before each step or sub-skill call, update task tracking: set in_progress when step starts, set completed when step ends. [BLOCKING] Every completed/skipped step MUST include brief evidence or explicit skip reason. [BLOCKING] If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions.

Quick Summary

Goal: Deliver an accurate, read-only pass/fail verdict — by running tests locally via the tester subagent and analyzing the summary report — with exact counts, failing-test names, report path, and Goal Contract evidence, so the user knows the true test state without any fix applied.

Summary:

• Always run tests through the tester subagent — never invoke test commands directly — then analyze its summary report.
• This skill is strictly READ-ONLY: report pass/fail counts, failing-test names, and the report path; stop at reporting and NEVER start implementing fixes (that is /fix's job).
• After the run, resolve the active Goal Contract and append verification evidence (command, exact counts, report path) to the goal file's Iteration Log, updating the Goal Satisfaction matrix; record "No active goal" inline when none exists. Never copy sensitive fixture data into the goal file.

Workflow:

1. Delegate — Launch tester subagent with test scope from arguments
2. Analyze — Review test results, identify failures and patterns
3. Report — Summarize pass/fail counts, highlight failing tests

Key Rules:

• READ-ONLY: do not implement fixes, only report results
• Activate relevant skills from catalog during process
• Always use tester subagent, not direct test commands

Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).

Use the tester subagent to run tests locally and analyze the summary report.

IMPORTANT: Stop at reporting results — do not start implementing. IMPORTANT: Analyze the skills catalog and activate the skills that are needed for the task during the process.

Goal Contract evidence (after test run): Resolve the active Goal Contract per the goal-contract-satisfaction-loop protocol (active plan goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md). When one exists, append the verification evidence to the goal file's Iteration Log — test command, exact pass/fail counts, report path — mapped to the saved success criteria the run verifies, and update the Goal Satisfaction matrix rows for those criteria (PASS/FAIL/BLOCKED). Record No active goal — evidence reported inline only. when none exists. Never copy raw sensitive fixture data into the goal file.

---

First Principle — Easy to Change

The success metric of every coding decision is future change cost. DRY, SRP, abstraction, design patterns, naming, layering, tests — every technique exists to serve one goal: making the next change cheaper.

When evaluating code, a refactor, a test, or an abstraction, ask: does this make the next change cheaper or more expensive?

• Reject "best practices" that raise change cost (premature abstraction, speculative generality, leaky indirection, ceremony without payoff).
• Name the real enemies in findings: coupling, hidden state, duplicated knowledge, unclear intent, irreversible decisions exposed too early.
• A simpler design that is easy to change beats a sophisticated design that isn't.

Apply this lens before invoking any specific rule, pattern, or checklist below — if a downstream rule would raise change cost, this principle wins.

---

Workflow Recommendation

MANDATORY IMPORTANT MUST ATTENTION — NO EXCEPTIONS: If you are NOT already in a workflow, you MUST ATTENTION use AskUserQuestion to ask the user. Do NOT judge task complexity or decide this is "simple enough to skip" — the user decides whether to use a workflow, not you:

1. Activate testing workflow (Recommended) — test
2. Execute /test directly — run this skill standalone

---

Next Steps

MANDATORY IMPORTANT MUST ATTENTION — NO EXCEPTIONS after completing this skill, you MUST ATTENTION use AskUserQuestion to present these options. Do NOT skip because the task seems "simple" or "obvious" — the user decides:

• "/docs-update (Recommended)" — Update documentation after tests pass
• "/fix" — If tests revealed failures that need fixing
• "/watzup" — Wrap up session and review all changes
• "Skip, continue manually" — user decides

[IMPORTANT] Use TaskCreate to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.

• docs/project-reference/domain-entities-reference.md — Domain entity catalog, relationships, cross-service sync (read when task involves business entities/models)

External Memory: For complex or lengthy work (research, analysis, scan, review), write intermediate findings and final results to a report file in plans/reports/ — prevents context loss and serves as deliverable.

Evidence Gate: MANDATORY IMPORTANT MUST ATTENTION — every claim, finding, and recommendation requires file:line proof or traced evidence with confidence percentage (>80% to act, <80% must verify first).

Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.

Evidence-Based Reasoning — Speculation is FORBIDDEN. Every claim needs proof.

1. Cite file:line, grep results, or framework docs for EVERY claim
2. Declare confidence: >80% act freely, 60-80% verify first, <60% DO NOT recommend
3. Cross-service validation required for architectural changes
4. "I don't have enough evidence" is valid and expected output

BLOCKED until: - [ ] Evidence file path (file:line) - [ ] Grep search performed - [ ] 3+ similar patterns found - [ ] Confidence level stated

Forbidden without proof: "obviously", "I think", "should be", "probably", "this is because" If incomplete → output: "Insufficient evidence. Verified: [...]. Not verified: [...]."

Source/test drift check. For coding, fix, debug, investigation, test, or review work: when source behavior changes, inspect affected unit/integration/E2E tests and decide from evidence whether tests should change to match intended behavior or the source change is an unintended bug to fix. Do not write tests for migration code; schema/data migrations are one-time execution paths, not core application logic.

AI Mistake Prevention — Failure modes to avoid on every task:

Re-read files after context changes. Context compaction, resume, or long-running work can make memory stale; verify current files before acting. Verify generated content against source evidence. AI hallucinates APIs, names, claims, and document facts. Check the relevant source before documenting or referencing. Check downstream references before deleting or renaming. Removing an artifact can stale docs, generated mirrors, configs, and callers; map references first. Trace the full impact chain after edits. Changing a definition can miss derived outputs and consumers. Follow the affected chain before declaring done. Verify ALL affected outputs, not just the first. One green check is not all green checks; validate every output surface the change can affect. Assume existing values are intentional — ask WHY before changing. Before changing a constant, limit, flag, wording, or pattern, read nearby context and history. Surface ambiguity before acting — don't pick silently. Multiple valid interpretations require an explicit question or stated assumption with risk. Keep shared guidance role-relevant. Universal guidance must help every receiving skill or agent; code-specific obligations belong only in code-specific protocols.

IMPORTANT MUST ATTENTION cite file:line evidence for every claim (confidence >80% to act). NEVER speculate without proof.

MUST ATTENTION apply critical + sequential thinking — every claim needs appropriate traced evidence (file:line for repo/code claims; source URL or artifact section for research, product, content, and docs claims); confidence >80% to act, <60% DO NOT recommend. Anti-hallucination: never present guess as fact, admit uncertainty freely, cross-reference independently, stay skeptical of own confidence.

MUST ATTENTION apply AI mistake prevention — verify generated content against evidence, trace downstream references before deleting or renaming, verify all affected outputs, re-read files after context loss, and surface ambiguity before acting.

• MANDATORY Resolve the active Goal Contract BEFORE work (active plan goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md → create from current request) and read saved success criteria before editing.
• MANDATORY Append iteration evidence after execution; emit a Goal Satisfaction matrix (PASS/FAIL/BLOCKED) before reporting PASS; loop on validated FAIL; escalate repeated no-progress or blockers. NEVER store secrets in goal files.

Prompt-Enhance Closing Anchors

IMPORTANT MUST ATTENTION follow declared step order for this skill; NEVER skip, reorder, or merge steps without explicit user approval IMPORTANT MUST ATTENTION for every step/sub-skill call: set in_progress before execution, set completed after execution IMPORTANT MUST ATTENTION every skipped step MUST include explicit reason; every completed step MUST include concise evidence IMPORTANT MUST ATTENTION if Task tools unavailable, maintain an equivalent step-by-step plan tracker with synchronized statuses

Closing Reminders

IMPORTANT MUST ATTENTION Goal: deliver an accurate, read-only pass/fail verdict — run tests via the tester subagent, analyze its summary report — with exact counts, failing-test names, report path, and Goal Contract evidence, so the user knows the true test state without any fix applied.

Protocols in force (concise digest of the SYNC/shared blocks this skill carries):

• Critical Thinking: ALWAYS apply critical + sequential thinking; traced proof, confidence >80%.
• Evidence: ALWAYS cite file:line per claim; NEVER speculate without proof.
• Source/Test Drift: when source changes, decide from evidence whether test or source is wrong; NEVER assume.
• AI Mistake Prevention: verify generated content against evidence, trace downstream references, verify all affected outputs, re-read after context loss, surface ambiguity.

MANDATORY IMPORTANT MUST ATTENTION READ-ONLY — run tests, report pass/fail counts + failing-test names + report path; NEVER implement fixes here, stop at reporting — why: fixing is /fix's job; mixing the two hides the true test state. MANDATORY IMPORTANT MUST ATTENTION ALWAYS run tests through the tester subagent; NEVER invoke test commands directly — why: the subagent isolates the run and produces the canonical summary report this skill analyzes. MANDATORY IMPORTANT MUST ATTENTION resolve the active Goal Contract after the run; append verification evidence (test command, exact pass/fail counts, report path) to the goal file's Iteration Log and update the Goal Satisfaction matrix; record No active goal — evidence reported inline only. when none exists; NEVER copy raw sensitive fixture data into the goal file — why: the goal file is the durable PASS/FAIL ledger, not a secrets store. MANDATORY IMPORTANT MUST ATTENTION cite file:line evidence for every claim about a failure (confidence >80% to act, <80% verify first); NEVER speculate which test failed or why — read the report — why: a guessed failure verdict sends the user to fix the wrong thing. MANDATORY IMPORTANT MUST ATTENTION before asserting a test/source relationship, grep 3+ similar tests and match the local pattern; apply the source/test drift check — decide from evidence whether a failing test guards intended behavior or the source is the bug — why: a mismatched assumption mislabels a real bug as a flaky test. MANDATORY IMPORTANT MUST ATTENTION break work into small todo tasks using TaskCreate BEFORE starting; mark one in_progress, complete immediately after evidence; add a final review todo to verify work quality. MANDATORY IMPORTANT MUST ATTENTION validate route/decisions with the user via AskUserQuestion — NEVER auto-decide a workflow vs standalone run. IMPORTANT MUST ATTENTION READ CLAUDE.md before starting.

Anti-Rationalization:

Evasion	Rebuttal
"Tests obviously pass, skip the run"	Run via tester anyway — a guessed verdict is not a verdict. Report real counts.
"I can run the test command directly"	NEVER — always delegate to the tester subagent; direct runs bypass the canonical report.
"Failure looks trivial, I'll just fix it"	Stop at reporting. Fixing is /fix's job; this skill is strictly READ-ONLY.
"No goal file, skip the evidence step"	Record No active goal — evidence reported inline only. Never silently skip the Goal Contract.
"I know which test failed"	Show file:line + the report path. No proof = no claim.

[IMPORTANT] Analyze how big the task is and break it into many small todo tasks systematically before starting — this is very important.

---

Closing reminder — Easy to Change is the success metric. Every finding, test, refactor, and abstraction must answer one question: does this make the next change cheaper or more expensive? If it doesn't reduce future change cost, reject it. Coupling, hidden state, duplicated knowledge, and unclear intent are the real enemies — call them out by name.

IMPORTANT MUST ATTENTION READ-ONLY — report pass/fail, NEVER fix here (that is /fix's job). IMPORTANT MUST ATTENTION ALWAYS run via the tester subagent; cite file:line + report path for every failure claim (confidence >80%). IMPORTANT MUST ATTENTION Goal: accurate read-only pass/fail verdict with exact counts, failing-test names, report path, and Goal Contract evidence — so the user knows the true test state without any fix applied.