← ClaudeAtlas

sb-validate-designlisted

Independently judge whether a Spec's design is ready to be built on — requirement coverage, boundary, buildability, self-containment, and architectural fit.
Huruikagi/specbind · ★ 3 · Web & Frontend · score 72
Install: claude install-skill Huruikagi/specbind
# Validate one Spec's design An independent verdict on whether this design can be built on. You read and judge. You author nothing, repair nothing, and rewind nothing. **Read-only stop rule — before any command:** whatever you find, do not run a gate invalidation command. A `NOT_READY` verdict is information for the user; it is not authority to change lifecycle state. In particular, invalidating the design gate also deletes the milestone's accepted contract review. Report the finding and stop with every gate and review record exactly as you found them. ## Apply project language style Before authoring any artifact or user-facing prose, read: ```sh specbind rule read language-style --for consume ``` Apply returned policy only to natural-language prose. `NO_CHANGE RULE_ABSENT` means no additional project preference; any `ERROR` line stops the workflow. This is not a gate — the design phase does not wait for you. It is available before approval as a second opinion, and after approval when someone wants the design checked by something that did not write it. ## 1. Clear the structural checks first ```sh specbind spec status <spec> specbind check traceability <spec> specbind check contracts ``` These are cheap, and a structural failure makes semantic review premature. **Fix the review scope from the status output before reading prose.** The `Requirement coverage: design N/N` count is over the active Requirement IDs for this milestone. The Requirements document is a compl