메뉴
Audit a technical spec for completeness and consistency. Use after /light-spec drafts a spec and before promoting to Approved. Use when a spec feels under-specified. Flags gaps for /light-spec-revise to close.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Feature-scoped security gate that runs at the Building → UAT seam (before pk ship). It classifies the change into sensitive categories (auth, payments, user-input, external-APIs, file-storage, PII) and, on any match, runs the category-specific security checklist against the feature's diff — producing a PASS/FAIL report + a Linear comment, and on PASS the sha-matched sentinel pk ship hard-requires (v4.17.0) on any project with a categories file. It does not transition state. Portable framework; the project's category definitions live in a per-project checks file. Different from /security-review (periodic repo-wide audit) and /pr-security-review (PR-scoped antagonistic review).
V2 daily-loop skill — plan + execute a Linear issue from inside its worktree. Use after pk branch opens a worktree. Use when an Approved Linear issue is ready for implementation. Native-on-Workflow is the sole executor (v4.0.0 removed the pluggable vbw backend).
Structured spec generation with auto-cycled agent review + tier auto-derive (v2.7.0-rc1+). Use when a Linear issue moves to spec stage. Use when writing/refining a feature spec before /work. Use when /spec-validator flags gaps.
Production-readiness gate for a feature about to reach its production environment — verifies the operational preconditions (error monitoring wired, no secrets in the client bundle, rate limiting on new public endpoints, backups active, feature flag for risky paths, dashboard chart) that the pre-deploy gate (/verify) does not. Produces a PASS/FAIL report + a Linear comment, and on PASS the sentinel pk promote hard-requires at the final hop (v4.17.0) on any project with a checks file; it does not transition state. Portable framework; concrete checks live in a per-project checks file. Different from /verify (code readiness) and /security-review (security audit).
verify — tier-aware evidence-gated pre-deploy gate. tier:standard|heavy write Logs/Verify/<date>/<id>/{evidence.txt,reality-check.md,verify-complete.md}; tier:quick writes only verify-complete.md on PASS. pk ship gates on a verify-complete.md whose sha matches HEAD. Use when a Linear issue is ready for verify (Stage 3). Use when /work finished and you need a Pass/Partial/Fail verdict per AC before pk ship.
Bug pipeline — intake, reproduce, regression-test-first, fix, ship, postmortem. Wraps /work and pk ship with discipline gates. Invoke when a bug is reported or spotted. Linear is the source of truth — resume by passing the issue ID.
| name | spec-validator |
| description | Audit a technical spec for completeness and consistency. Use after /light-spec drafts a spec and before promoting to Approved. Use when a spec feels under-specified. Flags gaps for /light-spec-revise to close. |
You are a specification quality auditor. Your job is to systematically validate specification documents for completeness, consistency, and correctness. Read method.config.md for project context.
This skill is invoked when the user says:
/spec-validatorStrategy docs live in Strategy/:
Generates validation report: Strategy/Spec_Validation_Report_YYYY-MM-DD_HH-MM.md
## Spec Validation Report — 2026-04-10
### Summary: CONDITIONAL GO
| Area | Status | Issues |
|------|--------|--------|
| Table Completeness | PASS | 0 |
| Cross-Document Consistency | WARN | 2 minor |
| Security & Permissions | PASS | 0 |
| Data Integrity | FAIL | 1 missing FK |
### Blocking Issues
1. Data Integrity: `budgets` table missing FK to `entities.id` — referenced in Doc2 §3.2 but not in schema
### Warnings
1. Doc1 §2.1 uses "project" while Doc3 §1.4 uses "engagement" for the same concept
2. Doc5 §3.1 references `admin` role but Doc1 §4.2 calls it `super_admin`