EVA / tree

Which prompt do you need? Answer one question at a time, or search by what you're trying to do.

What's your situation right now?

Never run EVA/Petrova here before Onboard · 4 prompts
I'm here — what's the state? Orient · 11 prompts
I need to record or justify a choice Decide · 6 prompts
I'm scoping work to do next Plan · 23 prompts
I'm doing the work Execute · 77 prompts
Something's off / I'm stuck Stuck · 15 prompts
Am I done? Verify · 13 prompts

Or: let the harness drive itself 13 chains that run the steps above for you →

Let the harness drive itself

What should the harness do for you?

These are chains, not single steps: each one runs several prompts from the branches below for you.

Bring a fresh repo into the fleet eva-onboard Bring a fresh repo into the fleet end-to-end via the bootstrap prose flow, the operator registry-PR gate, and an idempotent onboard resume.
Bring an app onto TOLL, gates/CUPEL and Orbit, rail by rail estate-onboard Orchestrates one app through the estate's rails in a fixed order, each with an entry check and a derived done condition - registry and contract, gates file with demand and TOLL gates, TOLL consumer (sandbox, then live by ruling), CUPEL leaves for code gates, an Orbit project seeded with metadata, staff guides, and a clean reconcile. It runs the existing prompt for each rail, stops at every operator act, and keeps a per-app ledger with the command that proves each rail.
Pick the single next highest-leverage move eva-next Read EVA workflow state + fleet.context and pick the single highest-leverage next prompt; emit the dispatch envelope. Does not invoke.
Plan → queue → execute one goal, step by step eva-flow Plan→Queue→Execute on a goal; plan the feature, emit an eva-task-batch, and advance exactly one step with a strict-JSON envelope.
Run one governed autopilot tick eva-tick Run a single governed petrova-autopilot iteration; pick and kick the next petrova verb and emit a progress_signal with predict_next and wake_seconds.
Cross the phase boundary (verify → close → open) eva-cycle Run the phase-boundary chain (verify-round → phase-close → optional phase-open); halt at first FAIL and draft a decision doc if an invariant slipped.
Respond to the latest red signal eva-recover Respond to the latest red signal — triage the failure, draft a decision doc with ≥2 alternatives, then plan the fix with halt gates and a verification round.
A script's CLI drifted from an external tool eva-cli-drift-recover A wrapper script assumed a CLI flag/subcommand shape an installed external tool no longer has. Diagnose the real contract, fix the script (not the invocation), verify, never bypass with a flag or env-var escape hatch.
Governance gauntlet, one PASS/WARN/FAIL table eva-health Run the read-only governance gauntlet (doctor, drift, boundary, invariant, MR, supersession) and emit one PASS/WARN/FAIL table with evidence.
Ratify a new fleet baseline eva-baseline Ratify a new fleet baseline after an all-PASS health pre-flight; declare the baseline with the live audit snapshot embedded. Refuses if the audit is red.
Ask a question, evidence-bound eva-ask Answer a question with an evidence-bound RAG pipeline; emit answer, evidence, and a validator verdict. Refuses-with-gap on insufficient evidence.
Re-project the handbook + manifest eva-project Re-project the handbook + command-manifest pair from the live catalogue. The only writer of the pair.
Plug this repo into the EVA timeline for its current phase eva-plug-in Chain eva-phase-manifest, eva-automation-triage and eva-automation-install for the current phase, halting at the first gate. Leaves the repo with a phase manifest, triage verdicts and, where justified, a draft PR of guarded automations.

See this step as a diagram →

Never run EVA/Petrova here before

How cold is the start?

Pick by how cold the start is. Once you're set up, move on to Orient.

Brand-new machine petrova-onboard Initialise a registered consumer repo's mechanical petrova floor — write `.petrova/contract.yaml` + install the `docs-invariants` workflow, via the `petrova_onboard` verb.
Repo present, env not wired petrova-bootstrap Bootstrap a bare-bones consumer repo into petrova shape (CLAUDE.md, MILESTONES.md, AGENTS.xml, docs/ scaffold).
Installing into a sibling repo petrova-install-playbook Step 0 of consumer onboarding. Deposit the petrova playbook (META-RULES.md, 00-bootstrap.md, partials, progress schema) into a consumer repo's `.petrova/playbook/` so subsequent bootstrap prompts can resolve `{{...}}` references against literal local paths.
Handing off to a fresh agent mid-task session-handoff Writes the handoff a fresh agent can actually act on — verified facts separated from beliefs, the exact commands that produced them, what is deployed vs merged vs open, and what is still UNPROVEN. Refuses to hand over false greens.

See this step as a diagram →

I'm here — what's the state?

What do you need to see?

All read-only. Pick by scope: fleet → repo → tooling → governance → changes → docs.

Whole fleet at a glance petrova-fleet-snapshot Produce or refresh fleet_snapshot.yaml for a slug from registry + remote state.
Is this repo healthy? petrova-health-check Five-dimension health snapshot: build, tests, docs freshness, decision-doc velocity, drift signals. Letter grade A–F.
Is my tooling healthy? petrova-doctor Read-only preflight — submodules, contract, registry entry, branch protection. Emits structured readiness JSON for petrova-autopilot.
What governance exists? petrova-governance-inventory Read-only governance scan: surface every governance signal in this repo and gap-rate against PETROVA.
What on MARY's governance snapshot needs attention? mary-governance-diagnose Read ONE mary.governance-snapshot.v1 run. Return at most five cited, label-GENERATED statements naming what needs attention, as strict JSON. Zero is a valid answer. A deterministic verifier (verify.sh) decides what renders.
What changed since X? petrova-changes-since What changed since {{since}} — git log + file deltas grouped by area, with intent summaries and privileged-path flags.
Are the docs current? petrova-doc-freshness Flag every docs/ file whose claims are now wrong because the underlying code changed and the doc didn't (MR-12 enforcement).
What is filed twice across the estate's knowledge stores? knowledge-dupes-review Triage the estate's duplicate-cluster report from scripts/knowledge-census.py. Labels each cluster as a dup (the same act or lesson filed twice) or a topic (related, cross-link only), names the routed home per the estate knowledge routing ruling, and proposes the pointer or cross-link for each copy. Read-only.
What manual ops should become Routines? petrova-routine-archaeology Read-only scan that surfaces manual operations worthy of becoming Claude Code Routines; emits ranked candidate specs.
What does my current phase still need to close? eva-phase-manifest Resolve a PETROVA-wired repo's current phase and acceptance gates, assess each with dated evidence, and route every open gate to the prompts, skills, workflows or human actions that close it. Read-only; writes .eva/phase-manifest.yaml.
Which screens does a product's demo account leave empty? demo-coverage-audit Read-only map of every screen a prospect sees in a product, the endpoint that feeds it, the tables behind it, and whether the demo seeder fills it. Output is a ranked gap table. Field-derived from the sparki-tools scoping on 2026-10-18.

See this step as a diagram →

I need to record or justify a choice

What kind of decision?

Capture one decision, weigh options, freeze a baseline, check against the north star, or record the GO a host write needs before it happens.

Capture a single decision petrova-decision-doc Author a dated, append-only decision doc at docs/decisions/YYYY-MM-DD-`slug`.md (MR-7).
Weigh options / ADR petrova-adr-tradeoff Architectural decision review — enumerate pains, options, rejection reasons, chosen + accepted trade. Drafts a decision doc.
The spec's default would block everything, or a 'turn it on' would break prod: stop and lay out three options spec-blocked-feature-stop Stops a change whose spec-correct default would block everything, because nothing yet exists that can produce the artifact the spec requires, or because flipping a setting would break production. Presents three options (build the missing tool and stay strict; stay strict and disclose the capability as unavailable; relax only through a decision with human sign-off) and researches before any flip.
Freeze a current-state baseline petrova-declare-baseline Ratify a new fleet baseline (v2, v3, ...) as a decision doc in petrova-codes; verb pre-flight refuses if any MR audit check fails.
Check alignment with the north star petrova-north-star-align Sample recent commits/PRs and judge whether each served the north-star, load-bearing infra, or backlog (MR-1 enforcement).
Authorise one write to a VPS deck (GO record, FLIGHT ratifies) deck-act-go Drafts the per-deck, per-act GO record (status proposed) that must exist before any write to a VPS deck — move, stop, firewall, DNS or provider API verb — with preconditions as refusal conditions, pass criteria, rollback and a spent line; then hands FLIGHT the ratification ask in plain English.

See this step as a diagram →

I'm scoping work to do next

What are you planning?

Pick by unit of work. plan-feature gives a human-readable scope; meta-prompt-generator gives a prompt an agent can run.

One feature, one repo petrova-plan-feature Translate a feature ask (vague or specific) into PETROVA-shaped scope: north-star sentence, tasksets with deliverable+verification+gate, reuse-first.
Bundle of tasks task-bundle-planner Decompose a goal + acceptance criteria into a TaskBatch — a structured queue of single-pass tasks, each grounded in a /map node with pre-bound args. Used by `eva tasks sync` to populate the EVA task backlog.
An implementation prompt for a downstream agent meta-prompt-generator Transforms "I want to do task X" into a rigorous, subagent-driven implementation prompt for a downstream coding agent — ground-truth-first, phased, diff-evidenced.
Add a milestone to the roadmap petrova-milestone-add Append a milestone entry to MILESTONES.md (used to land MR-2 deferred items).
Cross-repo execution graph repo-dag-generator Audit a repository and emit state.md + graph.md + per-node prompts/*.md — the execution plan for a fleet of agents to finish the repo.
Open a governance phase petrova-phase-open petrova-phase-open
Which recurring phase steps earn automation? eva-automation-triage Score every step in .eva/phase-manifest.yaml as automate, segment or keep-manual against a fixed rubric, citing which clauses held. Read-only; adds the triage block to the manifest.
What stands between a repo and revenue (gates-to-revenue) Which layer of the gates pattern? · 12 options
Find out whether anyone wants it (PLAY-010 discovery round, behind every demand gate) Which step of the discovery round? · 4 options

See this step as a diagram →

What stands between a repo and revenue (gates-to-revenue)

Which layer of the gates pattern?

A pipeline, not a menu: map a repo's gates once, sweep the estate for the queue, drive one repo, cut code-shaped work into CUPEL tickets.

Map one repo's gates into .petrova/gates.yaml gates-map Layer 1 of the gates-to-revenue pattern. Reads a repo's milestones, decisions, billing path and live surfaces, and writes .petrova/gates.yaml (schema gates/v1) with the validator and its CI step, so every gate's state is derived from evidence files rather than typed in.
Sweep every registered repo's gates into one queue gates-sweep Layer 2 of the gates-to-revenue pattern, across the estate. Reads every registered repo's .petrova/gates.yaml from its default branch via the GitHub API, derives state with the shared validator, and reports what waits on the operator, what an agent can take, what a non-engineer can walk, and which repos have no gates yet. Read-only.
Drive one repo's next movable gate gates-drive Layer 2 of the gates-to-revenue pattern, for one repo. Derives gate state with the validator, then takes the next movable thing - an agent-ready gate, a draft that turns an operator ruling into approve-or-close, a walk kit for a non-engineer - and records every move as evidence, never as an edited status.
Cut one agent-executable change under a gate into a CUPEL ticket gates-cupel-leaf Layer 3 of the gates-to-revenue pattern. Takes one code-shaped piece of work under a gate and writes it as a CUPEL ticket plus trace, with a RED command observed failing before GREEN, then links the trace from the gate's cupel list. Refuses work that cannot be made falsifiable - that stays gate work.
Draft a decision record for one uncleared ruling, for the operator to countersign gates-rule Reads the evidence behind one uncleared ruling blocker and drafts a decision record that sets out the question, the options and a recommendation, with an unticked countersign. The operator countersigns it on jzero /approvals and gates-scribe then clears the blocker, so the ruling is made without the operator editing a file.
Record cleared_by for rulings whose evidence already records a human sign-off gates-scribe Finds ruling blockers whose evidence file already exists but whose cleared_by was never set, confirms each file records the ruling with a human sign-off, and sets cleared_by for the confirmed ones in one PR per repo.
Project one product's human-owned gates into Orbit tasks for staff orbit-gates-seed Reads one repo's .petrova/gates.yaml, derives state with the shared validator, and reconciles the product's Orbit project against it through the Orbit MCP - one parent "Launch to revenue" task and one sub-task per unmet operator or non-engineer gate, matched by gate id so a re-run never duplicates. Orbit only shows the gates; the repo decides them.
Rewrite a product's support runbooks as plain family guides orbit-guide-write Rewrites one product's engineering support runbooks as short task guides a non-technical family member can follow, in the style of the Chronicle guides - no code, ids, file paths or engineering words, "pass it to Alex", captioned screenshots - and commits them to the product repo beside the runbooks, checked by guide_lint.py. Facts come only from the runbooks; anything they do not settle becomes "ask Alex".
Post a product's family guides into its Orbit Docs orbit-docs-sync Fetches a guide (or runbook) directory from GitHub at an exact commit, checks family guides against the plain-language standard, uploads their screenshots, posts each page as a child of an operator-made parent page through the Orbit MCP, then writes the set's README onto the parent as an "I want to…" index linking the Orbit pages. Re-runs update in place.
Hand an Orbit task to the next agent, or pick one up (CUPEL handoff record, re-derived first) orbit-handoff Emit mode writes a CUPEL handoff record (handoffs/HO-<task>-<seq>.yaml) in the product repo, where every state claim carries the command that reproduces it, links it from a one-line Orbit task comment and labels the task handoff:open. Resume mode is CUPEL's HOLDDOWN gate - re-derive every claim of the latest record before touching anything, record what changed, then claim the task.
Find where Orbit tasks drifted from their gates orbit-reconcile For every Orbit project seeded from a gates file, derives each gate's labels and state (gate_meta.py), reads the project's tasks, and reports drift with orbit_reconcile.py - Todo with a blocker, Backlog without one, Done but unmet, met but open, orphaned gates, people-owned gates with no task, and label drift. Report-only unless a tasks:write token is available, and even then fixes only labels and status; Source, relations and new tasks stay operator or browser asks.
Audit one project end to end, gates to public exposure, into a ranked drive-now list estate-audit Read-only. For one enrolled project (or every registry repo in coverage mode), runs nine lenses — gates, tracker, guide truth, loop exceptions, live truth, public surface, content pipeline, personal exposure and opportunities — reusing the latest artifact of the cycle that owns a lens when it is under seven days old, and ranks every finding into a "drive now" list that respects the project's holds and freezes. Field-derived from the Sparki audit of 2026-11-11.

See this step as a diagram →

Find out whether anyone wants it (PLAY-010 discovery round, behind every demand gate)

Which step of the discovery round?

A weekly loop, not a menu (cycle discovery-round). The agent prepares; the operator sends every message by hand. Candidate data stays in ~/discovery, outside every git tree.

Shortlist up to 30 people from the operator's public Bluesky rings (read-only, never contacts) discovery-shortlist PLAY-010 v2 step 2 — run the read-only scout CLI over the operator's public Bluesky rings and an operator-named segment, writing at most 30 candidates to a private round dir outside every git tree. Never contacts anyone.
Write open interview questions, no pitch discovery-brief PLAY-010 v2 step 3 — write the round's open interview questions from the operator's hypothesis and segment, with no pitch, into the private round dir.
Draft the first message; record the sha256 of the version the operator approves discovery-script PLAY-010 v2 step 3 — draft first-message script versions from the brief and the last round finding; after the operator approves one, record the sha256 the guard computed. The agent never sends.
Close the round: synthesis from operator notes, one change for next round, gate finding at DEMAND-NOT-MET discovery-synthesis PLAY-010 v2 round close — synthesise only from the operator's notes and outcomes.log, every claim citing a note; draft the round finding (one change for next round) and the app gate finding at result DEMAND-NOT-MET; write an aggregate-only round report. Never writes DEMAND-MET.

See this step as a diagram →

I'm doing the work

What are you executing?

The biggest branch. First decide: are you orchestrating, wiring, authoring, publishing, or running a fleet op?

Multi-step task, one repo orchestrate-multistep Executes one step of a JSON plan; emits strict-JSON handoff with predict/wake/learn fields per autopilot loop semantics.
Cross-repo DAG repo-dag-executor Drive a shell-script harness that dispatches Claude Code Task sub-agents against an audit DAG until every node verifies green.
Refactor with hard limits refactor-with-constraints Surgical refactor of a single file under named constraints; produces diff + rationale + risks.
Let the autopilot drive petrova-autopilot Reads readiness, picks the next petrova verb, dispatches via kick, and chains until DONE or operator gate.
Propose a fix for a known issue petrova-propose-fix Open a fix PR bound to a prior diagnose run. Validates that the diagnosis_id resolves to a real recent diagnose output and that every proposed change carries explicit MR grounding.
Land one security fix in a submodule: TDD, independent review, fold findings, merge, pin the gitlink security-pr-review-loop The end-to-end loop for one security-sensitive change in a submodule of a governed umbrella. Implement in a fresh worktree off origin/main with TDD, get strict CI green, get an independent read-only security review, fold every MEDIUM+ finding into the same PR (re-review after a BLOCK), log LOW findings as gap rows, merge, then bump the umbrella gitlink one submodule per commit.
Bump nestr's engine or registry gitlink with the refusal-code snapshot in the same commit refusal-code-catalogue-maintenance Keeps nestr's refusal-code catalogue (`docs/specs/refusal-codes.yaml`) and its snapshot pinned to the exact engine and pellets-registry gitlinks in step. Every engine or registry gitlink bump runs `scripts/check-refusal-codes.sh --write-snapshot` in the same commit, so the bump goes by PR, not direct push.
Wire a sibling system Which system? · 11 options
Author content / harness What kind of content? · 13 options
Publish content downstream What stage of the content pipeline? · 15 options
Make an org's landing page say exactly what the product does, at the quality its price implies Which pass of the landing-truth method? · 6 options
Fleet infrastructure op What kind of fleet op? · 23 options
Retire a host, domain or deck (consumers first, DNS last) surface-retire Takes a domain, app, service or whole deck out of service in the only safe order — consumers, router, probes, CI, DNS last — then writes the decision naming what it supersedes. The deck variant adds a 48-hour quiet watch and hands the subscription cancellation to the operator.
Consolidate one repo's local clones, worktrees, branches and stashes into one checkout local-checkout-consolidate Takes one repo's local sprawl (extra clones, sibling and .claude worktrees, merged branches, stale stashes) down to a single clean primary checkout on the default branch. Order is fixed — inventory, archive, operator gates, execution, verification. Nothing is deleted before it is bundled, and nothing the inventory cannot prove landed is deleted at all.

See this step as a diagram →

Wire a sibling system

Which system?

Contract-drift wiring lives under Stuck: you reach for it when you suspect drift, not during normal setup.

ares petrova-wire-ares Draft the ARES wire-decision doc and describe the manual contract.yaml evidence-block update; no dedicated wire-verb exists in petrova-codes.
crumb petrova-wire-crumb EXPERIMENTAL — describe intended CRUMB wiring shape; no backing verb in petrova-codes yet.
eva petrova-wire-eva EXPERIMENTAL — describe intended EVA prompt-library wiring shape; no backing verb in petrova-codes yet.
rocky petrova-wire-rocky EXPERIMENTAL — describe intended ROCKY RAG wiring shape; no backing verb in petrova-codes yet.
traceo petrova-wire-traceo Draft the TRACEO wire-decision doc and describe the manual contract.yaml evidence-block update; no dedicated wire-verb exists in petrova-codes.
Generic integration petrova-wire-integration Flip a registered consumer's `.petrova/contract.yaml` integration block from pending → wired with a validated evidence object. Generic over ares/traceo/crumb/rocky/eva.
An HTTP API as MCP tools mcp-provider-wire End-to-end flow for exposing an existing HTTP API as MCP tools through the pebble gateway — config, self-disable, registry dispatch, corpus entry, tests, and the two traps that mocked tests cannot catch (wrong auth scheme, wrong route).
An app's checkout and paid access onto the TOLL gate toll-consumer-wire Wires one consumer app's server to the TOLL gate. Checkout goes through toll.checkout with a namespaced subject, and paid access is read from toll.entitlements with a short cache, an explicit timeout and fail-closed denial. For an app that already bills Polar directly, it moves the entitlement source to TOLL behind a flag, keeps the app's ledger, plan-change and refund logic, and stops the local webhook from deciding access. One PR in the consumer repo; secrets and flag flips stay with the operator.
Register an app as a TOLL consumer (gate side: capabilities, spec, tests) toll-consumer-onboard Lands the null0-toll side of onboarding one or more consumer apps. One PR proves (and if red, fixes) that one Polar customer can hold paid access in two consumers at once. It also registers each consumer's capability strings, declares adopted Polar products in toll.spec.yaml by exact name, pins each consumer with tests/consumers/<kid>.test.ts, and writes the operator's onboarding record into the cutover runbook. Secrets, TOLL_CONSUMERS and Polar writes stay with the operator.
Several apps onto TOLL in one gated pass toll-consumer-wave Orchestrates moving several apps onto the TOLL gate in one pass. G0 collects the operator's rulings. T runs toll-consumer-onboard once for every app, including the multi-consumer subject fix. O1 is the operator's TOLL_CONSUMERS and Polar gate. W runs toll-consumer-wire for each app in parallel isolated worktrees. V runs sandbox drills plus the cross-app same-customer probe. R records the result. Each phase hands off with an explicit gate, and nothing proceeds on an assumed GO.
Join a content tool's taxonomy (Notion…) to a repo's, by verified key devaqua-taxonomy-bridge Add a verified join-key field linking an external content tool's human taxonomy (e.g. Notion lesson tags) to a repo-owned taxonomy (e.g. COACH milestone slugs), without retagging or guessing.

See this step as a diagram →

Author content / harness

What kind of content?

Handbook and brand content, test harnesses, the four-stage RAG pipeline, or direct fleet MCP calls.

Audit a product UI before redesigning it: controls to real work, numbers to window and n (read-only) product-surface-truth-audit Read-only. Before an app-UI redesign, traces each control on each product route to the handler behind it and asks whether it does the work it claims; traces each number to the metric, window and sample size the backend actually computes; and lists fabricated data (seed fallbacks, teaser charts, placeholder-as-default). Field-derived from the nestr web redesign (web#55-#63, engine#84, nestr#233, 2026-10-30).
Impeccable handbook (full) impeccable-handbook-generator Inspect a freshly /impeccable-onboarded project and emit a project-specific IMPECCABLE_HANDBOOK.md plus skeleton sidecar.
Run an impeccable harness impeccable-harness-executor Deterministic orchestrator that drives an IMPECCABLE_HANDBOOK.md to completion via Claude Code Task() sub-agents.
One handbook section handbook-section-generator Synthesises bullet-form notes into a named handbook section in a chosen voice; surfaces contradictions.
Brand asset brand-asset-generator Read BRAND.md + PRODUCT.md and emit a complete BRAND_ASSETS.md with image-gen prompts, palette, and typography for every named surface.
Email-flow verification harness verify-email-flow-harness Plug-in e2e verification of magic-link email flow — dispatch, read the mail over IMAP, click-through in headless Chromium, session assertion. Generic over app base URL, dispatch path, and probe email.
Crumb extraction (raw) crumb-extraction-harness Harness-pattern orchestrator that fans out background subagents across {{target_repos}}, dispatching the crumb-flashcard-extractor per repo with Ruflo memory/KG/intelligence enrichment and autopilot-shaped JSON handoff.
Crumb → flashcards crumb-flashcard-extractor Scan a source repository and emit CRUMB-schema flashcards (20-field strict frontmatter, mermaid-first diagrams) ready to drop into crumb.devarno.cloud.
RAG: rewrite query rag-query-rewriter Rewrites a user query for retrieval — expansion, decomposition, or HyDE — emitting a strict JSON plan.
RAG: rerank chunks rag-chunk-reranker Reranks candidate chunks against a query, balancing relevance and MMR-style diversity; preserves input ids.
RAG: synthesize context rag-context-synthesizer Composes a grounded answer from id-keyed chunks; cites by id; refuses on insufficient evidence.
RAG: validate evidence rag-evidence-validator Audits a RAG answer against its source chunks; pairs each claim to supporting ids and flags unsupported spans.
Call fleet MCP tools via PEBBLE gateway pebble-tools Discover and call fleet MCP tools (petrova, ares, hermes, traceo, github, Proof KB, …) through the one authenticated PEBBLE gateway at mcp.devarno.cloud, using the live /registry + session profiles.

See this step as a diagram →

Publish content downstream

What stage of the content pipeline?

A pipeline, not a menu: run the steps in order. Gate D is the only prompt in the whole catalogue that actually posts.

Declare the org's content arc/manifest content-arc-declare Author or amend an org's arc manifest in abacus _arcs/ (through-line, acts, windows) so a planned content run becomes checkable, not just intended.
Gate A: intake a closed decision into abacus content-decision-intake Gate A — read a closed, countersigned decision doc from a governed repo and, only if it's eligible, emit it as a ledger-artefact into abacus for drafting.
Draft a downlink blog entry downlink-entry-author Turn raw notes or a draft artefact into an abacus blog-post markdown file that projects onto devarno.com/downlink cleanly on the first try.
Project abacus → landing, or check drift downlink-publish Project abacus blog entries onto landing and verify the result, or check for drift between the two repos without touching anything.
Repurpose a shipped entry into a social artefact downlink-social-repurposer Turn a shipped DOWNLINK entry into a platform-native social artefact (X thread, LinkedIn post, Bluesky post, or newsletter excerpt) through a per-platform lens.
Gate D: dispatch the social artefact — the only prompt that actually posts content-social-dispatch Gate D — ask CELIA, through the asgard launch engine, to dispatch one approved, FLIGHT-countersigned social artefact. Dry-run first; posts only when the engine's dispatcher is live. The only prompt that leads to a post.

Alternative, for other orgs

Diagnose what each enrolled app has shipped, and which content classes are open (PLAY-022 sweep, step 1) content-diagnose Step 1 of the content-signal-sweep (PLAY-022). Reads the multi-repo commit scan and each enrolled app's gate state, decides whether class D is open, and writes one diagnosis card per app. Read-only.

Alternative, for other orgs

Suggest ranked content cards from a diagnosis (PLAY-022 sweep, step 2; suggestions only) content-suggest Step 2 of the content-signal-sweep (PLAY-022). Turns each diagnosed signal into suggestion cards in the classes that are open, at most five per app per sweep, then lets code drop what the rules forbid. Output is a feed file. Suggestions only.

Alternative, for other orgs

Measure how visible a project is under the operator's name, and where it is missing (read-only) public-exposure-audit Read-only. For one enrolled project, checks every public place the operator's name lives (personal site, content ledger, social identities) for the project, and the project's own surfaces for the operator; counts ledger artefacts about it by stage; and lists the gaps — shipped work with no artefact, a personal site that only links, a product with no founder line, a ledger with nothing past the inbox. Aggregates only.

Alternative, for other orgs

List openings a project has earned and nobody has opened: write-ups, libraries, listings, talks (read-only) opportunity-scan Read-only. From an estate-audit's evidence, lists openings beyond the current gates — a write-up a real incident earned, a library worth extracting under its own licence, a marketplace or directory listing the product already qualifies for, a talk or case study, an integration a customer would expect — each with the evidence that earned it, the effort, the play that would carry it, and any hold it would cross.

Alternative, for other orgs

Show a sweep's cards as tasks in the private Orbit project CONT, status derived from abacus (PLAY-022 pilot) content-cont-sync Step 3 of the content-signal-sweep (PLAY-022), interim surface. Plans one CONT task per card (title, class, product, a link to the card) with prompts/_shared/orbit/cont_cards.py, posts the plan through the Orbit MCP, and reconciles status from abacus. Done only when a human abacus 00-inbox commit carries the card id.

Alternative, for other orgs

Generalize publish to any org's own surface content-publish-sink Generalizes DOWNLINK Publish's regenerate-verify-drift-check-commit sequence to any org's own render surface, not just landing.

Alternative, for other orgs

Add, change or load a shared vocabulary term (platform, position, system, stage…) abacus-vocabulary Add or change a shared term in abacus _refs/vocabulary.yaml and carry it through the cheat sheet, ledger snapshot and asgard parity test, or explain how a service loads the vocabulary.

Alternative, for other orgs

Keep a static public projection in step with its ledger (pin, stale PR, operator deploy) public-projection-sync Keeps a static public projection in step with a private ledger without the projection ever being produced by a clock, a moving pin or an agent-initiated deploy. Proves the projector is deterministic, pins everything it reads, signals staleness with a PR instead of a deploy, and hands the deploy to the operator.

Alternative, for other orgs

Strip AI-writing tells from a draft before it ships (humanize-lint, rewrite, fact diff) prose-humanize Takes one piece of prose and a voice, strips the AI-writing tells catalogued by blader/humanizer (pinned v3.1.0@225a6f3), and returns a rewrite that says exactly what the original said. The deterministic humanize-lint gate runs before and after; a fact diff sits between them, so no tell is ever removed by inventing something.

See this step as a diagram →

Make an org's landing page say exactly what the product does, at the quality its price implies

Which pass of the landing-truth method?

A pipeline, not a menu: context, then the claims ledger, then funnel and fit, then the operator rules, then the sweep. The flow drives all of it for one org.

Drive one org's landing through the whole method (gates at conflicts, rulings, merge) landing-truth-flow Drives one org's landing page through the landing-truth method: context, claims ledger, funnel, value fit, operator rulings, sweep PRs, live re-read. One step per call, halting at operator gates, with a JSON handoff. Org-modular: every step takes the org, site and repo as inputs. Field-derived from traceo.cat (2026-10-21).
Find the landing source and every document that binds it (read-only) landing-context-map Read-only first pass of the landing-truth method. Locates the landing source, the documents that bind its copy, structure and design, the org's pricing ruling and audience statements, and registers every conflict with what the operator says they want. Field-derived from traceo.cat (2026-10-21).
Trace every claim on the site to code a customer can use today (read-only) landing-claims-ledger Read-only. Classifies every claim on an org's public surface (copy, captions, tables, alt text, metadata, share card) and traces it to the mechanism at a named commit, with a verdict and a customer-usable-today test. Field-derived from traceo.cat (2026-10-21), where code existed for most false claims.
Measure the signup funnel, phone reach, share card and crawlers (read-only) landing-funnel-integrity-audit Read-only, measured on the rendered page. Checks CTAs and links, one primary action per viewport, phone reach, contrast of the primary CTA and brand-colour text, metadata, share card, canonical, robots and sitemap, and layout defects such as empty bands and unsized images. Field-derived from traceo.cat (2026-10-21).
Who buys, what proof they need, which true features carry it, at this price (read-only) landing-value-fit-audit Read-only. From the claims ledger and the binding context, maps each audience to the proof it needs and the TRUE features that supply it, holds the page to the quality its price implies, flags slop, and ranks the product surfaces to show first. Never promotes a feature the ledger did not mark TRUE. Field-derived from traceo.cat (2026-10-21).
Land the ruled fixes as draft PRs, red-first, one per concern landing-truth-sweep The only writing pass of the landing-truth method. From the ledger, funnel audit, value-fit audit and the operator's rulings, opens draft PRs split by concern (hygiene, design tokens, claims), writes a red-first claim test, replaces false copy with ledger-true wording, holds commercially ruled rows, records the ruling in the org's governance convention, and verifies on the rendered build. Field-derived from traceo.cat (#364, #365, #366, 2026-10-21).

See this step as a diagram →

Fleet infrastructure op

What kind of fleet op?

Shared multi-tenant hosts. For liveness, use queue age: a runner's registered count doesn't tell you it's alive.

Bring up a new fleet host from bare machine or VM fleet-host-bringup Takes a bare machine to a serving hermes fleet host under docs/runbooks/fleet-host-bringup.md, then hands it to fleet-host-deploy.md. Encodes the traps a new host hits that an existing one never does — go missing from install.sh, the runner label derived from the hostname, panel registration blocked without a per-fleet cert, host-level podman state that install.sh does not carry, and per-job (not per-host) migration caps.
Roll out install.sh across tenant roots fleet-host-rollout Executes install.sh across tenant roots on a shared multi-tenant fleet host — rollouts, runner version bumps, tenant onboarding. Encodes the two absolute refusals (never dockerd / the docker group; never rsync or hand-edit onto a tenant), demands provenance and a green estate suite before rolling, and refuses to accept a green checkmark as verification.
Retire the eu-1 fleet host with no successor, lane by lane (fleet of subagents) hermes-retire-fleet Conducts a bounded fleet of subagents through the hermes plan that retires hermes-fleet-eu-1 with no replacement host. Gate tooling is built test-first, every org lane closes on `hermesctl retire-gate` going red to green, the box is decommissioned only under the fleet-safety-gate, and the sparki CX33 worker lane runs alongside. Purchases, cancellations, key revocation, countersigns and merges stay the operator's.
Triage an ingest ticket on a shared fleet host fleet-ingest-triage Answers "is the fleet registered and is telemetry flowing?" in one call, then walks the ingest chain — webhook → org → run → job → fleet push — to the exact broken link. Codifies the orphan-job failure mode and the seam that caused it.
Triage podman `exceeded num_locks` or testcontainers readiness on a tenant (read-only) fleet-podman-lock-triage Read-only triage for a hermes fleet tenant whose CI fails with podman `exceeded num_locks`, or with testcontainers readiness waits that "matched 0 times". Finds the tenant's real store, counts what holds the locks, reads the lock ceiling podman actually applies, and checks whether the tenant can read its own container logs. Hands any write to fleet-deploy-runner under the hermes runbook.
Audit what Hetzner bills against the documented baseline (read-only) hetzner-cost-audit Read-only audit of what the devarno estate is paying Hetzner for, and what the next invoice should be. Enumerates every billable Cloud resource through the hcloud CLI (one context per project), lists the Robot boxes, and checks both against the documented baseline. Anything unexplained is reported as a cost to chase, not deleted.
Audit what Railway bills per service, or check whether another PaaS would be cheaper (read-only) railway-cost-census Read-only census of what the estate pays Railway, per service x environment, for one billing cycle. Reads the GraphQL usage API with the account token, attributes memory, CPU, egress and volume to each container, reconciles against the dashboard, and flags egress spikes, idle Postgres floors and dead projects. Also answers "should we move to another PaaS" with the pricing-shape check.
Which apps earn more than they cost, and which to retire (read-only) unit-economics-review Triage the generated monthly unit-economics report (scripts/cycle-unit-economics.sh). Reads per-app revenue, Railway cost, gate progress and demand, and the PLAY-015 retirement proposals; names the one next operator act per app. Read-only.
Is a founding discount about to hit its cap or close its window, so a consumer must stop requesting it (read-only) founding-discount-watch Triage the generated choco founding-discount report (scripts/cycle-discount-watch.sh). Reads the window and redemption halves, says whether the operator must unset choco-gateway's TOLL_CHECKOUT_DISCOUNT now, soon, or not yet, and what is unknown (an unread redemption count). Read-only.
Is every surface running what its main says, and can the live gate take money (read-only) live-truth-triage Triage the generated live-truth report (scripts/cycle-live-truth.sh). Per surface, says whether production runs main, a failed or stuck deploy, or merged config never deployed; for the money path, whether the live TOLL gate is up, verifies webhooks and is watched. Ranks the operator acts and names what was unread. Read-only.
Wire approved automations (Routine now, EVA cycle later) eva-automation-install Turn each automate or segment verdict in .eva/phase-manifest.yaml into a guarded eva.automation.v1 spec, render it as a paste-ready Claude Code Routine (now) and an EVA cycle twin (migration target), and open one draft PR. Never merges, never creates Routines itself.
Move packages, module paths and CI references after a GitHub org rename github-org-rename-migration Moves everything that still resolves through GitHub's rename redirect after an org rename — npm scopes on GitHub Packages, Go module paths and tags, GOPRIVATE/insteadOf rewrites, .gitmodules, workflow repository guards — in producer-to-consumer order, while leaving runtime wire identifiers, secret names and historical docs alone.
Admit a CI workflow to a service by GitHub OIDC, no stored token gha-oidc-machine-identity Admits one GitHub Actions workflow to a service through OIDC workload federation instead of a stored token — a second issuer verified against GitHub's JWKS, an exact allowlist on numeric ids and workflow_ref, a fixed least role, a route and method scope, and a client that fetches the token just in time and pins it to one origin.
Sign an app on another apex in through airlock's cross-apex handoff (Pattern B) airlock-pattern-b-consumer Wires a Next.js app on its own apex to sign in through devarno-cloud airlock's cross-apex handoff. It verifies the 60-second EdDSA handoff token against the airlock JWKS, sets a host-only session cookie, and optionally mints the app's own downstream token server-side. Field-derived from chronicle-cat/app#44 (2026-10-15).
Land one mechanical workflow edit across many repos and orgs gha-estate-batch-edit Applies one mechanical workflow change (timeout-minutes, cron cadence, trigger removal) across many repos and orgs as one PR per repo, without spending CI minutes and without overriding a governed repo's own rules. Encodes the CI-FREE 2026-10-14 field lessons — skip-ci on both the commit and the squash subject, lint-neutral against base, governed orgs routed through their own decision process, and the human merging.
Move one org's gate CI from push/PR to a nightly batch (CI-FREE phase 4) ci-free-nightly-flip Moves one org's gate CI off push and pull_request onto a per-repo nightly-gates.yml that runs only when the default branch moved, using the repo's own GITHUB_TOKEN. Content differs per repo, so it reads each repo's workflows, splits remote-only jobs out, routes dormant repos to dispatch-only, and records an org decision. The human merges.
Plan and get signed off a push-to-nightly CI flip for an org whose gates protect security code gha-governed-org-nightly-flip Plans the CI-FREE push-to-nightly trigger flip for one org whose gates protect security code, and gets it approved as a proposed decision doc before any workflow is touched. Encodes the nestr-tools 2026-10-15 field lessons — advisory pre-merge gates on free-plan private repos, host-bound "local-ok" jobs, arch pins in code, orphaned petrova workflows, stale dependabot PRs, and the human signing off.
Give an org its own heavy-test lab on the Mac's external drive (CI-FREE Mac offload) mac-lab-bringup Gives one org its own test lab on the operator's Mac. That means an APFS sparse bundle on the external drive, Postgres and Redis on loopback ports no other lab uses, the `lab run` recorder, and labtop. Encodes the traps a first lab hits — exFAT drives, non-login PATH, the wrong Postgres major, the locale crash and the zsh word-splitting of ssh options.
Hand refused or operator-only production steps to the operator as one rehearsed wizard operator-wizard-handoff When the permission classifier refuses a production step, or governance reserves it for the operator, prepare and rehearse everything read-only, then hand the operator ONE hardened wizard script built from the wizard template. It is not a pile of copy-paste commands. The agent then verifies independently and continues the chain. Encodes the traps a first hand-off hits — the wrong database on a shared server, a raw tty, a pager that looks like a stall, re-runs that hit done steps, "dry runs" that write, and full-restore rollbacks that fail on new dependents.
Provision a Traceo workspace + baseline so a consumer's traceo probe reads ok traceo-workspace-baseline-provision Provider-side counterpart to petrova-wire-traceo. Gets a consumer's traceo probe to ok by putting its baseline where production actually serves baselines from (traceo-cat/ariel baselines/*.md at the pinned ariel rev), creating a same-tenant workspace the sanctioned way, repointing the OIDC trust entry, and verifying with an authenticated GET and a probe run.
Fill a product's demo@ account with realistic data, end to end (identity, seeder, env, plan, verify) demo-tenant-provision Drives one product from "no demo account" to "demo@ signs in to a populated, verified, resettable workspace". It runs the identity, coverage, seeder, env, reset, plan and verify steps in order, and halts at each operator gate. Field-derived from smo1-io (purr-api seed-demo, back-test) and sparki-tools (api-engine PRs 53, 60, 65 and 66, pilot, 2026-10-18/19).
Get a demo@ login into airlock and read back its user id for the product env demo-identity-bootstrap Gets a product's demo@ login into devarno-cloud airlock and reads back its user id for the product's demo env vars. It invites, halts for the operator's magic-link sign-in, then reads the id from the airlock database read-only. Never sets secrets. Field-derived from sparki-tools 2026-10-18/19 and smo1-io.
Write or extend a deterministic, guarded, resettable demo seeder demo-seed-author Writes or extends a product's demo seeder using the pattern proven in smo1-io purr-api (seed-demo) and sparki-tools api-engine (pkg/demo). A pure plan built from now, one transaction, seed and reset modes, demo-owned deletes only, an id+email guard, per-screen tests and a runbook. Opens one PR.

See this step as a diagram →

Something's off / I'm stuck

What kind of stuck?

Pick by what kind of wrongness: a failure, silence, drag, an observation, or one of the drift-class checks.

A run failed petrova-failure-triage Map an observed error/symptom to the closest PETROVA error code and prescribe the runbook recovery path adapted to this stack.
Work is sitting idle petrova-stalled-work Find PRs without recent activity, milestones not progressing, decisions open `14 days, findings without paired decisions, branches `30 days unmerged. Group: revivable / blocked / abandoned.
Feels harder than it should petrova-friction-classify Classify a friction item: closed (trivial follow-up) / in-budget (small, lands now) / deferred (next-phase milestone — MR-2). When in doubt, defer.
Capture a one-off observation petrova-finding Emit a raw finding at docs/findings/YYYYMMDD-HHMM-`slug`.md.
Suspect drift between repos petrova-drift-check Probe rank-graph contradictions and named anti-shape drift; surface or resolve.
Suspect a boundary violation petrova-boundary-audit Where can scripts/agents write to sensitive surfaces (workflows, secrets, IAM, db) without going through a reviewable PR? Propose typed verb gates.
Old decision still binding? petrova-supersession-check Find every closed-status decision doc whose claims a proposed change would contradict; draft Supersedes: docs (never edits originals — MR-7).
Upstream dep changed? petrova-upstream-watch Generic upstream-source poller. Cycle author declares the sources (PyPI, GitHub releases, RSS) and notify rules; this prompt classifies deltas as none | minor | breaking | unknown and routes escalations.
Wire a contract-drift detector petrova-wire-contract-drift Walks a contract repo (e.g. proto-schemas) HEAD against every consumer's gen/ checksum. Surfaces silent schema drift before it surfaces as a confusing build error.
Soak an invariant under load petrova-invariant-soak Runs an assertion table from the cycle.yaml against a staging slice. Each row is one project invariant (I-N) with a probe that yields pass | fail | skip.
Suspect a dev-mode auth fail-open auth-fail-open-audit Hunts the specific shape where a dev-mode escape hatch becomes the production front door — an absent identity treated as "auth is off" rather than "the caller did not authenticate". Probes the running service without credentials.
A transactional email was refused or never arrived smtp-sender-triage Traces a missing transactional email from the app log to the provider reply, separates refusal at submission from loss after acceptance, and proves the fix with a delivered message's headers. Treats DNS as a suspect only once the provider has accepted the message.
A workflow fails at Set up job / a `uses:` ref won't resolve action-ref-reachability Sweeps the workflows of a set of repos, classifies every `uses:` reference as reachable, unreachable across orgs, ref-missing or local, and recommends vendoring or inlining with a job-level guard. Proves each fix with the last failing run and the first run after the fix.
Railway app gets `connection reset by peer` from *.proxy.rlwy.net (database service not running?) railway-dead-service-diagnosis Diagnoses a Railway app that crash-loops with `connection reset by peer` to `*.proxy.rlwy.net` when the real cause is that the database service has no running deployment. Proves it read-only, then restores the service on its existing volume with `serviceInstanceDeployV2` and moves the app to the private `${{Postgres.DATABASE_URL}}` reference.
Non-root container gets permission denied on a root-owned volume nonroot-container-volume-permissions Fixes a distroless `:nonroot` image (UID 65532) that fails with "permission denied" on a volume the platform mounts root-owned, such as Railway's `/data`. The approved pattern starts the process as root, chowns only allowlisted paths under the mount with `os.Root` and `Lchown`, then drops to 65532 and proves the drop before any file or socket is opened.

See this step as a diagram →

Am I done?

What are you verifying?

Pick by what you're closing out: a task, a round, a PR, a signal, or a phase. When in doubt, run verify-for-real first.

A single task's AC task-acceptance-check Read-only verifier. Given a Task and a candidate completion artefact, scores each acceptance criterion line-by-line. Output is a structured pass/score block consumed by `tasks/complete`.
A full verification round petrova-verify-round Run the mandatory friction-probe verification round for an open phase (MR-10).
A merge request is green petrova-mr-check Audit a consumer repo against every meta-rule; emit a violations list and a progress signal.
Need human review petrova-request-review Open a PR with explicit file changes and request human review. Validates operator-supplied grounding (decision docs, MR citations, north-star refs) before composing the PR envelope.
Auto-merge when CI passes petrova-request-merge-when-green Open a PR with auto-merge enabled. Profile-gated — only repos with branch protection that permits auto-merge can use this verb. Validates merge_method and grounding before composing the PR envelope.
Is this green signal even real? verify-for-real Refuses the ways a green signal lies — exit code from the wrong process, a cancelled job read as a pass, a suite that is green because of the bug, a suite that collected zero tests, "tests pass" mistaken for "it works", and a broken measurement reporting absence as a clean negative. Drives the real system before any completion claim.
Run a heavy suite on the org's Mac lab and diff it against a baseline mac-lab-offload Runs one repo's heavy verification on the org's Mac lab instead of the workstation, recorded with `lab run` so the operator watches it in labtop. It works for a DB-backed Go suite, a full vitest run or a production build. Private dependencies are packed on the workstation, so the lab never holds a credential. The candidate is compared against a baseline by failing test NAME, and runs report skips and recovered panics instead of trusting the exit code.
Re-derive QA 'pass' verdicts from scratch (fresh session) qa-adversary Fresh-session re-derivation of every "pass" verdict in the QA Check Register, without reading prior evidence, to catch confirmation rather than verification.
Prove a liveness check can fail on its own (dead-man, both arms) dead-man-heartbeat Rebuilds a liveness or staleness check so it runs independently of the job it watches, sets its threshold from measured cadence plus scheduler lag, and proves it on both arms (a planted stale artefact goes red, a fresh one goes green) plus an external vantage that catches "nothing ran at all".
Is the demo account ready for a call? (sign in as demo@, check every page) demo-verify Drives the product as the demo login with Playwright after a reset, screenshots each page on the runbook checklist, checks each expected line, and posts a pass/fail status. Field-derived from smo1-io's manual checklist and the sparki-tools pilot.
Does a consumer's money path hold on sandbox Polar? (full matrix, before live) toll-sandbox-matrix Runs success, decline, abandon, duplicate and out-of-order webhook, refund, cancel, plan change and revoke for one TOLL consumer against the real sandbox gate and sandbox Polar, with a recorded finding and a verify-reviewer. Includes a working lab harness and the way to hold Polar deliveries so that a late event is a first arrival, not a replay.
Write up after-the-fact petrova-post-mortem Reconstruct the trigger chain over a window from commits/PRs/CI, name where the audit trail had gaps, output what would have prevented this.
Close the governance phase petrova-phase-close petrova-phase-close

See this step as a diagram →

Bring a fresh repo into the fleet

EVA onboard — bring a fresh repo into the fleet

eva-onboard draft

Bring a fresh repo into the fleet end-to-end via the bootstrap prose flow, the operator registry-PR gate, and an idempotent onboard resume.

kick eva-onboard Full prompt →

Use it when you'd say

“onboard this repo into the fleet”
“bootstrap a fresh petrova repo”
“bring a new repo into petrova”

Not for

repos that are not petrova-aware

What usually comes next

drives — How cold is the start? drives

← What should the harness do for you?

Bring an app onto TOLL, gates/CUPEL and Orbit, rail by rail

Estate onboard — bring one app onto TOLL, gates/CUPEL and Orbit, rail by rail

estate-onboard draft

Orchestrates one app through the estate's rails in a fixed order, each with an entry check and a derived done condition - registry and contract, gates file with demand and TOLL gates, TOLL consumer (sandbox, then live by ruling), CUPEL leaves for code gates, an Orbit project seeded with metadata, staff guides, and a clean reconcile. It runs the existing prompt for each rail, stops at every operator act, and keeps a per-app ledger with the command that proves each rail.

kick estate-onboard Full prompt →

Use it when you'd say

“onboard an app to toll cupel and orbit”
“get an app into orbit”
“what is left to onboard”

Not for

one rail on its own (call toll-consumer-onboard, gates-map, orbit-gates-seed or orbit-guide-write directly)
money acts or production cutovers (operator wizards)

← What should the harness do for you?

Pick the single next highest-leverage move

EVA next — predict the highest-leverage next prompt

eva-next draft

Read EVA workflow state + fleet.context and pick the single highest-leverage next prompt; emit the dispatch envelope. Does not invoke.

kick eva-next Full prompt →

Use it when you'd say

“what should I do next”
“pick the next prompt”
“cold start a petrova session”

Not for

repos that are not petrova-aware

What usually comes next

recommends from — doesn't invoke — What do you need to see? recommends from — doesn't invoke

← What should the harness do for you?

Plan → queue → execute one goal, step by step

EVA flow — plan, queue, and execute one step on a goal

eva-flow draft

Plan→Queue→Execute on a goal; plan the feature, emit an eva-task-batch, and advance exactly one step with a strict-JSON envelope.

kick eva-flow Full prompt →

Use it when you'd say

“plan and start this goal”
“run plan queue execute”
“advance one step toward a goal”

Not for

repos that are not petrova-aware

What usually comes next

drives — What are you planning? drives

← What should the harness do for you?

Run one governed autopilot tick

EVA tick — one governed petrova-autopilot iteration

eva-tick draft

Run a single governed petrova-autopilot iteration; pick and kick the next petrova verb and emit a progress_signal with predict_next and wake_seconds.

kick eva-tick Full prompt →

Use it when you'd say

“run one autopilot iteration”
“tick the petrova autopilot”
“advance autopilot one step”

Not for

repos that are not petrova-aware

What usually comes next

drives one petrova verb — What are you executing? drives one petrova verb

← What should the harness do for you?

Cross the phase boundary (verify → close → open)

EVA cycle — phase-boundary chain

eva-cycle tested

Run the phase-boundary chain (verify-round → phase-close → optional phase-open); halt at first FAIL and draft a decision doc if an invariant slipped.

kick eva-cycle Full prompt →

Use it when you'd say

“close out this phase”
“run the phase-boundary chain”
“verify and close the phase”

Not for

repos that are not petrova-aware

What usually comes next

drives — What are you verifying? drives

← What should the harness do for you?

Respond to the latest red signal

EVA recover — failure response on the latest red signal

eva-recover draft

Respond to the latest red signal — triage the failure, draft a decision doc with ≥2 alternatives, then plan the fix with halt gates and a verification round.

kick eva-recover Full prompt →

Use it when you'd say

“recover from this failure”
“the build went red, what now”
“triage and plan the fix”

Not for

repos that are not petrova-aware

What usually comes next

drives — What kind of stuck? drives

← What should the harness do for you?

A script's CLI drifted from an external tool

EVA CLI drift recover — fix a script's contract mismatch against an installed external tool

eva-cli-drift-recover draft

A wrapper script assumed a CLI flag/subcommand shape an installed external tool no longer has. Diagnose the real contract, fix the script (not the invocation), verify, never bypass with a flag or env-var escape hatch.

kick eva-cli-drift-recover Full prompt →

Use it when you'd say

“a script calling an external CLI just broke with an unrecognized flag or arg error”
“this tool's interface changed and the wrapper script wasn't updated”
“fix the CLI contract drift, don't route around it”

Not for

failures inside a petrova-governed repo's own verbs (use eva-recover)
application code bugs unrelated to an external tool's CLI surface

← What should the harness do for you?

Governance gauntlet, one PASS/WARN/FAIL table

EVA health — read-only governance gauntlet

eva-health draft

Run the read-only governance gauntlet (doctor, drift, boundary, invariant, MR, supersession) and emit one PASS/WARN/FAIL table with evidence.

kick eva-health Full prompt →

Use it when you'd say

“run the governance gauntlet”
“is this repo healthy”
“read-only petrova health check”

Not for

repos that are not petrova-aware

What usually comes next

reads — What do you need to see? reads

← What should the harness do for you?

Ratify a new fleet baseline

EVA baseline — ratify a new fleet baseline

eva-baseline draft

Ratify a new fleet baseline after an all-PASS health pre-flight; declare the baseline with the live audit snapshot embedded. Refuses if the audit is red.

kick eva-baseline Full prompt →

Use it when you'd say

“ratify a new fleet baseline”
“declare a petrova baseline”
“cut the next baseline version”

Not for

repos that are not petrova-aware

What usually comes next

eva-health in Let EVA drive requires a green run of

← What should the harness do for you?

Ask a question, evidence-bound

EVA ask — evidence-bound RAG answer

eva-ask draft

Answer a question with an evidence-bound RAG pipeline; emit answer, evidence, and a validator verdict. Refuses-with-gap on insufficient evidence.

kick eva-ask Full prompt →

Use it when you'd say

“answer this from the repo evidence”
“evidence-bound question”
“rag query with validation”

Not for

repos that are not petrova-aware

← What should the harness do for you?

Re-project the handbook + manifest

EVA project — re-project HANDBOOK.md + command-manifest.json

eva-project draft

Re-project the handbook + command-manifest pair from the live catalogue. The only writer of the pair.

kick eva-project Full prompt →

Use it when you'd say

“re-project the handbook”
“regenerate command-manifest”
“handbook is stale”

Not for

repos that are not eva-hq (the pack is authored only here)

← What should the harness do for you?

Plug this repo into the EVA timeline for its current phase

EVA plug-in — attach a PETROVA-wired repo to the EVA timeline

eva-plug-in draft

Chain eva-phase-manifest, eva-automation-triage and eva-automation-install for the current phase, halting at the first gate. Leaves the repo with a phase manifest, triage verdicts and, where justified, a draft PR of guarded automations.

kick eva-plug-in Full prompt →

Use it when you'd say

“plug this repo into the eva timeline”
“drive this repo's current phase with eva”
“set up eva automation for this phase”

Not for

repos without .petrova/contract.yaml (run eva-onboard)
crossing a phase boundary (use eva-cycle)
executing the phase's work (use eva-tick or petrova-autopilot)

What usually comes next

starts at the phase manifest — What do you need to see? starts at the phase manifest

← What should the harness do for you?

Brand-new machine

PETROVA onboard

petrova-onboard ready

Initialise a registered consumer repo's mechanical petrova floor — write `.petrova/contract.yaml` + install the `docs-invariants` workflow, via the `petrova_onboard` verb.

kick petrova-onboard Full prompt →

Use it when you'd say

“petrova onboard <slug>”
“run petrova onboard on <slug>”
“initialise petrova floor for <slug>”

Not for

repos not yet in `petrova-codes/registry.yaml` (register first, then onboard)
repos that already have `.petrova/contract.yaml` (use the re-onboard verb instead)
cross-repo batch workflows (one repo per invocation)

What usually comes next

— What do you need to see?

← How cold is the start?

Repo present, env not wired

PETROVA bootstrap (Day 1)

petrova-bootstrap ready

Bootstrap a bare-bones consumer repo into petrova shape (CLAUDE.md, MILESTONES.md, AGENTS.xml, docs/ scaffold).

kick petrova-bootstrap Full prompt →

Use it when you'd say

“petrova bootstrap”
“run petrova bootstrap on this repo”

Not for

repos that aren't petrova-shaped (no `.petrova/contract.yaml`)
cross-repo workflows (one repo per invocation)

What usually comes next

— What do you need to see?

← How cold is the start?

Installing into a sibling repo

PETROVA install playbook

petrova-install-playbook ready

Step 0 of consumer onboarding. Deposit the petrova playbook (META-RULES.md, 00-bootstrap.md, partials, progress schema) into a consumer repo's `.petrova/playbook/` so subsequent bootstrap prompts can resolve `{{...}}` references against literal local paths.

kick petrova-install-playbook Full prompt →

Use it when you'd say

“petrova install playbook for <slug>”
“install petrova playbook on <slug>”
“prepare <slug> for petrova bootstrap”

Not for

repos not yet in petrova-codes/registry.yaml (register first)
repos that already have .petrova/playbook/ (set overwrite: true only when re-syncing after eva-hq upstream changes)
cross-repo batch workflows (one repo per invocation)

What usually comes next

— What do you need to see?

← How cold is the start?

Handing off to a fresh agent mid-task

Session handoff (agent → agent)

session-handoff ready

Writes the handoff a fresh agent can actually act on — verified facts separated from beliefs, the exact commands that produced them, what is deployed vs merged vs open, and what is still UNPROVEN. Refuses to hand over false greens.

kick session-handoff Full prompt →

Use it when you'd say

“hand this off”
“write the handoff”
“summarise for the next agent”
“pick up where this left off”
“end of session summary”

Not for

user-facing release notes (this is agent-to-agent)
decision docs (see petrova-decision-doc)

What usually comes next

— What do you need to see?

← How cold is the start?

Whole fleet at a glance

PETROVA fleet snapshot

petrova-fleet-snapshot ready

Produce or refresh fleet_snapshot.yaml for a slug from registry + remote state.

kick petrova-fleet-snapshot Full prompt →

Use it when you'd say

“refresh fleet snapshot for a slug”
“run petrova-bot probe”

Not for

editing a consumer's .petrova/contract.yaml (forbidden by MR-13/14)

← What do you need to see?

Is this repo healthy?

PETROVA health check (5-dimension)

petrova-health-check ready

Five-dimension health snapshot: build, tests, docs freshness, decision-doc velocity, drift signals. Letter grade A–F.

kick petrova-health-check Full prompt →

Use it when you'd say

“run a health check”
“score this repo”
“health snapshot”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

← What do you need to see?

Is my tooling healthy?

PETROVA doctor (preflight)

petrova-doctor ready

Read-only preflight — submodules, contract, registry entry, branch protection. Emits structured readiness JSON for petrova-autopilot.

kick petrova-doctor Full prompt →

Use it when you'd say

“petrova doctor”
“is this repo ready for the next phase”
“preflight petrova”

Not for

mutation (read-only)

← What do you need to see?

What governance exists?

PETROVA governance inventory

petrova-governance-inventory ready

Read-only governance scan: surface every governance signal in this repo and gap-rate against PETROVA.

kick petrova-governance-inventory Full prompt →

Use it when you'd say

“run a governance inventory”
“audit governance signals”
“gap-rate this repo against petrova”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

← What do you need to see?

What on MARY's governance snapshot needs attention?

MARY governance diagnose (P6-L3 GENERATED statements)

mary-governance-diagnose draft

Read ONE mary.governance-snapshot.v1 run. Return at most five cited, label-GENERATED statements naming what needs attention, as strict JSON. Zero is a valid answer. A deterministic verifier (verify.sh) decides what renders.

kick mary-governance-diagnose Full prompt →

Use it when you'd say

“diagnose this governance snapshot”
“generate the P6-L3 statements for this run”
“what needs attention in this mary governance snapshot”

Not for

reading the mary-wiki corpus, docs/ or PR bodies (the input is one snapshot only)
computing figures (L1 analyzers in mary-wiki bin/governance-snapshot do that)
rendering, ranking bands or acting on anything (petrova-codes renders; nothing here acts)

← What do you need to see?

What changed since X?

PETROVA changes-since

petrova-changes-since ready

What changed since {{since}} — git log + file deltas grouped by area, with intent summaries and privileged-path flags.

kick petrova-changes-since Full prompt →

Use it when you'd say

“what changed since”
“catch me up on this repo”
“summarize recent changes”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

← What do you need to see?

Are the docs current?

PETROVA doc freshness audit

petrova-doc-freshness ready

Flag every docs/ file whose claims are now wrong because the underlying code changed and the doc didn't (MR-12 enforcement).

kick petrova-doc-freshness Full prompt →

Use it when you'd say

“audit docs freshness”
“find stale docs”
“enforce mr-12”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

← What do you need to see?

What is filed twice across the estate's knowledge stores?

Knowledge dupes review — one home per lesson, across every store

knowledge-dupes-review draft

Triage the estate's duplicate-cluster report from scripts/knowledge-census.py. Labels each cluster as a dup (the same act or lesson filed twice) or a topic (related, cross-link only), names the routed home per the estate knowledge routing ruling, and proposes the pointer or cross-link for each copy. Read-only.

kick knowledge-dupes-review Full prompt →

Use it when you'd say

“what is filed twice across the estate”
“duplicate findings across repos”
“knowledge dupes”

Not for

filing a new lesson (run knowledge-census.py search first)
moving or deleting documents

← What do you need to see?

What manual ops should become Routines?

PETROVA routine archaeology

petrova-routine-archaeology ready

Read-only scan that surfaces manual operations worthy of becoming Claude Code Routines; emits ranked candidate specs.

kick petrova-routine-archaeology Full prompt →

Use it when you'd say

“run petrova routine archaeology”
“find routine candidates in this repo”
“which manual ops should become routines”

Not for

proposing routines that write to docs/decisions/, docs/north-star/, registry.yaml, or META-RULES.md without verb routing
repos without .petrova/contract.yaml (halt and ask whether to proceed in non-compliant mode)

← What do you need to see?

What does my current phase still need to close?

EVA phase manifest — what the current phase still needs to close

eva-phase-manifest draft

Resolve a PETROVA-wired repo's current phase and acceptance gates, assess each with dated evidence, and route every open gate to the prompts, skills, workflows or human actions that close it. Read-only; writes .eva/phase-manifest.yaml.

kick eva-phase-manifest Full prompt →

Use it when you'd say

“what does my current phase still need”
“which gates are still open in this phase”
“plug this repo into the eva timeline”
“build the phase manifest”

Not for

repos without .petrova/contract.yaml (run eva-onboard first)
closing the phase itself (use eva-cycle)
picking a single next prompt without a phase view (use eva-next)

What usually comes next

eva-automation-triage in Plan
eva-cycle in Let EVA drive when every gate passes

← What do you need to see?

Which screens does a product's demo account leave empty?

Demo coverage audit (screen → endpoint → table → seeded?)

demo-coverage-audit draft

Read-only map of every screen a prospect sees in a product, the endpoint that feeds it, the tables behind it, and whether the demo seeder fills it. Output is a ranked gap table. Field-derived from the sparki-tools scoping on 2026-10-18.

kick demo-coverage-audit Full prompt →

Use it when you'd say

“audit demo coverage”
“what does the demo seed miss”
“which screens are empty in the demo”

Not for

code test coverage
writing or changing the seeder (demo-seed-author)

← What do you need to see?

Capture a single decision

PETROVA decision doc (ADR)

petrova-decision-doc ready

Author a dated, append-only decision doc at docs/decisions/YYYY-MM-DD-`slug`.md (MR-7).

kick petrova-decision-doc Full prompt →

Use it when you'd say

“write a decision doc”
“record an ADR for this repo”
“ratify decision”

Not for

editing an existing decision doc (use a superseding doc instead)
non-petrova repos without docs/decisions/

← What kind of decision?

Weigh options / ADR

PETROVA ADR with trade-off framework

petrova-adr-tradeoff ready

Architectural decision review — enumerate pains, options, rejection reasons, chosen + accepted trade. Drafts a decision doc.

kick petrova-adr-tradeoff Full prompt →

Use it when you'd say

“architectural decision review”
“weigh a trade-off”
“draft an adr”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

← What kind of decision?

The spec's default would block everything, or a 'turn it on' would break prod: stop and lay out three options

Spec-blocked feature, stop before coding (three options, no silent relaxation)

spec-blocked-feature-stop draft

Stops a change whose spec-correct default would block everything, because nothing yet exists that can produce the artifact the spec requires, or because flipping a setting would break production. Presents three options (build the missing tool and stay strict; stay strict and disclose the capability as unavailable; relax only through a decision with human sign-off) and researches before any flip.

kick spec-blocked-feature-stop Full prompt →

Use it when you'd say

“enforcing this would block every install”
“nothing can produce the provenance the spec requires”
“turn on rekor”
“just enable the transparency log”
“can we default this check off for now”
“the spec says MUST reject but nothing passes”

Not for

a requirement that real inputs can already meet (just implement it, under security-pr-review-loop)
writing the I-2 decision doc itself (use petrova-decision-doc once the operator picks the relax option)
weighing purely technical design options with no control at stake (use petrova-adr-tradeoff)
performance or UX trade-offs that do not touch a security control

What usually comes next

security-pr-review-loop in Execute option A: build the producer, stay strict
petrova-decision-doc in Decide option C: relax only via I-2 sign-off

← What kind of decision?

Freeze a current-state baseline

PETROVA declare baseline

petrova-declare-baseline ready

Ratify a new fleet baseline (v2, v3, ...) as a decision doc in petrova-codes; verb pre-flight refuses if any MR audit check fails.

kick petrova-declare-baseline Full prompt →

Use it when you'd say

“declare petrova baseline”
“ratify baseline v<n>”
“emit baseline adr”

Not for

declaring baselines for individual consumer repos (the verb only targets petrova-codes)
cases where the audit is known-red (the verb will refuse; fix the underlying gap first)

← What kind of decision?

Check alignment with the north star

PETROVA north-star alignment audit

petrova-north-star-align ready

Sample recent commits/PRs and judge whether each served the north-star, load-bearing infra, or backlog (MR-1 enforcement).

kick petrova-north-star-align Full prompt →

Use it when you'd say

“audit north-star alignment”
“mr-1 audit”
“is recent work on-target”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

← What kind of decision?

Authorise one write to a VPS deck (GO record, FLIGHT ratifies)

Deck act GO — the record that authorises one write to one host

deck-act-go draft

Drafts the per-deck, per-act GO record (status proposed) that must exist before any write to a VPS deck — move, stop, firewall, DNS or provider API verb — with preconditions as refusal conditions, pass criteria, rollback and a spent line; then hands FLIGHT the ratification ask in plain English.

kick deck-act-go Full prompt →

Use it when you'd say

“draft a GO for this deck”
“I need to stop a container on ODIN”
“write the GO before the firewall act”
“record the go-ahead for this host write”
“is there a GO covering this”

Not for

fleet hosts (eu-1, hermes*) — those go through fleet-safety-gate and fleet-deploy-runner from a hermes-rooted session
read-only SSH or provider API reads (sanctioned evidence, no GO needed)
the three BLACK verbs (recreate VM, set root password, delete snapshot) — only an operator decision countersigned in advance
retiring a whole surface (use surface-retire, which calls this prompt per act)

What usually comes next

petrova-request-review in Verify FLIGHT ratifies before the act

← What kind of decision?

One feature, one repo

PETROVA plan a feature

petrova-plan-feature ready

Translate a feature ask (vague or specific) into PETROVA-shaped scope: north-star sentence, tasksets with deliverable+verification+gate, reuse-first.

kick petrova-plan-feature Full prompt →

Use it when you'd say

“plan a feature”
“decompose a vague ask”
“scope this work petrova-style”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

What usually comes next

— What are you executing?
meta-prompt-generator in Plan turn a taskset into an executor-ready prompt

← What are you planning?

Bundle of tasks

Task bundle planner

task-bundle-planner ready

Decompose a goal + acceptance criteria into a TaskBatch — a structured queue of single-pass tasks, each grounded in a /map node with pre-bound args. Used by `eva tasks sync` to populate the EVA task backlog.

kick task-bundle-planner Full prompt →

Use it when you'd say

“decompose this goal into queueable tasks”
“plan a task bundle for the queue”
“turn this into a backlog”

Not for

executing the work itself (consumer agents do that)
producing a single ad-hoc task (use `tasks/create` directly)
planning when no /map nodes apply (the queue is grounded in /map)

What usually comes next

— What are you executing?

← What are you planning?

An implementation prompt for a downstream agent

Meta-Prompt Generator (implementation-prompt architect)

meta-prompt-generator draft

Transforms "I want to do task X" into a rigorous, subagent-driven implementation prompt for a downstream coding agent — ground-truth-first, phased, diff-evidenced.

kick meta-prompt-generator Full prompt →

Use it when you'd say

“turn this task into an implementation prompt”
“write me a prompt for a downstream agent”
“architect a prompt for this task”
“generate a rigorous coding prompt for task X”

Not for

writing the implementation itself
PETROVA feature scoping (use petrova-plan-feature)
trivial one-line edits that need no plan

What usually comes next

— What are you executing?

← What are you planning?

Add a milestone to the roadmap

PETROVA milestone add

petrova-milestone-add ready

Append a milestone entry to MILESTONES.md (used to land MR-2 deferred items).

kick petrova-milestone-add Full prompt →

Use it when you'd say

“add a milestone to petrova”
“record deferred friction as a milestone”

Not for

editing existing milestone entries (their text is the contract)

← What are you planning?

Cross-repo execution graph

Repo Audit DAG Generator

repo-dag-generator draft

Audit a repository and emit state.md + graph.md + per-node prompts/*.md — the execution plan for a fleet of agents to finish the repo.

kick repo-dag-generator Full prompt →

Use it when you'd say

“audit this repository”
“produce a work graph for this repo”
“generate audit prompts for the repo”
“plan what is left to finish this codebase”

Not for

single-file refactors (use refactor-with-constraints)
fresh feature work without an existing codebase
executing the audit (use repo-dag-executor)
explanation-only / read-only walkthrough requests

What usually comes next

— What are you executing?

← What are you planning?

Open a governance phase

Petrova Phase Open

petrova-phase-open ready

petrova-phase-open

kick petrova-phase-open Full prompt →

Use it when you'd say

“petrova phase open”

Not for

non-petrova repos

What usually comes next

phase active — What are you executing? phase active

← What are you planning?

Which recurring phase steps earn automation?

EVA automation triage — which phase steps earn automation

eva-automation-triage draft

Score every step in .eva/phase-manifest.yaml as automate, segment or keep-manual against a fixed rubric, citing which clauses held. Read-only; adds the triage block to the manifest.

kick eva-automation-triage Full prompt →

Use it when you'd say

“which of these steps should be automated”
“triage the phase manifest for automation”
“is this worth turning into a routine”

Not for

repos without .eva/phase-manifest.yaml (run eva-phase-manifest first)
mining git history for toil across the whole repo (use petrova-routine-archaeology)
installing automations (use eva-automation-install)

What usually comes next

eva-automation-install in Execute › Fleet op

← What are you planning?

Map one repo's gates into .petrova/gates.yaml

Gates map — find what stands between a repo and revenue, as derived-state gates

gates-map draft

Layer 1 of the gates-to-revenue pattern. Reads a repo's milestones, decisions, billing path and live surfaces, and writes .petrova/gates.yaml (schema gates/v1) with the validator and its CI step, so every gate's state is derived from evidence files rather than typed in.

kick gates-map Full prompt →

Use it when you'd say

“map the gates to revenue for a repo”
“what stands between this repo and taking money”
“set up gates.yaml”

Not for

driving an existing gate (gates-drive)
writing a CUPEL ticket (gates-cupel-leaf)
the estate-wide operator queue (gates-sweep)

← Which layer of the gates pattern?

Sweep every registered repo's gates into one queue

Gates sweep — the estate-wide queue between every repo and revenue

gates-sweep draft

Layer 2 of the gates-to-revenue pattern, across the estate. Reads every registered repo's .petrova/gates.yaml from its default branch via the GitHub API, derives state with the shared validator, and reports what waits on the operator, what an agent can take, what a non-engineer can walk, and which repos have no gates yet. Read-only.

kick gates-sweep Full prompt →

Use it when you'd say

“what is waiting on me across all repos”
“estate revenue gates”
“which repos are closest to revenue”

Not for

working a gate (gates-drive)
creating a gates file (gates-map)

← Which layer of the gates pattern?

Drive one repo's next movable gate

Gates drive — one session moving a repo's gates toward revenue

gates-drive draft

Layer 2 of the gates-to-revenue pattern, for one repo. Derives gate state with the validator, then takes the next movable thing - an agent-ready gate, a draft that turns an operator ruling into approve-or-close, a walk kit for a non-engineer - and records every move as evidence, never as an edited status.

kick gates-drive Full prompt →

Use it when you'd say

“drive the gates for a repo”
“what is next toward revenue”
“the operator set an env value or made a ruling”

Not for

a repo with no gates file (gates-map)
the estate-wide queue (gates-sweep)
running the verification round (petrova-verify-round)

← Which layer of the gates pattern?

Cut one agent-executable change under a gate into a CUPEL ticket

Gates CUPEL leaf — cut one agent-executable change under a gate into an admissible CUPEL ticket

gates-cupel-leaf draft

Layer 3 of the gates-to-revenue pattern. Takes one code-shaped piece of work under a gate and writes it as a CUPEL ticket plus trace, with a RED command observed failing before GREEN, then links the trace from the gate's cupel list. Refuses work that cannot be made falsifiable - that stays gate work.

kick gates-cupel-leaf Full prompt →

Use it when you'd say

“cut a CUPEL ticket under a gate”
“make this gate work a CUPEL criterion”

Not for

a human walk, an operator ruling or a config value
creating the gates file (gates-map)

← Which layer of the gates pattern?

Draft a decision record for one uncleared ruling, for the operator to countersign

Gates rule — draft the decision record a ruling blocker waits on

gates-rule draft

Reads the evidence behind one uncleared ruling blocker and drafts a decision record that sets out the question, the options and a recommendation, with an unticked countersign. The operator countersigns it on jzero /approvals and gates-scribe then clears the blocker, so the ruling is made without the operator editing a file.

kick gates-rule Full prompt →

Use it when you'd say

“draft the ruling for a gate blocker”
“turn a ruling blocker into a decision record”
“what do I have to decide for this gate”

Not for

making the ruling (the operator countersigns)
rulings already recorded (gates-scribe)
config blockers

← Which layer of the gates pattern?

Record cleared_by for rulings whose evidence already records a human sign-off

Gates scribe — record rulings that were already made

gates-scribe draft

Finds ruling blockers whose evidence file already exists but whose cleared_by was never set, confirms each file records the ruling with a human sign-off, and sets cleared_by for the confirmed ones in one PR per repo.

kick gates-scribe Full prompt →

Use it when you'd say

“scribe the gates for a repo”
“clear rulings that are already recorded”
“a stale ruling blocker on the path”

Not for

config blockers
discharging gates (gates-drive)
the estate-wide queue (gates-sweep)

← Which layer of the gates pattern?

Project one product's human-owned gates into Orbit tasks for staff

Orbit gates seed — project one product's revenue gates into Orbit tasks for staff

orbit-gates-seed draft

Reads one repo's .petrova/gates.yaml, derives state with the shared validator, and reconciles the product's Orbit project against it through the Orbit MCP - one parent "Launch to revenue" task and one sub-task per unmet operator or non-engineer gate, matched by gate id so a re-run never duplicates. Orbit only shows the gates; the repo decides them.

kick orbit-gates-seed Full prompt →

Use it when you'd say

“seed orbit from the gates”
“sync launch tasks into orbit”
“put the revenue gates in front of staff”

Not for

working a gate (gates-drive)
copying runbooks into Orbit Docs (orbit-docs-sync)
the estate-wide queue (gates-sweep)

← Which layer of the gates pattern?

Rewrite a product's support runbooks as plain family guides

Orbit guide write — turn a product's support runbooks into plain-language family guides

orbit-guide-write draft

Rewrites one product's engineering support runbooks as short task guides a non-technical family member can follow, in the style of the Chronicle guides - no code, ids, file paths or engineering words, "pass it to Alex", captioned screenshots - and commits them to the product repo beside the runbooks, checked by guide_lint.py. Facts come only from the runbooks; anything they do not settle becomes "ask Alex".

kick orbit-guide-write Full prompt →

Use it when you'd say

“write family guides for a product”
“simplify the runbooks for non-technical people”
“de-jargon the support docs”

Not for

posting guides to Orbit (orbit-docs-sync)
editing the engineering runbooks themselves

← Which layer of the gates pattern?

Post a product's family guides into its Orbit Docs

Orbit docs sync — post one repo's family guides (or runbook copies) into a product's Orbit Docs

orbit-docs-sync draft

Fetches a guide (or runbook) directory from GitHub at an exact commit, checks family guides against the plain-language standard, uploads their screenshots, posts each page as a child of an operator-made parent page through the Orbit MCP, then writes the set's README onto the parent as an "I want to…" index linking the Orbit pages. Re-runs update in place.

kick orbit-docs-sync Full prompt →

Use it when you'd say

“put the runbooks in orbit”
“re-sync the orbit runbooks”
“port staff guides into orbit docs”

Not for

launch tasks (orbit-gates-seed)
changing what a runbook says (edit the repo, then re-sync)

← Which layer of the gates pattern?

Hand an Orbit task to the next agent, or pick one up (CUPEL handoff record, re-derived first)

Orbit handoff — emit or resume a CUPEL handoff record for an Orbit task

orbit-handoff draft

Emit mode writes a CUPEL handoff record (handoffs/HO-<task>-<seq>.yaml) in the product repo, where every state claim carries the command that reproduces it, links it from a one-line Orbit task comment and labels the task handoff:open. Resume mode is CUPEL's HOLDDOWN gate - re-derive every claim of the latest record before touching anything, record what changed, then claim the task.

kick orbit-handoff Full prompt →

Use it when you'd say

“hand this task off”
“write the handoff record”
“pick up the open handoff”

Not for

human progress notes on a task
seeding or re-seeding tasks (orbit-gates-seed)

← Which layer of the gates pattern?

Find where Orbit tasks drifted from their gates

Orbit reconcile — find where Orbit tasks have drifted from the gates they project

orbit-reconcile draft

For every Orbit project seeded from a gates file, derives each gate's labels and state (gate_meta.py), reads the project's tasks, and reports drift with orbit_reconcile.py - Todo with a blocker, Backlog without one, Done but unmet, met but open, orphaned gates, people-owned gates with no task, and label drift. Report-only unless a tasks:write token is available, and even then fixes only labels and status; Source, relations and new tasks stay operator or browser asks.

kick orbit-reconcile Full prompt →

Use it when you'd say

“reconcile orbit”
“is orbit in sync with the gates”

Not for

first seeding of a project (orbit-gates-seed)
deciding a gate is met

← Which layer of the gates pattern?

Audit one project end to end, gates to public exposure, into a ranked drive-now list

Estate audit — one ranked "drive now" list per project, from gates to public exposure

estate-audit draft

Read-only. For one enrolled project (or every registry repo in coverage mode), runs nine lenses — gates, tracker, guide truth, loop exceptions, live truth, public surface, content pipeline, personal exposure and opportunities — reusing the latest artifact of the cycle that owns a lens when it is under seven days old, and ranks every finding into a "drive now" list that respects the project's holds and freezes. Field-derived from the Sparki audit of 2026-11-11.

kick estate-audit Full prompt →

Use it when you'd say

“audit the project end to end”
“what can we drive now”
“is the tracker telling the truth”
“how visible is this project under my name”

Not for

fixing a finding (each finding names who and what fixes it)
posting, sending or contacting anyone (PLAY-004 v2, PLAY-010 v2)
deciding a gate is met

What usually comes next

gates-sweep in Plan › Gates lens: gates
orbit-reconcile in Plan › Gates lens: tracker
live-truth-triage in Execute › Fleet op lens: live
landing-claims-ledger in Execute › Landing truth lens: surface
content-diagnose in Execute › Publish lens: content
public-exposure-audit in Execute › Publish lens: exposure
opportunity-scan in Execute › Publish lens: opportunity

← Which layer of the gates pattern?

Shortlist up to 30 people from the operator's public Bluesky rings (read-only, never contacts)

Discovery Shortlist

discovery-shortlist draft

PLAY-010 v2 step 2 — run the read-only scout CLI over the operator's public Bluesky rings and an operator-named segment, writing at most 30 candidates to a private round dir outside every git tree. Never contacts anyone.

kick discovery-shortlist Full prompt →

Use it when you'd say

“open a discovery round”
“build the discovery shortlist”
“who should we interview this round”
“run scout for the discovery round”

Not for

contacting, following or messaging anyone (the operator, by hand)
naming the segment, hypothesis, threshold or send cap (operator rulings, step 1)
interview questions (discovery-brief) or the first message (discovery-script)
searching posts with an app password, or any third-party directory

What usually comes next

discovery-brief in Plan › Discovery

← Which step of the discovery round?

Write open interview questions, no pitch

Discovery Brief

discovery-brief draft

PLAY-010 v2 step 3 — write the round's open interview questions from the operator's hypothesis and segment, with no pitch, into the private round dir.

kick discovery-brief Full prompt →

Use it when you'd say

“write the discovery interview questions”
“draft the interview brief for this round”
“what should I ask in these customer conversations”

Not for

the first message that opens a conversation (discovery-script)
pitching, demoing or describing the product
choosing the hypothesis or segment (operator rulings, step 1)

What usually comes next

discovery-script in Plan › Discovery

← Which step of the discovery round?

Draft the first message; record the sha256 of the version the operator approves

Discovery Script

discovery-script draft

PLAY-010 v2 step 3 — draft first-message script versions from the brief and the last round finding; after the operator approves one, record the sha256 the guard computed. The agent never sends.

kick discovery-script Full prompt →

Use it when you'd say

“draft the first message for the discovery round”
“write the cold DM script versions”
“record the approved discovery script”
“I approve script v2”

Not for

sending, scheduling or posting the message (operator, by hand)
interview questions (discovery-brief)
public build-in-public posts (PLAY-004 v2 through CELIA)

What usually comes next

discovery-synthesis in Plan › Discovery operator sends by hand, logs outcomes

← Which step of the discovery round?

Close the round: synthesis from operator notes, one change for next round, gate finding at DEMAND-NOT-MET

Discovery Synthesis

discovery-synthesis draft

PLAY-010 v2 round close — synthesise only from the operator's notes and outcomes.log, every claim citing a note; draft the round finding (one change for next round) and the app gate finding at result DEMAND-NOT-MET; write an aggregate-only round report. Never writes DEMAND-MET.

kick discovery-synthesis Full prompt →

Use it when you'd say

“close the discovery round”
“synthesise the discovery conversations”
“write the round finding for play-010”
“did this round meet the demand threshold”

Not for

declaring demand met (operator verdict only; the agent never writes DEMAND-MET)
filing or committing the drafts (operator, after reading them)
summarising calls the operator did not write notes for
setting the threshold N (ruling:demand-threshold, operator)

What usually comes next

discovery-shortlist in Plan › Discovery next round applies the one change

← Which step of the discovery round?

Multi-step task, one repo

Multi-step Orchestration Executor (autopilot-shaped)

orchestrate-multistep tested

Executes one step of a JSON plan; emits strict-JSON handoff with predict/wake/learn fields per autopilot loop semantics.

kick orchestrate-multistep Full prompt →

Use it when you'd say

“run the next step of this plan”
“advance the orchestration”
“execute one step of this plan”
“drive the multi-step pipeline forward”

Not for

one-shot tasks
ad-hoc planning without a structured plan
workflows requiring lookahead across multiple steps
plans not expressible as a JSON `steps[]` DAG

← What are you executing?

Cross-repo DAG

Repo Audit DAG Executor

repo-dag-executor draft

Drive a shell-script harness that dispatches Claude Code Task sub-agents against an audit DAG until every node verifies green.

kick repo-dag-executor Full prompt →

Use it when you'd say

“run the repo audit”
“execute the audit graph”
“dispatch the audit nodes”
“drive the audit harness to completion”

Not for

generating the audit (use repo-dag-generator)
one-shot refactors or feature work
audits without state.md / graph.md / prompts/ on disk
workflows requiring lookahead beyond the supplied DAG

← What are you executing?

Refactor with hard limits

Refactor with Explicit Constraints

refactor-with-constraints ready

Surgical refactor of a single file under named constraints; produces diff + rationale + risks.

kick refactor-with-constraints Full prompt →

Use it when you'd say

“refactor”
“tighten this”
“clean up this file”
“restructure under constraints”

Not for

cross-file refactors
dependency upgrades
greenfield code generation
explain-only / read-only requests
files larger than 500 lines

← What are you executing?

Let the autopilot drive

PETROVA autopilot (lifecycle outer loop)

petrova-autopilot ready

Reads readiness, picks the next petrova verb, dispatches via kick, and chains until DONE or operator gate.

kick petrova-autopilot Full prompt →

Use it when you'd say

“run petrova autopilot”
“drive the petrova lifecycle forward”
“advance one iteration of the petrova loop”

Not for

one-shot petrova actions (use the specific verb directly)
workflows outside the petrova lifecycle

← What are you executing?

Propose a fix for a known issue

PETROVA propose fix

petrova-propose-fix ready

Open a fix PR bound to a prior diagnose run. Validates that the diagnosis_id resolves to a real recent diagnose output and that every proposed change carries explicit MR grounding.

kick petrova-propose-fix Full prompt →

Use it when you'd say

“petrova propose fix for <slug>”
“propose fix on <slug>”
“submit fix bound to <diagnosis-id>”

Not for

repos not in `petrova-codes/registry.yaml`
fixes without a prior diagnose run (run diagnose first, get a diagnosis_id)
fixes touching closed decision docs (MR-8 violation — supersede via new doc)
fixes where the diagnosis_id is older than 24 hours (re-run diagnose)

← What are you executing?

Land one security fix in a submodule: TDD, independent review, fold findings, merge, pin the gitlink

Security PR loop (worktree, TDD, independent review, fold, merge, pin)

security-pr-review-loop draft

The end-to-end loop for one security-sensitive change in a submodule of a governed umbrella. Implement in a fresh worktree off origin/main with TDD, get strict CI green, get an independent read-only security review, fold every MEDIUM+ finding into the same PR (re-review after a BLOCK), log LOW findings as gap rows, merge, then bump the umbrella gitlink one submodule per commit.

kick security-pr-review-loop Full prompt →

Use it when you'd say

“implement this security fix and get it reviewed”
“run the pellets-security-auditor on this PR”
“fold the review findings into the PR”
“the reviewer said BLOCK”
“merge it and bump the gitlink”
“next gap row, same loop”

Not for

a read-only audit with no change (use auth-fail-open-audit, or the auditor alone)
non-security changes that need no independent review
bumping two or more submodules in one commit (I-3 needs per-submodule risk notes; split them)
repos with no umbrella gitlink (stop after merge)
relaxing a control to get a PR through (that is spec-blocked-feature-stop, then an I-2 decision)

What usually comes next

refusal-code-catalogue-maintenance in Execute engine/registry gitlink bump

← What are you executing?

Bump nestr's engine or registry gitlink with the refusal-code snapshot in the same commit

Refusal-code catalogue and snapshot (nestr umbrella)

refusal-code-catalogue-maintenance draft

Keeps nestr's refusal-code catalogue (`docs/specs/refusal-codes.yaml`) and its snapshot pinned to the exact engine and pellets-registry gitlinks in step. Every engine or registry gitlink bump runs `scripts/check-refusal-codes.sh --write-snapshot` in the same commit, so the bump goes by PR, not direct push.

kick refusal-code-catalogue-maintenance Full prompt →

Use it when you'd say

“bump the engine gitlink”
“bump the pellets-registry gitlink”
“refusal-codes snapshot is stale”
“docs-invariants fails on refusal codes”
“new E_ code has no catalogue entry”
“engine embedded catalogue differs from the umbrella copy”

Not for

bumping web, perch or olly gitlinks (no refusal-code scan; ordinary gitlink bump)
writing the user-facing explanation text for a code in the web app (that is the web repo's own change)
adding a refusal path in Go (do that in the submodule under security-pr-review-loop, then come back here)
repos other than nestr-tools/nestr

← What are you executing?

ares

Petrova Wire Ares

petrova-wire-ares ready

Draft the ARES wire-decision doc and describe the manual contract.yaml evidence-block update; no dedicated wire-verb exists in petrova-codes.

kick petrova-wire-ares Full prompt →

Use it when you'd say

“petrova wire ares”

Not for

non-petrova repos

← Which system?

crumb

Petrova Wire Crumb

petrova-wire-crumb draft

EXPERIMENTAL — describe intended CRUMB wiring shape; no backing verb in petrova-codes yet.

kick petrova-wire-crumb Full prompt →

Use it when you'd say

“petrova wire crumb”

Not for

non-petrova repos

← Which system?

eva

Petrova Wire Eva

petrova-wire-eva draft

EXPERIMENTAL — describe intended EVA prompt-library wiring shape; no backing verb in petrova-codes yet.

kick petrova-wire-eva Full prompt →

Use it when you'd say

“petrova wire eva”

Not for

non-petrova repos

← Which system?

rocky

Petrova Wire Rocky

petrova-wire-rocky draft

EXPERIMENTAL — describe intended ROCKY RAG wiring shape; no backing verb in petrova-codes yet.

kick petrova-wire-rocky Full prompt →

Use it when you'd say

“petrova wire rocky”

Not for

non-petrova repos

← Which system?

traceo

Petrova Wire Traceo

petrova-wire-traceo ready

Draft the TRACEO wire-decision doc and describe the manual contract.yaml evidence-block update; no dedicated wire-verb exists in petrova-codes.

kick petrova-wire-traceo Full prompt →

Use it when you'd say

“petrova wire traceo”

Not for

non-petrova repos

← Which system?

Generic integration

PETROVA wire integration

petrova-wire-integration ready

Flip a registered consumer's `.petrova/contract.yaml` integration block from pending → wired with a validated evidence object. Generic over ares/traceo/crumb/rocky/eva.

kick petrova-wire-integration Full prompt →

Use it when you'd say

“petrova wire integration”
“wire integration <name> for <repo>”
“flip <integration> to wired on <repo>”

Not for

repos not in registry.yaml
integrations declared not_applicable in registry.yaml
already-wired integrations (no re-wires)

← Which system?

An HTTP API as MCP tools

Wire a REST API as an MCP provider (pebble flow)

mcp-provider-wire ready

End-to-end flow for exposing an existing HTTP API as MCP tools through the pebble gateway — config, self-disable, registry dispatch, corpus entry, tests, and the two traps that mocked tests cannot catch (wrong auth scheme, wrong route).

kick mcp-provider-wire Full prompt →

Use it when you'd say

“add an MCP provider”
“expose this API to agents as tools”
“wire X into pebble”
“new pebble provider”

Not for

proxying an upstream that is already an MCP server (that is a transport proxy, not this pattern)
designing the upstream API itself (see read-surface-first)

← Which system?

An app's checkout and paid access onto the TOLL gate

TOLL consumer wire (move an app's checkout and access check onto the TOLL gate)

toll-consumer-wire draft

Wires one consumer app's server to the TOLL gate. Checkout goes through toll.checkout with a namespaced subject, and paid access is read from toll.entitlements with a short cache, an explicit timeout and fail-closed denial. For an app that already bills Polar directly, it moves the entitlement source to TOLL behind a flag, keeps the app's ledger, plan-change and refund logic, and stops the local webhook from deciding access. One PR in the consumer repo; secrets and flag flips stay with the operator.

kick toll-consumer-wire Full prompt →

Use it when you'd say

“wire an app to toll”
“move billing onto toll”
“toll consumer for”
“replace direct polar billing with toll”
“toll checkout and entitlements in the app”

Not for

the null0-toll side: capabilities, spec, consumer tests (toll-consumer-onboard)
apps with no server-side place for a secret (TOLL is not compatible; stop)
env production or live Polar products before P3 lands
setting secrets or flipping flags in a deployed environment (operator)

← Which system?

TOLL consumer onboard (gate side: capabilities, spec, consumer tests, multi-consumer subject safety)

toll-consumer-onboard draft

Lands the null0-toll side of onboarding one or more consumer apps. One PR proves (and if red, fixes) that one Polar customer can hold paid access in two consumers at once. It also registers each consumer's capability strings, declares adopted Polar products in toll.spec.yaml by exact name, pins each consumer with tests/consumers/<kid>.test.ts, and writes the operator's onboarding record into the cutover runbook. Secrets, TOLL_CONSUMERS and Polar writes stay with the operator.

kick toll-consumer-onboard Full prompt →

Use it when you'd say

“onboard an app to toll”
“register a toll consumer”
“add a capability to toll”
“toll consumer onboarding”
“toll side of the consumer wiring”

Not for

wiring the consumer app's checkout or access check (toll-consumer-wire)
running a multi-app pass end to end (toll-consumer-wave)
production Polar money, env production, prod OAT (P3 is its own milestone)
setting TOLL_CONSUMERS, Railway variables or any secret (operator)
renaming an existing capability (never; add and deprecate)

← Which system?

Several apps onto TOLL in one gated pass

TOLL consumer wave (onboard and wire several apps onto TOLL in one gated pass)

toll-consumer-wave draft

Orchestrates moving several apps onto the TOLL gate in one pass. G0 collects the operator's rulings. T runs toll-consumer-onboard once for every app, including the multi-consumer subject fix. O1 is the operator's TOLL_CONSUMERS and Polar gate. W runs toll-consumer-wire for each app in parallel isolated worktrees. V runs sandbox drills plus the cross-app same-customer probe. R records the result. Each phase hands off with an explicit gate, and nothing proceeds on an assumed GO.

kick toll-consumer-wave Full prompt →

Use it when you'd say

“toll consumer wave”
“wire several apps to toll”
“migrate direct polar apps onto toll”
“onboard smo1 and choco to toll”
“same pass toll wiring”

Not for

one app whose kid is already onboarded (toll-consumer-wire)
gate-side changes only (toll-consumer-onboard)
production Polar money (P3)
apps with no server-side secret store

← Which system?

Join a content tool's taxonomy (Notion…) to a repo's, by verified key

DEVAQUA content-tool ↔ repo-taxonomy join-key bridge

devaqua-taxonomy-bridge ready

Add a verified join-key field linking an external content tool's human taxonomy (e.g. Notion lesson tags) to a repo-owned taxonomy (e.g. COACH milestone slugs), without retagging or guessing.

kick devaqua-taxonomy-bridge Full prompt →

Use it when you'd say

“bridge notion to repo taxonomy”
“join key between content tool and codebase”
“link lesson content to milestone taxonomy”
“devaqua practices to coach milestones”

Not for

writing new taxonomy values into the repo itself (that's a code change, not a bridge)
any write path that could be mistaken for the system-of-record write (e.g. never let the content tool write attestation/progress state back into a signed event log)

← Which system?

Audit a product UI before redesigning it: controls to real work, numbers to window and n (read-only)

Product surface truth audit (every control traced to work it really does, every number to its window and n)

product-surface-truth-audit draft

Read-only. Before an app-UI redesign, traces each control on each product route to the handler behind it and asks whether it does the work it claims; traces each number to the metric, window and sample size the backend actually computes; and lists fabricated data (seed fallbacks, teaser charts, placeholder-as-default). Field-derived from the nestr web redesign (web#55-#63, engine#84, nestr#233, 2026-10-30).

kick product-surface-truth-audit Full prompt →

Use it when you'd say

“audit the product surface before the redesign”
“is this button actually wired”
“can we trust the dashboard numbers”
“which screens show sample data”
“trace the UI controls to the backend”

Not for

public marketing or pricing pages (landing-claims-ledger)
whether a demo account fills each screen (demo-coverage-audit)
generating or running the design plan (impeccable-handbook-generator, impeccable-harness-executor)
fixing the backend (open findings; fix under security-pr-review-loop or the repo's own flow)

What usually comes next

impeccable-handbook-generator in Execute › Author redesign inputs (nestr web, 2026-10-30)

← What kind of content?

Impeccable handbook (full)

Impeccable Handbook Generator

impeccable-handbook-generator draft

Inspect a freshly /impeccable-onboarded project and emit a project-specific IMPECCABLE_HANDBOOK.md plus skeleton sidecar.

kick impeccable-handbook-generator Full prompt →

Use it when you'd say

“generate the impeccable handbook”
“produce IMPECCABLE_HANDBOOK.md”
“draft the impeccable plan”
“synthesise an impeccable handbook for this project”

Not for

projects without a PRODUCT.md
greenfield projects with no codebase
executing handbook prompts (use impeccable-harness-executor)
one-shot design questions

← What kind of content?

Run an impeccable harness

Impeccable Harness Executor

impeccable-harness-executor draft

Deterministic orchestrator that drives an IMPECCABLE_HANDBOOK.md to completion via Claude Code Task() sub-agents.

kick impeccable-harness-executor Full prompt →

Use it when you'd say

“run the impeccable harness”
“execute the impeccable handbook”
“advance the impeccable plan to the next phase”
“dispatch the next handbook prompt”

Not for

generating an IMPECCABLE_HANDBOOK.md (use impeccable-handbook-generator)
one-shot design or refactor tasks
projects without a checkbox-formatted handbook

← What kind of content?

One handbook section

Generate a Handbook Section from Notes

handbook-section-generator tested

Synthesises bullet-form notes into a named handbook section in a chosen voice; surfaces contradictions.

kick handbook-section-generator Full prompt →

Use it when you'd say

“draft a handbook section”
“write up these notes”
“turn these bullets into prose”
“synthesise these notes”

Not for

stream-of-consciousness or unstructured input
greenfield long-form writing without source notes
terse summaries / TL;DRs

← What kind of content?

Brand asset

Brand Asset Generator

brand-asset-generator draft

Read BRAND.md + PRODUCT.md and emit a complete BRAND_ASSETS.md with image-gen prompts, palette, and typography for every named surface.

kick brand-asset-generator Full prompt →

Use it when you'd say

“generate brand assets”
“produce BRAND_ASSETS.md”
“generate logo prompts”
“build brand media package”
“bootstrap brand identity”
“create image gen prompts for my brand”
“what should my logo look like”

Not for

projects without a BRAND.md (create one first)
executing or rendering image prompts (use an image gen tool)
impeccable UI work (use impeccable-handbook-generator)
editing or critiquing existing visual assets

← What kind of content?

Email-flow verification harness

Verify end-to-end email flow for any app

verify-email-flow-harness ready

Plug-in e2e verification of magic-link email flow — dispatch, read the mail over IMAP, click-through in headless Chromium, session assertion. Generic over app base URL, dispatch path, and probe email.

kick verify-email-flow-harness Full prompt →

Use it when you'd say

“verify the e2e email flow”
“check magic-link end-to-end”
“run email flow harness”
“plug in to eva and verify email”

Not for

apps whose sign-in mail cannot reach the probe mailbox (the IMAP poll won't find the message)
apps with non-magic-link auth (OAuth-only, password-only)

← What kind of content?

Crumb extraction (raw)

CRUMB Extraction Harness

crumb-extraction-harness draft

Harness-pattern orchestrator that fans out background subagents across {{target_repos}}, dispatching the crumb-flashcard-extractor per repo with Ruflo memory/KG/intelligence enrichment and autopilot-shaped JSON handoff.

kick crumb-extraction-harness Full prompt →

Use it when you'd say

“bootstrap crumb across these repos”
“extract crumb cards for the whole portfolio”
“run the crumb harness over these projects”
“dispatch crumb extraction across multiple repos”
“generate crumb flashcards for all of devarno-cloud”

Not for

single-repo crumb extraction (use crumb-flashcard-extractor)
editing or reformatting existing crumb cards
generating non-CRUMB flashcards or design docs
audits or refactors (use repo-dag-executor / orchestrate-multistep)

← What kind of content?

Crumb → flashcards

CRUMB Flashcard Extractor

crumb-flashcard-extractor draft

Scan a source repository and emit CRUMB-schema flashcards (20-field strict frontmatter, mermaid-first diagrams) ready to drop into crumb.devarno.cloud.

kick crumb-flashcard-extractor Full prompt →

Use it when you'd say

“extract crumb flashcards”
“generate crumb cards from repo”
“crumb cards for this project”
“bootstrap flashcards for crumb”
“scan repo and produce crumb flashcards”
“turn this codebase into flashcards”

Not for

generic CTO flashcards outside the CRUMB schema (use the freeform prompt)
rewriting or reformatting an existing crumb card (edit it directly)
generating image/UI assets (use brand-asset-generator)
producing protocol or design documents (this prompt emits cards only)

← What kind of content?

RAG: rewrite query

RAG Query Rewriter (expand · decompose · HyDE)

rag-query-rewriter draft

Rewrites a user query for retrieval — expansion, decomposition, or HyDE — emitting a strict JSON plan.

kick rag-query-rewriter Full prompt →

Use it when you'd say

“rewrite this query for RAG”
“expand this query”
“decompose this question”
“generate a HyDE document”
“prep this question for retrieval”

Not for

executing the retrieval itself
ranking returned chunks
composing the final answer
queries already in a search DSL (BM25, Lucene, SQL)

← What kind of content?

RAG: rerank chunks

RAG Chunk Reranker (LLM-as-reranker with MMR diversity)

rag-chunk-reranker draft

Reranks candidate chunks against a query, balancing relevance and MMR-style diversity; preserves input ids.

kick rag-chunk-reranker Full prompt →

Use it when you'd say

“rerank these chunks”
“score these passages for relevance”
“pick the top K chunks for this query”
“reduce these candidates with MMR”

Not for

first-stage retrieval (use a retriever)
candidate sets larger than ~50 chunks
cross-document summarisation
de-duplication of identical chunks (do that upstream)

← What kind of content?

RAG: synthesize context

RAG Context Synthesizer (cited answer with coverage report)

rag-context-synthesizer draft

Composes a grounded answer from id-keyed chunks; cites by id; refuses on insufficient evidence.

kick rag-context-synthesizer Full prompt →

Use it when you'd say

“synthesise an answer from these chunks”
“write a cited summary from these passages”
“answer using only these chunks”
“compose a grounded answer with citations”

Not for

retrieval / search
reranking candidate chunks
faithfulness / grounding validation
open-ended writing without supplied sources

← What kind of content?

RAG: validate evidence

RAG Evidence Validator (faithfulness · groundedness · citation audit)

rag-evidence-validator draft

Audits a RAG answer against its source chunks; pairs each claim to supporting ids and flags unsupported spans.

kick rag-evidence-validator Full prompt →

Use it when you'd say

“validate this RAG answer”
“is this answer grounded in the chunks”
“audit the citations in this answer”
“check the faithfulness of this output”

Not for

composing or rewriting the answer
retrieving additional chunks
stylistic editing
non-RAG fact-checking against open knowledge

← What kind of content?

Call fleet MCP tools via PEBBLE gateway

Fleet tools via the PEBBLE gateway

pebble-tools ready

Discover and call fleet MCP tools (petrova, ares, hermes, traceo, github, Proof KB, …) through the one authenticated PEBBLE gateway at mcp.devarno.cloud, using the live /registry + session profiles.

kick pebble-tools Full prompt →

Use it when you'd say

“pebble tools”
“fleet tools”
“mcp gateway”
“use pebble”
“wire to pebble”

Not for

non-devarno-cloud repos

← What kind of content?

Declare the org's content arc/manifest

Content Arc Declare

content-arc-declare draft

Author or amend an org's arc manifest in abacus _arcs/ (through-line, acts, windows) so a planned content run becomes checkable, not just intended.

kick content-arc-declare Full prompt →

Use it when you'd say

“declare a content arc for this org”
“write the arc manifest”
“plan the content run for stratt-blue/null0-blue/devaqua-blue/devarno-downlink”
“supersede this arc's schedule”

Not for

checking an existing arc against reality (abacus's own validator does this on read; fathom's check_drift.py does the idea-space projection check)
deciding pacing/saturation within an already-declared arc (Yáo's arc-state, not this)
drafting the actual content (jazz)
opening/closing a PETROVA phase (petrova-phase-open/petrova-phase-close) — an arc is a plan, not a phase, per abacus _arcs/README.md's stated asymmetry with docs/decisions/

What usually comes next

content-decision-intake in Execute › Publish

← What stage of the content pipeline?

Gate A: intake a closed decision into abacus

Content Decision Intake

content-decision-intake draft

Gate A — read a closed, countersigned decision doc from a governed repo and, only if it's eligible, emit it as a ledger-artefact into abacus for drafting.

kick content-decision-intake Full prompt →

Use it when you'd say

“feed this decision into the content pipeline”
“is this decision eligible for content”
“intake this ADR for downlink/journal”
“gate this decision for publishing”

Not for

judging content quality, voice, or provenance once drafted (jazz's 30_verify_gate)
drafting the actual journal/blog entry (jazz's 00_core_translator + org adapter)
deciding when in the arc it should ship (Yáo / content-arc-declare cadence)
editing or reopening the decision doc itself (that's petrova-decide/petrova-phase-close territory, upstream of this)

What usually comes next

downlink-entry-author in Execute › Publish

← What stage of the content pipeline?

Draft a downlink blog entry

DOWNLINK Entry Author

downlink-entry-author draft

Turn raw notes or a draft artefact into an abacus blog-post markdown file that projects onto devarno.com/downlink cleanly on the first try.

kick downlink-entry-author Full prompt →

Use it when you'd say

“add a downlink entry”
“write a downlink post”
“new downlink article”
“turn these notes into a downlink entry”
“author an abacus blog post”
“convert this artefact into a downlink post”

Not for

editing an already-shipped entry (edit the abacus markdown directly and append a transition_history note)
projecting an entry onto landing (that is `npm run project:content` in landing; see the downlink-publish cycle)
generating the social variants of an entry (use downlink-social-repurposer)
picking or changing the featured entry (FEATURED_SLUG is hardcoded in landing/src/lib/blog-taxonomy.ts)
generating cover or card art (this prompt references image paths, it does not create them)

What usually comes next

downlink-publish in Execute › Publish
prose-humanize in Execute › Publish before it projects

← What stage of the content pipeline?

Project abacus → landing, or check drift

DOWNLINK Publish

downlink-publish draft

Project abacus blog entries onto landing and verify the result, or check for drift between the two repos without touching anything.

kick downlink-publish Full prompt →

Use it when you'd say

“publish the downlink entry”
“project content onto landing”
“reproject downlink”
“check downlink drift”
“is landing in sync with abacus”
“regenerate the blog projection”

Not for

authoring a new entry (use downlink-entry-author)
writing social variants (use downlink-social-repurposer)
hand-editing anything under src/content/blog/_generated (it is generated; the CI drift guard fails on hand-edits)
changing which entry is featured (FEATURED_SLUG is a hardcoded constant in landing)

What usually comes next

downlink-social-repurposer in Execute › Publish

← What stage of the content pipeline?

Diagnose what each enrolled app has shipped, and which content classes are open (PLAY-022 sweep, step 1)

Content diagnose — per-app D1 to D5 card from scanned signals and gate state

content-diagnose draft

Step 1 of the content-signal-sweep (PLAY-022). Reads the multi-repo commit scan and each enrolled app's gate state, decides whether class D is open, and writes one diagnosis card per app. Read-only.

kick content-diagnose Full prompt →

Use it when you'd say

“diagnose content signals for the enrolled apps”
“which content classes are open”

Not for

writing suggestion cards (content-suggest)
creating or editing any abacus artefact (a human commit does that, PLAY-022 refusals)
posting anywhere (PLAY-004 v2)

← What stage of the content pipeline?

Suggest ranked content cards from a diagnosis (PLAY-022 sweep, step 2; suggestions only)

Content suggest — ranked suggestion cards per app, through a platform lens

content-suggest draft

Step 2 of the content-signal-sweep (PLAY-022). Turns each diagnosed signal into suggestion cards in the classes that are open, at most five per app per sweep, then lets code drop what the rules forbid. Output is a feed file. Suggestions only.

kick content-suggest Full prompt →

Use it when you'd say

“suggest content for the enrolled apps”
“what should I post about an app”

Not for

posting or scheduling (PLAY-004 v2)
creating or editing any abacus artefact
delivering the feed to clio (a later task)

← What stage of the content pipeline?

Measure how visible a project is under the operator's name, and where it is missing (read-only)

Public exposure audit — is the project visible under the operator's name, and where is it missing

public-exposure-audit draft

Read-only. For one enrolled project, checks every public place the operator's name lives (personal site, content ledger, social identities) for the project, and the project's own surfaces for the operator; counts ledger artefacts about it by stage; and lists the gaps — shipped work with no artefact, a personal site that only links, a product with no founder line, a ledger with nothing past the inbox. Aggregates only.

kick public-exposure-audit Full prompt →

Use it when you'd say

“how visible is this project under my name”
“what have I published about this project”

Not for

drafting or publishing posts (content-suggest, PLAY-004 v2)
reading third-party profiles or followers (discovery-shortlist, under PLAY-010)

← What stage of the content pipeline?

List openings a project has earned and nobody has opened: write-ups, libraries, listings, talks (read-only)

Opportunity scan — openings a project has earned and nobody has opened

opportunity-scan draft

Read-only. From an estate-audit's evidence, lists openings beyond the current gates — a write-up a real incident earned, a library worth extracting under its own licence, a marketplace or directory listing the product already qualifies for, a talk or case study, an integration a customer would expect — each with the evidence that earned it, the effort, the play that would carry it, and any hold it would cross.

kick opportunity-scan Full prompt →

Use it when you'd say

“what openings has this project earned”
“where could this project get seen”

Not for

contacting, applying or publishing (the operator, through the named play)
market sizing or competitor research

← What stage of the content pipeline?

Show a sweep's cards as tasks in the private Orbit project CONT, status derived from abacus (PLAY-022 pilot)

Content CONT sync — show a sweep's cards as tasks in the private Orbit project CONT

content-cont-sync draft

Step 3 of the content-signal-sweep (PLAY-022), interim surface. Plans one CONT task per card (title, class, product, a link to the card) with prompts/_shared/orbit/cont_cards.py, posts the plan through the Orbit MCP, and reconciles status from abacus. Done only when a human abacus 00-inbox commit carries the card id.

kick content-cont-sync Full prompt →

Use it when you'd say

“put the sweep cards in orbit”
“reconcile cont”
“which content picks have landed”

Not for

marking a card Done by hand (status is derived only)
creating or editing any abacus artefact
posting content anywhere (PLAY-004 v2)
any app other than sparki-tools while the pilot runs

← What stage of the content pipeline?

Generalize publish to any org's own surface

Content Publish Sink

content-publish-sink draft

Generalizes DOWNLINK Publish's regenerate-verify-drift-check-commit sequence to any org's own render surface, not just landing.

kick content-publish-sink Full prompt →

Use it when you'd say

“publish this approved entry to its surface”
“project this abacus entry onto stratt-blue/null0-blue/devaqua-blue”
“check render drift for this surface”
“regenerate the journal page for this entry”

Not for

devarno.com/downlink specifically (use the existing downlink-publish prompt directly; this one is for every OTHER surface)
drafting or gating the entry (jazz, content-decision-intake)
the actual social-platform post (content-social-dispatch)

What usually comes next

downlink-publish in Execute › Publish generalizes

← What stage of the content pipeline?

Add, change or load a shared vocabulary term (platform, position, system, stage…)

Abacus Vocabulary

abacus-vocabulary draft

Add or change a shared term in abacus _refs/vocabulary.yaml and carry it through the cheat sheet, ledger snapshot and asgard parity test, or explain how a service loads the vocabulary.

kick abacus-vocabulary Full prompt →

Use it when you'd say

“add a platform to the vocabulary”
“add a shared term”
“add a new system name”
“yao rejects this platform or position”
“change a term in the abacus vocabulary”
“retire a vocabulary value”
“how do I load the vocabulary”
“where is the platform list”

Not for

adding a content type or a frontmatter field (that is a queue-schema.js SCHEMAS change plus an abacus template, not a vocabulary term)
arc layers, registers, blog domains or other enums the vocabulary does not carry yet
renaming a stage id (stages are recorded, never silently renamed; `archived` stays a known variant of `archive`)
drafting the content that uses the term (jazz, downlink-entry-author)

← What stage of the content pipeline?

Keep a static public projection in step with its ledger (pin, stale PR, operator deploy)

Public projection sync, keep the static page equal to its ledger

public-projection-sync draft

Keeps a static public projection in step with a private ledger without the projection ever being produced by a clock, a moving pin or an agent-initiated deploy. Proves the projector is deterministic, pins everything it reads, signals staleness with a PR instead of a deploy, and hands the deploy to the operator.

kick public-projection-sync Full prompt →

Use it when you'd say

“the public site is showing stale numbers”
“re-pin the projector lock after changing the ladder code”
“bump the projection schema version”
“prepare the gated deploy for the public page”
“is the served page the same as the gated build”

Not for

publishing a blog or journal entry (use downlink-publish or abacus-ship-and-project)
deploying to production without an operator dispatch
live or dynamic sites that read the ledger at request time

What usually comes next

verify-for-real in Verify served == gated

← What stage of the content pipeline?

Strip AI-writing tells from a draft before it ships (humanize-lint, rewrite, fact diff)

Prose humanize: lint, rewrite, fact-diff, re-lint

prose-humanize tested

Takes one piece of prose and a voice, strips the AI-writing tells catalogued by blader/humanizer (pinned v3.1.0@225a6f3), and returns a rewrite that says exactly what the original said. The deterministic humanize-lint gate runs before and after; a fact diff sits between them, so no tell is ever removed by inventing something.

kick prose-humanize Full prompt →

Use it when you'd say

“humanize this draft”
“remove the AI tells from this”
“this reads like a chatbot wrote it”
“de-slop this post”
“fix the humanizer warnings”

Not for

rewriting already-shipped content (edit the source and record the change the way its ledger requires)
changing what a draft claims; facts, numbers, names and links survive unchanged or the run stops
a human-authored draft the operator did not ask to rewrite (report the lint result instead)
voice or brand decisions (the voice comes from the input, never from this prompt)

← What stage of the content pipeline?

Drive one org's landing through the whole method (gates at conflicts, rulings, merge)

Landing truth flow (take one org's public surface to a true, slop-free page at the quality its price implies)

landing-truth-flow draft

Drives one org's landing page through the landing-truth method: context, claims ledger, funnel, value fit, operator rulings, sweep PRs, live re-read. One step per call, halting at operator gates, with a JSON handoff. Org-modular: every step takes the org, site and repo as inputs. Field-derived from traceo.cat (2026-10-21).

kick landing-truth-flow Full prompt →

Use it when you'd say

“run the landing truth flow”
“make the landing page slop-free”
“repeat the landing refinement for”
“does our landing reflect what we sell”
“landing page claims, ux and funnel review”

Not for

one audit on its own (landing-claims-ledger, landing-funnel-integrity-audit, landing-value-fit-audit)
a rebrand or new visual identity
changing prices or tiers (a pricing decision)

What usually comes next

landing-context-map in Execute › Landing truth step 1
landing-claims-ledger in Execute › Landing truth step 2
landing-funnel-integrity-audit in Execute › Landing truth step 3
landing-value-fit-audit in Execute › Landing truth step 4
landing-truth-sweep in Execute › Landing truth step 6

← Which pass of the landing-truth method?

Find the landing source and every document that binds it (read-only)

Landing context map (find the source and every document that binds an org's public surface)

landing-context-map draft

Read-only first pass of the landing-truth method. Locates the landing source, the documents that bind its copy, structure and design, the org's pricing ruling and audience statements, and registers every conflict with what the operator says they want. Field-derived from traceo.cat (2026-10-21).

kick landing-context-map Full prompt →

Use it when you'd say

“where does the landing page live”
“map the context for a landing review”
“what binds the marketing site”
“before we critique the landing page”

Not for

deciding whether a claim is true (landing-claims-ledger)
editing copy or opening PRs (landing-truth-sweep)

← Which pass of the landing-truth method?

Trace every claim on the site to code a customer can use today (read-only)

Landing claims ledger (every sentence on the public surface, traced to the code a customer can actually use)

landing-claims-ledger draft

Read-only. Classifies every claim on an org's public surface (copy, captions, tables, alt text, metadata, share card) and traces it to the mechanism at a named commit, with a verdict and a customer-usable-today test. Field-derived from traceo.cat (2026-10-21), where code existed for most false claims.

kick landing-claims-ledger Full prompt →

Use it when you'd say

“build the claims ledger”
“which landing claims are false”
“does the site oversell”
“check the marketing copy against the code”
“claims versus mechanism”

Not for

rewriting the copy (landing-truth-sweep)
broken links, metadata or layout (landing-funnel-integrity-audit)
controls and numbers inside an authenticated product UI (product-surface-truth-audit)

← Which pass of the landing-truth method?

Measure the signup funnel, phone reach, share card and crawlers (read-only)

Landing funnel integrity audit (every path from arrival to signup works, on a phone, and reads right to crawlers)

landing-funnel-integrity-audit draft

Read-only, measured on the rendered page. Checks CTAs and links, one primary action per viewport, phone reach, contrast of the primary CTA and brand-colour text, metadata, share card, canonical, robots and sitemap, and layout defects such as empty bands and unsized images. Field-derived from traceo.cat (2026-10-21).

kick landing-funnel-integrity-audit Full prompt →

Use it when you'd say

“audit the landing funnel”
“is the signup path broken”
“check the landing on mobile”
“link preview shows no image”
“landing seo and metadata check”

Not for

whether claims are true (landing-claims-ledger)
audience and positioning (landing-value-fit-audit)
applying fixes (landing-truth-sweep)

← Which pass of the landing-truth method?

Who buys, what proof they need, which true features carry it, at this price (read-only)

Landing value-fit audit (who buys, what proof they need, which true features carry it, at the price asked)

landing-value-fit-audit draft

Read-only. From the claims ledger and the binding context, maps each audience to the proof it needs and the TRUE features that supply it, holds the page to the quality its price implies, flags slop, and ranks the product surfaces to show first. Never promotes a feature the ledger did not mark TRUE. Field-derived from traceo.cat (2026-10-21).

kick landing-value-fit-audit Full prompt →

Use it when you'd say

“which surfaces should the landing lead with”
“does the landing fit our price”
“critique the landing for our target audiences”
“is the landing copy slop”
“features on sale versus audiences”

Not for

verifying claims against code (landing-claims-ledger)
broken links or metadata (landing-funnel-integrity-audit)
writing the new copy into the repo (landing-truth-sweep)

← Which pass of the landing-truth method?

Land the ruled fixes as draft PRs, red-first, one per concern

Landing truth sweep (land the ruled fixes as draft PRs, one per concern, red-first, recorded in the org's own form)

landing-truth-sweep draft

The only writing pass of the landing-truth method. From the ledger, funnel audit, value-fit audit and the operator's rulings, opens draft PRs split by concern (hygiene, design tokens, claims), writes a red-first claim test, replaces false copy with ledger-true wording, holds commercially ruled rows, records the ruling in the org's governance convention, and verifies on the rendered build. Field-derived from traceo.cat (#364, #365, #366, 2026-10-21).

kick landing-truth-sweep Full prompt →

Use it when you'd say

“apply the landing fixes”
“sweep the false claims off the site”
“land the landing critique”
“fix the landing page per the audit”

Not for

auditing claims or the funnel (run the landing-* audits first)
merging or deploying (operator)
changing prices or tier contents (a pricing decision)

What usually comes next

prose-humanize in Execute › Publish new copy before it lands

← Which pass of the landing-truth method?

Bring up a new fleet host from bare machine or VM

Fleet-host bring-up (hermes, bare machine to serving host)

fleet-host-bringup draft

Takes a bare machine to a serving hermes fleet host under docs/runbooks/fleet-host-bringup.md, then hands it to fleet-host-deploy.md. Encodes the traps a new host hits that an existing one never does — go missing from install.sh, the runner label derived from the hostname, panel registration blocked without a per-fleet cert, host-level podman state that install.sh does not carry, and per-job (not per-host) migration caps.

kick fleet-host-bringup Full prompt →

Use it when you'd say

“bring up a new fleet host”
“set up home-1”
“install hermes on the new box”
“new runner host bring-up”
“migrate the fleet to the owned machine”

Not for

rolling install.sh or a version bump on an existing host (use fleet-host-rollout)
retiring or cancelling the old host (its own decision, then fleet-deploy-runner)
minting the fleet's panel mTLS cert (cert-rotator; blocked until its milestone closes)

← What kind of fleet op?

Roll out install.sh across tenant roots

Fleet-host rollout (hermes runner estate)

fleet-host-rollout ready

Executes install.sh across tenant roots on a shared multi-tenant fleet host — rollouts, runner version bumps, tenant onboarding. Encodes the two absolute refusals (never dockerd / the docker group; never rsync or hand-edit onto a tenant), demands provenance and a green estate suite before rolling, and refuses to accept a green checkmark as verification.

kick fleet-host-rollout Full prompt →

Use it when you'd say

“roll this to the tenants”
“run install.sh on the fleet”
“bump the runner version”
“onboard a new tenant onto the fleet”
“deploy to hermes-fleet”

Not for

deploying hermes-panel (different surface — see the panel deploy skill / deploy-runner)
diagnosing telemetry or orphaned jobs (use fleet-ingest-triage)
writing the source fix itself (fix source, THEN roll it)

← What kind of fleet op?

Retire the eu-1 fleet host with no successor, lane by lane (fleet of subagents)

HERMES retire fleet (eu-1 out with no successor, plus the sparki worker lane)

hermes-retire-fleet draft

Conducts a bounded fleet of subagents through the hermes plan that retires hermes-fleet-eu-1 with no replacement host. Gate tooling is built test-first, every org lane closes on `hermesctl retire-gate` going red to green, the box is decommissioned only under the fleet-safety-gate, and the sparki CX33 worker lane runs alongside. Purchases, cancellations, key revocation, countersigns and merges stay the operator's.

kick hermes-retire-fleet Full prompt →

Use it when you'd say

“retire eu-1”
“run the hermes retire fleet”
“next retirement lane”
“decommission the auction box”
“CI-FREE with no fleet host”
“sparki worker lane”

Not for

bringing up or rolling a fleet host (fleet-host-bringup, fleet-host-rollout)
a single org's nightly flip with nothing else (ci-free-nightly-flip, gha-governed-org-nightly-flip)
buying, cancelling, revoking keys, countersigning or merging (operator)
sparki launch gates other than G-1-9's worker verification (launch-to-revenue record in sparki-tools/platform-docs)

← What kind of fleet op?

Triage an ingest ticket on a shared fleet host

Fleet telemetry ingest triage (hermes)

fleet-ingest-triage ready

Answers "is the fleet registered and is telemetry flowing?" in one call, then walks the ingest chain — webhook → org → run → job → fleet push — to the exact broken link. Codifies the orphan-job failure mode and the seam that caused it.

kick fleet-ingest-triage Full prompt →

Use it when you'd say

“is telemetry flowing”
“why are jobs orphaned”
“runners look idle”
“is eu-1 registered”
“fleet shows no telemetry”

Not for

writing the fix (triage first, then TDD)
runner provisioning (see install.sh / onboard-org)

← What kind of fleet op?

Triage podman `exceeded num_locks` or testcontainers readiness on a tenant (read-only)

Fleet podman lock / testcontainers triage (hermes)

fleet-podman-lock-triage draft

Read-only triage for a hermes fleet tenant whose CI fails with podman `exceeded num_locks`, or with testcontainers readiness waits that "matched 0 times". Finds the tenant's real store, counts what holds the locks, reads the lock ceiling podman actually applies, and checks whether the tenant can read its own container logs. Hands any write to fleet-deploy-runner under the hermes runbook.

kick fleet-podman-lock-triage Full prompt →

Use it when you'd say

“exceeded num_locks”
“allocating lock for new container”
“matched 0 times expected”
“testcontainers leaking on the fleet”
“podman locks exhausted”

Not for

executing the cleanup or a config change (fleet-deploy-runner, under the runbook)
rolling install.sh (use fleet-host-rollout)
application test failures that are not container-runtime shaped

← What kind of fleet op?

Audit what Hetzner bills against the documented baseline (read-only)

Hetzner cost audit (estate infra spend)

hetzner-cost-audit draft

Read-only audit of what the devarno estate is paying Hetzner for, and what the next invoice should be. Enumerates every billable Cloud resource through the hcloud CLI (one context per project), lists the Robot boxes, and checks both against the documented baseline. Anything unexplained is reported as a cost to chase, not deleted.

kick hetzner-cost-audit Full prompt →

Use it when you'd say

“where is the hetzner invoice”
“is a big hetzner charge coming”
“audit hetzner spend”
“what are we paying hetzner for”
“hetzner cost check”

Not for

cancelling, re-bidding or resizing a server (a decision doc in the owning repo first; this prompt only gathers evidence)
rotating or creating API tokens (operator-only, in the Cloud Console)
fleet-host runner changes (use fleet-host-rollout)

← What kind of fleet op?

Audit what Railway bills per service, or check whether another PaaS would be cheaper (read-only)

Railway cost census (per service, per cycle)

railway-cost-census draft

Read-only census of what the estate pays Railway, per service x environment, for one billing cycle. Reads the GraphQL usage API with the account token, attributes memory, CPU, egress and volume to each container, reconciles against the dashboard, and flags egress spikes, idle Postgres floors and dead projects. Also answers "should we move to another PaaS" with the pricing-shape check.

kick railway-cost-census Full prompt →

Use it when you'd say

“audit railway spend”
“railway bill went up”
“railway egress spike”
“what are we paying railway for”
“should we move off railway”
“compare railway with another paas”

Not for

any Railway write (variables, redeploys, deletions); those are operator-approved and production variables are FLIGHT-only
a Railway app that cannot reach its database (use railway-dead-service-diagnosis)
Vercel build cost (the build-cost ledger, build-cost-fanout.md)
Hetzner spend (use hetzner-cost-audit)

← What kind of fleet op?

Which apps earn more than they cost, and which to retire (read-only)

Unit economics review — what each app earns against what it costs

unit-economics-review draft

Triage the generated monthly unit-economics report (scripts/cycle-unit-economics.sh). Reads per-app revenue, Railway cost, gate progress and demand, and the PLAY-015 retirement proposals; names the one next operator act per app. Read-only.

kick unit-economics-review Full prompt →

Use it when you'd say

“which apps lose money”
“unit economics review”
“what should we retire”

Not for

retiring an app (PLAY-015, operator)
changing prices or plans (money act)
remapping Railway projects (edit cycles/monthly-unit-economics/projects.yaml in a PR)

← What kind of fleet op?

Is a founding discount about to hit its cap or close its window, so a consumer must stop requesting it (read-only)

Founding discount watch — will a capped, dated discount stop applying?

founding-discount-watch draft

Triage the generated choco founding-discount report (scripts/cycle-discount-watch.sh). Reads the window and redemption halves, says whether the operator must unset choco-gateway's TOLL_CHECKOUT_DISCOUNT now, soon, or not yet, and what is unknown (an unread redemption count). Read-only.

kick founding-discount-watch Full prompt →

Use it when you'd say

“founding discount running out”
“choco founding discount”
“turn off the founding discount”

Not for

unsetting TOLL_CHECKOUT_DISCOUNT (operator, Railway)
editing or deleting the Polar discount (money act)
changing the watched cap or dates (edit watch.yaml in a PR)

← What kind of fleet op?

Is every surface running what its main says, and can the live gate take money (read-only)

Live truth — is every surface running what main says, and can the live gate take money?

live-truth-triage draft

Triage the generated live-truth report (scripts/cycle-live-truth.sh). Per surface, says whether production runs main, a failed or stuck deploy, or merged config never deployed; for the money path, whether the live TOLL gate is up, verifies webhooks and is watched. Ranks the operator acts and names what was unread. Read-only.

kick live-truth-triage Full prompt →

Use it when you'd say

“is everything deployed”
“is it running main”
“did that merge ship”
“merged but not deployed”
“can the live gate take money”

Not for

redeploying or reconnecting a Railway or Vercel source (operator)
editing Railway, Vercel or Polar settings (operator)
deploying DSN config to panel-1 (operator / DSN runbook)
adding or changing a watched surface (edit surfaces.yaml in a PR)

← What kind of fleet op?

Wire approved automations (Routine now, EVA cycle later)

EVA automation install — wire approved automations as reviewable specs

eva-automation-install draft

Turn each automate or segment verdict in .eva/phase-manifest.yaml into a guarded eva.automation.v1 spec, render it as a paste-ready Claude Code Routine (now) and an EVA cycle twin (migration target), and open one draft PR. Never merges, never creates Routines itself.

kick eva-automation-install Full prompt →

Use it when you'd say

“install the approved automations”
“wire these steps as routines”
“render the automation specs for review”

Not for

steps triaged keep-manual
merging, enabling, or scheduling anything without a human (read-propose ceiling)
admitting a fleet to a repo (registry edit via petrova-codes)

← What kind of fleet op?

Move packages, module paths and CI references after a GitHub org rename

GitHub org-rename migration (package identity, module paths, CI references)

github-org-rename-migration draft

Moves everything that still resolves through GitHub's rename redirect after an org rename — npm scopes on GitHub Packages, Go module paths and tags, GOPRIVATE/insteadOf rewrites, .gitmodules, workflow repository guards — in producer-to-consumer order, while leaving runtime wire identifiers, secret names and historical docs alone.

kick github-org-rename-migration Full prompt →

Use it when you'd say

“the org was renamed, move the packages”
“npm package does not exist under owner”
“go module path still has the old org”
“workflow skipped since the org rename”
“repoint repos after a GitHub org rename”

Not for

renaming a single repo inside one org (GitHub redirects that; update remotes only)
renaming runtime wire identifiers such as container label keys (needs its own migration)
rotating the secret behind a renamed org (use credential-rotation-propagation)
changing a petrova registry slug (slugs are fleet identity, not GitHub identity)

← What kind of fleet op?

Admit a CI workflow to a service by GitHub OIDC, no stored token

GitHub Actions OIDC as a route-scoped machine identity

gha-oidc-machine-identity draft

Admits one GitHub Actions workflow to a service through OIDC workload federation instead of a stored token — a second issuer verified against GitHub's JWKS, an exact allowlist on numeric ids and workflow_ref, a fixed least role, a route and method scope, and a client that fetches the token just in time and pins it to one origin.

kick gha-oidc-machine-identity Full prompt →

Use it when you'd say

“let this workflow call the service without a secret”
“add GitHub OIDC auth to the API”
“CI gets 401 because it has no credential”
“workload identity federation for GitHub Actions”
“replace the service token with OIDC”

Not for

human user login or session auth
cloud-provider OIDC roles (AWS, GCP, Azure) where the provider owns verification
rotating an existing secret (use credential-rotation-propagation)
granting broad or write access to a machine principal (needs its own decision)

← What kind of fleet op?

Sign an app on another apex in through airlock's cross-apex handoff (Pattern B)

Airlock Pattern B consumer (cross-apex handoff sign-in for a Next.js app)

airlock-pattern-b-consumer draft

Wires a Next.js app on its own apex to sign in through devarno-cloud airlock's cross-apex handoff. It verifies the 60-second EdDSA handoff token against the airlock JWKS, sets a host-only session cookie, and optionally mints the app's own downstream token server-side. Field-derived from chronicle-cat/app#44 (2026-10-15).

kick airlock-pattern-b-consumer Full prompt →

Use it when you'd say

“airlock consumer for”
“pattern b handoff”
“sign in through airlock”
“cross-apex sign in”

Not for

registering the consumer origin in airlock (devarno-cloud/airlock handoff_consumers + src/registry/origins.ts)
devarno.cloud subdomain apps (Pattern A)
setting secrets (operator gate)

← What kind of fleet op?

Land one mechanical workflow edit across many repos and orgs

GitHub Actions estate batch edit (many orgs, one mechanical change)

gha-estate-batch-edit draft

Applies one mechanical workflow change (timeout-minutes, cron cadence, trigger removal) across many repos and orgs as one PR per repo, without spending CI minutes and without overriding a governed repo's own rules. Encodes the CI-FREE 2026-10-14 field lessons — skip-ci on both the commit and the squash subject, lint-neutral against base, governed orgs routed through their own decision process, and the human merging.

kick gha-estate-batch-edit Full prompt →

Use it when you'd say

“add timeout-minutes to every job”
“slow these crons across the estate”
“batch workflow PRs across orgs”
“CI-FREE workflow edits”
“open a PR in every repo that”

Not for

merging the PRs (the auto-mode classifier blocks bulk agent merges; the human merges)
changes in mary-wiki, petrova-codes or eva-hq that a ratified decision governs (draft a decision there instead)
fleet-host changes (fleet-host-rollout)

← What kind of fleet op?

Move one org's gate CI from push/PR to a nightly batch (CI-FREE phase 4)

CI-FREE phase 4 per-org flip (gate CI from push/PR to a no-App nightly batch)

ci-free-nightly-flip draft

Moves one org's gate CI off push and pull_request onto a per-repo nightly-gates.yml that runs only when the default branch moved, using the repo's own GITHUB_TOKEN. Content differs per repo, so it reads each repo's workflows, splits remote-only jobs out, routes dormant repos to dispatch-only, and records an org decision. The human merges.

kick ci-free-nightly-flip Full prompt →

Use it when you'd say

“flip this org to nightly”
“CI-FREE phase 4”
“move gate CI off push”
“nightly gates for”
“optimise CI minutes for”

Not for

one identical edit across many orgs (gha-estate-batch-edit)
repointing runs-on to HERMES / home-1 labels (fleet-host-rollout and the CI-FREE W5 label batch)
merging the PRs (the human merges)

← What kind of fleet op?

Plan and get signed off a push-to-nightly CI flip for an org whose gates protect security code

GitHub Actions nightly flip for a governed org (security gates, decision first)

gha-governed-org-nightly-flip draft

Plans the CI-FREE push-to-nightly trigger flip for one org whose gates protect security code, and gets it approved as a proposed decision doc before any workflow is touched. Encodes the nestr-tools 2026-10-15 field lessons — advisory pre-merge gates on free-plan private repos, host-bound "local-ok" jobs, arch pins in code, orphaned petrova workflows, stale dependabot PRs, and the human signing off.

kick gha-governed-org-nightly-flip Full prompt →

Use it when you'd say

“flip this org's gates to nightly”
“CI-FREE phase 4 for a governed org”
“move security gates off push”
“plan the nightly flip for”
“draft the CI-FREE decision for”

Not for

estate-wide mechanical edits across many orgs (use gha-estate-batch-edit)
merging the decision PR or the workflow PRs (the human merges)
settings changes (branch protection, Actions budgets, runner groups, repo settings)

← What kind of fleet op?

Give an org its own heavy-test lab on the Mac's external drive (CI-FREE Mac offload)

Mac lab bring-up (one org's offload lab on the Mac's external drive)

mac-lab-bringup tested

Gives one org its own test lab on the operator's Mac. That means an APFS sparse bundle on the external drive, Postgres and Redis on loopback ports no other lab uses, the `lab run` recorder, and labtop. Encodes the traps a first lab hits — exFAT drives, non-login PATH, the wrong Postgres major, the locale crash and the zsh word-splitting of ssh options.

kick mac-lab-bringup Full prompt →

Use it when you'd say

“set up a mac lab for”
“give this org a lab on the mac”
“ci-free mac offload”
“macbook testing for”
“new lab on the mac”

Not for

running a test suite on a lab that already exists (mac-lab-offload)
the hermes home-1 VM or any fleet host on the Mac (fleet-host-bringup, fleet-safety-gate)
making the lab a CI gate (it produces evidence; gates stay in CI-FREE nightly workflows)

← What kind of fleet op?

Hand refused or operator-only production steps to the operator as one rehearsed wizard

Operator wizard hand-off (refused or operator-only production steps, as one guided script)

operator-wizard-handoff draft

When the permission classifier refuses a production step, or governance reserves it for the operator, prepare and rehearse everything read-only, then hand the operator ONE hardened wizard script built from the wizard template. It is not a pile of copy-paste commands. The agent then verifies independently and continues the chain. Encodes the traps a first hand-off hits — the wrong database on a shared server, a raw tty, a pager that looks like a stall, re-runs that hit done steps, "dry runs" that write, and full-restore rollbacks that fail on new dependents.

kick operator-wizard-handoff Full prompt →

Use it when you'd say

“hand this to me as a wizard”
“the classifier refused the production step”
“bundle the operator steps”
“i'll run the prod steps myself”
“operator-only migration”

Not for

getting around a permission refusal by other means (never; that is laundering)
steps the agent is permitted to run (run them)
one-off provider-UI credential setup with no production write (use the wizard skill directly)

← What kind of fleet op?

Provision a Traceo workspace + baseline so a consumer's traceo probe reads ok

Provision a Traceo workspace and baseline for a petrova consumer

traceo-workspace-baseline-provision draft

Provider-side counterpart to petrova-wire-traceo. Gets a consumer's traceo probe to ok by putting its baseline where production actually serves baselines from (traceo-cat/ariel baselines/*.md at the pinned ariel rev), creating a same-tenant workspace the sanctioned way, repointing the OIDC trust entry, and verifying with an authenticated GET and a probe run.

kick traceo-workspace-baseline-provision Full prompt →

Use it when you'd say

“baseline not found in traceo”
“create the traceo baseline for this consumer”
“traceo probe is failing for kahn-hq”
“provision a traceo workspace”
“onboard a repo onto traceo baselines”

Not for

the consumer-side contract.yaml evidence edit alone (use petrova-wire-traceo)
admitting a new CI caller to traceo (use gha-oidc-machine-identity)
writing baselines through POST /api/ariel/baselines in production (ephemeral, see rules)
downgrading a contract to traceo pending (an operator contract ruling)

← What kind of fleet op?

Fill a product's demo@ account with realistic data, end to end (identity, seeder, env, plan, verify)

Demo tenant provision (fill a product's demo@ account with realistic data, end to end)

demo-tenant-provision draft

Drives one product from "no demo account" to "demo@ signs in to a populated, verified, resettable workspace". It runs the identity, coverage, seeder, env, reset, plan and verify steps in order, and halts at each operator gate. Field-derived from smo1-io (purr-api seed-demo, back-test) and sparki-tools (api-engine PRs 53, 60, 65 and 66, pilot, 2026-10-18/19).

kick demo-tenant-provision Full prompt →

Use it when you'd say

“prepare all demo data for”
“set up the demo tenant for”
“fill the demo account”
“demo@ account with mock data”
“provision a demo workspace”

Not for

local dev seed data or test fixtures
load or performance data
refreshing an existing demo tenant (cycles/demo-refresh)
setting secrets or Railway variables (operator gate)

What usually comes next

demo-identity-bootstrap in Execute › Fleet op step 2
demo-coverage-audit in Orient step 3
demo-seed-author in Execute › Fleet op step 4
demo-verify in Verify step 7
operator-wizard-handoff in Execute › Fleet op operator gates as one wizard

← What kind of fleet op?

Get a demo@ login into airlock and read back its user id for the product env

Demo identity bootstrap (Airlock invite → first sign-in → demo user id)

demo-identity-bootstrap draft

Gets a product's demo@ login into devarno-cloud airlock and reads back its user id for the product's demo env vars. It invites, halts for the operator's magic-link sign-in, then reads the id from the airlock database read-only. Never sets secrets. Field-derived from sparki-tools 2026-10-18/19 and smo1-io.

kick demo-identity-bootstrap Full prompt →

Use it when you'd say

“create the demo login”
“airlock id for demo@”
“demo user id”
“invite demo@ to airlock”

Not for

real customer accounts
airlock sign-in loops or session storms
setting Railway variables (operator gate)

← What kind of fleet op?

Write or extend a deterministic, guarded, resettable demo seeder

Demo seed author (deterministic, guarded, resettable demo data for one product)

demo-seed-author draft

Writes or extends a product's demo seeder using the pattern proven in smo1-io purr-api (seed-demo) and sparki-tools api-engine (pkg/demo). A pure plan built from now, one transaction, seed and reset modes, demo-owned deletes only, an id+email guard, per-screen tests and a runbook. Opens one PR.

kick demo-seed-author Full prompt →

Use it when you'd say

“write the demo seeder”
“seed the empty demo screens”
“extend the demo reset”
“demo data generator”

Not for

test fixtures or local dev seeds
the plan or tier (billing state)
running the seed against production

← What kind of fleet op?

Retire a host, domain or deck (consumers first, DNS last)

Retire a surface — ordered teardown, DNS last

surface-retire draft

Takes a domain, app, service or whole deck out of service in the only safe order — consumers, router, probes, CI, DNS last — then writes the decision naming what it supersedes. The deck variant adds a 48-hour quiet watch and hands the subscription cancellation to the operator.

kick surface-retire Full prompt →

Use it when you'd say

“retire this host”
“decommission ODIN”
“take this domain out of service”
“we renamed the front, clean up the old one”
“the box is going, what still points at it”

Not for

deleting code or dropping a dependency
a temporary outage or maintenance window
moving one workload between decks without retiring anything (deck-act-go alone)

What usually comes next

deck-act-go in Decide every host write inside the teardown needs its own GO

← What are you executing?

Consolidate one repo's local clones, worktrees, branches and stashes into one checkout

Local-checkout consolidation — one clean checkout per repo

local-checkout-consolidate draft

Takes one repo's local sprawl (extra clones, sibling and .claude worktrees, merged branches, stale stashes) down to a single clean primary checkout on the default branch. Order is fixed — inventory, archive, operator gates, execution, verification. Nothing is deleted before it is bundled, and nothing the inventory cannot prove landed is deleted at all.

kick local-checkout-consolidate Full prompt →

Use it when you'd say

“consolidate my local checkouts”
“clean up the worktrees in this repo”
“too many branches and worktrees locally”
“one clean checkout per repo”
“prune merged branches and stashes”

Not for

deleting remote branches without asking (the remote-delete gate, every run)
dead-code sweeps or any cleanup inside the repo's tree (scope is git hygiene only)
fleet hosts (eu-1, hermes*) or any machine but the operator's own
repos the operator did not name

← What are you executing?

A run failed

PETROVA failure-mode triage

petrova-failure-triage ready

Map an observed error/symptom to the closest PETROVA error code and prescribe the runbook recovery path adapted to this stack.

kick petrova-failure-triage Full prompt →

Use it when you'd say

“failure triage”
“map this error to petrova”
“recover from this error”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

What usually comes next

petrova-propose-fix in Execute propose a fix

← What kind of stuck?

Work is sitting idle

PETROVA stalled-work scan

petrova-stalled-work ready

Find PRs without recent activity, milestones not progressing, decisions open `14 days, findings without paired decisions, branches `30 days unmerged. Group: revivable / blocked / abandoned.

kick petrova-stalled-work Full prompt →

Use it when you'd say

“find stalled work”
“what's blocked”
“scan for abandoned items”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

← What kind of stuck?

Feels harder than it should

PETROVA friction classifier

petrova-friction-classify ready

Classify a friction item: closed (trivial follow-up) / in-budget (small, lands now) / deferred (next-phase milestone — MR-2). When in doubt, defer.

kick petrova-friction-classify Full prompt →

Use it when you'd say

“classify friction”
“is this in-budget or deferred”
“apply mr-2 to this item”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

← What kind of stuck?

Capture a one-off observation

PETROVA finding

petrova-finding ready

Emit a raw finding at docs/findings/YYYYMMDD-HHMM-`slug`.md.

kick petrova-finding Full prompt →

Use it when you'd say

“record a finding”
“capture an observation in petrova”

Not for

editing existing findings
non-petrova repos without docs/findings/

← What kind of stuck?

Suspect drift between repos

PETROVA drift check

petrova-drift-check ready

Probe rank-graph contradictions and named anti-shape drift; surface or resolve.

kick petrova-drift-check Full prompt →

Use it when you'd say

“petrova drift-check”
“run petrova drift-check on this repo”

Not for

repos that aren't petrova-shaped (no `.petrova/contract.yaml`)
cross-repo workflows (one repo per invocation)

← What kind of stuck?

Suspect a boundary violation

PETROVA boundary + privileged-path audit

petrova-boundary-audit ready

Where can scripts/agents write to sensitive surfaces (workflows, secrets, IAM, db) without going through a reviewable PR? Propose typed verb gates.

kick petrova-boundary-audit Full prompt →

Use it when you'd say

“audit boundaries”
“privileged path audit”
“find unbounded writes”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

← What kind of stuck?

Old decision still binding?

PETROVA supersession check

petrova-supersession-check ready

Find every closed-status decision doc whose claims a proposed change would contradict; draft Supersedes: docs (never edits originals — MR-7).

kick petrova-supersession-check Full prompt →

Use it when you'd say

“supersession check”
“what decisions does this change contradict”
“mr-7 supersession”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

← What kind of stuck?

Upstream dep changed?

PETROVA upstream watch

petrova-upstream-watch ready

Generic upstream-source poller. Cycle author declares the sources (PyPI, GitHub releases, RSS) and notify rules; this prompt classifies deltas as none | minor | breaking | unknown and routes escalations.

kick petrova-upstream-watch Full prompt →

Use it when you'd say

“watch upstream”
“check for breaking changes upstream”
“atproto release watch”
“polar release watch”

Not for

internal repos with no external upstream constraints (the verb still works but findings are vacuous).

← What kind of stuck?

Wire a contract-drift detector

PETROVA wire-contract drift

petrova-wire-contract-drift ready

Walks a contract repo (e.g. proto-schemas) HEAD against every consumer's gen/ checksum. Surfaces silent schema drift before it surfaces as a confusing build error.

kick petrova-wire-contract-drift Full prompt →

Use it when you'd say

“check wire-contract drift”
“proto-schema drift walk”
“gen/ checksum check”

Not for

monorepos where the contract repo and consumer code share a single commit graph (the cycle then has nothing to compare).

← What kind of stuck?

Soak an invariant under load

PETROVA invariant soak

petrova-invariant-soak ready

Runs an assertion table from the cycle.yaml against a staging slice. Each row is one project invariant (I-N) with a probe that yields pass | fail | skip.

kick petrova-invariant-soak Full prompt →

Use it when you'd say

“soak the invariants”
“assert I-N”
“weekly invariant rehearsal”

Not for

repos with no project invariants declared in CLAUDE.md (the verb still works but findings are vacuous).

← What kind of stuck?

Suspect a dev-mode auth fail-open

Auth fail-open audit

auth-fail-open-audit ready

Hunts the specific shape where a dev-mode escape hatch becomes the production front door — an absent identity treated as "auth is off" rather than "the caller did not authenticate". Probes the running service without credentials.

kick auth-fail-open-audit Full prompt →

Use it when you'd say

“audit the auth on this service”
“can an unauthenticated caller reach this”
“does this API actually require a token”
“security review the gateway”
“does the cache path skip the protection check”
“custom slug bypasses the password”

Not for

writing the fix (audit first, then TDD the fix)
authorization policy design (this is about the guard being reached at all, on every path)

← What kind of stuck?

A transactional email was refused or never arrived

SMTP sender triage, prove why a transactional email was refused or lost

smtp-sender-triage draft

Traces a missing transactional email from the app log to the provider reply, separates refusal at submission from loss after acceptance, and proves the fix with a delivered message's headers. Treats DNS as a suspect only once the provider has accepted the message.

kick smtp-sender-triage Full prompt →

Use it when you'd say

“password reset email never arrived”
“verification email not received”
“EENVELOPE”
“SMTP 553”
“Sender address rejected”
“moving an app to a new mail sender”

Not for

rotating the SMTP password (use credential-rotation-propagation)
a sign-in loop with mail arriving correctly (use airlock-session-diagnosis)

← What kind of stuck?

A workflow fails at Set up job / a `uses:` ref won't resolve

Action ref reachability, prove every uses ref resolves from its org

action-ref-reachability draft

Sweeps the workflows of a set of repos, classifies every `uses:` reference as reachable, unreachable across orgs, ref-missing or local, and recommends vendoring or inlining with a job-level guard. Proves each fix with the last failing run and the first run after the fix.

kick action-ref-reachability Full prompt →

Use it when you'd say

“a workflow fails at Set up job”
“Unable to resolve action”
“can this repo use that shared action”
“we made the repo private, what breaks”
“audit uses refs across the org”

Not for

rotating the secret the action needs (use credential-rotation-propagation)
admitting a workflow to a service by OIDC (use gha-oidc-machine-identity)

What usually comes next

petrova-wire-eva in Execute › Wire cross-org consumers vendor, never uses: a private ref

← What kind of stuck?

Railway app gets `connection reset by peer` from *.proxy.rlwy.net (database service not running?)

Railway dead database service (proxy resets, nothing behind it)

railway-dead-service-diagnosis draft

Diagnoses a Railway app that crash-loops with `connection reset by peer` to `*.proxy.rlwy.net` when the real cause is that the database service has no running deployment. Proves it read-only, then restores the service on its existing volume with `serviceInstanceDeployV2` and moves the app to the private `${{Postgres.DATABASE_URL}}` reference.

kick railway-dead-service-diagnosis Full prompt →

Use it when you'd say

“connection reset by peer proxy.rlwy.net”
“railway app crash-loops connecting to postgres”
“failed to connect to the database on railway”
“railway redeploy says No deployment found”
“railway postgres service has no deployment”
“latestDeployment is null”

Not for

a database that is running and refusing auth or rejecting the role (credentials, not liveness; see credential-rotation-propagation)
slow queries, pool exhaustion or connection limits on a live database
Postgres outside Railway, or a Railway database you have not disambiguated (run railway-target-disambiguation first)
major-version upgrades of the data directory (pg_upgrade or dump/restore is its own change with its own decision)
restoring from backup after data loss (this prompt assumes the volume is intact)

← What kind of stuck?

Non-root container gets permission denied on a root-owned volume

Non-root container on a root-owned volume (chown then drop)

nonroot-container-volume-permissions draft

Fixes a distroless `:nonroot` image (UID 65532) that fails with "permission denied" on a volume the platform mounts root-owned, such as Railway's `/data`. The approved pattern starts the process as root, chowns only allowlisted paths under the mount with `os.Root` and `Lchown`, then drops to 65532 and proves the drop before any file or socket is opened.

kick nonroot-container-volume-permissions Full prompt →

Use it when you'd say

“permission denied on /data in a nonroot container”
“distroless nonroot cannot write to the volume”
“railway volume is root-owned”
“uid 65532 permission denied”
“should we run the container as root”
“chown the volume then drop privileges”

Not for

platforms that can set the volume owner or fsGroup (set it there, no code change)
images that already run as root by design (that is a different decision, not this fix)
read-only data the process never writes (mount it read-only instead)
non-Go services (the pattern carries over, the os.Root details do not)
a SELinux or AppArmor denial (check the audit log first; ownership is not the problem)

What usually comes next

security-pr-review-loop in Execute

← What kind of stuck?

A single task's AC

Task acceptance check

task-acceptance-check ready

Read-only verifier. Given a Task and a candidate completion artefact, scores each acceptance criterion line-by-line. Output is a structured pass/score block consumed by `tasks/complete`.

kick task-acceptance-check Full prompt →

Use it when you'd say

“check this task's acceptance criteria”
“verify the work meets the AC”
“score this completion against AC”

Not for

producing the work itself
reviewing code style/quality (use a code-review prompt)
tasks without explicit acceptance_criteria

← What are you verifying?

A full verification round

PETROVA verification round

petrova-verify-round ready

Run the mandatory friction-probe verification round for an open phase (MR-10).

kick petrova-verify-round Full prompt →

Use it when you'd say

“petrova verify-round”
“run petrova verify-round on this repo”

Not for

repos that aren't petrova-shaped (no `.petrova/contract.yaml`)
cross-repo workflows (one repo per invocation)

← What are you verifying?

A merge request is green

PETROVA MR-1..21 audit

petrova-mr-check ready

Audit a consumer repo against every meta-rule; emit a violations list and a progress signal.

kick petrova-mr-check Full prompt →

Use it when you'd say

“audit petrova invariants”
“check meta-rules on this repo”
“run an MR audit”

Not for

non-petrova repos
mutating fixes (this verb is read-only; pair with petrova-decision-doc to record a fix decision)

← What are you verifying?

Need human review

PETROVA request review

petrova-request-review ready

Open a PR with explicit file changes and request human review. Validates operator-supplied grounding (decision docs, MR citations, north-star refs) before composing the PR envelope.

kick petrova-request-review Full prompt →

Use it when you'd say

“petrova request review for <slug>”
“open review PR on <slug>”
“request review on <slug>”

Not for

repos not in `petrova-codes/registry.yaml`
PRs that should auto-merge once CI passes (use `petrova-request-merge-when-green` instead)
changes without at least one grounding ref (decision doc, north-star section, MR, or finding)

← What are you verifying?

Auto-merge when CI passes

PETROVA request merge when green

petrova-request-merge-when-green ready

Open a PR with auto-merge enabled. Profile-gated — only repos with branch protection that permits auto-merge can use this verb. Validates merge_method and grounding before composing the PR envelope.

kick petrova-request-merge-when-green Full prompt →

Use it when you'd say

“petrova request merge when green for <slug>”
“auto-merge PR on <slug>”
“enable auto-merge on <slug>”

Not for

repos without branch protection (no required status checks on default branch)
repos with registry profile=strict (human merge required — use `petrova-request-review`)
PRs that need human-eyes review before merge
cross-repo batch auto-merge flows

← What are you verifying?

Is this green signal even real?

Verify for real (anti-false-green)

verify-for-real ready

Refuses the ways a green signal lies — exit code from the wrong process, a cancelled job read as a pass, a suite that is green because of the bug, a suite that collected zero tests, "tests pass" mistaken for "it works", and a broken measurement reporting absence as a clean negative. Drives the real system before any completion claim.

kick verify-for-real Full prompt →

Use it when you'd say

“verify this properly”
“is it actually fixed”
“tests pass but it still fails”
“before I claim this is done”
“ci is green but”
“the search found nothing”
“confirm nothing else is affected”

Not for

writing new tests from scratch (use test-driven-development)
reviewing a diff for style

← What are you verifying?

Run a heavy suite on the org's Mac lab and diff it against a baseline

Mac lab offload (run a heavy suite on an org's Mac lab, against a baseline)

mac-lab-offload tested

Runs one repo's heavy verification on the org's Mac lab instead of the workstation, recorded with `lab run` so the operator watches it in labtop. It works for a DB-backed Go suite, a full vitest run or a production build. Private dependencies are packed on the workstation, so the lab never holds a credential. The candidate is compared against a baseline by failing test NAME, and runs report skips and recovered panics instead of trusting the exit code.

kick mac-lab-offload Full prompt →

Use it when you'd say

“run this on the mac”
“offload the test suite”
“power-test on the macbook”
“did my pr add failures”
“run the db suite on the lab”

Not for

creating the lab, ports or volume (mac-lab-bringup)
docker or testcontainers suites (no docker on the lab; record them as not run)
deciding merge readiness alone (pair with verify-for-real; the lab produces evidence, not a gate)

← What are you verifying?

Re-derive QA 'pass' verdicts from scratch (fresh session)

QA adversary (independent re-derivation)

qa-adversary draft

Fresh-session re-derivation of every "pass" verdict in the QA Check Register, without reading prior evidence, to catch confirmation rather than verification.

kick qa-adversary Full prompt →

Use it when you'd say

“qa adversary”
“re-derive qa verdicts”
“w4 adversary”

Not for

confirming a row without visiting the primary surface yourself
reading Red Evidence or Notes before forming your own verdict

← What are you verifying?

Prove a liveness check can fail on its own (dead-man, both arms)

Dead-man heartbeat, prove the watcher can fail without the watched

dead-man-heartbeat draft

Rebuilds a liveness or staleness check so it runs independently of the job it watches, sets its threshold from measured cadence plus scheduler lag, and proves it on both arms (a planted stale artefact goes red, a fresh one goes green) plus an external vantage that catches "nothing ran at all".

kick dead-man-heartbeat Full prompt →

Use it when you'd say

“add a heartbeat to this loop”
“would we notice if the cron stopped”
“the heartbeat never fires”
“prove the staleness check works”
“dead man switch for this workflow”

Not for

uptime probes of an HTTP surface that already has an external monitor (use estate-analytics-wiring)
runner liveness on fleet hosts (use fleet-ingest-triage; registered count is not liveness)
designing the alert routing or paging policy

What usually comes next

verify-for-real in Verify

← What are you verifying?

Is the demo account ready for a call? (sign in as demo@, check every page)

Demo verify (sign in as demo@, screenshot every page, check the runbook)

demo-verify draft

Drives the product as the demo login with Playwright after a reset, screenshots each page on the runbook checklist, checks each expected line, and posts a pass/fail status. Field-derived from smo1-io's manual checklist and the sparki-tools pilot.

kick demo-verify Full prompt →

Use it when you'd say

“verify the demo account”
“is the demo ready for the call”
“check demo@ after reset”

Not for

product e2e test suites
fixing seed gaps (demo-seed-author)

← What are you verifying?

Does a consumer's money path hold on sandbox Polar? (full matrix, before live)

TOLL sandbox matrix (prove a consumer's money paths on real sandbox Polar)

toll-sandbox-matrix draft

Runs success, decline, abandon, duplicate and out-of-order webhook, refund, cancel, plan change and revoke for one TOLL consumer against the real sandbox gate and sandbox Polar, with a recorded finding and a verify-reviewer. Includes a working lab harness and the way to hold Polar deliveries so that a late event is a first arrival, not a replay.

kick toll-sandbox-matrix Full prompt →

Use it when you'd say

“sandbox matrix”
“test-mode matrix”
“prove out-of-order webhook”
“hold polar deliveries”
“redeliver polar webhook”

Not for

wiring an app to TOLL (toll-consumer-wire)
anything on toll.gate.live or production Polar
setting secrets or changing a deployed environment (operator)

← What are you verifying?

Write up after-the-fact

PETROVA post-mortem from audit trail

petrova-post-mortem ready

Reconstruct the trigger chain over a window from commits/PRs/CI, name where the audit trail had gaps, output what would have prevented this.

kick petrova-post-mortem Full prompt →

Use it when you'd say

“post-mortem”
“reconstruct what went wrong”
“audit-trail gap analysis”

Not for

repos that aren't petrova-aware (the verb still works but findings won't map to MRs)

What usually comes next

petrova-decision-doc in Decide often spawns

← What are you verifying?

Close the governance phase

Petrova Phase Close

petrova-phase-close ready

petrova-phase-close

kick petrova-phase-close Full prompt →

Use it when you'd say

“petrova phase close”

Not for

non-petrova repos

What usually comes next

new cycle — What do you need to see? new cycle

← What are you verifying?

The same tree as diagrams, one step at a time. Click a box to open it; ⤢ opens fullscreen.

flowchart LR
    B1["Onboard<br/><small>4 prompts</small>"] --> B2["Orient<br/><small>11 prompts</small>"]
    B2 --> B3["Decide<br/><small>6 prompts</small>"]
    B3 --> B4["Plan<br/><small>23 prompts</small>"]
    B4 --> B5["Execute<br/><small>77 prompts</small>"]
    B5 --> B7["Verify<br/><small>13 prompts</small>"]
    B5 -.->|"something's off"| B6["Stuck<br/><small>15 prompts</small>"]
    B6 -.->|"fix"| B5
    B7 -.->|"new cycle"| B2
    B7 -.->|"post-mortem"| B3
    B0["Let EVA drive<br/><small>13 prompts</small>"] -.->|"drives"| B5
    click B0 "#map-B0"
    click B1 "#map-B1"
    click B2 "#map-B2"
    click B3 "#map-B3"
    click B4 "#map-B4"
    click B5 "#map-B5"
    click B6 "#map-B6"
    click B7 "#map-B7"
    classDef meta fill:#2a2140,stroke:#c588ff,color:#e6e6e6;
    classDef branch fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    class B0 meta;
    class B1,B2,B3,B4,B5,B6,B7 branch;

Let EVA drive

Walk this step in the guide →

flowchart LR
    Q{{"What should the harness do for you?"}}
    o0(["Bring a fresh repo into the fleet<br/><b>eva-onboard</b>"])
    Q --> o0
    click o0 "/prompts/eva-onboard/"
    o1(["Bring an app onto TOLL, gates/CUPEL and Orbit, rail by rail<br/><b>estate-onboard</b>"])
    Q --> o1
    click o1 "/prompts/estate-onboard/"
    o2(["Pick the single next highest-leverage move<br/><b>eva-next</b>"])
    Q --> o2
    click o2 "/prompts/eva-next/"
    o3(["Plan → queue → execute one goal, step by step<br/><b>eva-flow</b>"])
    Q --> o3
    click o3 "/prompts/eva-flow/"
    o4(["Run one governed autopilot tick<br/><b>eva-tick</b>"])
    Q --> o4
    click o4 "/prompts/eva-tick/"
    o5(["Cross the phase boundary (verify → close → open)<br/><b>eva-cycle</b>"])
    Q --> o5
    click o5 "/prompts/eva-cycle/"
    o6(["Respond to the latest red signal<br/><b>eva-recover</b>"])
    Q --> o6
    click o6 "/prompts/eva-recover/"
    o7(["A script's CLI drifted from an external tool<br/><b>eva-cli-drift-recover</b>"])
    Q --> o7
    click o7 "/prompts/eva-cli-drift-recover/"
    o8(["Governance gauntlet, one PASS/WARN/FAIL table<br/><b>eva-health</b>"])
    Q --> o8
    click o8 "/prompts/eva-health/"
    o9(["Ratify a new fleet baseline<br/><b>eva-baseline</b>"])
    Q --> o9
    click o9 "/prompts/eva-baseline/"
    o10(["Ask a question, evidence-bound<br/><b>eva-ask</b>"])
    Q --> o10
    click o10 "/prompts/eva-ask/"
    o11(["Re-project the handbook + manifest<br/><b>eva-project</b>"])
    Q --> o11
    click o11 "/prompts/eva-project/"
    o12(["Plug this repo into the EVA timeline for its current phase<br/><b>eva-plug-in</b>"])
    Q --> o12
    click o12 "/prompts/eva-plug-in/"
    s0["→ Onboard"]
    o0 -.->|"drives"| s0
    click s0 "#map-B1"
    s1["→ Orient"]
    o2 -.->|"recommends from — doesn't invoke"| s1
    click s1 "#map-B2"
    s2["→ Plan"]
    o3 -.->|"drives"| s2
    click s2 "#map-B4"
    s3["→ Execute"]
    o4 -.->|"drives one petrova verb"| s3
    click s3 "#map-B5"
    s4["→ Verify"]
    o5 -.->|"drives"| s4
    click s4 "#map-B7"
    s5["→ Stuck"]
    o6 -.->|"drives"| s5
    click s5 "#map-B6"
    s6["→ Orient"]
    o8 -.->|"reads"| s6
    click s6 "#map-B2"
    o9 -.->|"requires a green run of"| o8
    s7["→ Orient"]
    o12 -.->|"starts at the phase manifest"| s7
    click s7 "#map-B2"
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5,o6,o7,o8,o9,o10,o11,o12 leaf;
    class s0,s1,s2,s3,s4,s5,s6,s7 stub;

Onboard

Walk this step in the guide →

flowchart LR
    Q{{"How cold is the start?"}}
    o0(["Brand-new machine<br/><b>petrova-onboard</b>"])
    Q --> o0
    click o0 "/prompts/petrova-onboard/"
    o1(["Repo present, env not wired<br/><b>petrova-bootstrap</b>"])
    Q --> o1
    click o1 "/prompts/petrova-bootstrap/"
    o2(["Installing into a sibling repo<br/><b>petrova-install-playbook</b>"])
    Q --> o2
    click o2 "/prompts/petrova-install-playbook/"
    o3(["Handing off to a fresh agent mid-task<br/><b>session-handoff</b>"])
    Q --> o3
    click o3 "/prompts/session-handoff/"
    s0["→ Orient"]
    o0 -.-> s0
    click s0 "#map-B2"
    s1["→ Orient"]
    o1 -.-> s1
    click s1 "#map-B2"
    s2["→ Orient"]
    o2 -.-> s2
    click s2 "#map-B2"
    s3["→ Orient"]
    o3 -.-> s3
    click s3 "#map-B2"
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3 leaf;
    class s0,s1,s2,s3 stub;

Orient

Walk this step in the guide →

flowchart LR
    Q{{"What do you need to see?"}}
    o0(["Whole fleet at a glance<br/><b>petrova-fleet-snapshot</b>"])
    Q --> o0
    click o0 "/prompts/petrova-fleet-snapshot/"
    o1(["Is this repo healthy?<br/><b>petrova-health-check</b>"])
    Q --> o1
    click o1 "/prompts/petrova-health-check/"
    o2(["Is my tooling healthy?<br/><b>petrova-doctor</b>"])
    Q --> o2
    click o2 "/prompts/petrova-doctor/"
    o3(["What governance exists?<br/><b>petrova-governance-inventory</b>"])
    Q --> o3
    click o3 "/prompts/petrova-governance-inventory/"
    o4(["What on MARY's governance snapshot needs attention?<br/><b>mary-governance-diagnose</b>"])
    Q --> o4
    click o4 "/prompts/mary-governance-diagnose/"
    o5(["What changed since X?<br/><b>petrova-changes-since</b>"])
    Q --> o5
    click o5 "/prompts/petrova-changes-since/"
    o6(["Are the docs current?<br/><b>petrova-doc-freshness</b>"])
    Q --> o6
    click o6 "/prompts/petrova-doc-freshness/"
    o7(["What is filed twice across the estate's knowledge stores?<br/><b>knowledge-dupes-review</b>"])
    Q --> o7
    click o7 "/prompts/knowledge-dupes-review/"
    o8(["What manual ops should become Routines?<br/><b>petrova-routine-archaeology</b>"])
    Q --> o8
    click o8 "/prompts/petrova-routine-archaeology/"
    o9(["What does my current phase still need to close?<br/><b>eva-phase-manifest</b>"])
    Q --> o9
    click o9 "/prompts/eva-phase-manifest/"
    o10(["Which screens does a product's demo account leave empty?<br/><b>demo-coverage-audit</b>"])
    Q --> o10
    click o10 "/prompts/demo-coverage-audit/"
    s0["→ Plan: eva-automation-triage"]
    o9 -.-> s0
    click s0 "/prompts/eva-automation-triage/"
    s1["→ Let EVA drive: eva-cycle"]
    o9 -.->|"when every gate passes"| s1
    click s1 "/prompts/eva-cycle/"
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5,o6,o7,o8,o9,o10 leaf;
    class s0,s1 stub;

Decide

Walk this step in the guide →

flowchart LR
    Q{{"What kind of decision?"}}
    o0(["Capture a single decision<br/><b>petrova-decision-doc</b>"])
    Q --> o0
    click o0 "/prompts/petrova-decision-doc/"
    o1(["Weigh options / ADR<br/><b>petrova-adr-tradeoff</b>"])
    Q --> o1
    click o1 "/prompts/petrova-adr-tradeoff/"
    o2(["The spec's default would block everything, or a 'turn it on' would break prod: stop and lay out three options<br/><b>spec-blocked-feature-stop</b>"])
    Q --> o2
    click o2 "/prompts/spec-blocked-feature-stop/"
    o3(["Freeze a current-state baseline<br/><b>petrova-declare-baseline</b>"])
    Q --> o3
    click o3 "/prompts/petrova-declare-baseline/"
    o4(["Check alignment with the north star<br/><b>petrova-north-star-align</b>"])
    Q --> o4
    click o4 "/prompts/petrova-north-star-align/"
    o5(["Authorise one write to a VPS deck (GO record, FLIGHT ratifies)<br/><b>deck-act-go</b>"])
    Q --> o5
    click o5 "/prompts/deck-act-go/"
    s0["→ Verify: petrova-request-review"]
    o5 -.->|"FLIGHT ratifies before the act"| s0
    click s0 "/prompts/petrova-request-review/"
    s1["→ Execute: security-pr-review-loop"]
    o2 -.->|"option A: build the producer, stay strict"| s1
    click s1 "/prompts/security-pr-review-loop/"
    o2 -.->|"option C: relax only via I-2 sign-off"| o0
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5 leaf;
    class s0,s1 stub;

Plan

Walk this step in the guide →

flowchart LR
    Q{{"What are you planning?"}}
    o0(["One feature, one repo<br/><b>petrova-plan-feature</b>"])
    Q --> o0
    click o0 "/prompts/petrova-plan-feature/"
    o1(["Bundle of tasks<br/><b>task-bundle-planner</b>"])
    Q --> o1
    click o1 "/prompts/task-bundle-planner/"
    o2(["An implementation prompt for a downstream agent<br/><b>meta-prompt-generator</b>"])
    Q --> o2
    click o2 "/prompts/meta-prompt-generator/"
    o3(["Add a milestone to the roadmap<br/><b>petrova-milestone-add</b>"])
    Q --> o3
    click o3 "/prompts/petrova-milestone-add/"
    o4(["Cross-repo execution graph<br/><b>repo-dag-generator</b>"])
    Q --> o4
    click o4 "/prompts/repo-dag-generator/"
    o5(["Open a governance phase<br/><b>petrova-phase-open</b>"])
    Q --> o5
    click o5 "/prompts/petrova-phase-open/"
    o6(["Which recurring phase steps earn automation?<br/><b>eva-automation-triage</b>"])
    Q --> o6
    click o6 "/prompts/eva-automation-triage/"
    o7{{"What stands between a repo and revenue (gates-to-revenue)<br/><small>Gates →</small>"}}
    Q --> o7
    click o7 "#map-B4G"
    o8{{"Find out whether anyone wants it (PLAY-010 discovery round, behind every demand gate)<br/><small>Discovery →</small>"}}
    Q --> o8
    click o8 "#map-B4D"
    s0["→ Execute"]
    o4 -.-> s0
    click s0 "#map-B5"
    s1["→ Execute"]
    o0 -.-> s1
    click s1 "#map-B5"
    s2["→ Execute"]
    o1 -.-> s2
    click s2 "#map-B5"
    s3["→ Execute"]
    o2 -.-> s3
    click s3 "#map-B5"
    o0 -.->|"turn a taskset into an executor-ready prompt"| o2
    s4["→ Execute"]
    o5 -.->|"phase active"| s4
    click s4 "#map-B5"
    s5["→ Execute: eva-automation-install"]
    o6 -.-> s5
    click s5 "/prompts/eva-automation-install/"
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5,o6 leaf;
    class o7,o8 sub;
    class s0,s1,s2,s3,s4,s5 stub;

Plan › Gates

Walk this step in the guide →

flowchart TD
    Q{{"Which layer of the gates pattern?"}}
    o0(["Map one repo's gates into .petrova/gates.yaml<br/><b>gates-map</b>"])
    Q --> o0
    click o0 "/prompts/gates-map/"
    o1(["Sweep every registered repo's gates into one queue<br/><b>gates-sweep</b>"])
    o0 --> o1
    click o1 "/prompts/gates-sweep/"
    o2(["Drive one repo's next movable gate<br/><b>gates-drive</b>"])
    o1 --> o2
    click o2 "/prompts/gates-drive/"
    o3(["Cut one agent-executable change under a gate into a CUPEL ticket<br/><b>gates-cupel-leaf</b>"])
    o2 --> o3
    click o3 "/prompts/gates-cupel-leaf/"
    o4(["Draft a decision record for one uncleared ruling, for the operator to countersign<br/><b>gates-rule</b>"])
    o3 --> o4
    click o4 "/prompts/gates-rule/"
    o5(["Record cleared_by for rulings whose evidence already records a human sign-off<br/><b>gates-scribe</b>"])
    o4 --> o5
    click o5 "/prompts/gates-scribe/"
    o6(["Project one product's human-owned gates into Orbit tasks for staff<br/><b>orbit-gates-seed</b>"])
    o5 --> o6
    click o6 "/prompts/orbit-gates-seed/"
    o7(["Rewrite a product's support runbooks as plain family guides<br/><b>orbit-guide-write</b>"])
    o6 --> o7
    click o7 "/prompts/orbit-guide-write/"
    o8(["Post a product's family guides into its Orbit Docs<br/><b>orbit-docs-sync</b>"])
    o7 --> o8
    click o8 "/prompts/orbit-docs-sync/"
    o9(["Hand an Orbit task to the next agent, or pick one up (CUPEL handoff record, re-derived first)<br/><b>orbit-handoff</b>"])
    o8 --> o9
    click o9 "/prompts/orbit-handoff/"
    o10(["Find where Orbit tasks drifted from their gates<br/><b>orbit-reconcile</b>"])
    o9 --> o10
    click o10 "/prompts/orbit-reconcile/"
    o11(["Audit one project end to end, gates to public exposure, into a ranked drive-now list<br/><b>estate-audit</b>"])
    o10 --> o11
    click o11 "/prompts/estate-audit/"
    o11 -.->|"lens: gates"| o1
    o11 -.->|"lens: tracker"| o10
    s0["→ Execute: live-truth-triage"]
    o11 -.->|"lens: live"| s0
    click s0 "/prompts/live-truth-triage/"
    s1["→ Execute: landing-claims-ledger"]
    o11 -.->|"lens: surface"| s1
    click s1 "/prompts/landing-claims-ledger/"
    s2["→ Execute: content-diagnose"]
    o11 -.->|"lens: content"| s2
    click s2 "/prompts/content-diagnose/"
    s3["→ Execute: public-exposure-audit"]
    o11 -.->|"lens: exposure"| s3
    click s3 "/prompts/public-exposure-audit/"
    s4["→ Execute: opportunity-scan"]
    o11 -.->|"lens: opportunity"| s4
    click s4 "/prompts/opportunity-scan/"
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5,o6,o7,o8,o9,o10,o11 leaf;
    class s0,s1,s2,s3,s4 stub;

Plan › Discovery

Walk this step in the guide →

flowchart TD
    Q{{"Which step of the discovery round?"}}
    o0(["Shortlist up to 30 people from the operator's public Bluesky rings (read-only, never contacts)<br/><b>discovery-shortlist</b>"])
    Q --> o0
    click o0 "/prompts/discovery-shortlist/"
    o1(["Write open interview questions, no pitch<br/><b>discovery-brief</b>"])
    o0 --> o1
    click o1 "/prompts/discovery-brief/"
    o2(["Draft the first message; record the sha256 of the version the operator approves<br/><b>discovery-script</b>"])
    o1 --> o2
    click o2 "/prompts/discovery-script/"
    o3(["Close the round: synthesis from operator notes, one change for next round, gate finding at DEMAND-NOT-MET<br/><b>discovery-synthesis</b>"])
    o2 --> o3
    click o3 "/prompts/discovery-synthesis/"
    o3 -.->|"next round applies the one change"| o0
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3 leaf;

Execute

Walk this step in the guide →

flowchart LR
    Q{{"What are you executing?"}}
    o0(["Multi-step task, one repo<br/><b>orchestrate-multistep</b>"])
    Q --> o0
    click o0 "/prompts/orchestrate-multistep/"
    o1(["Cross-repo DAG<br/><b>repo-dag-executor</b>"])
    Q --> o1
    click o1 "/prompts/repo-dag-executor/"
    o2(["Refactor with hard limits<br/><b>refactor-with-constraints</b>"])
    Q --> o2
    click o2 "/prompts/refactor-with-constraints/"
    o3(["Let the autopilot drive<br/><b>petrova-autopilot</b>"])
    Q --> o3
    click o3 "/prompts/petrova-autopilot/"
    o4(["Propose a fix for a known issue<br/><b>petrova-propose-fix</b>"])
    Q --> o4
    click o4 "/prompts/petrova-propose-fix/"
    o5(["Land one security fix in a submodule: TDD, independent review, fold findings, merge, pin the gitlink<br/><b>security-pr-review-loop</b>"])
    Q --> o5
    click o5 "/prompts/security-pr-review-loop/"
    o6(["Bump nestr's engine or registry gitlink with the refusal-code snapshot in the same commit<br/><b>refusal-code-catalogue-maintenance</b>"])
    Q --> o6
    click o6 "/prompts/refusal-code-catalogue-maintenance/"
    o7{{"Wire a sibling system<br/><small>Wire →</small>"}}
    Q --> o7
    click o7 "#map-B5W"
    o8{{"Author content / harness<br/><small>Author →</small>"}}
    Q --> o8
    click o8 "#map-B5A"
    o9{{"Publish content downstream<br/><small>Publish →</small>"}}
    Q --> o9
    click o9 "#map-B5C"
    o10{{"Make an org's landing page say exactly what the product does, at the quality its price implies<br/><small>Landing truth →</small>"}}
    Q --> o10
    click o10 "#map-B5L"
    o11{{"Fleet infrastructure op<br/><small>Fleet op →</small>"}}
    Q --> o11
    click o11 "#map-B5F"
    o12(["Retire a host, domain or deck (consumers first, DNS last)<br/><b>surface-retire</b>"])
    Q --> o12
    click o12 "/prompts/surface-retire/"
    o13(["Consolidate one repo's local clones, worktrees, branches and stashes into one checkout<br/><b>local-checkout-consolidate</b>"])
    Q --> o13
    click o13 "/prompts/local-checkout-consolidate/"
    s0["→ Decide: deck-act-go"]
    o12 -.->|"every host write inside the teardown needs its own GO"| s0
    click s0 "/prompts/deck-act-go/"
    o5 -.->|"engine/registry gitlink bump"| o6
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5,o6,o12,o13 leaf;
    class o7,o8,o9,o10,o11 sub;
    class s0 stub;

Execute › Wire

Walk this step in the guide →

flowchart LR
    Q{{"Which system?"}}
    o0(["ares<br/><b>petrova-wire-ares</b>"])
    Q --> o0
    click o0 "/prompts/petrova-wire-ares/"
    o1(["crumb<br/><b>petrova-wire-crumb</b>"])
    Q --> o1
    click o1 "/prompts/petrova-wire-crumb/"
    o2(["eva<br/><b>petrova-wire-eva</b>"])
    Q --> o2
    click o2 "/prompts/petrova-wire-eva/"
    o3(["rocky<br/><b>petrova-wire-rocky</b>"])
    Q --> o3
    click o3 "/prompts/petrova-wire-rocky/"
    o4(["traceo<br/><b>petrova-wire-traceo</b>"])
    Q --> o4
    click o4 "/prompts/petrova-wire-traceo/"
    o5(["Generic integration<br/><b>petrova-wire-integration</b>"])
    Q --> o5
    click o5 "/prompts/petrova-wire-integration/"
    o6(["An HTTP API as MCP tools<br/><b>mcp-provider-wire</b>"])
    Q --> o6
    click o6 "/prompts/mcp-provider-wire/"
    o7(["An app's checkout and paid access onto the TOLL gate<br/><b>toll-consumer-wire</b>"])
    Q --> o7
    click o7 "/prompts/toll-consumer-wire/"
    o8(["Register an app as a TOLL consumer (gate side: capabilities, spec, tests)<br/><b>toll-consumer-onboard</b>"])
    Q --> o8
    click o8 "/prompts/toll-consumer-onboard/"
    o9(["Several apps onto TOLL in one gated pass<br/><b>toll-consumer-wave</b>"])
    Q --> o9
    click o9 "/prompts/toll-consumer-wave/"
    o10(["Join a content tool's taxonomy (Notion…) to a repo's, by verified key<br/><b>devaqua-taxonomy-bridge</b>"])
    Q --> o10
    click o10 "/prompts/devaqua-taxonomy-bridge/"
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5,o6,o7,o8,o9,o10 leaf;

Execute › Author

Walk this step in the guide →

flowchart LR
    Q{{"What kind of content?"}}
    o0(["Audit a product UI before redesigning it: controls to real work, numbers to window and n (read-only)<br/><b>product-surface-truth-audit</b>"])
    Q --> o0
    click o0 "/prompts/product-surface-truth-audit/"
    o1(["Impeccable handbook (full)<br/><b>impeccable-handbook-generator</b>"])
    Q --> o1
    click o1 "/prompts/impeccable-handbook-generator/"
    o2(["Run an impeccable harness<br/><b>impeccable-harness-executor</b>"])
    Q --> o2
    click o2 "/prompts/impeccable-harness-executor/"
    o3(["One handbook section<br/><b>handbook-section-generator</b>"])
    Q --> o3
    click o3 "/prompts/handbook-section-generator/"
    o4(["Brand asset<br/><b>brand-asset-generator</b>"])
    Q --> o4
    click o4 "/prompts/brand-asset-generator/"
    o5(["Email-flow verification harness<br/><b>verify-email-flow-harness</b>"])
    Q --> o5
    click o5 "/prompts/verify-email-flow-harness/"
    o6(["Crumb extraction (raw)<br/><b>crumb-extraction-harness</b>"])
    Q --> o6
    click o6 "/prompts/crumb-extraction-harness/"
    o7(["Crumb → flashcards<br/><b>crumb-flashcard-extractor</b>"])
    Q --> o7
    click o7 "/prompts/crumb-flashcard-extractor/"
    o8(["RAG: rewrite query<br/><b>rag-query-rewriter</b>"])
    Q --> o8
    click o8 "/prompts/rag-query-rewriter/"
    o9(["RAG: rerank chunks<br/><b>rag-chunk-reranker</b>"])
    Q --> o9
    click o9 "/prompts/rag-chunk-reranker/"
    o10(["RAG: synthesize context<br/><b>rag-context-synthesizer</b>"])
    Q --> o10
    click o10 "/prompts/rag-context-synthesizer/"
    o11(["RAG: validate evidence<br/><b>rag-evidence-validator</b>"])
    Q --> o11
    click o11 "/prompts/rag-evidence-validator/"
    o12(["Call fleet MCP tools via PEBBLE gateway<br/><b>pebble-tools</b>"])
    Q --> o12
    click o12 "/prompts/pebble-tools/"
    o0 -.->|"redesign inputs (nestr web, 2026-10-30)"| o1
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5,o6,o7,o8,o9,o10,o11,o12 leaf;

Execute › Publish

Walk this step in the guide →

flowchart TD
    Q{{"What stage of the content pipeline?"}}
    o0(["Declare the org's content arc/manifest<br/><b>content-arc-declare</b>"])
    Q --> o0
    click o0 "/prompts/content-arc-declare/"
    o1(["Gate A: intake a closed decision into abacus<br/><b>content-decision-intake</b>"])
    o0 --> o1
    click o1 "/prompts/content-decision-intake/"
    o2(["Draft a downlink blog entry<br/><b>downlink-entry-author</b>"])
    o1 --> o2
    click o2 "/prompts/downlink-entry-author/"
    o3(["Project abacus → landing, or check drift<br/><b>downlink-publish</b>"])
    o2 --> o3
    click o3 "/prompts/downlink-publish/"
    o4(["Repurpose a shipped entry into a social artefact<br/><b>downlink-social-repurposer</b>"])
    o3 --> o4
    click o4 "/prompts/downlink-social-repurposer/"
    o5(["Gate D: dispatch the social artefact — the only prompt that actually posts<br/><b>content-social-dispatch</b>"])
    o4 --> o5
    click o5 "/prompts/content-social-dispatch/"
    o6(["Diagnose what each enrolled app has shipped, and which content classes are open (PLAY-022 sweep, step 1)<br/><b>content-diagnose</b>"])
    click o6 "/prompts/content-diagnose/"
    o7(["Suggest ranked content cards from a diagnosis (PLAY-022 sweep, step 2; suggestions only)<br/><b>content-suggest</b>"])
    click o7 "/prompts/content-suggest/"
    o8(["Measure how visible a project is under the operator's name, and where it is missing (read-only)<br/><b>public-exposure-audit</b>"])
    click o8 "/prompts/public-exposure-audit/"
    o9(["List openings a project has earned and nobody has opened: write-ups, libraries, listings, talks (read-only)<br/><b>opportunity-scan</b>"])
    click o9 "/prompts/opportunity-scan/"
    o10(["Show a sweep's cards as tasks in the private Orbit project CONT, status derived from abacus (PLAY-022 pilot)<br/><b>content-cont-sync</b>"])
    click o10 "/prompts/content-cont-sync/"
    o11(["Generalize publish to any org's own surface<br/><b>content-publish-sink</b>"])
    click o11 "/prompts/content-publish-sink/"
    o12(["Add, change or load a shared vocabulary term (platform, position, system, stage…)<br/><b>abacus-vocabulary</b>"])
    click o12 "/prompts/abacus-vocabulary/"
    o13(["Keep a static public projection in step with its ledger (pin, stale PR, operator deploy)<br/><b>public-projection-sync</b>"])
    click o13 "/prompts/public-projection-sync/"
    o14(["Strip AI-writing tells from a draft before it ships (humanize-lint, rewrite, fact diff)<br/><b>prose-humanize</b>"])
    click o14 "/prompts/prose-humanize/"
    o11 -.->|"generalizes"| o3
    o2 -.->|"before it projects"| o14
    s0["→ Verify: verify-for-real"]
    o13 -.->|"served == gated"| s0
    click s0 "/prompts/verify-for-real/"
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5,o6,o7,o8,o9,o10,o11,o12,o13,o14 leaf;
    class s0 stub;

Execute › Landing truth

Walk this step in the guide →

flowchart TD
    Q{{"Which pass of the landing-truth method?"}}
    o0(["Drive one org's landing through the whole method (gates at conflicts, rulings, merge)<br/><b>landing-truth-flow</b>"])
    Q --> o0
    click o0 "/prompts/landing-truth-flow/"
    o1(["Find the landing source and every document that binds it (read-only)<br/><b>landing-context-map</b>"])
    o0 --> o1
    click o1 "/prompts/landing-context-map/"
    o2(["Trace every claim on the site to code a customer can use today (read-only)<br/><b>landing-claims-ledger</b>"])
    o1 --> o2
    click o2 "/prompts/landing-claims-ledger/"
    o3(["Measure the signup funnel, phone reach, share card and crawlers (read-only)<br/><b>landing-funnel-integrity-audit</b>"])
    o2 --> o3
    click o3 "/prompts/landing-funnel-integrity-audit/"
    o4(["Who buys, what proof they need, which true features carry it, at this price (read-only)<br/><b>landing-value-fit-audit</b>"])
    o3 --> o4
    click o4 "/prompts/landing-value-fit-audit/"
    o5(["Land the ruled fixes as draft PRs, red-first, one per concern<br/><b>landing-truth-sweep</b>"])
    o4 --> o5
    click o5 "/prompts/landing-truth-sweep/"
    o0 -.->|"step 1"| o1
    o0 -.->|"step 2"| o2
    o0 -.->|"step 3"| o3
    o0 -.->|"step 4"| o4
    o0 -.->|"step 6"| o5
    s0["→ Execute: prose-humanize"]
    o5 -.->|"new copy before it lands"| s0
    click s0 "/prompts/prose-humanize/"
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5 leaf;
    class s0 stub;

Execute › Fleet op

Walk this step in the guide →

flowchart LR
    Q{{"What kind of fleet op?"}}
    o0(["Bring up a new fleet host from bare machine or VM<br/><b>fleet-host-bringup</b>"])
    Q --> o0
    click o0 "/prompts/fleet-host-bringup/"
    o1(["Roll out install.sh across tenant roots<br/><b>fleet-host-rollout</b>"])
    Q --> o1
    click o1 "/prompts/fleet-host-rollout/"
    o2(["Retire the eu-1 fleet host with no successor, lane by lane (fleet of subagents)<br/><b>hermes-retire-fleet</b>"])
    Q --> o2
    click o2 "/prompts/hermes-retire-fleet/"
    o3(["Triage an ingest ticket on a shared fleet host<br/><b>fleet-ingest-triage</b>"])
    Q --> o3
    click o3 "/prompts/fleet-ingest-triage/"
    o4(["Triage podman `exceeded num_locks` or testcontainers readiness on a tenant (read-only)<br/><b>fleet-podman-lock-triage</b>"])
    Q --> o4
    click o4 "/prompts/fleet-podman-lock-triage/"
    o5(["Audit what Hetzner bills against the documented baseline (read-only)<br/><b>hetzner-cost-audit</b>"])
    Q --> o5
    click o5 "/prompts/hetzner-cost-audit/"
    o6(["Audit what Railway bills per service, or check whether another PaaS would be cheaper (read-only)<br/><b>railway-cost-census</b>"])
    Q --> o6
    click o6 "/prompts/railway-cost-census/"
    o7(["Which apps earn more than they cost, and which to retire (read-only)<br/><b>unit-economics-review</b>"])
    Q --> o7
    click o7 "/prompts/unit-economics-review/"
    o8(["Is a founding discount about to hit its cap or close its window, so a consumer must stop requesting it (read-only)<br/><b>founding-discount-watch</b>"])
    Q --> o8
    click o8 "/prompts/founding-discount-watch/"
    o9(["Is every surface running what its main says, and can the live gate take money (read-only)<br/><b>live-truth-triage</b>"])
    Q --> o9
    click o9 "/prompts/live-truth-triage/"
    o10(["Wire approved automations (Routine now, EVA cycle later)<br/><b>eva-automation-install</b>"])
    Q --> o10
    click o10 "/prompts/eva-automation-install/"
    o11(["Move packages, module paths and CI references after a GitHub org rename<br/><b>github-org-rename-migration</b>"])
    Q --> o11
    click o11 "/prompts/github-org-rename-migration/"
    o12(["Admit a CI workflow to a service by GitHub OIDC, no stored token<br/><b>gha-oidc-machine-identity</b>"])
    Q --> o12
    click o12 "/prompts/gha-oidc-machine-identity/"
    o13(["Sign an app on another apex in through airlock's cross-apex handoff (Pattern B)<br/><b>airlock-pattern-b-consumer</b>"])
    Q --> o13
    click o13 "/prompts/airlock-pattern-b-consumer/"
    o14(["Land one mechanical workflow edit across many repos and orgs<br/><b>gha-estate-batch-edit</b>"])
    Q --> o14
    click o14 "/prompts/gha-estate-batch-edit/"
    o15(["Move one org's gate CI from push/PR to a nightly batch (CI-FREE phase 4)<br/><b>ci-free-nightly-flip</b>"])
    Q --> o15
    click o15 "/prompts/ci-free-nightly-flip/"
    o16(["Plan and get signed off a push-to-nightly CI flip for an org whose gates protect security code<br/><b>gha-governed-org-nightly-flip</b>"])
    Q --> o16
    click o16 "/prompts/gha-governed-org-nightly-flip/"
    o17(["Give an org its own heavy-test lab on the Mac's external drive (CI-FREE Mac offload)<br/><b>mac-lab-bringup</b>"])
    Q --> o17
    click o17 "/prompts/mac-lab-bringup/"
    o18(["Hand refused or operator-only production steps to the operator as one rehearsed wizard<br/><b>operator-wizard-handoff</b>"])
    Q --> o18
    click o18 "/prompts/operator-wizard-handoff/"
    o19(["Provision a Traceo workspace + baseline so a consumer's traceo probe reads ok<br/><b>traceo-workspace-baseline-provision</b>"])
    Q --> o19
    click o19 "/prompts/traceo-workspace-baseline-provision/"
    o20(["Fill a product's demo@ account with realistic data, end to end (identity, seeder, env, plan, verify)<br/><b>demo-tenant-provision</b>"])
    Q --> o20
    click o20 "/prompts/demo-tenant-provision/"
    o21(["Get a demo@ login into airlock and read back its user id for the product env<br/><b>demo-identity-bootstrap</b>"])
    Q --> o21
    click o21 "/prompts/demo-identity-bootstrap/"
    o22(["Write or extend a deterministic, guarded, resettable demo seeder<br/><b>demo-seed-author</b>"])
    Q --> o22
    click o22 "/prompts/demo-seed-author/"
    o20 -.->|"step 2"| o21
    s0["→ Orient: demo-coverage-audit"]
    o20 -.->|"step 3"| s0
    click s0 "/prompts/demo-coverage-audit/"
    o20 -.->|"step 4"| o22
    s1["→ Verify: demo-verify"]
    o20 -.->|"step 7"| s1
    click s1 "/prompts/demo-verify/"
    o20 -.->|"operator gates as one wizard"| o18
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5,o6,o7,o8,o9,o10,o11,o12,o13,o14,o15,o16,o17,o18,o19,o20,o21,o22 leaf;
    class s0,s1 stub;

Stuck

Walk this step in the guide →

flowchart LR
    Q{{"What kind of stuck?"}}
    o0(["A run failed<br/><b>petrova-failure-triage</b>"])
    Q --> o0
    click o0 "/prompts/petrova-failure-triage/"
    o1(["Work is sitting idle<br/><b>petrova-stalled-work</b>"])
    Q --> o1
    click o1 "/prompts/petrova-stalled-work/"
    o2(["Feels harder than it should<br/><b>petrova-friction-classify</b>"])
    Q --> o2
    click o2 "/prompts/petrova-friction-classify/"
    o3(["Capture a one-off observation<br/><b>petrova-finding</b>"])
    Q --> o3
    click o3 "/prompts/petrova-finding/"
    o4(["Suspect drift between repos<br/><b>petrova-drift-check</b>"])
    Q --> o4
    click o4 "/prompts/petrova-drift-check/"
    o5(["Suspect a boundary violation<br/><b>petrova-boundary-audit</b>"])
    Q --> o5
    click o5 "/prompts/petrova-boundary-audit/"
    o6(["Old decision still binding?<br/><b>petrova-supersession-check</b>"])
    Q --> o6
    click o6 "/prompts/petrova-supersession-check/"
    o7(["Upstream dep changed?<br/><b>petrova-upstream-watch</b>"])
    Q --> o7
    click o7 "/prompts/petrova-upstream-watch/"
    o8(["Wire a contract-drift detector<br/><b>petrova-wire-contract-drift</b>"])
    Q --> o8
    click o8 "/prompts/petrova-wire-contract-drift/"
    o9(["Soak an invariant under load<br/><b>petrova-invariant-soak</b>"])
    Q --> o9
    click o9 "/prompts/petrova-invariant-soak/"
    o10(["Suspect a dev-mode auth fail-open<br/><b>auth-fail-open-audit</b>"])
    Q --> o10
    click o10 "/prompts/auth-fail-open-audit/"
    o11(["A transactional email was refused or never arrived<br/><b>smtp-sender-triage</b>"])
    Q --> o11
    click o11 "/prompts/smtp-sender-triage/"
    o12(["A workflow fails at Set up job / a `uses:` ref won't resolve<br/><b>action-ref-reachability</b>"])
    Q --> o12
    click o12 "/prompts/action-ref-reachability/"
    o13(["Railway app gets `connection reset by peer` from *.proxy.rlwy.net (database service not running?)<br/><b>railway-dead-service-diagnosis</b>"])
    Q --> o13
    click o13 "/prompts/railway-dead-service-diagnosis/"
    o14(["Non-root container gets permission denied on a root-owned volume<br/><b>nonroot-container-volume-permissions</b>"])
    Q --> o14
    click o14 "/prompts/nonroot-container-volume-permissions/"
    s0["→ Execute: petrova-wire-eva"]
    o12 -.->|"cross-org consumers vendor, never uses: a private ref"| s0
    click s0 "/prompts/petrova-wire-eva/"
    s1["→ Execute: petrova-propose-fix"]
    o0 -.->|"propose a fix"| s1
    click s1 "/prompts/petrova-propose-fix/"
    s2["→ Execute: security-pr-review-loop"]
    o14 -.-> s2
    click s2 "/prompts/security-pr-review-loop/"
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5,o6,o7,o8,o9,o10,o11,o12,o13,o14 leaf;
    class s0,s1,s2 stub;

Verify

Walk this step in the guide →

flowchart LR
    Q{{"What are you verifying?"}}
    o0(["A single task's AC<br/><b>task-acceptance-check</b>"])
    Q --> o0
    click o0 "/prompts/task-acceptance-check/"
    o1(["A full verification round<br/><b>petrova-verify-round</b>"])
    Q --> o1
    click o1 "/prompts/petrova-verify-round/"
    o2(["A merge request is green<br/><b>petrova-mr-check</b>"])
    Q --> o2
    click o2 "/prompts/petrova-mr-check/"
    o3(["Need human review<br/><b>petrova-request-review</b>"])
    Q --> o3
    click o3 "/prompts/petrova-request-review/"
    o4(["Auto-merge when CI passes<br/><b>petrova-request-merge-when-green</b>"])
    Q --> o4
    click o4 "/prompts/petrova-request-merge-when-green/"
    o5(["Is this green signal even real?<br/><b>verify-for-real</b>"])
    Q --> o5
    click o5 "/prompts/verify-for-real/"
    o6(["Run a heavy suite on the org's Mac lab and diff it against a baseline<br/><b>mac-lab-offload</b>"])
    Q --> o6
    click o6 "/prompts/mac-lab-offload/"
    o7(["Re-derive QA 'pass' verdicts from scratch (fresh session)<br/><b>qa-adversary</b>"])
    Q --> o7
    click o7 "/prompts/qa-adversary/"
    o8(["Prove a liveness check can fail on its own (dead-man, both arms)<br/><b>dead-man-heartbeat</b>"])
    Q --> o8
    click o8 "/prompts/dead-man-heartbeat/"
    o9(["Is the demo account ready for a call? (sign in as demo@, check every page)<br/><b>demo-verify</b>"])
    Q --> o9
    click o9 "/prompts/demo-verify/"
    o10(["Does a consumer's money path hold on sandbox Polar? (full matrix, before live)<br/><b>toll-sandbox-matrix</b>"])
    Q --> o10
    click o10 "/prompts/toll-sandbox-matrix/"
    o11(["Write up after-the-fact<br/><b>petrova-post-mortem</b>"])
    Q --> o11
    click o11 "/prompts/petrova-post-mortem/"
    o12(["Close the governance phase<br/><b>petrova-phase-close</b>"])
    Q --> o12
    click o12 "/prompts/petrova-phase-close/"
    o8 -.-> o5
    s0["→ Decide: petrova-decision-doc"]
    o11 -.->|"often spawns"| s0
    click s0 "/prompts/petrova-decision-doc/"
    s1["→ Orient"]
    o12 -.->|"new cycle"| s1
    click s1 "#map-B2"
    classDef q fill:#2a2410,stroke:#f0b400,color:#e6e6e6;
    classDef leaf fill:#10231a,stroke:#7fdd7f,color:#e6e6e6;
    classDef sub fill:#1c2125,stroke:#f0b400,color:#e6e6e6,stroke-dasharray:4 3;
    classDef stub fill:#14181a,stroke:#5a6068,color:#8a9099;
    class Q q;
    class o0,o1,o2,o3,o4,o5,o6,o7,o8,o9,o10,o11,o12 leaf;
    class s0,s1 stub;

162 of 165 prompt dirs placed · not placed: devaqua-coach-read-actor (empty dir — decision doc lives in devaqua-taxonomy-bridge/), devaqua-taxonomy-coverage (empty dir — decision doc lives in devaqua-taxonomy-bridge/), launch-to-revenue (mission prompt + per-org parameters, not yet catalogued (no meta.yml); see docs/findings/20261021-1923-l2r-bound-to-plays.md) · source: docs/eva-decision-tree.yml ↗