Menú
Perform quality gate analysis on ISO-style specifications to ensure completeness, consistency, and atomicity.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | spec-integrity-analysis |
| description | Perform quality gate analysis on ISO-style specifications to ensure completeness, consistency, and atomicity. |
This skill performs a quality gate analysis on specifications (User Stories, FR/SR, StR, NFR) before task generation.
Completeness Analysis:
Consistency & Conflict Analysis:
For every FR, explicitly check for these patterns:
| Pattern | Probe Question |
|---|---|
| FR delegates to an external CLI (git, gh, cookiecutter, etc.) | Is there an NFR declaring the tool's minimum version, detection method, and user-facing error when absent? |
| FR performs a lookup over multiple sources (registries, plugins, taps) | Is there an explicit tie-breaking policy when two sources return the same key? (first-wins, last-wins, error, merge — must be a stated decision) |
| FR calls an external API that returns paginated results | Does an NFR state whether full enumeration is required? If a cap is acceptable, is it documented as a known limitation? |
| FR calls an external API in a loop or concurrently | Does an NFR declare max concurrency, rate limit awareness, retry policy, and that errors must surface (not be silently swallowed)? |
| FR involves a scaffolding or generation command | Are both an interactive mode (human at terminal) and a scripted/CI mode explicitly specified with their flags? |
| FR calls an authenticated external API | Does an NFR declare the required auth scopes and mandate a clear user-facing error when scope is insufficient (not silent empty results)? |
| FR depends on a package or service not yet implemented | Is the interim fallback and eventual resolution chain documented? Is the hardcoded default traceable to a known stub? |
Atomicity & Testability Analysis:
Before finalizing, verify against spec-failure-domain-analysis:
Convert ISO spec requirements (StR, FR, NFR) into a TDD-based project plan with dependency analysis, parallel execution tracks, quality gates, and task decomposition. Selects or starts a plan and writes a frontmatter-typed plan bundle under plan/<Plan-id>-<slug>/ (Plan + Task + index + log).
Create or update spec artifacts from a design or change request. Orchestrates authoring each requested requirement type (StR/US/FR/NFR/IT) as a discrete file using quoin catalog templates and Quire validation.
Analyze requirement statements (FR/NFR/StR) for EARS requirement-grammar conformance and author a SpecReview of the findings.
Build and maintain the requirements Test Matrix ensuring 100% coverage.
Review requirements for quality, consistency, and completeness.
Verify a targeted plan is complete and validated — every task done, the Test Matrix backed by real tracking tags in tests, and code fully traced to spec (flagging underspecified code with no owning requirement). Optional semantic review checks that intent↔test↔code actually agree. Emits a quire-validated SpecReview artifact to reviews/YY-MM-DD-<slug>.md.
