Spec validator

Skill willianbs/skills/spec-validator

Validates engineering specs before implementation. Ensures requirements are complete, consistent, testable, and implementation-ready. Use for tickets, PRDs, RFCs, or verbal feature asks. Emits SPEC_STATUS. Never redesigns the product or starts coding.From its SKILL.md

Install

npx -y skills add willianbs/skills --skill spec-validator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

23 days oldThe repository was created 23 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.3 KB, 724 tokens by cl100k_base, as published. Nobody here has run it

Purpose

Determine whether work is safe to plan and implement. Ambiguity is a defect.

When to Use / When NOT to Use

Use when: new feature, non-trivial change, unclear ticket, before delivery-planner.

Do not use when: pure bugfix with clear expected behavior (defect-analyst); typo/chore; user already has Ready SPEC_STATUS.

Preconditions

Some form of intent exists (doc, ticket, or user description). If absent, interview briefly then validate.

Inputs / Outputs

Inputs: spec/ticket/ask, optional CONTEXT_PACK.

Outputs: SPEC_STATUS with AC IDs.

Upstream / Downstream

Upstream: context-loader, engineering-mentor (clarification), engineering-os.

Downstream: adr-enforcer, delivery-planner, test-strategy-designer.

Core Principles

Ambiguity is a defect.
Acceptance criteria must be testable.
Reject vague language (“fast”, “intuitive”, “handle correctly”) without metrics/examples.
Tier validation effort to risk.
Security/privacy NFRs required for auth/PII/payments/integrations.
Do not invent product requirements.
Prefer Block over hopeful Ready.

Process

Tier

Signal	Tier
Copy/docs/chore, no behavior change	Trivial — lite checklist
User-facing or multi-file behavior	Feature — full
Auth, PII, payments, migrations, public API	HighRisk — full + NFR bar

Lite (Trivial)

Confirm objective, out-of-scope, and one AC. Ready if unambiguous.

Full

Completeness — actors, flows, data, errors, edge cases, out of scope.
Consistency — no contradictions.
Testability — each AC observable/verifiable; assign AC-# IDs.
Constraints — perf, compatibility, deadlines.
NFRs — for HighRisk: authz, data handling, audit, failure modes.
Open questions — blocking vs non-blocking.
Readiness decision.

Evidence Requirements

Quote ambiguous phrases. Map each blocking issue to a missing AC or contradiction.

Stop Conditions / Failure Modes

Condition	Action
Blocking ambiguity remains	`NotReady` / `Blocked`
HighRisk missing security NFR section	`NotReady`
Spec asks for architecture change	Flag ADR need; do not approve silently

Severity + Confidence

Severity on issues (Critical = unsafe to build). Confidence on readiness judgment.

Output Contract

## SPEC_STATUS
Tier: Trivial | Feature | HighRisk
Readiness: Ready | ReadyWithConditions | NotReady | Blocked
Acceptance criteria:
  - AC-1: ...
Blocking issues: ...
Non-blocking issues: ...
NFR notes: ...
Decision: Proceed | ProceedWithConditions | Revise | Block

Handoffs

delivery-planner — when Ready / ReadyWithConditions
adr-enforcer — architecture implications
requirements-grill (if installed) — adversarial clarification
security-auditor — threat-sensitive specs (advisory)

Never

Never start implementation.
Never “fill in” product decisions without labeling them as assumptions needing approval.
Never mark Ready when ACs are not testable.

What ships with it: 1 file

656 B alongside SKILL.md

README.md656 B