Verify a selected work boundary

Establish the requested task, change, milestone, phase, or project scope. Load the relevant references:

Use a current sdd-orient handoff for governing instructions, Git state, dirty-path ownership, relevant documents, and declared commands. sdd-manage coordinates the requested scope and execution prerequisites; the active implementation workflow, sdd-implement for main task work or sdd-steer for a checkpoint amendment, requests verification within its boundary. Read the owning TASKS or FEATURE-TASKS, relevant SPEC contracts, PLAN exit conditions, design and layout, actual changes, tests, and existing evidence as needed. Read-only check planning can precede execution; commands with side effects require the established eligible Git worktree and authorized environment.

For an explicit boundary review task, load boundary review and assess implementation code separately from test execution. Neither activity substitutes for the other. Return findings and recheck evidence without repairs or task/hosted state changes.

1. Identify the acceptance and exit conditions to verify and the implementation state being checked.
2. Select sufficient direct, dependent, integration, and boundary checks. Use project commands and an existing verification map where useful; neither a map nor new scripts are required.
3. Run the selected checks and inspect actual outcomes, including failures, warnings, skips, and collection counts where relevant.
4. Associate each condition with evidence and any limitation. Distinguish verified, failed, blocked, and not checked conditions; passing checks do not establish acceptance they never exercised.
5. Classify observed failures where evidence permits and return remaining work to its owner. Do not silently omit an unrelated or pre-existing failure from the results.

sdd-tdd owns testing strategy and test design or changes; this skill assesses coverage and executes the verification campaign. sdd-docs owns documentation maintenance. The active implementation workflow owns repairs, completion checkboxes, commits, pushes, and issue-closure coordination. Leave source, tests, governing documents, and task status unchanged during verification; report necessary changes rather than repairing them here. Account for command-generated artifacts and preserve unrelated pending work.

Return the boundary and implementation state, conditions assessed, check selection and rationale, commands and environment, observed outcomes and evidence locations, failure classifications, omitted or blocked checks, and remaining gaps. sdd-report owns presentation of these facts. Existing task evidence or a project-designated record may hold durable results; no separate verification journal is required. State when the selected conditions are verified without equating that finding with task completion or whole-project correctness.