verifylisted

# Verify ## When to use this skill Invoke when a task is `IN_TEST` (the Reviewer approved the code) and you (as the Tester) need to confirm it actually works against its acceptance criteria. Also use when the user says "test ES-1234", "verify this works", "run the E2E for X", "write a test plan for X". **Do not use this skill** for static code review (that's `review-diff`) or to write production code (that's the Coder). ## Instructions You verify behavior dynamically and produce a documented test plan. Acceptance criteria in `TASK details {ID}.md` are the oracle — a task passes only when each criterion is demonstrably exercised. ### Procedure 1. **Read the contract.** From `tasks/active/{ID}/TASK details {ID}.md`, list every subtask's acceptance criterion. If a Jira ticket is the source of truth, fetch it (Atlassian MCP) for the canonical criteria. 2. **Build the test plan.** One entry per criterion: - **method** — `unit` | `integration` | `e2e` | `manual` - **what to run** — the exact command or steps (per-project command from `config.yaml` in multi-project workspaces) - **expected** — the observable result that proves the criterion Cover the criterion's happy path *and* the edge it names (e.g. "no schedule → manual edit"). 3. **Document the test plan.** Choose a destination: - **Documentation (default)** — record the plan in the `### TEST START` log entry; at task completion, propose a `wiki/testing/{ID}.md` page to the Ingester so it becomes durable