Use for independent review of Rudder implementations, UI workflows, proposals, agent work, or final handoffs. Judges first-principles intent, raw-request and correction adherence, functional trust, adversarial risk, product taste, and evidence integrity; requires traceable acceptance-packet alignment and comparative…
Use when analyzing one Rudder agent run or recent run batches: run IDs, partial IDs, transcripts, run logs, execution traces, runtime failures, finalizer failures, stdout/stderr, run quality, or recent org run behavior.
Use for Rudder's root-level delivery lifecycle when work spans implementation, review, black-box acceptance, integration, or handoff and candidate/source/runtime/data identity can drift. It captures raw intent and corrections, freezes an acceptance packet, coordinates reviewer/verifier/final-review receipts, records…
Use when creating realistic Rudder mock, demo, seed, fixture, screenshot, test, CSV, JSON, SQL, TypeScript, or scenario data for local development, demos, screenshots, product explanations, and workflow validation.
Use after implementation when Rudder needs independent black-box acceptance of the exact final candidate on a real UI, Desktop, CLI, runtime, integration, or release surface. Locks candidate and environment identity, maps criteria to terminal evidence, and returns exactly PASS, FAIL, or QUESTION without reviewing…
Use when inspecting, preparing, executing, recovering, or verifying Rudder releases across npm, GitHub Releases, Desktop assets, tags, dist-tags, changelogs, install smoke, stable/canary promotion, rollback, and release workflow failures. Use for both hands-on publish requests and read-only release readiness…
Use when Rudder Desktop or its development shell will not launch, gets stuck at login/account gate, has pending device approval or local-session exchange, returns 401 during update, points at the wrong instance, hits migration-journal/schema-history divergence, needs a backup or rollback decision, fails during…
Use for repeatable Rudder performance audits, regressions, profiling, optimization proposals, or implementation verification across Messenger, Chat, Issues, Runs, Desktop, API payloads, database queries, rendering, memory, and high-volume workflows. Trigger for daily performance checks, product latency or memory…
Use when verifying Rudder agent runtime behavior in a real local environment, especially MCP/native Rudder tools across Codex, Claude, OpenCode, Pi, or user-named runtimes. Trigger for requests like 真是/真实环境跑过吗, 排查所有 rudder tools, transcript/fallback verification, runtime MCP availability, provider matrix proof, or…
Use to audit or clean Rudder worktrees, generated artifacts, logs, caches, and repo-owned processes without deleting active work, user data, or unrelated machine state. Returns AUDIT, CLEANED, or BLOCKED.
Use when the user explicitly asks to stop, restart, kill, or clean Rudder repo-local pnpm dev processes or local dev runtime residue, including “把 pnpm dev 停了”, “重启 dev”, or “清掉 dev 残留”.
Instructions for Undertone0809/rudder, a project described as: Open-source local Agent harness for self-improving agent teams: run agents, review work, and turn feedback into reusable skills.
Expert advisor for when a build, UI, workflow, spec, or implementation feels wrong but the user cannot yet express the right product, design, engineering, or evaluation critique. Use before more implementation to turn vague dissatisfaction, weak AI-built results, traces, benchmarks, or eval evidence into a grounded…
Use when reviewing a local Codex session, task, thread, or commit as a product manager or first-principles reviewer for product correctness, scope, behavior, validation, and whether the task solved the right user problem.
Use when a Rudder development request has an unclear lifecycle stage or owner: requirements, advisor analysis, UI design, implementation, verification, review, release, recovery, runtime contracts, performance, component lab, handoff, or named-skill optimization.
Use this prompt for a spawned final reviewer after verifier PASS. This reviewer checks whether the implementation, contracts, tests, product proof, and handoff are trustworthy.
Use this prompt for a spawned final reviewer after verifier PASS. This reviewer asks whether the stage solved the right problem in the smallest durable way.
Use this prompt for a spawned verifier child after writer implementation and writer checks. The verifier answers whether the product path works from the actor's side. It does not review architecture and it does not fix failures.
Use when maintaining Rudder landing-page/demo screenshot workflows: seeding screenshot-ready demo orgs, capturing polished full-page app screenshots, producing screenshot manifests, or handing a seeded environment to the user for self-capture.
Use when checking out, running, previewing, reviewing, or validating a GitHub pull request locally in a safe worktree, including PR preview URLs, local screenshots, readiness checks, logs, and cleanup instructions.
Use when Rudder pages or product surfaces show missing, stale, sparse, empty, slow, or wrong data, including Calendar, runs, issues, dashboard counts, chat output, prod/local org data, API/UI/DB mismatches, or “这个数据从哪来”.