How do I install the Sdd Verify skill?

Run npx skillmds@latest add jantoniofc/sdd-verify in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Sdd Verify safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Sdd Verify?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Sdd Verify free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Sdd Verify?

JantonioFC (@jantoniofc) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Sdd Verify by jantoniofc — Agent Skill

Name: Sdd Verify
Rating: 4.2 (5 reviews)
Author: JantonioFC

File contents

ORCHESTRATOR GATE: If you loaded this skill via the skill() tool, you are the ORCHESTRATOR — STOP. Do NOT execute these instructions inline. Delegate to the dedicated sdd-verify sub-agent using your platform's delegation primitive (e.g., task(...), sub-agent invocation, etc.). This skill is for EXECUTORS only.

Executor Override

If you ARE the sdd-verify sub-agent (NOT the orchestrator), the gate above does NOT apply to you. Continue with the phase work below. Do NOT delegate. Do NOT call the Skill tool. You are the executor — execute.

Activation Contract

Run when the orchestrator launches verification for an SDD change. You are the quality gate: prove completion with source inspection plus real execution evidence.

Hard Rules

Read proposal, spec, design, and tasks before judging implementation.
Execute relevant tests; static analysis alone is never verification.
A spec scenario is compliant only when a covering test passed at runtime.
Compare specs first, design second, task completion third.
Do not fix issues; report them for the orchestrator/user.
Persist verify-report according to mode: Engram, openspec file, hybrid both, or inline-only for none.
If Strict TDD is active, load strict-tdd-verify.md from this skill directory; if inactive, never load it.
Return the Section D envelope from ../_shared/sdd-phase-common.md.

Decision Gates

Condition	Action
Orchestrator says `STRICT TDD MODE IS ACTIVE`	Treat as authoritative.
Cached/config `strict_tdd: true` and runner exists	Strict TDD verify; load module.
Strict TDD false or no runner	Standard verify; skip TDD checks.
Task incomplete	CRITICAL for core task, WARNING for cleanup task.
Test command exits non-zero	CRITICAL.
Spec scenario has no passing covering test	CRITICAL `UNTESTED` or `FAILING`.
Design deviation exists	WARNING unless it breaks a spec.

Execution Steps

Load relevant skills via shared SDD Section A.
Retrieve artifacts via shared Section B for the active persistence mode.
Resolve testing/TDD mode from cached capabilities, config, or project files.
Count completed and incomplete tasks.
Map each spec requirement/scenario to implementation evidence and tests.
Check design decisions against changed code.
Run test, build/type-check, and coverage commands when available.
Build the behavioral compliance matrix from actual test results.
Persist and return the verification report.

Output Contract

Return ## Verification Report with change, mode, completeness table, build/tests/coverage evidence, spec compliance matrix, correctness table, design coherence table, issues grouped as CRITICAL/WARNING/SUGGESTION, and final verdict PASS, PASS WITH WARNINGS, or FAIL.

References

references/report-format.md — full report template, compliance statuses, and command evidence fields.
strict-tdd-verify.md — load only when Strict TDD is active.
../_shared/sdd-phase-common.md — skill loading, retrieval, persistence, and return envelope.

---name: sdd-verifydescription: Trigger: SDD verification phase, verify change. Execute tests and prove implementation matches specs, design, and tasks.license: MIT---> **ORCHESTRATOR GATE**: If you loaded this skill via the `skill()` tool, you are> the ORCHESTRATOR — STOP. Do NOT execute these instructions inline. Delegate to> the dedicated `sdd-verify` sub-agent using your platform's delegation primitive> (e.g., `task(...)`, sub-agent invocation, etc.). This skill is for EXECUTORS> only.## Executor OverrideIf you ARE the `sdd-verify` sub-agent (NOT the orchestrator), the gate above does NOT apply to you. Continue with the phase work below. Do NOT delegate. Do NOT call the Skill tool. You are the executor — execute.## Activation ContractRun when the orchestrator launches verification for an SDD change. You are the quality gate: prove completion with source inspection plus real execution evidence.## Hard Rules- Read proposal, spec, design, and tasks before judging implementation.- Execute relevant tests; static analysis alone is never verification.- A spec scenario is compliant only when a covering test passed at runtime.- Compare specs first, design second, task completion third.- Do not fix issues; report them for the orchestrator/user.- Persist `verify-report` according to mode: Engram, openspec file, hybrid both, or inline-only for `none`.- If Strict TDD is active, load `strict-tdd-verify.md` from this skill directory; if inactive, never load it.- Return the Section D envelope from `../_shared/sdd-phase-common.md`.## Decision Gates| Condition | Action ||---|---|| Orchestrator says `STRICT TDD MODE IS ACTIVE` | Treat as authoritative. || Cached/config `strict_tdd: true` and runner exists | Strict TDD verify; load module. || Strict TDD false or no runner | Standard verify; skip TDD checks. || Task incomplete | CRITICAL for core task, WARNING for cleanup task. || Test command exits non-zero | CRITICAL. || Spec scenario has no passing covering test | CRITICAL `UNTESTED` or `FAILING`. || Design deviation exists | WARNING unless it breaks a spec. |## Execution Steps1. Load relevant skills via shared SDD Section A.2. Retrieve artifacts via shared Section B for the active persistence mode.3. Resolve testing/TDD mode from cached capabilities, config, or project files.4. Count completed and incomplete tasks.5. Map each spec requirement/scenario to implementation evidence and tests.6. Check design decisions against changed code.7. Run test, build/type-check, and coverage commands when available.8. Build the behavioral compliance matrix from actual test results.9. Persist and return the verification report.## Output ContractReturn `## Verification Report` with change, mode, completeness table, build/tests/coverage evidence, spec compliance matrix, correctness table, design coherence table, issues grouped as CRITICAL/WARNING/SUGGESTION, and final verdict `PASS`, `PASS WITH WARNINGS`, or `FAIL`.## References- [references/report-format.md](references/report-format.md) — full report template, compliance statuses, and command evidence fields.- [strict-tdd-verify.md](strict-tdd-verify.md) — load only when Strict TDD is active.- `../_shared/sdd-phase-common.md` — skill loading, retrieval, persistence, and return envelope.

Frequently asked questions

Sdd Verify