git:20260908.c32d373 to git:20260909.950f5ff

---

name: saf-check-task

description: Independently check one implemented SDD task against its acceptance criteria and configured gates before handoff. Use for a task-scoped readiness check, not feature-wide validation or code changes.

compatibility: Requires Git and a compatible Agent Skills host.

---

# Check one SDD task

## When to use

## When not to use

Do not use to implement fixes, review an entire feature, approve a PR, or infer an ambiguous task identity. Reject a discovery-only workspace because it is not a spec package with implementation-ready task evidence. To validate a whole feature already integrated, use `saf-validate` instead of repeating this process task by task.

## Inputs

- One canonical task reference.

- Optional `.sdd-agentic-flow/config.yml` overrides, the task's SDD artifacts, current diff, and validation commands.

## Workflow

1. Read `.sdd-agentic-flow/config.yml` when present; otherwise use canonical effective defaults. Resolve exactly one package and exactly one task. Load this skill's existing Inputs/Workflow list only.

2. Follow this **fresh-eyes** order (state-checking, not narrative-judging): re-read spec + repo contracts → re-derive expected per AC (ignore implementer narrative) → run current sensor commands (environment state) → requirement coverage matrix (`requirement → sensor → current result`) → apply false-positive catalog → Status (existing enum only). Prefer a fresh independent verifier context when the host provides one; otherwise explicitly re-ground the oracle from canonical artifacts. Read `.sdd-agentic-flow/context/project-context.md` and `.sdd-agentic-flow/context/domain-glossary.md` when they exist. Inspect changed files for scope drift and pre-existing changes.

3. Derive task-scoped validation obligations from the required behaviors, current diff, affected seams, repository contracts, and risk, following `change-impact-validation.md`. Select the smallest adequate sensor set and name any omitted higher-level sensor with a requirement-based reason. Confirm each sensor observes a contractual seam and that its oracle is grounded in spec, repo contracts, or configured gates — not inferred solely from the implementation. Flag tautology. Missing RED is not an automatic fail; `n/a — not used as proof` is valid. For each required behavior, assess the non-shallow litmus by considering a plausible wrong implementation that would survive the selected sensors. A surviving counterexample is a sensor gap; inability to identify one is recorded as a limitation and does not prove adequacy or inadequacy. If the selected sensors cannot discriminate the required behavior, record **Shallow sensor** or an evidence gap — not PASS.

4. Confirm the declared slice is independently verifiable, or that horizontal work and dependencies are explicitly justified. An unmapped AC cannot silently PASS. Include **unchanged** ACs in the coverage matrix; do not skip unchanged-behavior sensors on bugfix. If the spec is still **ambiguous**, do not PASS an implementation of one interpretation. On spec drift, write `needs changes` with a reconciliation note — do not rewrite the spec to match the code.

5. Run only configured, safe, task-relevant checks, applying `../sdd-agentic-flow-shared/references/evidence-standard.md`. Record commands and results as **evidence** (command, exit status, observed result, requirement mapping). Emit the v4 check-report contract: top-line `Feature: <feature-slug>` and an evidence index table (`| Requirement anchor | Sensor | Result | Freshness |`) plus the detailed current evidence record required by evidence-standard — a summary-only row cannot establish adequacy. Distinguish current vs historical vs not-run. Record missing or inadequate sensors as explicit gaps. Never turn missing evidence into a pass. A passing sensor is evidence, not a correctness verdict. Self-report is not evidence. This skill must not inherit author narrative. Re-ground goal, completion criteria, and oracle from canonical artifacts per [task-context-package.md](../sdd-agentic-flow-shared/references/task-context-package.md) and [bounded-execution.md](../sdd-agentic-flow-shared/references/bounded-execution.md). If the effective contract changed, re-evaluate affected evidence freshness before classifying the task; a pending proposal is not an effective contract.

6. Independently judge **engineering fit** against `../sdd-agentic-flow-shared/references/engineering-principles.md` (project conventions, extra abstraction, unnecessary files). Keep that judgment separate from spec/correctness. Engineering-fit issues are findings; they do not flip PASS unless they hit an AC, a safety rule, or an explicit human bar. `PASS` stays owned by evidence-standard and the false-positive catalog.

7. Classify the task as `pass`, `needs changes`, `blocked`, or `inconclusive`, with actionable gaps. In autonomous mode, an attributable `needs changes` result identifies the owning `saf-implement` repair transition; it does not authorize this Skill to mutate code. Classify `blocked` and `inconclusive` by cause before routing. Never write `Status: pass` on a false-positive catalog hit. Do not implement fixes, edit tests to force PASS, LGTM from prose, use the changed implementation as the correctness oracle, or rewrite the test suite as a second implementation.

## Safety

This is read-only except for disposable test artifacts permitted by configuration. Do not change code, specs, Git, trackers, PRs, remote services, or default configuration. Self-report is not evidence. This skill must not inherit author narrative.

## Output

Return task identity, validation scope (impact, obligations, selected and omitted sensors), criterion-to-evidence summary, executed checks, scope findings, final classification, and next step. Include `Status`, `Next recommended skill`, and `Reason`. When the classification is `needs changes`, `blocked`, or `inconclusive` and resolution is likely to span a session or agent boundary, write or update `handoff.md` per `../sdd-agentic-flow-shared/references/handoff-standard.md`.

### Autonomy

Supports `manual`, `supervised`, and `autonomous` autonomy levels. In autonomous mode, a `pass`

report with satisfied gates advances normally. An attributable `needs changes` report authorizes

`saf-implement` followed by a fresh check; `blocked` and `inconclusive` require cause

classification. This Skill remains read-only and never repairs its own findings. See

`../sdd-agentic-flow-shared/references/autonomy-guardrails.md`.