SDD Specification

Treat SDD as an optional methodology and keep the specification as the active source of intended behavior.

1. Discover candidate specifications metadata-first with metadata guidance, then read the complete governing specification before implementation or review.
2. Resolve or expose contradictions without letting tests or implementation silently redefine intent.
3. Maintain compact routing metadata, stable acceptance criteria, invariants, exclusions, authority, compatibility, recovery behavior, and unresolved decisions. Use the specification template only when no repository convention exists.
4. Create the separate behavior/oracle matrix before the new implementation is shown to its reviewer. Classify each oracle's provenance with provenance guidance.
5. Keep the specification, matrix, tests, implementation, durable documentation, and evidence reconciled through formal SDD review and reconciliation.
6. Preserve authority boundaries and report contradictions or missing decisions instead of inventing policy.

The skill works independently. When an installed TDD capability is available, hand it approved behavior, invariants, and matrix rows; when an installed review capability is available, hand it the governing input, expected behavior, tests, complete diff, fresh results, and risks. These optional capability handoffs create no runtime dependency and require no copied companion skill.