Prompt Upgrade

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](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 () 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](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](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](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](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

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: alpiex1336-code
• Source: alpiex1336-code/skill-package
• License: MIT

Install and usage instructions live in the source repository linked above.