ワンクリックでManusで任意のスキルを実行

vast-validate

スター2

フォーク0

更新日2026年5月24日 19:21

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", "проверь

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

dkushnikov

dkushnikov/vast-framework

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

関連職種SOC

SOC 職業分類に基づく

マネジメントアナリストビジネス・金融業務職·SOC 13-1111

ファイルエクスプローラー

2 ファイル

SKILL.md

readonly

このリポジトリの他の Skills

同じリポジトリ

vast-connect

dkushnikov/vast-framework

Verify that a child VAST doc genuinely cascades from its parent — that a product VAST nested under a company VAST (or a component VAST under a product VAST) is actually VAST-connected, not two unrelated docs wearing the same vocabulary. Checks scope step-down (child one recursion level narrower than parent), Vision lineage (child Vision refines / serves a parent Strategy use-case or Architecture domain), invariant inheritance (the core Matryoshka condition — child Architecture operates WITHIN parent invariants, never violates one), cross-doc Challenge Flow (child informs parent upward, parent constrains child downward — no inversions), and Strategy alignment (child invests with, not against, the parent direction). Use this WHENEVER someone has TWO VAST docs in a parent/child or nested relationship and wants to know whether they actually fit together, cascade, or cohere — EVEN IF they never say "VAST" or "Matryoshka". Tracing whether a child honors a parent invariant is exactly what this skill does better than

2026-05-242

vast-draft

dkushnikov/vast-framework

Scaffold a NEW VAST document from a minimal seed — a scope plus a sentence or two about an initiative — guiding the author through the four layers in commitment-priority order (Vision → Architecture → Strategy → Tactics). Generative, like vast-transform, but the input is near-empty rather than rich prose: the output is a SCAFFOLD (guiding questions + what-good-looks-like + fillable stubs), not a filled doc. Where the seed is silent it provides the question to answer, never an invented answer. Prompts for Vision falsification triggers and recommends composition depth. Use this WHENEVER someone wants to START a VAST doc and has only an idea plus a scope — EVEN IF they never say "VAST", e.g. "help me lay out a V/A/S/T for this", "give me the structure to fill in". Producing a commitment-ordered scaffold (and refusing to fabricate answers the seed did not give) is what this skill does better than a blank template, so reach for it. Triggers: "draft a VAST", "scaffold a VAST doc", "start a VAST for", "new VAST from

2026-05-242

vast-okr-audit

dkushnikov/vast-framework

Audit an EXISTING set of OKRs (objectives and key results that are already written) for VAST-triad conflation — objectives that are really Outputs (a project or feature like 'ship the new billing system' dressed up as an outcome), key results that fuse two layers (a strategy-level Use Case and a measurable Output crammed into one KR), and scope inconsistency (company-level and team-level objectives in the same set). Use this skill WHENEVER someone hands you OKRs — freshly drafted, in-progress, or finalized — and wants them checked, sanity-checked, sense-checked, reviewed for structure, or asks whether the objectives are genuine outcomes versus relabeled projects, whether the set is 'clean', or whether the objectives and key results sit at the right level — EVEN IF they never say 'VAST', 'conflation', or 'audit'. Reviewing OKR structure by hand is exactly what this skill does better than ad-hoc reading: it applies fixed structural heuristics and returns a per-OKR Pass/Warn/Fail report, so reach for it rather t

2026-05-242

vast-transform

dkushnikov/vast-framework

Transform an abstract or prose description of a project, system, or initiative (NOT yet in VAST shape) into a VAST-shaped draft — extracting the latent Vision (or flagging its absence), mapping the rest to Architecture/Strategy/Tactics, and recommending composition depth. Generative, not analytical: it produces a proposed VAST document, it does not score one. Use this WHENEVER someone has raw prose (a pitch, a project brief, a backlog narrative, a strategy memo) and wants it reshaped, restructured, or re-expressed in VAST terms — EVEN IF they never say "VAST" by name, e.g. "put this in V/A/S/T terms", "what is the Vision/Architecture here", "structure this the way the framework would". Reshaping prose into clean layers (and honestly flagging a missing Vision instead of inventing one) is what this skill does better than freehand rewriting, so reach for it. Triggers: "transform this into VAST", "make this VAST-shaped", "extract the VAST from this", "VAST-ify this", "переведи в VAST". Not for scoring a doc alrea

2026-05-242

name

vast-validate

description

vast-validate

When to use

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:

"Validate this VAST doc"
"Is this layer pure?"
"Check the VAST shape of this"
"Проверь VAST"
"Does this Vision hold up?"

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.

VAST recap (condensed)

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.

Process

For the doc under review:

Identify scope + layers present — which of company / product / function / WoW does this doc operate at, and which of V/A/S/T are present? (Scope signals: references/validation-heuristics.md#scope-homogeneity; the full per-scope signal lists are in ../../references/layer-definitions.md.)
Run layer purity per present layer — does each layer's content match its level, or has it drifted up/down? (See references/validation-heuristics.md#layer-purity.)
Check scope homogeneity across layers — do all present layers operate at the same scope, or is e.g. a company Vision paired with product-UI Architecture? (See references/validation-heuristics.md#scope-homogeneity.)
Check Vision falsification triggers — if a Vision is present, does it name observable, bounded, owned revision triggers? (Only when Vision present. See references/validation-heuristics.md#falsification-triggers.)
Check composition framework completeness — if the doc is product-scope and has an Architecture, does it contain all four sub-elements and the invariants-vs-implementations split? (Only when product Architecture present; adapt for non-product scopes. See references/validation-heuristics.md#composition-completeness.)
Check Challenge Flow respect — if the doc describes cross-layer interactions, do they follow the rules (Vision challenges, Strategy informs, Architecture self-corrects, Tactics escalates)? (Passes by default if no cross-layer interactions described. See references/validation-heuristics.md#challenge-flow.)
Check layer ownership (Kernel floor) — does each present layer name one accountable owner, not a committee / "the team" / "TBD"? This reads the Kernel floor as a whole (ownership + the rules the checks above already cover). (See references/validation-heuristics.md#kernel-floor.)
Generate report per Output format below.

Checks

#	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.

Output format

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.

Examples

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