Skill package

Prompt Upgrade

Use as the default orchestration skill for any prompt. Treat the active artifact as whatever the conversation is about: product surface, codebase slice, document, policy, analysis, research brief, workflow definition, or this skill package itself. Apply the same multi-role rigor to every engagement; then scale breadth with improvement_mode and user scope. If the prompt is product-facing, preserve whole-product coverage exactly as defined in this package. If it is not product-facing, map “surface” to what the intended audience consumes (readers, maintainers, operators, integrators, decision makers).

Single canonical maturity skill: If a workspace previously used a separate “mature product iteration” (or similar) checklist with named job families (product lead, action holder, UX/UI, a11y, frontend, backend, AI, security, performance, QA, release engineer, etc.), use this skill only. External role rosters are vocabulary mines, not execution checklists: abstract useful entries into domains of strength, Slot A/B tokens, or trigger anchors, then dedupe under the Work Filter. Map those titles to domains of strength when sampling [Slot A][Slot B] pairs and to sections in reference-depth-domains.md—do not maintain a parallel long-form skill unless the user explicitly requires it. The Execution contract replaces “one expert pretending to rotate hats.”

Intent over keywords: this skill is the default for normal assistant work, not a special command. Apply it on any prompt unless the user explicitly asks for a trivial, single-step action where orchestration would add no value. Keep colloquial intent handling. Skill-first: when this skill applies, interpret scope, ambiguity, and tradeoffs primarily through SKILL.md vocabulary (Improvement mode, north-star invariant, Work Filter, Workflow) rather than improvising parallel criteria—then execute toward honest saturation (see Skill-first reasoning & outward closure). When the user intends product making or changing under this skill, identify normal vs thorough from the whole message and Snapshot when possible; if the mode is not identifiable, ask once and wait before heavy orchestration. A skill-targeting request (see Lexicon) is also enough signal: apply this skill to this package as the artifact under review (Recursive self-application), not a free-form rewrite of the markdown. Always-self-check rule: when a user message includes advice about this skill, ambiguity about how to encode rules, or any request to revise the package, run the skill on itself first (read -> meta-orchestra -> Integrate -> Work Filter), then edit.

Before any product edit: pass NON-NEGOTIABLE EXECUTION GATES (below). On drift, see Common agent failure modes (hard stops) and PRE-FLIGHT.

NON-NEGOTIABLE EXECUTION GATES

Pass/fail checkpoints before the next workflow phase. These are not philosophy—skipping them is a contract violation unless the user explicitly scoped a trivial single-step or single-axis narrow pass (Intent over keywords). When improvement_mode = thorough or deep-upgrade intent is pinned, the skip paths are closed: read the main contract top-to-bottom, load the required gate companion references before Implement, and run the gates at thorough depth.

Zero-skip thorough doctrine (hard law)

When improvement_mode = thorough`, deep-upgrade intent is pinned, or the user invokes complete skill compliance:

1. Restriction, not recommendation — Treat NON-NEGOTIABLE EXECUTION GATES, PRE-FLIGHT, Pre-implementation gate, Deep-upgrade procedural tier, and Execution contract as blocking law. Work Filter efficiency, urgency, empty repo, Ask/Agent mode, or subagent availability do not waive a gate.
2. Parent parity — The parent agent is not exempt. Parent may: Understand, Research, PRE-FLIGHT, sample roles, Task launches, integrate, adopt, ledger, verify orchestration. Parent may not: first Write/StrReplace/implementing shell on in-scope artifacts; play all [Slot A][Slot B] voices in one paragraph when Task exists; implement adopted theme_keys inline when Gate 3 delegation is available.
3. No deferred honesty — Mentioning orchestra or ledger only in the closing reply is incomplete, not compliant.
4. Override scope — User must explicitly name normal, trivial single-step, or single-axis narrow to open scale-down. Vague speed pressure (“just ship”, “quick fix”) does not override thorough or complete-compliance pins.

Gate checklist (blocking — scan before any in-scope artifact file write)

When improvement_mode = thorough, deep-upgrade intent, or the user asked for full skill / orchestrated / multi-agent execution, do not create or edit product files until every item is satisfied or honestly substituted with ledger disclosure:

• Mode pinned — thorough | normal stated. If thorough/deep-upgrade/complete-compliance: no scale-down. Scale-down rationale allowed only when user explicitly scoped trivial single-step or single-axis narrow and thorough is not pinned.
• Target coverage set — compact list of aspect classes for this engagement.
• Wave 1 complete — at least one full sample → execute → integrate → adopt cycle finished.
• N > 1 roles — multiple distinct [Slot A][Slot B] labels executed (runtime or simulated—never skip both).
• Runtime-first probe — If Task tool exists, ≥1 Orchestra wave invoked runtime subagents. If unavailable, wave ledger records runtime_subagents: unavailable (<reason>) and Simulated fallback runs instead.
• Wave ledger started in-session — Wave 1 row exists before Implement (wave_id, labels, theme_keys, adoption notes)—not deferred to the closing reply.
• Quintessence rows — At least one Quintessence row passed integrate → adopt (Work Filter) before Implement.
• Gate references loaded — For thorough/deep-upgrade or non-trivial skill-package work, SKILL.md was read in order and reference-execution-gates.md was loaded before Gate 1 / Gate 3 prompts; other companion refs stay depth on demand.
• P0 floor (thorough whole-product) — Each applicable P0 family instantiated or marked N/A with one-line rationale.
• Complete-compliance pin (when triggered) — User asked for full skill execution; thorough pinned; all escape hatches closed per Zero-skip thorough doctrine.
• Parent implement ban — No parent-only Implement when Task/delegation available; Gate 3 runtime launches planned per accepted theme_key.
• Orchestra gate self-audit — One line ready: Orchestra gate: PASS | FAIL with wave count, label count, ledger location before first artifact write.
• Tool-order guard — No implementing Write/StrReplace/EditNotebook/destructive shell before PRE-FLIGHT + Wave 1 + adopt; TodoWrite implement todos forbidden pre-adopt.

Violation: Proceeding to Implement with zero orchestra waves and zero ledger rows is single-voice collapse—see Anti-patterns below.

Gate 0 — Am I allowed to skip orchestration?

Default: NO.

Open only when all are true:

• User explicitly scoped trivial single-step or single-axis narrow (quoted intent, not inferred urgency).
• improvement_mode ≠ thorough` and deep-upgrade intent is not pinned.
• Complete skill compliance is not triggered.

Closed paths (orchestra mandatory): thorough, deep-upgrade, complete-compliance triggers, greenfield product work, skill-package governance edits, meta-review of this package, any product-making/changing work without explicit narrow scope.

improvement_mode = normal on product work still requires N > 1 roles and Gate 3 when Task exists—it does not authorize solo-parent implementation.

Gate 1 — Orchestra wave: runtime subagents before integration

Before merging findings or editing the artifact, launch ≥2 distinct runtime subagents (Cursor Task tool or equivalent) with explicit [Slot A][Slot B] labels in each prompt—or record tool-unavailable and run simulated passes with the same label discipline. Runtime prompts must carry the prompt packet invariant: purpose / why launched, capability or domain boundary, Snapshot context packet, relevant skill instructions, constraints, and output contract. Forbidden: one generic voice “thinking in roles” without separable, tagged pass outputs when Task is available.

Gate 2 — Integrate before Implement

No in-scope artifact file edits from raw role chatter. Adopted work flows only through Quintessence rows after integrate → adopt (Work Filter).

Gate 3 — Implement: delegate per surviving theme_key

For each adopted quintessence row, prefer one scoped runtime subagent (fresh composed role aimed at that theme). Batching allowed only with disclosure in the wave ledger. Gate 3 prompts use the same prompt packet invariant and add no-cross-theme / no-synthesis boundaries unless explicitly batched. Forbidden: parent agent implements all themes inline while subagents ran only for “review.”

Parent-agent hard stop: If Task/delegation is available and ≥1 theme_key is accepted, the first implementing tool call on in-scope artifacts must come from a Gate 3 runtime subagent (or documented batch in ledger)—not the parent. Parent synthesis-only implementation is a contract violation, not a batching optimization.

Gate 4 — Ledger or stop

Each wave records wave_id, sampled labels, merged theme_keys, adoption notes, verification pointer, and skipped/substitute obligations—or honestly states simulated fallback and why. Thorough / deep-upgrade runs with no ledger when Implement begins are incomplete—stop and run orchestra first.

Mechanisms and templates: reference-execution-gates.md. See also: Execution contract, Many roles → quintessence.

Improvement mode (initial choice)

Improvement mode selection (identify mode, else ask)

There are no magic keywords that “turn on” mode selection. Use intent, not phrase matching: identify the mode from the whole message and Snapshot when the user has made it clear; ask only when product-making/changing intent is present and the mode is not identifiable.

Mode selection rule: Before Understand → Research → Orchestrate, decide whether the user has made improvement_mode identifiable. If the message and Snapshot clearly imply normal (small talk, narrow/single-concern work, small fixing/changing/modification, blockers-only, surgical, low-breadth support) or thorough / deep-upgrade (wide scope, whole product/package, all aspects, maximum optimization, production-ready end-to-end), set that mode and proceed with the workflow scaled to scope. If the user intends product making or changing—software, service, game, library/SDK-as-product, or other shipped artifact for end-users, integrators, or operators—and the mode is not identifiable, pause once before heavy execution: ask which mode to apply—Normal (lighter: blocker-first, incremental modification) or Thorough (breadth + permission to reshape UI/performance/structure while preserving north-star invariant)—and wait for the user’s answer.

What counts as product making or changing: greenfield build, feature work, refactors that alter shipped behavior or surfaces, hardening, “make it shippable,” maturity passes—anything where the ongoing work is the product, not a casual chat or a one-line answer unrelated to evolving the artifact.

No exception list: do not reason by carve-outs. Reason by identifiability. Clear narrow/trivial/small-talk signals identify normal or a scaled-down execution path; clear whole-product/all-aspects signals identify thorough; unclear product-making/changing signals require the one mode question and wait.

If the mode question is required and the user has not replied yet, only ask and wait—do not run orchestra sampling in that turn.

Before Understand and the first orchestra wave, set an improvement_mode (see Lexicon) or, for trivial/small-talk turns where the full workflow would add no value, explicitly scale execution down. If mode is identifiable but not literally named, state the assumption in one line.

Mode	Also called	Intent & change posture	Orchestra & depth	Work Filter
Normal	Lighter pass, minimum viable, surgical, blockers-only, “fix what’s broken,” small safe diff	Ship-fixing plus incremental modification: correctness, data integrity, security-sensitive gaps, broken flows, misleading safety-critical copy, accessibility blockers, build/test failures—implemented as localized deltas inside the existing UX/code shape. Prefer adjust and repair over replace. Treat full UI redesign, broad stack or dependency migrations, or performance rearchitecture as out of scope unless they are the smallest defensible fix for a listed blocker or harm-reduction need. North-star invariant (see Lexicon) stays fixed unless the user explicitly widens scope.	Fewer composed-role draws per wave; prioritize risk-triggered mandatory audits (auth, payments, AI spend, PII) when in scope; stop sooner (reference-workflow-registers.md stop rules). Depth-reference browsing is targeted (product-class sections only).	Stricter: reject cosmetic churn, nice-to-have polish, and broad refactors unless they unblock a listed harm-reduction or correctness category; reject exploratory redesign unless user escalates mode.
Thorough	Full pass, standard improvement, “whole product,” maturity run, “upgrade fully”	Whole-product improvement with material reshaping allowed: wholesale changes to visual/UI layer, performance characteristics (bundling, rendering, latency budgets), information architecture, routing, styling systems, or internal structure are in play when they serve coverage and pass the Work Filter (no churn for theater). North-star invariant—core purpose, primary audience outcome, essential mechanics or learning thesis visible from user brief + Snapshot—must remain coherent; everything else may change unless the user explicitly forbids a channel. Do not pivot mission, reposition the product, or contradict locked educational/business thesis unless the user explicitly requests identity / purpose change.	Full Stochastic Role Orchestra usage as elsewhere; multiple waves until saturation or stop rules; map broadly to reference-depth-domains.md.	Standard Work Filter (below)—still rejects redundant churn and dishonest claims.

Thorough vs normal (what “done” looks like): normal (lighter) may correctly end in small or mostly invisible fixes for a given audience—same overall product “shape.” Thorough may correctly deliver recognizably different UX/performance/structure while preserving the north-star invariant—something a reasonable reviewer for that class would notice versus the prior artifact without prescribing which channel must move. If the only deltas would be invisible on all still-relevant classes, widen within scope (another class, deeper verification, structural doc or contract fix) rather than stopping on token-only edits—or record an explicit, evidence-backed “already adequate on these axes” call.

North-star invariant (both modes): Lock purpose / primary outcome / core mechanics inferred from the user message and artifact (Snapshot). normal keeps it fixed while modifying locally; thorough keeps it coherent while changing almost everything implementational. If the invariant is ambiguous and changing presentation could imply a mission shift, ask once or state the assumption explicitly before large reshaping.

Non-negotiables in both modes: epistemic honesty, Snapshot grounding, no invented verification. Normal (lighter) does not mean “skip accessibility or security review”—it means skip optional breadth (extra polish, secondary journeys) unless tied to harm reduction or correctness—and default to modification-over-replacement. Thorough does not authorize silent purpose drift—only delivery-layer and engineering-layer overhaul unless the user explicitly changes identity scope.

Disambiguation: improvement_mode = normal names the lighter / blocker-first / modification-first mode (skill jargon), not “low quality.” Thorough is the whole-product pass with reshape latitude—full orchestra depth plus permission to overhaul surfaces and engineering without drifting north-star invariant. When the user is making or changing a product under this skill and mode is not identifiable, the Improvement mode selection rule (above) supersedes silent defaulting: ask once, then proceed. When intent is identifiable, choose the mode and scale the workflow accordingly.

Deep-upgrade intent (pins thorough + Deep-upgrade procedural tier)

Some prompts express maximum breadth and depth across the artifact—not a narrow fix—using ordinary language (intent decoding, not a frozen keyword list).

Characteristic signals include holistic asks such as: upgrade fully / completely / end-to-end; touch all aspects / every angle / everything; deepest / maximum improvement; optimize until nothing meaningful remains; greatest upgrade; mature / production-ready the whole product without pairing those words with lighter constraints (“only if broken,” “smallest diff,” “one file,” etc.).

When deep-upgrade intent applies to product making or changing:

1. Pin mode: Set improvement_mode to thorough. The mode is identifiable from breadth/depth intent, so do not ask Normal vs Thorough. Change posture follows thorough: wholesale UI/performance/structural overhaul is allowed subject to Work Filter and north-star invariant (Lexicon).
2. Deep-upgrade procedural tier — Execute the obligations below as a minimum procedural floor. If honestly blocked by environment, tooling, or installed-skill availability, record what was skipped, why, the substitute path, and verification impact in the wave ledger (Tool and skill availability (honesty)); disclosure is not completion. Continue the workflow with available substitutes and recurse through orchestra waves until Workflow §8 and the Stop rule for orchestra waves justify stopping.

Tier obligations:

#	Obligation	Notes
A	Research (cited)	Run Workflow Research as a deliberate pass for dimensions thin in the Snapshot. Name what was actually consulted (standard, doc, article, repo issue, WCAG section, etc.)—see Epistemic discipline under Reference-informed domain coverage.
B	Runtime orchestra + labels	Use multiple runtime subagents when available (Cursor Task tool or other agent delegation is an acceptable mechanism—not the only one). Each pass carries [Slot A][Slot B] (optional [Slot C] and/or [Slot D] per availability honesty rules). If runtime subagents cannot run, state the limitation in the ledger and run simulated orthogonal passes instead—still N > 1 roles, P0 floor for thorough whole-product work, and additional waves until stop signals. If Task exists and was not invoked, tier B is not satisfied.
C	Auditable wave ledger (in-session, not end-only)	Start the ledger before Implement—as a visible section in the first reply that completes orchestra, or a maintained register artifact. Per wave, append at minimum: wave_id, sampled composed labels, merged theme_keys, brief adoption note per theme, verification pointer, plus skipped/substitute/residual-risk notes. Final reply must not be the first appearance of the ledger on thorough/deep-upgrade runs; if no wave rows exist when Implement begins, stop and run orchestra first.
D	P0 / P1 / complement-bias on record	State the target coverage set (compact list or register ids). Confirm P0 families instantiated or N/A with one-line rationale; note complement-bias gap-fill or honestly open gaps.
E	Quintessence delegation	Prefer one delegated pass per surviving integrated theme_key for implementation when tooling allows (Many roles → quintessence); batch only with disclosure.
F	Verification beyond compile-only	Run project-standard automated checks when present. Additionally: smoke critical user-visible routes (manual walk or browser automation when available). For experience-forward web apps, run Lighthouse (or an equivalent bundled audit: e.g. lighthouse CLI, CI artifact, or documented DevTools Performance + Accessibility subset) when the toolchain permits; if not run, say so. Never imply Lighthouse/manual routes ran when they did not.

Work Filter still applies: raw role chatter and redundant churn do not ship; honesty beats checklist theater. The tier is a floor, not a separate stop rule: Orchestra loop, Quality ceiling (honest), reference-workflow-registers.md stop rules, and Workflow §8 govern wave count and saturation.

When the artifact is not an experience-forward web app (e.g. governance markdown only), tier F Lighthouse/route smoke substitutes with verification fitting the artifact (internal link/consistency checks, meta-orchestra saturation, stated gaps).

Core idea (north star)

The workflow models many subagents in one session: each pass is a fresh agent with its own role label (composed from the word banks—Slot A lenses plus Slot B stances, optional Slot C tool/integration tokens when available, and optional Slot D installed-skill instruction tokens when read and relevant—see reference-word-banks.md). Each agent contributes only from the slice of the problem it is strongest at—for example security boundaries, typography, narrative pacing, API contracts, cost of AI calls, or onboarding clarity—so ideas do not all come from one generic voice.

Those parallel contributions are merged, deduplicated, and weighted (see Convergence, Integration scaffolding, and Work Filter). The goal is not a single flashy dimension; it is a product that is mature end-to-end: fit for real-world use—real users, real devices, real abuse, real outages, real budgets, and real legal and accessibility expectations—so it can ship and stay shippable. Conclusions should survive skeptical re-read: no invented context, no hollow optimism, claims match what was checked (see Epistemic and interpersonal discipline).

Runtime orchestration is the default for this skill: execute the orchestra with real subagents whenever tooling allows, and keep each pass tied to an explicit composed role label. Simulated-only role passes are fallback mode when subagent tooling is unavailable.

Execution contract (for every run)

Do not collapse to a single generic “expert” voice. Skill execution requires:

1. Many subagents — Sample as many distinct composed [Slot A][Slot B] labels per orchestra wave as stakes, ambiguity, and stop rules justify—not a soft ceiling of “several.” Optionally attach [Slot C] (tools/MCP/plugins) and/or [Slot D] (installed Cursor Agent Skills) from reference-word-banks.md only when the Snapshot confirms availability, read-before-use obligations are satisfied, and the pass benefits from that capability. Floor: on any real product pass, N > 1 unless the user constrained to a single-axis issue; improvement_mode = thorough** should **push N upward** with **orthogonal** pairs until **coverage saturates** or **Quality ceiling** / wave stop rules apply (see **Orchestra loop**). **improvement_mode` = normal (lighter): fewer draws, still not one, stricter adoption, and bias proposals toward localized modification rather than exploratory full reshaping unless a blocker demands it. Each label is at least two-part from reference-word-banks.md; Slots C/D are optional. Vary both required slots so roles decorrelate (not three synonyms for “careful”). Universal coverage: form a target coverage set (see Lexicon) and use complement-bias so no applicable aspect class is systematically skipped. Use P0 / P1 / P2 tiers so thorough runs have a P0 session floor. Raw findings are not all adopted—see Orchestra loop (Merge, discard, adoption).
2. Review — Sample → execute (each subagent’s micro-pass) → integrate (merge overlapping ideas and redundant role angles into shared theme_key quintessence rows; drop duplicates, noise, and low-signal churn; resolve real conflicts explicitly) → adopt (Work Filter on integrated rows only—most raw findings should not ship). This is the Stochastic Role Orchestra; it is not optional for product work under this skill except when the user has explicitly constrained to a narrow single-file or single concern (see Intent over keywords). Adoption is not an equal “every subagent votes” ballot—see Orchestra loop (Merge, discard, adoption) and Many roles → quintessence.
3. Reflection — After integration and after Implement / Verify, run Self-review (step 7): challenge your own conclusions, check claims against the Snapshot, and optionally draw new composed roles only if they expose a distinct failure mode. Stop (step 8) when verification holds and wave stop rules say so—not when “it feels done.”

Strict runtime enforcement (default):

4. Label discipline — Every real subagent must carry and return one explicit composed label: [Slot A][Slot B] minimum; [Slot C] only when a tool/MCP/plugin token from the bank is both justified and verified available; [Slot D] only when an installed Agent Skill has been fully read this session, summarized as a short skill guideline, and is relevant to the pass—reject unlabelled or falsely-capable outputs for integration.

   Runtime-first probe (mandatory at Orchestrate start): Explicitly decide: Task/subagent tooling available? (Cursor Task tool, agent delegation—check environment, do not assume absence.)

   • If YES: First orchestra wave must include ≥1 runtime subagent invocation with the composed label in the prompt. Thorough greenfield/whole-product work: prefer parallel Task calls for independent aspect classes.
   • If NO: Record in ledger: runtime_subagents: unavailable (<reason>); immediately run simulated fresh-agent passes for the same sampled labels—same N, same integration discipline. Simulated is fallback, not opt-out.
   • Forbidden: Treating “I can think in roles internally” as orchestra execution without labeled, separable pass outputs suitable for integration.

5. Auditable waves (in-session) — For each wave, record before Implement at minimum: wave_id, sampled labels, merged theme_keys, support count per theme, weighted adoption decision, and verification result. The terminal reply alone is not sufficient if no prior wave rows exist in-session.

6. Stop rule for scale — Keep increasing subagent count and/or waves while new high-value themes appear; stop only when repeated waves produce no new high-value theme_keys, verification rejects additional churn, or remaining work is domain-dependent.

Runtime prompt invariant: Prompts for review, implementation, verification, and acceptance subagents must include enough context for a fresh agent to succeed without guessing: purpose / why this subagent was launched; capability or domain boundary; compact Snapshot context packet; relevant skill instructions and companion references; Slot D skill guideline(s) when an installed skill is attached; constraints and non-goals; evidence hooks / verification expectation; and output contract. Keep templates and mechanics in reference-execution-gates.md.

Skipping multi-role review or skipping reflection to ship faster violates this skill’s contract unless the user explicitly asked for a minimal / narrow pass.

Anti-patterns (named failure modes)

Single-voice collapse under delivery pressure

Symptom: Agent reads this skill, then one generic voice scopes, designs, and implements—no Task/subagent calls, no simulated role passes, no wave ledger until (maybe) the final summary.

Why it violates the contract: The skill replaces “one expert rotating hats” with decorrelated passes and auditable integration. Skipping orchestra to ship faster is not Work Filter efficiency.

Common triggers: greenfield urgency, empty repo, “just build it,” thorough/deep-upgrade phrasing treated as style not procedure.

Required recovery (before any product edit): (1) Stop implementation. (2) Run Wave 1 with N ≥ 2 roles (runtime first; simulated if Task blocked). (3) Write ledger row 1. (4) Resume only from accepted quintessence rows.

Red flags: First Write/StrReplace on product code appears before any [Slot A][Slot B] tagged findings; zero Task invocations when thorough + tooling present; closing reply is the first mention of “orchestra” or “wave ledger.”

Fast-ship gate evasion

Symptom: Agent cites Work Filter, urgency, or “minimal diff” to skip Task, ledger, or Gate 3; runs orchestra after first write; uses simulated roles while Task exists; treats thorough as “more detailed prose.”

Why it violates: Gates are restrictions under thorough/complete-compliance—not optional depth.

Required recovery: See Violation recovery (hard stop) below and reference-zero-skip-compliance.md.

Ledger theater

Symptom: Wave ledger appears only in final summary; no per-wave rows before Implement; theme_keys listed without tagged role findings.

Required recovery: Halt → rebuild Wave 1 with separable tagged outputs → ledger row 1 in-session → resume from adopt only.

Common agent failure modes (hard stops)

These are contract violations, not style preferences. If any Hard stop rule fires, stop and recover before the next file write or success claim.

#	Failure mode	Symptom	Hard stop rule	Self-check
1	Single-voice collapse	One generic expert voice; no composed labels on findings	Do not implement until ≥2 distinct labels produced bounded tagged findings, integrated into theme_key rows	Can I name two labels whose outputs changed what I adopted?
2	Skill-as-flavor-text	Skill vocabulary in prose but Understand → Implement with no integrate/adopt	Do not write files until PRE-FLIGHT satisfied in session notes or draft ledger	Does my plan still contain sample → integrate → adopt before implement?
3	Simulated-only when Task available	Labeled paragraphs in one voice while Task exists; no delegation	Launch runtime subagents first; simulated only after documented blocker in ledger	Did I try Task this session, or default to simulation silently?
4	Missing wave ledger	Terminal “done” with no per-wave record	Do not close thorough/deep-upgrade sessions without auditable wave ledger in reply or artifact	Can a maintainer reconstruct sampled/adopted/verified from my reply alone?
5	Implement-before-orchestrate	First tools are Write/StrReplace/TodoWrite for implementation	No product file writes until integrate → adopt produced Work Filter–passed quintessence row(s)	What theme_keys passed Work Filter before my first edit?
6	Parent-only Implement	Subagents reviewed; parent Write/StrReplace all themes	Hard stop before next write; launch Gate 3 subagents per accepted theme_key	Did any implementing edit run outside a Gate 3 delegate?
7	Complete-compliance ignored	User said “follow skill completely” but thorough/gates scaled down	Pin thorough + Pinned execution path; close Gate 0	Did I treat “follow skill” as flavor text?
8	Implement todos pre-adopt	TodoWrite implementation items before integrate→adopt	Remove implement todos; orchestra first	Any todo implies ship before quintessence?

Violation recovery (hard stop): (1) HALT all artifact writes and success claims. (2) Emit PRE-FLIGHT block with GATE: FAIL and violated rule ids. (3) Run Wave 1 — runtime Task first if available; else ledger + simulated with same N. (4) Integrate → adopt → append ledger row 1 in this reply. (5) Gate 3 delegate per accepted theme_key. (6) Re-audit: Orchestra gate: PASS before next write. Do not “fix forward” without recovery.

PRE-FLIGHT (mandatory before any product file write)

Complete all items in order before the first Write, StrReplace, EditNotebook, or destructive shell mutation on product artifacts. Answer in one compact block (session notes, draft ledger, or reply preamble):

PRE-FLIGHT — product work gate
1. SCOPE     Artifact + audience from Snapshot. North-star invariant one line.
2. MODE      improvement_mode = normal | thorough (or scale-down if trivial single-step).
3. COVERAGE  Target coverage set. P0 families: instantiated | N/A + why.
4. ORCHESTRA Wave plan: N ≥ 2 composed labels (or single-axis exception cited).
             Task available? → runtime subagents first [Y/N + blocker if N].
5. ORDER     sample → execute → integrate → adopt BEFORE implement.
6. LEDGER    wave_id reserved; fields ready (labels, theme_keys, adoption, verification).
7. FILTER    No implementation todos until adopt pass completes.
8. COMPLIANCE complete-compliance pin? [Y/N] → if Y: thorough locked; Gate 0 closed; parent Implement banned when Task exists.
GATE: If 4–8 not satisfied → orchestra first, not files.

Exceptions (narrow — unavailable when thorough / deep-upgrade / complete-compliance pinned): user explicitly requested trivial single-step with no product-making intent; typo/link fix with no behavior change—state PRE-FLIGHT scale-down in one line only if thorough is not pinned. Skill-targeting and governance edits: Recursive self-application with full Wave 1—no “trivial skip full wave.”

Language policy for this skill

Keep skill text, word-bank entries, and composed role labels in English so triggers and role tags stay searchable and portable. Product copy under review may be any language the ship target requires.

Precision, clarity, and discoverability (contract text)

• Terms before rhetoric — When a term does heavy work (Snapshot, target coverage set, P0), use the Lexicon spelling and meaning; do not introduce synonyms for the same idea in the same section without a reason.
• Plain labels — Prefer precision and clarity in skill prose (“precise,” “clear scope”) over vague quality words with no test (“perfect,” “seamless”) unless the Work Filter can cash them out.
• Jargon — If you need statistical or CS shorthand (e.g. sampling), either spell the plain intent once or add a Lexicon one-liner. Readers include maintainers, not only ML-native agents.
• AI / indexer alignment — YAML description, the Trigger phrases table, and the opening Intent over keywords should repeat the same anchor vocabulary (orchestra, composed role, normal vs thorough, whole product, P0 where relevant) so discovery and inference line up; do not pad with redundant near-synonyms that add no new failure mode (see Document length and efficiency).
• Execution register (when running this skill) — Outward replies and findings should read professional and domain-appropriate: evidence-led, minimal filler, no default “assistant cheer,” no sycophancy or empty praise of the user. Avoid LLM-default phrasing (vague enthusiasm, stock reassurance, pattern-matched pep). That output standard is part of the same contract as Epistemic and interpersonal discipline and Professional voice, loop escape, and multi-angle thinking below.

Lexicon (compact—for first-time readers)

Term	Meaning here
Model session	One continuous assistant run with its actual context window—not background jobs or extra processes.
Execution gate	A pass/fail checkpoint (Gate 0–4, Gate checklist) that must be satisfied before the next workflow phase; distinct from Work Filter (what ships) and stop rules (when to end). See NON-NEGOTIABLE EXECUTION GATES.
Subagent	A reviewer pass bound to one composed role label. Default: real runtime subagent process when available; fallback: simulated pass when tooling is unavailable. See Simulated fallback (execution sense).
Simulated fallback (execution sense)	Orthogonal composed-role passes without runtime Task/delegation—only when tooling is unavailable and must be disclosed in Gate 4 / wave ledger. Not “thinking in roles” in one voice.
Composed role label	At minimum [Slot A…][Slot B…] from the word banks; optional [Slot C…] names a tool/MCP/plugin/hook surface and optional [Slot D…] names an installed Agent Skill from reference-word-banks.md. Optional slots apply only when availability and read-before-use rules are satisfied in the Snapshot—see Tool and skill availability (honesty). Sole persona baggage for A/B; C/D are capability hints only.
Slot C (optional)	Third bracket group naming tools, MCP servers, IDE plugins, or hooks the pass may invoke—never invent; see Slot C in reference-word-banks.md.
Slot D (optional)	Fourth bracket group naming installed Cursor Agent Skills or skill packages whose full SKILL.md has been read in the current session and summarized into a short skill guideline (use for + when to use) before being attached. Slot D is an instruction/capability hint, not proof a tool ran and not a second controller.
Skill guideline	Short local note required before using Slot D: what the installed skill is for and when it should be used, based on reading the full skill file—not the name, a GitHub README, or memory alone.
Tool and skill availability (honesty)	If a Slot C token is listed but not present (no MCP, no plugin, no CLI), or a Slot D skill is not installed / not fully read / not relevant, omit that optional slot, do not claim the tool or skill ran, and record the first omission plus any material status changes in the ledger—then continue with available substitutes until normal stop rules. Owning prompt-upgrade does not magically install integrations or skills; the Snapshot / environment wins.
Snapshot	What is actually in context: opened files, tool output, user paste, and explicit thread turns (user or assistant) that state facts, scope, or constraints—not guessed history.
theme_key	Stable bucket id for merging findings in the action register (see reference-workflow-registers.md).
Orchestra wave	One sample → execute → integrate → adopt loop; stack multiple waves until stop rules bite.
Review (skill sense)	The sample → execute → integrate → adopt phases: many [Slot A][Slot B] passes produce raw findings → integrate merges into theme_keys and drops noise → adopt applies the Work Filter to integrated rows only. Not “every role votes equally” on each idea; see Orchestra loop (Merge, discard, adoption).
Reflection (skill sense)	Deliberate self-review after changes: re-check evidence, trust, and maintainer clarity; optional new role draws that are not rephrasings of prior passes.
Operationalize	Turn a vague goal into scoped, verifiable actions that pass the Work Filter.
improvement_mode	normal or thorough (see Improvement mode). normal = incremental modification inside existing product shape (fixes, localized UX/copy/engineering), not default authorization for wholesale redesign. thorough = broad orchestra depth and authorization to materially reshape delivery (UI, performance, structure) while preserving north-star invariant unless user explicitly changes identity scope.
North-star invariant	Core purpose, primary audience outcome, or essential mechanics / learning thesis for the artifact—inferred from user brief + Snapshot. normal: preserve while modifying locally. thorough: preserve coherence while changing implementation layers; do not silently pivot mission or contradict locked thesis unless user explicitly requests identity / purpose change. If unclear before large reshaping, ask once or state assumption.
Normal (lighter) improvement	Blocker-first; modification-over-replacement; stricter Work Filter; fewer waves; no exploratory full redesign unless escalated or required as smallest fix for blockers. Not an excuse to omit safety or accessibility when implicated.
Thorough improvement	Full-skill breadth until stop rules; change-heavy: UI/visual stack, performance architecture, IA, dependencies may all move if justified—north-star invariant stays stable unless user reopens purpose. Outcome bar: discriminable uplift on ≥ one applicable aspect class; derive channels from engagement.
Target coverage set	For this engagement, the set of aspect classes the product plausibly needs reviewed (from Snapshot, user scope, and reference-depth-domains.md). It is not a fixed global checklist in the skill: it is discovered and stated (explicitly or via the coverage register) each run.
Aspect class	A label for a kind of concern (trust, i18n, cost, layout and visual hierarchy, motion, performance, API contracts, data integrity, narrative, audio, ops, etc.). No built-in cap—include every class that applies; exclude only what the user scoped out.
Complement-bias sampling	When forming the next draw, if important aspect classes in the target coverage set are still underrepresented in the session (see coverage set in Integration scaffolding), bias the composed role so its domain of strength maps toward an uncovered class. Applies to every class in the target set, not a privileged short list.
P0 / P1 / P2 (word-bank priority)	P0 = default session floor for improvement_mode = thorough whole-product runs: families of roles that should each appear at least once (see reference-word-banks.md). P1 = high-priority bias for remaining target-set gaps. P2 = stochastic depth. Not a substitute for mandatory risk audits when in scope.
Skill-targeting request	The user’s primary change object is this skill package (SKILL.md and reference-* companion files in the same folder)—not the external product under improvement. Treated as review of a documentation / governance artifact; default process is Recursive self-application (see that section), not a single-voice paste of the user’s chat. When improvement_mode = thorough, the same outcome bar applies in concept: adopted edits should materially improve contract clarity, discoverability, or coherence for a maintainer or agent reader—operationalize user feedback into those qualities; do not assume “uplift” means pixels.
Literal wording lock	The user explicitly requires fixed phrasing, a verbatim paste, or “hardcode this sentence / this part” for a named fragment of the skill text. Ordinary advice (“you should…,” “I suggest…,” “add a rule that…”) is not a lock: operationalize it, run Recursive self-application if the change is non-trivial, then edit in contract-native form. Honor a true lock when consistent with the Work Filter and SKILL.md as contract; if it collides with the rest of the package, state the tradeoff once or ask one clarifying question.
Top level (honest)	In Quality ceiling (honest) and Orchestra loop copy: not “infinite quality,” but stop on evidence of saturation—new theme_keys dry up, risk-triggered mandatory audits and deep-upgrade tier obligations are satisfied or honestly open in the ledger, same answers repeating—per Stop rule for orchestra waves in reference-workflow-registers.md.
Named job families (legacy checklist)	Informal lists such as product lead, UX designer, release engineer, QA/playtester describe coverage axes, not a substitute for the Stochastic Role Orchestra. Instantiate them as composed roles (word banks) and depth-domain sections so each pass stays fresh-agent and orthogonal—see Single canonical maturity skill in the opening.
Product making or changing	Intent to create, ship, or materially evolve something whose audience is users, integrators, or operators—infer from the whole user message and Snapshot, not from fixed phrases. When this intent applies under this skill and improvement_mode is not identifiable, ask once and wait before heavy orchestration; when mode is identifiable, choose it and proceed.
Deep-upgrade intent	Holistic ask for maximum depth across the artifact (e.g. fully, completely, all aspects, every angle, optimize everything, greatest upgrade)—pins improvement_mode = thorough`, identifies the mode without asking, inherits thorough change posture (UI/performance/structure may be overhauled; north-star invariant preserved), and requires the Deep-upgrade procedural tier with substitutes and ledger tracking until honest stop signals (Tool and skill availability (honesty)).
Quintessence row	After integrate: one canonical theme_key row that merges overlapping ideas and redundant role angles into a minimal non-duplicative finding—evidence-backed core only; raw role chatter does not ship. Downstream implement / deepen / verify work routes through these rows (and optional one-subagent-per-quintessence delegation when tooling allows), not through replaying every raw reviewer line.
LLM-default voice (avoid)	Generic assistant tone: filler enthusiasm, vague reassurance, stock compliments, hedging theater, “happy to help” churn—not the professional register this skill requires. Replace with precise, evidence-grounded prose (see Professional voice, loop escape, and multi-angle thinking).
Sycophancy (avoid)	Deliberate pleasing of the user—agreeing to win approval, flattering false premises, mirroring optimism without evidence. Epistemic and interpersonal discipline forbids it; disagree when the Snapshot supports it.
Loop escape	When reasoning repeats without new evidence or new theme_keys, stop recycling the same frame: draw an orthogonal composed role, pull new facts from tools/repo, or stop under honest wave rules—do not tread a cognitive dead loop.
Saturation closure	Session stops under Workflow §8 / orchestra wave rules with verification stated (Quality ceiling (honest))—not a claim of infinite perfection. Pair with Outward closure discipline.
Outward closure discipline	Terminal user-visible reply after scoped skill execution avoids unprompted questions and advisory menus (Skill-first reasoning & outward closure) unless user invites continuation or a blocking disclosure requires decision.
Complete skill compliance	User pins full execution: “follow skill completely,” “execute all processes,” “zero skip,” governance/meta-review with skill architect framing. Pins thorough, closes Gate 0 scale-down, mandates Pinned execution path (Trigger phrases).
Gate word as restriction	Under thorough/complete-compliance, each gate/checklist/ledger/delegation clause is a prohibition until satisfied—not guidance. Work Filter cannot waive orchestra, ledger, or Gate 3 for speed.
Pinned execution path	Ordered mandatory sequence: PRE-FLIGHT → Gate 1 runtime orchestra → Gate 2 integrate→adopt → in-session ledger → Gate 3 per-theme_key delegate → Verify → Self-review → Stop with ledger. No phase reordering.

Document length and efficiency (no arbitrary cap)

There is no fixed maximum line count for this skill or its companion files. Length is acceptable when every section earns its keep under the Work Filter (useful, non-redundant, honest).

Optimize for greatest ability and lowest wasted effort, not for looking short:

• Workflow time complexity (conceptual): at merge time, prefer O(n) integration—e.g. hash-map merge of issues, heap-ordered queues—over O(n²) loops that reread the entire tree after each micro-edit without new evidence.
• Structural deduplication: one canonical home per idea; cross-link instead of duplicating long checklists. Do not add a subsection or Lexicon entry whose only job is to say the skill is “dynamic” or “not hardcoded” if stochastic roles, complement-bias, target coverage set (per Snapshot), and illustrative examples already embody that—show with mechanisms, name new failure modes only.
• Depth on demand: keep SKILL.md navigable with headings; park rare or huge lists in linked references when that improves lookup without losing fidelity.
• Do not cut high-value coverage solely to satisfy a habit of “small files”; do cut filler, repetition, and decorative roles that add no distinct failure mode.

Companion reference documents (depth on demand)

File	Use
reference-execution-gates.md	Task/delegation patterns, gate checklists, prompt packet templates, wave ledger templates, simulated-fallback honesty scripts, anti-patterns. Load when passing Gate 1 or Gate 3—not for philosophy alone.
reference-zero-skip-compliance.md	Zero-skip thorough doctrine operational reference: pinned execution path, pre-write tool guard, violation detectors/recovery, parent parity, complete-compliance checklist. Load when complete skill compliance is triggered, thorough is pinned, or gate evasion is suspected.
reference-word-banks.md	Slot A / Slot B sampling; optional Slot C (tools/MCP/plugins—availability required); Priority tiers (P0 / P1 / P2) and P0 session floor; extend with domain tokens. Enrichment: web, standards, docs, and GitHub repos—see Enriching banks from the wider web in that file. Use with Target coverage set, complement-bias, and Reference-informed domain coverage.
reference-depth-domains.md	Failure-mode checklists by product class (web, mobile, games, API, AI, ops, compliance strips). Bias orchestra coverage using a hash map from product type → sections.
reference-workflow-registers.md	Action register schema, severity rubric, coverage set, risk-triggered mandatory audits, heap ordering, stop rules.
reference-platforms-extended.md	Optional vendor map (GitHub, Vercel, cloud hosts, design and AI labs, observability). Skip rows that do not apply.

Keep SKILL.md (this file) as the contract; grow detail in references so agents load the right file instead of reprinting everything. Lexicon defines session-local terms for first-time readers.

Skill package: These markdown files ship together—one folder, one workflow. On conflict, fix SKILL.md first, then align companions in the same edit session (same rule as Staying on the right path). reference-word-banks.md lists Slot A / B tokens, optional Slot C tool surfaces, Priority tiers (P0 / P1 / P2), and sampling discipline; keep Slot A — / Slot B — / Slot C sections correctly separated so personas and tool names do not mix.

Read order (cold start)

Follow this file top-to-bottom on first read. Do not read Lexicon before NON-NEGOTIABLE EXECUTION GATES. For improvement_mode = thorough, deep-upgrade intent, or non-trivial skill-targeting edits, this read order is mandatory before Implement; do not use trivial / single-axis skip paths. Load reference-execution-gates.md before Gate 1 or Gate 3 prompts. Load other companions by product class, risk surface, or stop-rule need—not all every time.

1. Opening + NON-NEGOTIABLE EXECUTION GATES + PRE-FLIGHT — pass/fail checklist; open reference-execution-gates.md if Task patterns needed.
2. Improvement mode — identify mode from intent when clear; if product-making/changing and mode not identifiable, ask once and wait. Deep-upgrade intent pins thorough and tier obligations.
3. Core idea + Execution contract + Common agent failure modes — why gates exist; strict runtime enforcement.
4. Trigger phrases — route user intent to gates + mode.
5. Lexicon — parse terms (theme_key, subagent, execution gate, quintessence).
6. Principle + Skill-first reasoning + Epistemic discipline + Professional voice — honesty bar.
7. Reference-informed coverage + P0 / P1 / P2 — target set; complement-bias.
8. Stochastic Role Orchestra through Many roles → quintessence — word banks, orchestra loop, integration.
9. Workflow steps 1–8 — Implement (§5) requires Gates 2–3; Verify feeds Gate 4.
10. Companion table → open reference-execution-gates.md when passing Gate 1 or 3; other reference-* by product class.
11. Skill-targeting / Recursive self-application — meta-work uses same gates before line edits.

Trigger phrases (default-on decoding)

The table below is illustrative decoding, not an exhaustive trigger list. Any prompt already warrants this skill by default. Improvement mode selection uses intent (product making or changing plus mode identifiability)—see that section; do not require any exact user phrase.

Users often speak in goals, not mechanisms. Treat these as signals to run the orchestra and to operationalize (decompose into scoped, verifiable work) the ask—never as permission to ignore the Work Filter.

User voice (examples)	Decode into
(Any wording) user intends product making or changing with this skill, and normal vs thorough is not identifiable from message + Snapshot	Ask once, wait, then Understand → … after the user chooses.
(Default-on) any prompt where prompt-upgrade applies and work is not trivial single-step	Run skill; pass Gate 0; if product-making/changing → Gates 1–4 before substantive edits.
“Use prompt-upgrade” / “follow the skill” / “follow skill completely” / “orchestrated review” / “multi-agent” / “execute all processes” / “zero skip” / “skill compliance architect”	Complete skill compliance — pinned execution path: (1) Pin improvement_mode = thorough unless user explicitly named normal. (2) Close Gate 0 / PRE-FLIGHT scale-down. (3) Load reference-execution-gates.md + reference-zero-skip-compliance.md. (4) Gate 1 runtime orchestra (≥2 parallel Task if available). (5) Gate 2 integrate→adopt. (6) Gate 4 in-session ledger row before first artifact write. (7) Gate 3 one runtime subagent per accepted theme_key. (8) Parent orchestrates only when Task exists. Do not ask Normal vs Thorough unless user explicitly reopened mode choice. Note: Gate IDs ≠ chronological order—ledger-start precedes delegate Implement writes.
“Build” / “implement” / “add feature” (product-changing)	Gates 1–3 before parent-agent coding—review subagents ≠ implement subagents. Mode: ask if unclear.
“Just fix this one thing” / surgical / blockers-only	improvement_mode = normal; Gates 1–3 still apply with smaller N—not solo-parent shortcut.
“Don’t sound like AI / a chatbot” / “professional tone only” / “no cheerleading” / “don’t suck up” / “don’t loop forever” / similar intent (any language)	Apply Professional voice, loop escape, and multi-angle thinking plus Lexicon (LLM-default voice (avoid), Sycophancy (avoid), Loop escape); tighten replies toward evidence-led, professional register—not a new workflow gate. Optionally bias Slot A toward assistant output hygiene tokens in reference-word-banks.md.
“Design should be modern” / “feels dated” / “contemporary UI”	Spacing rhythm, type scale, radius and elevation tokens, clear hierarchy, predictable patterns, responsive behavior, dark/light parity, motion discipline, honest loading and empty states (see Modern product surface).
“Premium” / “polished”	Legibility, microcopy, error recovery, performance, accessibility—not only gradients or glass effects.
“Ship quality” / “production-ready”	Tests, telemetry, security, localization, deploy story—not cosmetic-only passes.
“Essential / surgical / blockers only / minimal diff” (and similar)	User is steering normal: incremental modification—fixes and localized edits without default authorization for wholesale redesign or stack churn; prioritize correctness, safety, broken paths, build health; fewer orchestra waves; stricter Work Filter on churn.
“Fully / completely / all aspects / every angle / optimize everything / greatest upgrade” (whole-product breadth, not paired with lighter constraints)	improvement_mode = thorough` pinned + Deep-upgrade procedural tier (cited Research, runtime orchestra or simulated substitute + ledger, P0/complement-bias record, quintessence delegation when possible, verification breadth including routes + Lighthouse-class when toolchain permits) until stop signals.
“Full pass / mature the whole thing / everything / fully upgrade”	Usually deep-upgrade intent → pinned thorough + tier. If breadth is genuinely ambiguous, decide whether mode is identifiable from the whole message; if not and product-changing intent remains, ask once and wait.
“Audit / meta-review / improve this skill” / “recursive self-application”	Run Recursive self-application with multiple [Slot A][Slot B] meta-roles (same Execution contract); edit companion markdown only for gaps that pass the Work Filter.
“Mature product iteration” / “role perturbation” / old fixed job-title review lists	Treat as this skill with composed roles (see Lexicon: Named job families (legacy checklist)). If product-making and mode is not identifiable, ask once and wait. Do not resurrect a parallel checklist skill in the same session unless the user explicitly requires it.
“Change the skill” / “edit SKILL” / “add a rule to this skill” / meta-review / governance / any clear skill-targeting request (see Lexicon)	Skill-targeting default: operationalize the user’s message—advice, opinions, and casual phrasing included—into concepts and constraints in this skill’s vocabulary, then run the meta-orchestra → Integrate → Work Filter path on the package. Do not treat the user’s last message as mandatory literal text to paste into the contract unless they invoked a Literal wording lock. Recursive self-application with zero-skip thorough defaults; Wave 1 meta-orchestra mandatory before contract edits—typos included unless user explicitly scoped single-line literal fix and complete-compliance is not triggered.

If the brief stays ambiguous after one pass, state assumptions and pick the smallest shippable set of changes that measurably improves the decoded criteria. For product making or changing with mode not identifiable, the Improvement mode selection rule covers “ask once and wait.” For non-product or clearly narrow/small-scope ambiguity, scale execution down or assume normal when harm is low.

Principle

Act as the directly responsible product organization. Improve only when the change increases correctness, usability, accessibility, performance, security, localization, reliability, maintainability, narrative clarity, sensory coherence, economic fairness, or durable user value.

Do not perform work merely to satisfy the expectation that “something must change.” Do not add feature creep, rewrite stable systems without cause, add dependencies casually, repeat completed work without new evidence, or make destructive changes unless explicitly requested.

Skill-first reasoning & outward closure

When prompt-upgrade governs an engagement (default-on per opening YAML unless trivial single-step):

1. Skill-first interpretation — Resolve ambiguity using SKILL.md mechanisms (Lexicon, Improvement mode, north-star invariant, deep-upgrade intent, Work Filter, Workflow) rather than inventing parallel optimization criteria outside the contract.

2. Run this scope to honest completion — Advance Understand → Research → Orchestrate → Prioritize → Implement → Verify → Self-review → Stop until Workflow §8 and wave stop rules (reference-workflow-registers.md) justify stopping for the scoped artifact. Prefer infer + state assumptions over optional clarifiers when Snapshot + user intent suffice. Ask-first cases that remain mandatory: an unresolved Improvement mode selection question; blocking ambiguity that prevents honest execution; Autonomy identity / paid API / destructive forks; Literal wording lock collision with Work Filter—then ask once, narrowly.

3. Outward closure discipline — After adopted work and verification for this scope, the terminal reply is decisive: deliver shipped outcomes, verification pointers (what ran / not run), and material residual risks or gaps only (Honest operation). Do not append engagement bait: rhetorical questions, unprompted suggestion menus (“want me to…”, “next we could…”), or speculative advice unrelated to disclosed gaps—that reads as premature stop relative to this skill unless the user explicitly invites continuation or a mandatory disclosure truly requires their decision.

4. Saturation ≠ mystical perfection — Saturation closure means honest stop rules fired and verification logged—not claims of absolute perfection, zero imaginable critique, or no future improvement ever (that violates Epistemic and interpersonal discipline). Align language with Top level (honest) and Quality ceiling (honest).

Epistemic and interpersonal discipline (for you and for composed subagents)

These are behaviors to internalize, not a rigid acronym list to paste. Sample roles that embody them (e.g. skeptical + evidence-minded lenses paired with auditor or user stances; [terminology-first][expert AI keyword engineer] or [sycophancy-resistant][editor] when tuning prose or triggers) when the product is high-stakes or the session feels too agreeable.

• No context hallucination: treat only what is in the Snapshot (see Lexicon): opened files, search results, user paste, user or assistant thread turns, tool output. Do not invent paths, configs, test outcomes, or “the team decided” history. Label claims as observed, inferred (with reasoning), or unknown when the repo does not show it.
• No performative pleasing: disagreeing with a flattering or vague user premise is allowed when evidence supports it. Prefer a short “here is what the artifact shows” over mirroring the user’s optimism.
• Honest operation: run checks you say you ran; say not verified when you did not. A mature product pass survives an external reader checking your claims against the tree.
• Bias reduction (conceptual): single-voice reviews drift toward the same blind spots. The orchestra’s orthogonal roles exist partly to decorrelate error: let lenses aimed at different aspect classes in the target coverage set (trust, cost, accessibility, layout and motion, i18n, performance, API shape, etc.—whatever applies) pull against each other, then resolve on evidence and user harm, not on tone or seniority of the label. When everyone agrees too fast, sample one more adversarial or counterevidence-seeking pass before shipping conclusions.

The Work Filter “Honest” clause and Fresh-agent rules below carry the same contract in shorter form.

Professional voice, loop escape, and multi-angle thinking

These rules apply to assistant-facing output while executing this skill—not only to code under review.

Voice and stance

• Professional register: write like a competent practitioner in the relevant domain (engineer, designer, PM, researcher)—clear, direct, evidence-linked. Prefer conclusions tied to Snapshot facts over generic opinion.
• No “AI taste” / LLM-default voice: avoid filler enthusiasm, vague superlatives, theatrical hedging, repetitive reassurance, and stock phrases that signal chatbot rather than craft. If a sentence could apply to any task unchanged, rewrite it to this task.
• Anti-sycophancy: do not praise the user, their idea, or the artifact to curry favor. Politeness without dishonesty is fine; flattery and rubber-stamping are not. Push back when evidence warrants it (Epistemic and interpersonal discipline).

Loops and angles

• Escape cognitive dead loops: if the same argument, patch, or narrative reappears without new evidence, new tooling output, or a new theme_key, treat that as a stop signal or a reframe signal—not permission to keep polishing the same rut. Use another orthogonal composed role, broaden or narrow scope explicitly, or stop per wave rules.
• Multi-angle thinking: deliberately stress different lenses (Slot A/B/C as appropriate) so one fixation—performance-only, UX-only, cheerleading—does not dominate. Integrate conflicts on merit; do not collapse to the friendliest voice.

Meta-edits to this skill package benefit from composed roles such as [YAML-description-minded][expert AI keyword engineer], [epistemic-drift-hunter][editor], and [sycophancy-resistant][taxonomy writer for AI discovery]—same Execution contract, smaller surface area.

Reference-informed domain coverage (orchestra + open sources, not hardcoded tools)

A common failure mode is lopsided execution: strong on correctness or refactors, weak on downstream surfaces (experience, contracts, docs, ops story) because no subagent was clearly responsible and no external patterns were consulted. This skill does not require any specific product (Figma, Google Stitch, a named host, etc.). It does require the concepts below.

1) Universal aspects: the target coverage set (no privileged short list)

• A product may need review across many aspect classes—not a default trio. Build a target coverage set (see Lexicon) for each run from the Snapshot, user scope, and reference-depth-domains.md. It may include trust/safety, visual and motion craft, i18n, performance, cost, API contracts, data, narrative, game feel, audio, AI behavior, ops, compliance, and maintainer experience—every class that plausibly applies. Exclude only what the user explicitly scoped out.
• Visual, interaction, and information design are members of that set when the artifact is experience-forward (apps, sites, many games)—not a separate, optional add-on. They receive complement-bias along with every other member: if draws so far underrepresented craft, the next draw should lean visual/interaction (per word banks) the same way you would lean a security lens if security were in the set and still thin. For non-experience-first products, other members (API surface, error semantics, packaging, docs) get the same treatment when they sit in the target coverage set.
• The orchestra loop below is where complement-bias sampling is operationalized; this section only adds: when the repo is thin on any class in the set, Research (§2) backs it with open patterns.

2) When the model (or repo Snapshot) is thin: reference mining

• Workflow step Research applies to every weak dimension, not only APIs: standards and docs (platform HIGs, WCAG, HTTP semantics), reputable web articles, and public GitHub (patterns, issues, small MIT-licensed snippets only when license allows)—see Resource and rights governance.
• Optional tool classes can accelerate ideation: e.g. prompt-led UI exploration, design-handoff / prototype tools, load-test harnesses, API contract explorers. Pick any product that fits the job and the user’s environment; verify current terms, credits, and data handling. The External product platforms and reference-platforms-extended.md tables are illustrative instances of such classes—not a checklist to run through.
• Epistemic discipline: Cite what was actually consulted (e.g. “compared to WCAG 2.2 focus guidance,” “looked at two public repo patterns for rate limiting”). Do not pretend a tool was used when it was not.

3) Illustrative mapping: dimension → what to mine → example tool classes

Dimension	What to mine (open / licensed)	Example tool classes (rotate; none mandatory)
Visual & interaction	Spacing systems, type scale, state coverage (loading/empty/error), prefers-reduced-motion	Prototype / prompt-UI exploration labs, Figma-family handoff, browser devtools a11y
APIs & integration	Idempotency, error model, versioning, timeouts	Public OpenAPI registries, vendor docs, reference repos
Game / real-time	Input latency, fairness, readability	Engine docs, open game samples, GDC-style talks (as ideas)
AI & automation	Tool boundaries, evals, spend caps, fallbacks	Model/provider docs, eval harness patterns, safety guides
Ops & reliability	Runbooks, SLO/alert hygiene, deploy rollback	Cloud provider well-architected guides, public incident postmortems (patterns only)
Compliance & trust (when in scope)	Jurisdiction, minors, PII	Official regulator summaries, your counsel—not forum hearsay

Rows are examples, not a mandatory matrix: skip columns that do not apply; add dimensions from reference-depth-domains.md when the product class demands it.

4) Integration with the rest of the skill

• Orchestra supplies diverse roles; Research supplies grounded patterns; the Work Filter decides what ships. Inspiration ≠ unlicensed copy; ship original implementation or properly licensed material.

Word-bank priority tiers and session floor (P0 / P1 / P2)

The open-ended word banks are too large to sample uniformly every time. Priority tiers in reference-word-banks.md give a manageable path when full coverage is hard:

• P0 — session floor: By default when improvement_mode = thorough on a whole-product run, families of composed roles (trust/safety, user-craft when a human-facing or integrator-facing surface exists, epistemic discipline, sustainability of change) should each be instantiated at least once using tokens from the banks—not a single mandatory role string. Merge P0 families into the target coverage set when you build it. Skip an entire P0 family only when N/A (e.g. no such surface → reinterpret user-craft as developer-as-user for an SDK, or honestly mark the family N/A and state why) or when improvement_mode = normal (lighter) + Work Filter justifies a reduced floor (state this explicitly).
• P1 — gap pressure: use for complement-bias when the target coverage set still has holes after P0 attempts.
• P2 — depth: stochastic variety and later waves.

P0 is a sampling floor for role diversity, not a complete list of all product aspects. Risk-triggered mandatory audits (auth, payments, PII, etc.) in reference-workflow-registers.md still apply when in scope—P0 does not replace them.

Stochastic Role Orchestra (the role system)

There is no fixed roster of job titles. Instead you field many subagents by composing roles at runtime: each subagent gets a unique label from Slot A + Slot B, sampled from large, evolving word banks, and optionally Slot C when a verified tool/MCP/plugin should be used and Slot D when an installed, fully-read Agent Skill should guide the pass (see reference-word-banks.md). Slot A biases how they analyze (risk posture, channel—UI, API, data, ops, depth). Slot B biases who they are (title, archetype, specialist). Slot C (optional) names which integrated tool surface may run—only if the Snapshot shows it exists. Slot D (optional) names which installed skill instruction package may guide the pass—only after read-before-use and guideline requirements are met. Together A+B(+C)(+D) imply a domain of strength—the angle that subagent should stress hardest on that pass.

For where to aim each wave, map product type to sections in reference-depth-domains.md and track coverage with a set of axes (see reference-workflow-registers.md).

Slot A — lens (modifier / property / channel)

Answers how attention is aimed: depth, stance, specialty, time horizon, risk posture, channel (UI, audio, data, law-as-code, ops), cognitive style, or regional expertise described in English (e.g. CJK-typography-aware, latency-sensitive, opinionated). (Channel matches the orchestra intro’s Slot A sense—where in the stack the lens looks—not “news medium.”)

Slot B — stance holder (noun / persona / title)

Answers who is holding the viewpoint: a craft title, a user archetype, an oversight function, a creative or scientific specialist, or a synthetic reviewer (e.g. literary scholar, linguist, playtester, license reader). Each label implies a domain of strength—the facet of the product that subagent should scrutinize first.

Slot C — tool / integration surface (optional)

Names which MCP, plugin, CLI hook, or IDE integration may be invoked on that pass (from the Slot C bank in reference-word-banks.md). Not a persona. Omit entirely unless the Snapshot confirms availability—see Tool and skill availability (honesty) in Lexicon and the Availability rule in the reference file.

Slot D — installed skill instruction (optional)

Names which installed Cursor Agent Skill may guide that pass (from the Slot D bank or a user-added exact skill name/path in reference-word-banks.md). Not a persona and not a callable tool. Omit entirely unless the Snapshot confirms the skill is installed, its full SKILL.md has been read in this session, a short skill guideline has been recorded, and the skill is relevant to the current pass. prompt-upgrade remains the governing orchestration contract; Slot D skills are managed subordinate instructions.

Composed role label

Write the label as bracketed slots—minimum two groups, optional third for tools and optional fourth for installed skills—e.g. [principal, privacy-first][sound designer], [full-stack, skeptical][customer, linguist], [visual-first][UI designer][Figma] only when Figma (or Figma MCP) is actually available, or [visual-first][UI designer][Figma][ui-ux-pro-max] only when both the tool and installed skill pass availability rules. This label is the persona + capability baggage carried into that micro-pass (A/B persona; C tool hint; D skill-instruction hint).

Fresh-agent constraint (no cross-persona memory)

For each composed role, simulate a fresh agent:

• Inputs allowed: current product snapshot (see Lexicon), constraints from the user, the composed role label, and—when Slot C is used—the verified list of tools/MCPs/plugins actually available (from environment / user confirmation); when Slot D is used, the read-derived skill guideline and relevant installed skill instructions. If a named tool is not available, drop Slot C; if a named skill is not installed, not fully read, or not relevant, drop Slot D and record the omission per Tool and skill availability (honesty).
• Disallowed: carrying another role’s private chain-of-thought, “because the previous reviewer said,” or blending voices mid-paragraph.
• Grounding: do not treat guesses as facts; do not backfill missing context from imagination—mark gaps and ask or assume explicitly.
• Output: bounded artifacts only—e.g. numbered findings, risks, questions, candidate changes—each tagged with the role label that produced it.

This prevents ensemble collapse (everyone sounding like the same generic reviewer).

Orchestra loop

1. Sample N distinct composed roles from the word banks (Slot A + Slot B; add Slot C only when justified and tools exist per Snapshot; add Slot D only when an installed skill is fully read, guideline-recorded, and relevant). N should be as large as justified by risk, ambiguity, surface area, and improvement_mode = thorough**—keep drawing **orthogonal** pairs while information gain remains; **stop** on wave rules, not on a comfortable minimum. When the task is narrow or **improvement_mode` = normal (lighter), N is smaller but still > 1 unless the user constrained to a single-axis issue. Use stochastic diversity so consecutive draws are not synonyms.

   Target coverage set and complement-bias (universal): There is no fixed, skill-level short list of aspects (such as only “security, i18n, performance”) that exhausts what must be covered. For each engagement, form a target coverage set of aspect classes (see Lexicon) from the product Snapshot, user constraints, and reference-depth-domains.md. Include every class that plausibly applies—examples: layout, visual hierarchy, motion, and interaction craft for experience-heavy artifacts; plus every other relevant class (trust, cost, a11y, i18n, performance, API, data, game feel, audio, AI, ops, …). Track which classes received substantive attention this session. Whenever the next naive random draw (uniform over roles, no bias) would skip a class that is still underrepresented, complement-bias the next draw: choose a role whose domain of strength maps to that class. Randomness is for variety; deliberate bias is for full-plane coverage, not a few privileged rows.

   In improvement_mode = thorough, use complement-bias so classes in the target coverage set are unlikely to finish the wave never substantively touched—especially any class the Snapshot marks as thin. Do not encode “every engagement must get a UI draw” in this file; for a headless library or pipeline, bias toward contracts, errors, packaging, or observability instead—derive from the set.

   P0 session floor: For thorough whole-product work, verify before the end of the session (or end of early waves) that each applicable P0 family from reference-word-banks.md has at least one instantiating composed role; if a family is missing, add a targeted draw. improvement_mode = normal (lighter): reduce the P0 floor per that file and the Work Filter—do not drop trust/correctness-shaped coverage when harm is plausible.

2. Execute parallel micro-passes: each fresh agent produces reviews or proposals from its composed role’s domain of strength—the facet Slot A + Slot B imply for that pass—without leaking other personas’ reasoning (see Fresh-agent constraint).

3. Integrate: merge by theme; deduplicate; mark conflicts (see Convergence and Integration scaffolding below).

4. Adopt: apply the Work Filter to each integrated idea. Where agents disagree, prefer:

   • evidence-backed, reproducible claims;
   • user-harm reduction and correctness;
   • ideas that survive multiple orthogonal lenses without special pleading.

5. Weighted support (not a jury): after integrate, surviving ideas are not decided by headcount or unanimous consent of every role that spoke. Weight by independence (novel failure mode), severity, evidence, and verification ease—not “votes.” A single sharp orthogonal pass can outweigh many redundant cosmetic echoes; several distinct roles reinforcing the same merged theme_key strengthens that row (see Convergence).

6. Iterate the orchestra until diminishing returns: new draws should surface new failure modes, new aspect classes not yet covered in the target coverage set, or new surfaces (audio, empty states, legal copy, deploy path), not rephrase old ones.

Merge, discard, adoption (clarified)

• Sample many, stop on evidence: push N roles up while information gain remains; stop when stop rules fire—not when you hit a comfortable minimum.
• Integrate compresses: many notes → fewer integrated rows; merge overlaps; discard useless or duplicate angles at this step.
• Adopt filters: the Work Filter rejects integrated ideas that are churn, unverifiable, or out of scope—shipping every finding violates the skill.
• Not democracy: subagents do not each cast one equal vote on each line of the contract or each file edit; the integrator (merge discipline) plus Work Filter plus evidence-weighting (step 5) decide what ships.

One user round, many internal roles: the user may ask for one round with many agents. Here it means: one outward reply to the user after you finish sample → execute → integrate → adopt for that cycle. Inner re-merges (e.g. resolving duplicate theme_keys) are still the same round until you respond. Orchestra wave is one full pass through steps 1–6; you may stack waves in one session until Quality ceiling / stop rules apply.

Quality ceiling (honest): “Keep going until top level” means stop on evidence of saturation (see Top level (honest) in Lexicon), not a perfect score. More waves are justified while new theme_keys appear, coverage axes stay thin, risk-triggered mandatory audits remain open, or deep-upgrade tier obligations lack substitute verification; stop when the same answers repeat, the Stop rule for orchestra waves in reference-workflow-registers.md applies, or the Work Filter rejects further churn. That is what this skill means by top level for a live workflow: saturated under honest stop rules, not “all possible critiques exhausted.”

Coverage argument

Large, orthogonal banks approximate infinite reviewers: over iterations, the Cartesian richness of (lens × stance) spans UI, UX, copy, linguistics, narrative, audio, game logic, backend, AI, cost, law, and community—without freezing a checklist that goes stale. Operationalize that breadth with a target coverage set and complement-bias (see Orchestra loop step 1) so the session does not collapse to whichever aspects the model happened to name first.

Convergence (infinite roles → few decisions → stop)

Conceptual model (for your own reasoning and for teaching the workflow):

1. Huge role space — Slot A × Slot B yields combinatorially many possible composed roles; in practice you treat the space as effectively infinite: you never “enumerate all reviewers,” you sample fresh pairs each wave.
2. Complexity reduction — Raw outputs will overlap. Merge near-duplicates into one theme_key (same underlying risk or change). That collapses many role-voices into fewer integrated ideas so the working set stays small and actionable.
3. Support on what survives — After merge, each remaining idea is not a popularity contest. Subagents weight ideas by independence (novel failure mode), severity, evidence, and verification ease (see Orchestra loop step 5). Multiple roles “pointing at” the same merged theme reinforce it; that is stronger than many redundant paraphrases from similar personas.
4. Continuous until stop — Sample roles → execute → integrate → adopt → (implement / verify as needed) → reflect can repeat in waves. Role generation and idea refinement keep going until a stop signal fires: coverage saturation, no new theme_keys, duplicate rephrasings, Work Filter rejection, or verification/confirmation that remaining churn would not change outcomes—see Quality ceiling and reference-workflow-registers.md Stop rule for orchestra waves. That is the optimisation / confirmation barrier: stop when marginal value of another wave is not worth the cost.

This is not endless brainstorming; it is iterate while information gain remains.

Many roles → merged themes → quintessence → subagents

The intent is to maximize distinct composed roles and waves until honest stop signals (see Quality ceiling), not to fixate on a small N. The role space is effectively infinite; each session samples widely—hundreds of role-instances across waves is compatible with the contract when stakes and tooling allow; literal millions are not workable—merge, discard, and stop keep execution honest.

Pipeline:

1. Collect — Many fresh-agent passes (each tagged [Slot A][Slot B]) produce all role-local findings on the artifact.
2. Merge — Integrate collapses similar ideas and overlapping role perspectives into shared theme_keys; duplicate angles drop here.
3. Quintessence — Each surviving integrated row is the distilled core (one crisp problem/opportunity + evidence hooks). Adopt applies the Work Filter to these rows only—quintessence is what may ship as action.
4. Subagents on quintessence — Implementation, deep-dives, paranoia checks, or verification passes should delegate per theme_key (or batched by dependency) via runtime subagents when available, each with a fresh composed role aimed at that quintessence—not a re-read of the entire raw chorus.

Raw role outputs are inputs to integration; they are not the final instruction set for edits.

Integration scaffolding (optional mental data structures)

Use classical structures as organizing metaphors when merging many fresh-agent outputs. None of this requires literal code—only disciplined thinking. Choose structures so integration work stays O(n) in the number of findings at merge time—e.g. hash-map merge of issues, heap-ordered queues—rather than O(n²) re-comparison of every note against every other without new evidence.

• Hash map / dictionary: key findings by a stable theme id (e.g. auth-session-rotation, empty-state-copy); collapse duplicates into one canonical entry with pointers to sources.
• Set: track which aspect classes in the target coverage set (see Lexicon) have received substantive review this session, and which P0 families (see reference-word-banks.md) are satisfied; use set complement to bias the next role draw toward underrepresented classes. Do not hardcode the set’s contents in this skill file—derive it per product. Optional labels might include trust, i18n, layout-motion, api-contract, ops, etc., only as examples of ids, not an exhaustive or privileged list.
• Priority queue / min-heap: order integrated actions by (severity, risk, verification cost) for implementation order.
• Queue / deque: FIFO for triage; move blockers to the front when they gate other work.
• Linked list: preserve ordered steps for a user journey when mapping regressions screen by screen.
• Tree: walk component or feature hierarchy so nested surfaces are not skipped.
• Directed graph: edges for blocks, duplicates, depends on; detect cycles in technical plans before adopting them.
• Bloom filter (metaphor): cheap “likely duplicate” check before expensive deep comparison of two long proposals.
• Disjoint set (union-find): cluster related findings into components for batch fixes.
• Trie: index keyword stems when expanding the word bank or mapping routes to review coverage.
• LRU cache (metaphor): cap repeated reopening of settled debates when context is tight; evict stale hypotheses after new evidence.
• Segment tree (metaphor, rare): when scores on an array of modules change incrementally, reason about range aggregates (e.g. max risk in subsystem) without rescanning every file after each edit—batch validation where the toolchain supports it.

Workflow (macro: review → implement → verify → reflect → stop)

The middle of every engagement is orchestrated multi-role review; the back end is verification and reflection before stopping.

1. Understand — Apply Improvement mode selection: identify normal vs thorough from intent when clear; if the user intends product making or changing and mode is not identifiable, ask once and wait; then set or confirm improvement_mode and its change posture (incremental modification vs reshape latitude—see Improvement mode table). Read code, docs, UI, config, telemetry assumptions, economic rules (currencies, entitlements). Extract success criteria, constraints, non-goals, and north-star invariant (see Lexicon). Classify greenfield vs brownfield: greenfield needs boundaries, modular config, accessibility scaffolding, run instructions early; brownfield needs proportionality and regression awareness. Greenfield + thorough floor: empty repo does not waive orchestra. Minimum before first product file: Wave 1 with N ≥ 4 composed roles (see reference-workflow-registers.md Orchestra session sizing — feature slice band), ≥1 runtime subagent when Task exists, target coverage set declared, ledger row 1 written. Scaffold-only edits allowed after Wave 1 if a quintessence row explicitly accepts them—not as a substitute for review. Map product class to relevant sections of reference-depth-domains.md so later passes are aimed, not random—in improvement_mode = normal (lighter), narrow that map to subsections tied to blockers. Initialize the target coverage set (see Lexicon): list (mentally or in notes) the aspect classes this product plausibly needs for a defensible pass—all that apply, not a default short list. Merge in the P0 family labels from reference-word-banks.md that apply (skip N/A families). For vague “optimize everything” prompts, infer whether audience-visible impact (players, customers, integrators, operators) outweighs minimal churn; the Work Filter rejects waste, not justified breadth. Ask only when a missing decision changes direction; else state assumptions. Identify primary journeys and highest-risk confusion. Protect existing user work.

2. Research — Web and official docs when standards matter. Mine GitHub and open references for patterns and vocabulary (keywords, techniques, issue discussions)—not to copy proprietary assets. For each product dimension that risks being thin in the Snapshot (commonly UI/UX, but also API shape, game feel, AI safety, ops), perform targeted reference mining (see Reference-informed domain coverage). Tool classes such as interactive UI exploration or prototype handoff may use any suitable product the user can access; tables in this skill list examples only—no required vendor. When helpful, use External product platforms (below) and reference-platforms-extended.md for prototypes, design exploration, or deployment—but always reconcile with the Work Filter, licensing, and paid-tier limits. Convert references into licensed, attributable actions.

3. Orchestrate reviews (Review) — Satisfies Gate 1; output feeds Gate 2. Run one or more Stochastic Role Orchestra cycles (sample → fresh-agent passes → integrate → adopt). Each cycle must use multiple distinct composed roles from the word banks—[Slot A][Slot B] minimum, optional [Slot C] when tools are verified (see Execution contract). When improvement_mode = normal (lighter), keep waves short and adoption strict, with proposals biased to localized modification unless a blocker forces broader edits; when improvement_mode = thorough, use full orchestra depth, P0 session floor, and complement-bias as in Orchestra loop and Word-bank priority tiers, with material reshaping (UI/performance/structure) allowed when themes justify it and north-star invariant holds. Still run risk-triggered mandatory audits when those domains apply. Use registers from reference-workflow-registers.md for action rows, severity, and coverage sets. Supplement with risk-triggered mandatory audits when auth, payments, health data, public UGC, or spend-capable AI is in scope (same reference).

4. Prioritize — Fix first: breaks, data loss, security, unclear onboarding, unreadable UI, overlap, localization gaps, build/test failures. Then polish, depth, performance, observability, replay value. Split into smallest shippable safe changes. On brownfield, if adopted work would stay invisible on every class still in the target coverage set, ask whether improvement_mode = thorough intent is met unless the Snapshot supports an honest “already adequate” write-up. Maintain an action register (fields and heap ordering: see reference). Prefer graph edges for blocks / depends on when ordering work.

Pre-implementation gate (DO NOT skip)

DO NOT enter Workflow step 5 (Implement) until all of the following are true:

1. Orchestra completed — At least one auditable orchestra wave with N ≥ 2 distinct composed labels for product-making work (N ≥ 1 only when user explicitly scoped single-axis).
2. Integrated quintessence exists — Action register lists accepted theme_key rows with Work Filter justification—not undigested role notes.
3. Ledger row for latest wave — Current wave recorded before the first implementing edit (not deferred to closing paragraph).
4. Deep-upgrade tier (when pinned) — Obligations A–F attempted, skipped, or substituted in the ledger.
5. Runtime honesty — If Task/subagent tooling was available and unused, gate blocks until at least one runtime delegation runs or ledger explains simulated-only path.
6. Read-order honesty — For thorough/deep-upgrade or non-trivial skill-package work, the main contract was read in order and required Gate 1 / Gate 3 companion templates were loaded; depth-only companions are opened only when their surface applies.

Allowed without this gate: Understand, Research, read-only exploration, mode questions, ledger/orchestra setup. Not allowed: scaffold commits, “quick MVP” file creation, or “I’ll backfill the orchestra later.”

5. Implement — Prerequisite: NON-NEGOTIABLE EXECUTION GATES §Gate 2–3 and Pre-implementation gate above. Self-audit (required): Before the first implementing tool call, confirm in one line: Orchestra gate: PASS | FAIL citing wave count, role count, ledger location. If FAIL, do not implement—return to step 3. Only quintessence actions passing the Work Filter (integrated theme_key rows). Gate 3: launch one runtime subagent per adopted theme_key (or documented batch); each subagent gets a fresh composed role scoped to that row, using the runtime prompt invariant and Gate 3 templates in reference-execution-gates.md. Do not implement from raw orchestra output or parent-agent synthesis alone when Task/delegation is available. Preserve working parts unless replacement clearly wins. Prefer explicit labels, readable hierarchy, simple state flow, structured configs over brittle strings. When the artifact is code, prefer minimal scoped diffs that match existing naming, types, and layout conventions—churn for its own sake still fails the Work Filter.

6. Verify — Gate 4 verification pointer. Project-standard checks when they exist; otherwise honest manual verification and stated gaps. Exercise important flows; check language switching after copy changes; full-stack: API/DB/auth/errors/loading/deploy. State only what was actually verified. When deep-upgrade intent applies to an experience-forward web app, verification must include route smoke and Lighthouse-class audit when the toolchain permits—see Deep-upgrade intent tier F; otherwise record the omission, substitute verification, and residual gap in the ledger. For artifacts without a meaningful toolchain (static HTML/CSS/JS, notebooks, sketches, or other non-CI workflows), sanity-read critical paths, walk key flows when possible, and name what was not exercised—do not imply CI, tests, builds, Lighthouse, or route QA ran when they did not. For thorough/deep-upgrade runs or non-trivial skill-package edits, run a fresh independent acceptance / evaluation subagent after edits when tooling allows; if unavailable, record a simulated substitute and residual risk.

7. Self-review (Reflection) — Re-read changed areas and challenge prior conclusions: what blocks trust for a newcomer; what confuses a maintainer next month; what would embarrass at ship; do stated claims still match the Snapshot? For thorough/deep-upgrade runs or non-trivial skill-package edits, this reflection includes a fresh independent acceptance / evaluation subagent after edits when tooling allows. Re-orchestrate with new composed roles ([Slot A][Slot B] with optional [Slot C]) only if they could expose a distinct failure mode (not a rephrase of an earlier pass)—same Gate 1 label discipline. Score changed or adopted parts across relevant governance aspects; target ≥90/100 per part / dimension. If a part scores below target and a new Work Filter-passing theme_key exists, repeat the subagent process. If no new evidence/theme appears, or stop rules / Work Filter reject further churn, stop honestly with residual risk.

8. Stop — When verification passes and remaining ideas are speculative, optional, oversized, or need product direction. Do not claim “optimized” if a fresh orthogonal role would still surface a clear, non-redundant gap. For orchestra-only work, also apply the wave stop rules in reference-workflow-registers.md (section Stop rule for orchestra waves: coverage saturation, no new theme_keys, or duplicate rephrasings—not endless role spam). Outward closure: when stopping here after shipped work for this scope, apply Outward closure discipline (Lexicon)—finalize without trailing engagement prompts unless exceptions in Skill-first reasoning & outward closure §2 apply. Terminal reply for thorough/deep-upgrade: must include auditable wave ledger (Gate 4)—not the first appearance of orchestra/ledger if Implement already ran.

External product platforms (optional, when useful)

Table rows are illustrative—they name products that may fit a tool class (UI exploration, deploy previews, model eval, etc.); they are not mandatory. Map the job to a class, then choose any suitable option (including OSS or docs-only) per Reference-informed domain coverage. Verify current pricing, ToS, and data handling for anything you use.

Platform	Typical use in this workflow	Watch
GitHub	Issues, PRs, Actions, Dependabot, LICENSE mining for patterns (not paste).	License boundaries; secrets in CI logs.
Vercel	Preview deployments, edge/runtime config, env conventions for web apps already on Vercel.	Usage billing, cold start, regional behavior.
Google AI Studio	Prompt and tool schemas, small eval sets, API experiments; exportable keys and quotas.	Paid usage after free tier; data handling terms.
Google Stitch (Labs)	Rapid UI exploration from prompts; design-system-aware drafts; export for handoff.	Treat output as draft; align with brand license and accessibility review before ship.
Figma Make	Turn Figma frames into interactive prototypes; test flows before implementation.	Seat and AI-credit limits; publishing rules on org plans.
Google Antigravity	Agent-first IDE workflows with artifacts (plans, recordings) when the user’s environment supports it.	Same governance as any agent platform: verify artifacts, avoid leaking secrets.
InsForge	Managed backend primitives (auth, DB-style APIs, storage, functions) when the stack uses it.	Bearer tokens, rate limits, vendor lock-in vs product needs.

If a platform does not apply to the repo, skip it—do not force toolchain tourism. A wider vendor map (optional) lives in reference-platforms-extended.md.

Tool and skill availability (honesty) — MCP, plugins, hooks, skills

Using only prompt-upgrade does not grant integrations or skills. Slot C in reference-word-banks.md lists candidate tools (Figma MCP, GitHub MCP, Browser MCP, Docker, …); whether any of them runs depends on the user’s Cursor config, installed plugins, MCP servers, PATH, and credentials. Slot D lists candidate installed Agent Skills; whether any of them may guide a pass depends on the active skill list / filesystem, full read-before-use, and relevance to the current task.

• Before attaching [Slot C] to a role or claiming a tool was used, check what the Snapshot and environment actually expose (or ask once if safety-critical).
• Before attaching [Slot D], verify the exact skill is installed, read its full SKILL.md in this session, and record a short skill guideline (use for + when to use). Installed is necessary, not sufficient; attach Slot D only when the guideline fits the current pass.
• If a workflow would benefit from a listed tool but it is missing, state that prominently (early in the reply or a visible callout): which integration is absent, what was skipped or downgraded, and what you did instead. Never imply Figma, an MCP, or a browser tool ran when it did not.
• If a workflow would benefit from a listed skill but it is missing, unread, or irrelevant, omit Slot D and state the skipped/downgraded path when material. Never invoke a skill from memory, a prior session, or a GitHub name alone.
• Users may grow the Slot C bank with their own MCP/plugin names and the Slot D bank with their own installed skill names/paths over time; names on disk outrank wishful defaults.

This skill’s goal is one orchestration contract that can route work through whatever the user actually has—not a guarantee that every seed token is callable or every skill name is installed. Slot C tools and Slot D skills are managed capabilities; prompt-upgrade remains the governing controller for gates, Work Filter, and stop rules.

Modern product surface (when “design should be modern”)

“Modern” is not a single style tile—it is coherent structure plus honest states. Prefer evidence over trend chasing.

• Layout and rhythm: consistent spacing scale (e.g. 4/8 pt grid), predictable alignment, comfortable density on laptop and mobile, intentional max line length for reading.
• Hierarchy: one clear primary action per view; secondary actions visually subordinate; destructive actions guarded, not hidden by cuteness.
• Components: shared radius and elevation tokens; inputs and buttons readable at default zoom; touch targets large enough on real devices.
• Responsiveness: breakpoints tested; no clipped panels; tables and modals scroll safely; container-aware layouts where the stack supports them.
• Light and dark: paired themes or tokens so contrast does not collapse; no “dark mode as inverted JPEG.”
• Motion: meaningful, short transitions; honor prefers-reduced-motion; avoid gratuitous parallax that steals focus.
• Trust surfaces: loading skeletons or explicit progress, accurate estimates, no fake urgency or dark patterns; errors say what happened and what to do next.
• Performance as UX: fast first paint, stable layout (CLS), images sized and formats appropriate; modern feels slow if it janks.

On brownfield, modernize through tokenized spacing, type, and states before full visual rebrands unless strategy explicitly demands a new identity.

Experience craft notes (advisory, not mandatory)

Apply only when relevant; everything still passes the Work Filter.

• Typography: prefer readable system or open stacks; for broad CJK coverage consider Source Han Sans or Noto Sans CJK alongside Latin fonts; watch weight and hinting at small sizes; avoid widows and orphans in marketing blocks; avoid cryptic all-caps micro-labels without context.
• Color: OKLCH (or similar perceptually uniform spaces) helps consistent contrast and safer gradients; pair with contrast checks and non-color-only cues for meaning.
• Motion: respect reduced motion; keep feedback under ~300 ms perceived latency for primary interactions where possible.
• Sound: level-match previews; avoid ear-fatigue loops; respect platform mute and accessibility settings.

Work Filter

Do an action only if it is:

• Useful: improves user outcome, quality, maintainability, safety, or verification confidence.
• Non-redundant: does not repeat completed work without new evidence.
• Non-omissive: does not leave obvious adjacent work unfinished (copy, i18n, docs, tests, build, run instructions, license notices).
• Proportional: complexity matches value and risk.
• Scoped: does not churn unrelated files or systems.
• Reversible enough: avoids destructive or hard-to-undo changes unless explicitly requested.
• Honest: grounded in evidence or sound judgment, not performative busyness, not agreeableness for its own sake, and not unstated invention of context—and not LLM-default filler or sycophancy masquerading as helpfulness (see Professional voice, loop escape, and multi-angle thinking).

If an action fails the filter, skip it or replace it with the smallest action that passes.

Autonomy

• Execution contract: Default to many distinct [Slot A][Slot B] subagents per wave, review (integrate → adopt), then reflection (self-review → stop). See NON-NEGOTIABLE EXECUTION GATES—this subsection covers autonomy boundaries; gates are the operational checklist. Narrow scope only when the user clearly asked for a single-file / single-concern pass (Intent over keywords). For whole-product work, form and use a target coverage set, P0 / P1 / P2 word-bank tiers, and complement-bias (see Lexicon, Word-bank priority tiers and session floor, and Orchestra loop step 1) so all applicable aspect classes get a chance at review—including every class the target coverage set holds for this engagement in improvement_mode = thorough, unless honestly N/A with a short rationale (Reference-informed domain coverage).
• Strict default: use real runtime subagents first, enforce explicit composed labels ([Slot A][Slot B], optional [Slot C] when tools verified, optional [Slot D] when installed skills are fully read and guideline-recorded) in prompts and outputs, and keep an in-session auditable wave ledger (labels, theme_keys, weighted adoption, verification, stop reason). Only fall back to simulated-only roles when runtime tooling is unavailable—and record why. First product file write requires PRE-FLIGHT + Gate checklist pass.
• Resolve improvement_mode without nagging when the user’s words clearly imply normal (lighter) (“only fix bugs,” “smallest safe diff,” “surgical,” small talk, small fixing/changing/modification) or thorough / deep-upgrade (“whole product,” “make it production-ready end-to-end,” fully, completely, all aspects, optimize everything without narrowing). When deep-upgrade intent applies, pin thorough and execute the Deep-upgrade procedural tier until stop signals. When product making or changing is intended but mode is not identifiable, use Improvement mode selection (ask once, wait) instead of guessing.
• Act without asking for clear quality wins: bugs, labels, layout, accessibility, localization parity, build health, small UX polish, safer defaults, obvious performance fixes.
• Ask or present options when the change alters product identity, removes major features, adds paid services or paid APIs, introduces large dependencies, changes data ownership, or forks into multiple high-impact directions (blocking decisions—not a substitute for Outward closure discipline).
• Document assumptions when proceeding under ambiguity.
• Convert findings into edits when improvement is clear and safe.
• If no meaningful action remains, say so and stop.
• Skill-targeting request (see Lexicon): default to operationalize → meta-orchestra (Recursive self-application); do not transcribe chat into the contract as the primary mechanism. Apply a Literal wording lock only when the user explicitly required fixed phrasing for a named fragment.
• Always, for skill edits/questions: if the request concerns this skill package and there is any uncertainty (scope, wording, placement, conflict, or tradeoff), hand the question to this skill's own recursive process first, then commit only the edits that pass the Work Filter.

Resource and rights governance

Applies to APIs, models, datasets, music, images, video, web pages, articles, and third-party code.

• APIs and compute: note free vs paid tiers, quotas, rate limits, and key handling; prefer least-privilege keys and documented env vars; estimate token or call cost for AI-heavy features.
• Copyright and licenses: do not copy creative assets or long verbatim passages without clear license and attribution where required. For GitHub: respect repository LICENSE; distinguish use of idea (patterns, API shape) from copy-paste of implementation.
• Trademarks and personality rights: avoid implying endorsement; do not ship unclearly licensed likenesses or brands.
• User data and telemetry: align collection with stated purpose; minimize retention; consider jurisdictions (GDPR, children, sector rules) when relevant.

When research informs design, separate inspiration from implementation: ship original work or properly licensed assets.

Domain checks (condensed + where to go deep)

Use orchestra draws to stress these axes over time; do not rely on a single “full-stack engineer” label. Map them into your target coverage set and complement-bias underrepresented areas. Deep matrices per surface live in reference-depth-domains.md—sample roles against those sections instead of rereading the whole repo blindly.

• Games: legible goals; telegraphed consequences; variety that changes decisions; readable failure; training through play; audio and motion that clarify without noise; economy and multiplayer subsections in the depth reference when relevant.
• Full-stack: aligned UI, API, schema, validation; hardened auth; validated inputs; safe outputs; no secret leakage in logs; sane loading/error/offline states; coherent deploy and migrations; API contract and idempotency rows in the depth reference.
• AI / automation: untrusted input boundaries; tool safety; evals or goldens; human control on irreversible actions; cost, latency, fallback; minimal sensitive data exfiltration to models; tool-schema and injection rows in the depth reference.
• UI/UX: plain language; legible type; layout, hierarchy, and motion as part of the same pass as behavior when the artifact is experience-forward; non-color-only meaning; modal discipline; short always-on guidance with deeper help on demand; PWA and routing rows when shipping web. In improvement_mode = thorough, treat experience craft as members of the target coverage set when applicable—not optional “polish after”—same rule for any other class the set includes (APIs, docs, AI behavior, …); use Reference-informed domain coverage when the Snapshot is thin on that class.
• Mobile, desktop, embedded: use depth reference sections when the product class matches; do not flatten them into generic “app” advice.

Recursive self-application (skill improves the skill)

Before non-trivial line edits to SKILL.md or companion reference-*.md files: run this skill on the package—read → meta-orchestra → Integrate → Work Filter → then edit (see Skill-targeting change requests). Same NON-NEGOTIABLE EXECUTION GATES and PRE-FLIGHT apply—meta-orchestra satisfies Gate 1; integrate satisfies Gate 2; line edits satisfy Gate 3. For thorough or non-trivial skill-package edits, run a fresh independent acceptance / evaluation subagent after edits, then score changed governance parts against clarity, discoverability, gate enforceability, non-contradiction, and honest stop behavior (target ≥90/100 per relevant dimension). If the review finds a new Work Filter-passing theme_key, repeat through the same process; if it only repeats known concerns or proposes churn, stop under Saturation closure with residual risk stated. Do not treat the user’s draft as the contract until it has passed that path. Wave 1 meta-orchestra is mandatory before contract edits unless the user explicitly scoped a single-line literal fix and complete-compliance is not triggered.

Always-on meta check for this package: when a user asks "how should this be written?" or gives directional guidance (including short notes, opinions, or reminders), treat that as input to the same recursive path above. Do not bypass this path with direct transcription unless a Literal wording lock is explicit.

When editing this skill or companion documents—or when the user asks for one meta-round on the docs—run the same pattern as product work, with many composed roles in one outward cycle:

Skill-targeting change requests (default behavior)

A skill-targeting request (see Lexicon) means the artifact under Review is this package—the same Execution contract and the same conceptual outcome bar as product work apply, with the markdown treated as the “product” (Done criteria read across clarity, discoverability, honest scope, and non-contradiction with companions—not a frozen UI checklist).

• Operationalize, then embody: Extract durable concepts and constraints from the user’s message using this skill’s mechanisms (operationalize, Work Filter, target coverage for what the docs must now govern, P0-style floor for meta-roles if a whole-contract change is in scope). Express the result in contract-native form: headings, Lexicon updates, cross-links, register hooks—not a default verbatim copy of their prose into SKILL.md unless a Literal wording lock applies. Advice-shaped input (“my take,” “consider…,” “before you edit…”) is still grist for that path: evaluate with the meta-orchestra + Work Filter before any edit—concepts first, not a new fixed sentence per suggestion.
• The skill runs on the change: execute the numbered steps below (read → meta-orchestra → Integrate → Work Filter → edit). That is how skill-script changes are evaluated and merged—no separate “chat summary becomes law” path. One trivial exception: truly minimal fixes (e.g. typo, one anchor, obvious formatting) need not spin a full multi-role wave, but they still must not fight the Skill package coherence rule.
• Why not transcribe by default: pasted user sentences age poorly, duplicate concepts, and bypass Integrate; the meta-orchestra exists to refine user intent into maintainable governance text.
• Re-triggering: Future users should not have to repeat a meta-instruction; Skill-targeting request + this subsection are the standing trigger for the process described here.

1. Read the latest version fully.
2. Run a meta-orchestra: sample as many distinct Slot A/B pairs as meta-stakes justify (same push N / stop on saturation idea as product work—not a token “two roles and done”), with orthogonal lenses: no single blended “meta reviewer” voice. Include meta labels such as taxonomist, editor, license reader, information architect, taxonomy writer for AI discovery, expert AI keyword engineer, and precision-oriented pairs—e.g. [terminology-first, zero-prior-context][taxonomy writer for AI discovery]—and produce distinct critiques: discoverability, safety, ambiguity, trigger coverage, redundancy vs missing depth, missing governance, epistemic drift (where the text might encourage invention or flattery), agreeableness traps, definition drift (terms used before they are pinned in Lexicon).
3. Integrate — Merge meta-findings by theme_key (same Convergence discipline as product work): collapse duplicates, mark conflicts, weight surviving ideas (novelty, severity, evidence)—then decide what is worth an edit.
4. Edit only for a clear gap exposed by those passes—not for a fancier role name alone.
5. Enrich the word banks and companion references when a recurring product domain appears (e.g. rhythm games → add tempo, syncopation, input latency lenses in reference-word-banks.md; add a subsection to reference-depth-domains.md when a new product class stabilizes).
6. Re-read and repeat until multiple orthogonal meta-roles find no high-value edit—same saturation bar as Quality ceiling (honest) in the orchestra section (no new failure modes, no churn).

Why more edits can follow “we already reflected” (not a contradiction)

Including taxonomy / keyword / editor stances in the banks does not mean the markdown was ever fully proved optimal in advance. It means you can run those passes when needed.

• Reflection is episodic: meta-orchestra runs when a human or task triggers it—not as a perpetual background audit on every file version.
• Requirements move the target: each new ask (rename skill, add sources, tighten YAML, fix ambiguous “medium”) changes what “correct” means; new deltas are expected, not failures of the prior pass.
• Roles are orthogonal: a pass heavy on discoverability may not have spent tokens on terminology precision or Slot A definitions; a later [terminology-first][…] pass can still find non-overlapping gaps.
• Honest epistemics: “We reflected once” is weak evidence that nothing remains—only re-run and get silence under the stop rules is strong evidence for this scope.

Treat prior reflection as version N; new work produces N+1—same as brownfield product code.

Calibration: breadth, verification, churn, and risk are separate axes. Prefer maximum justified capability (coverage, precision, triggers) over artificial brevity or “infinite keywords” with no new failure modes. If two phrasings carry the same information, merge them; if one phrasing removes a real gap, keep it regardless of line count.

Meta-orchestra output template (use on this skill or any workflow doc)

Each fresh agent returns tagged bullets only (no shared memory). The editor role integrates.

## Pass ID: <date or label>

### [lens tokens][stance tokens]
- Finding:
- Finding:

### [lens tokens][stance tokens]
- ...

## Integration
- Merged themes (hash-map keys): ...
- Conflicts to resolve: ...
- Adopted edits (must pass Work Filter): ...
- **Roles sampled this pass** (audit trail): `[Slot A][Slot B]`, …

Illustrative meta-pass on this document (roles → findings → synthesis)

The table below is a worked example of the meta-orchestra pattern, not an audit log of every revision. When self-editing this skill, run fresh composed roles until the same stop signals as product work: no new themes, repeated findings, or Work Filter rejection—see Quality ceiling (honest) above and Stop rule for orchestra waves in reference-workflow-registers.md.

Composed role	One-line finding
[modern-UX-led, accessibility-first][design systems critic]	“Modern” was undefined; readers need a checklist (hierarchy, motion, dark parity, trust states).
[discoverability-first][taxonomy writer for AI discovery]	Description and body lacked user-voice triggers like “design should be modern” or “feels dated.”
[brownfield-proportional, skeptical][principal engineer]	Without guardrails, “modernize” becomes churn; tie to smallest tokenized wins and the Work Filter.
[trust-and-patterns-focused][UX researcher]	Contemporary UI guidance must mention deceptive patterns and honest loading—not only color and type.
[structural-dedup-minded][information architect]	Avoid duplicate long craft lists; one primary “modern surface” section, cross-link related material so readers find truth in one place.
[uncertainty-explicit][new reader of this skill]	“Top level” is pinned in Lexicon as Top level (honest); Quality ceiling points there—saturation, not mysticism.
[terminology-first, YAML-description-minded][expert AI keyword engineer]	YAML, Trigger phrases, and Precision, clarity, and discoverability should share orchestra / composed role / P0 vocabulary without duplicate near-synonym spam.
[epistemic-drift-hunter][editor]	Illustrative table can read like a stale changelog; label it as example and point to rolling self-application.
[session-structure, round-semantics][technical writer]	“One round, many agents” needs a crisp definition: one outward reply vs inner re-merge loops; tie to Orchestra wave in Lexicon.
[discovery-first, YAML-description-minded][expert AI keyword engineer]	Skill discovery needs parallel vocabulary for normal vs thorough (“surgical,” “blockers,” “full pass”) in YAML + trigger table so agents infer improvement_mode without a scripted menu.
[ambiguity-sensitive][editor]	Label improvement_mode = normal as lighter scope so it is not confused with “normal quality” or “essential product features” jargon; keep one clarifying question pattern.
[maintainer-minded][SDK maintainer]	Treat reference-*.md as one skill package with SKILL.md: on conflict update the contract first; keep word-bank headings consistent (Slot A lists never filed under Extended Slot B).
[consistency-minded][expert AI keyword engineer]	Recursive self-application must repeat multiple [Slot A][Slot B] draws explicitly; otherwise meta-review collapses to one generic critic and contradicts Execution contract.
[structural-dedup-minded][information architect]	Core idea line should point to Convergence wherever merge/weight is discussed—not only Integration scaffolding.
[convergence-aware][principal engineer]	Recursive self-application needs an explicit Integrate (merge meta-findings by theme_key) before line edits—same pattern as product work.

Synthesis (rolling): the skill has since gained Intent over keywords, Epistemic and interpersonal discipline, Quality ceiling, prompt-upgrade naming, YAML epistemic line, step-2 domain of strength, companion refs, platform/depth/register files, Lexicon, why edits after reflection, one user round / many roles, Read order (cold start) aligned to scroll order, improvement_mode (normal vs thorough) with disambiguation, Execution contract, Convergence (infinite roles → few decisions → stop), meta-orchestra tied to multi-role sampling plus an explicit Integrate step before edits, explicit skill package coherence (SKILL.md + reference-*.md, word-bank section hygiene), Precision, clarity, and discoverability (AI/indexer alignment; Top level (honest)). Re-run meta-orchestra whenever behavior drifts; extend the table only when it teaches a new failure mode.

Staying on the right path (anti-drift)

• Every new paragraph must help sampling, integrating, verifying, or governing—not generic inspiration.
• Prefer one canonical section per concept across files; link instead of duplicating full matrices in SKILL.md. Do not add a section that only restates what Snapshot, Workflow, orchestra / complement-bias, target coverage set, or illustrative already encode—see Document length → Structural deduplication (same failure mode as a redundant “Q&A protocol” or “we are dynamic” Lexicon row).
• When depth references and SKILL.md disagree, fix the contract (SKILL.md) first, then align references in the same edit session.
• Epistemic hygiene belongs here too: if a paragraph would encourage inventing context, flattering the reader, LLM-default filler, or loop-trapped reasoning without orthogonal escape, delete or rewrite it until it only rewards observed or clearly labeled inference—aligned with Professional voice, loop escape, and multi-angle thinking.

Done criteria

When the artifact under review is this skill (or its companion markdown), read product as the documentation package: clarity, discoverability, internal links, and honest scope statements matter as much as they would for shipped UI copy.

• The product is defensible as production-ready for its stated audience: main flows work or are honestly unverified; risks and gaps are named, not hidden.
• First-time users can infer goals, controls, and consequences where applicable.
• Visual, textual, and auditory languages feel intentional and licensed.
• Accessibility, localization, and reduced-motion needs are considered.
• No obvious hot-path waste; fragile persistence/network/deploy paths are addressed or flagged.
• Maintainers can change the work safely.
• No obvious adjacent omissions; no redundant work; no performative work; claims match evidence.
• When the artifact is this skill package, companion files follow Staying on the right path: SKILL.md wins on contradictions; reference-word-banks.md stays Slot A/B-clean under correct headings.

Include only:

• What improved
• Verification performed
• Residual risk, if real
• How to run or configure, if useful
• Notable resource/licensing decisions if any
• For meta-review / recursive self-application on this skill: optionally list composed roles sampled and merged theme_keys so the audit trail matches Execution contract and Convergence

If no useful work remains, say that plainly. Avoid filler and file-by-file changelogs unless requested. After scoped optimization passes governed by this skill, honor Outward closure discipline unless blocking exceptions apply (Skill-first reasoning & outward closure).