Help us improve
Share bugs, ideas, or general feedback.
From vast-skills
Validate a document that claims VAST shape — a single layer (e.g. a Vision doc) or a full V/A/S/T doc — checking that each layer is what it claims to be, scope is consistent across layers, and framework discipline holds. Detects layer drift (Vision written as a feature/deadline list, Architecture written as a project plan), mixed scope (company-level Vision + product-UI Architecture), missing Vision falsification triggers, incomplete composition frameworks, and Challenge Flow violations. Use this WHENEVER someone shares a Vision, Architecture, Strategy, or Tactics doc and wants it checked, reviewed, sanity-checked, or pressure-tested for whether the layers are clean and well-formed — EVEN IF they never say "VAST" or "layer purity". Checking layer discipline by hand is exactly what this skill does better: it applies fixed structural checks and returns a per-check Pass/Warn/Fail report, so reach for it rather than eyeballing. Triggers: "validate this VAST doc", "is this layer pure", "check VAST shape", "проверь VAST", "does this Vision hold up", "is this Architecture really architecture", "validate Architecture doc". Not for OKR-only docs (use vast-okr-audit), reshaping raw prose into VAST (use vast-transform), or relating two docs (use vast-connect).
npx claudepluginhub dkushnikov/vast-framework --plugin vast-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/vast-skills:vast-validateThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Invoke when you have a document that claims VAST shape — one layer (a standalone Vision, Architecture, Strategy, or Tactics doc) or a full V/A/S/T set — and want to verify it respects the framework: each layer contains content appropriate to its level, the doc operates at one consistent scope, and framework discipline (Vision falsification, composition completeness, Challenge Flow) holds.
Creates p5.js generative art with seeded randomness, noise fields, and interactive parameter exploration. Use for algorithmic art, flow fields, or particle systems.
Share bugs, ideas, or general feedback.
Invoke when you have a document that claims VAST shape — one layer (a standalone Vision, Architecture, Strategy, or Tactics doc) or a full V/A/S/T set — and want to verify it respects the framework: each layer contains content appropriate to its level, the doc operates at one consistent scope, and framework discipline (Vision falsification, composition completeness, Challenge Flow) holds.
Common triggers:
This skill is distinct from vast-okr-audit: that one audits OKR-shaped docs (Objectives + KRs) for triad conflation; this one validates docs that explicitly claim a VAST layer structure.
A VAST doc names up to four layers, each owning a distinct level of commitment:
| Layer | Owns | Drift looks like |
|---|---|---|
| Vision | What experiences we enable, for whom, why — as a falsifiable hypothesis with named revision triggers. | A feature list or roadmap with deadlines (Tactics drift); market positioning swallowing the product (Strategy/scope drift). |
| Architecture | The composition framework — skill library, interfaces, invariants, implementations. The structural domains and their guarantees. | A project/task list (Tactics drift); market stance (Vision drift). |
| Strategy | Which experiences to compose next — sequencing, customer validation, investment direction within the framework. | Concrete deliverables with dates (Tactics drift); redefining the framework (Architecture drift). |
| Tactics | Personalized instance delivery — specific compositions for specific users at specific times. | (Tactics is the floor — content rarely drifts up, but generic aspiration with no concrete delivery is hollow.) |
Two cross-cutting disciplines: Vision is a hypothesis with named falsification triggers (governance.md Vision Falsification Protocol), and challenge flows down, feedback flows up (Vision challenges Architecture; Strategy informs, never overrides; glossary.md Challenge Flow).
For the four layers, the triad, and the invariants/implementations split, see ../../references/vast-essentials.md. For the four-scope model (company / product / function / WoW) and per-scope identifying signals, see ../../references/layer-definitions.md. The eight common confusions are in ../../references/anti-patterns.md. Detailed validation heuristics are in references/validation-heuristics.md — read those if any classification is ambiguous.
For the doc under review:
references/validation-heuristics.md#scope-homogeneity; the full per-scope signal lists are in ../../references/layer-definitions.md.)references/validation-heuristics.md#layer-purity.)references/validation-heuristics.md#scope-homogeneity.)references/validation-heuristics.md#falsification-triggers.)references/validation-heuristics.md#composition-completeness.)references/validation-heuristics.md#challenge-flow.)references/validation-heuristics.md#kernel-floor.)| # | Check | Heuristic (1-liner) | Detail reference |
|---|---|---|---|
| 1 | Layer purity | Each present layer holds content appropriate to its level. Vision = why/experiences/outcomes (not features/deadlines). Architecture = composition framework / structural domains (not a project list, not market stance, not an org chart / tech stack). Strategy = investment direction/sequencing. Tactics = concrete delivery. Content belonging to another layer → Fail; mild bleed → Warn. | references/validation-heuristics.md#layer-purity (primary); ../../references/anti-patterns.md (#1 Vision-as-Use-Case, #2 Architecture-by-default, #9 AP-03 Architecture-as-org-chart/stack) |
| 2 | Scope homogeneity | The doc operates at ONE scope (company / product / function / WoW). Layers at different scopes (e.g. company Vision + product-UI Architecture) → Fail; a single ambiguous layer → Warn. | references/validation-heuristics.md#scope-homogeneity (primary); ../../references/layer-definitions.md (per-scope identifying signals) |
| 3 | Vision falsification triggers | If a Vision is present, it names observable + bounded + owned revision triggers. No triggers at all → Fail; present-but-vague/unowned → Warn. (Skip if no Vision present.) | references/validation-heuristics.md#falsification-triggers |
| 4 | Composition framework completeness | If product-scope Architecture is present, it contains all four sub-elements (skill library, interfaces, invariants, implementations) AND splits invariants from implementations. Partial → Warn; absent (Architecture claimed but framework empty/hand-wavy) → Fail; invariants tier populated with substrate-coupled specifics (models/prompts/tunings) → AP-04. Non-product scopes adapt to org capabilities / process building blocks. (Skip if no Architecture present.) | references/validation-heuristics.md#composition-completeness (primary); ../../references/vast-essentials.md (invariants/implementations split); ../../references/anti-patterns.md (#10 AP-04 implementation-as-invariant) |
| 5 | Challenge Flow respect | If cross-layer interactions are described, they follow: Vision challenges Architecture (only downward challenge right); Strategy informs Architecture (never overrides); Architecture self-corrects; Tactics escalates. Violations (esp. Strategy overriding Architecture) → Fail. Passes by default if no cross-layer interactions described. | references/validation-heuristics.md#challenge-flow (primary); ../../references/anti-patterns.md (#8 Strategy challenging Architecture) |
| 6 | Kernel floor (ownership) | Each present layer names ONE accountable owner (one neck) — not a committee, "the team", or "TBD". Ownerless/committee-owned layer → Fail (AP-09); a doc that names no owners and doesn't claim "VAST applied" → Warn. Also reads the floor as a whole (ownership + Architecture-before-Strategy + Vision-falsifiable + invariants/implementations); below the floor = VAST vocabulary, not applied. | references/validation-heuristics.md#kernel-floor (primary); ../../references/anti-patterns.md (#11 AP-09 ownerless layers) |
Check numbers above are stable identifiers, not an execution order. The Process runs scope+layers → purity → scope homogeneity → falsification → composition → Challenge Flow → ownership; the report groups findings by severity. Reference checks by name (e.g. "Layer purity"), not by number, in the report.
Produce a markdown report with this exact structure:
# VAST Validation Report — {doc title or filename}
**Scope detected:** company | product | function | WoW | mixed
**Layers present:** {V / A / S / T — which of the four appear}
## ✅ Pass
- {layer or quote} — {check name} — {brief evidence}
## ⚠️ Warn
- {layer or quote} — {check name}: {what's borderline} — {suggested reframe}
## 🚨 Fail
- {layer or quote} — {check name}: {why fails} — {evidence quote} — {suggested fix}
## Summary
{1-3 sentences: overall state, whether the Kernel floor holds, top 1-2 fixes recommended.}
If a severity section has no items, write - (none) under it — keep all three sections present so report structure is identical across clean and flagged docs. Checks that are skipped (e.g. falsification when no Vision present, composition when no Architecture present) do not appear in the report at all — only checks that actually ran produce Pass/Warn/Fail lines.
See:
../../examples/04-vast-clean/ — well-formed product-scope V/A/S/T, no findings expected../../examples/05-vast-layer-impure/ — Vision-as-feature-list + Architecture-as-project-plan, expect layer-purity / falsification / composition fails../../examples/06-vast-scope-mixed/ — company-level Vision + product-UI Architecture, expect scope-homogeneity + layer-purity + falsification fails