yknothing Implementation Alignment Review
Context
This skill checks whether the implementation actually satisfies the user's intent and approved scope.
See context notes.
Inputs
I/O contract notes define required inputs and authority.
Process
Step 1: Reconstruct the Intent Contract
State the intended outcome in one or two concrete sentences. Separate must-have behavior, non-targets, and later work. Do not infer extra scope from implementation shape.
Step 2: Build a Coverage Matrix
Map each user requirement, acceptance criterion, and priority item to implementation evidence. Mark each row as implemented, partially implemented, deferred, contradicted, or unverifiable.
Step 3: Compare Behavior to Claims
Check final messages, docs, quality reports, release notes, and test names against the actual code and runtime evidence. Flag any claim that turns simulated, fake, fixture, local-only, or partial evidence into a stronger statement.
Step 4: Check Consistency Across Artifacts
Verify that code, tests, docs, runbooks, risk registers, and quality snapshots tell the same story. Mismatches are findings even when each file is locally coherent.
Step 5: Classify Gaps
Prioritize:
- Blocking: Intent not implemented, wrong target, false completion claim, missing acceptance criterion, or unowned contradiction.
- Should-fix: Partial coverage or ambiguous evidence that could mislead a downstream reviewer.
- Question: Missing context that can change severity.
Outputs
Produce only declared outputs at their documented quality boundary.
Quality Gate
- Every must-have intent item maps to code, test, documentation, or an explicit deferred/non-target decision.
- No simulated, fake, fixture, or local-only evidence is described as real runtime or production evidence.
- Completion status is no stronger than the weakest required evidence.
- Cross-file contradictions are either fixed or reported as findings.