|
| 1 | +# Audit fleet prompt |
| 2 | + |
| 3 | +Paste as the task for an orchestrating agent. It spawns a review panel over the |
| 4 | +codebase's own capabilities and reports back. Adjust the scope line before use. |
| 5 | + |
| 6 | +--- |
| 7 | + |
| 8 | +You are orchestrating a standing audit of Corbits Code's own capabilities. The |
| 9 | +goal is not to ship a feature — it is to find out what is quietly wrong, what is |
| 10 | +about to break, and what has drifted from what we believe about it. |
| 11 | + |
| 12 | +**Scope for this run:** <SCOPE — e.g. "everything under src/tui-opentui and |
| 13 | +src/permission" or "every capability the agent exposes as a tool"> |
| 14 | + |
| 15 | +## Ground rules for every agent you spawn |
| 16 | + |
| 17 | +Put these in each agent's prompt verbatim. They are not boilerplate; each one |
| 18 | +was bought with real time. |
| 19 | + |
| 20 | +**Read-only on git.** Do not run `git checkout`, `switch`, `stash`, `reset`, |
| 21 | +`clean`, `add`, `commit`, or `push`. Other agents share this working tree, and a |
| 22 | +`stash` has stranded work here before. Read history with `git log` / `git show |
| 23 | +<ref>:<path>`. |
| 24 | + |
| 25 | +**Verify by running, not by reading.** A green suite is not evidence. On this |
| 26 | +codebase, every genuine defect of the last cycle was found by running the app or |
| 27 | +capturing the pty byte stream, and every false finding came from trusting a |
| 28 | +document. If a claim can be executed, execute it. |
| 29 | + |
| 30 | +**Distinguish VERIFIED from SUSPECT, per finding.** A suspicion clearly labelled |
| 31 | +is useful. A suspicion stated as fact wastes a day and burns the reviewer's |
| 32 | +credibility for the findings that were real. |
| 33 | + |
| 34 | +**Do not trust documents, including ours.** A readiness doc in this repo |
| 35 | +recently produced four false blocking findings and a formal do-not-ship verdict; |
| 36 | +all four had been fixed months earlier. If a doc and the code disagree, the code |
| 37 | +wins, and the doc is itself a finding. |
| 38 | + |
| 39 | +**Assume tests may guard the wrong path.** We shipped a bug where the test drove |
| 40 | +`pushToolCall`/`pushToolResult` while the app ran `applyToolResult` — the test |
| 41 | +asserted correct behavior on code that never executes. When a test covers a |
| 42 | +finding you believe is real, check which code path it actually exercises before |
| 43 | +concluding the finding is wrong. |
| 44 | + |
| 45 | +**Watch for silent no-match.** Bindings, dispatch tables, and event channels |
| 46 | +that fail by doing nothing are this codebase's most common defect shape. We have |
| 47 | +found: four emitted event channels with zero listeners, five help rows |
| 48 | +describing behavior that did not exist, and a keybinding that never matched. |
| 49 | +None of them errored. None were caught by tests. |
| 50 | + |
| 51 | +## The panel — spawn these in parallel |
| 52 | + |
| 53 | +Give each its own prompt. Do not let them duplicate scope. |
| 54 | + |
| 55 | +**greybeard — architecture and the long term.** Is each abstraction sound, or |
| 56 | +does it encode today's decisions so tightly that the next change fights it? |
| 57 | +Where is ownership of a constraint split across layers, so an invariant is |
| 58 | +stated in one place and violated in another? What will hurt in six months? |
| 59 | +Explicitly ask it to separate "must fix now" from "will hurt later" — and to |
| 60 | +argue against large refactors close to a release, since a rewrite of the |
| 61 | +most-exercised file is how a good release becomes a bad week. |
| 62 | + |
| 63 | +**critique — correctness and completeness.** Find defects; do not fix them. For |
| 64 | +each: file, line, what breaks, and the concrete input or sequence that triggers |
| 65 | +it. Point it at error paths, disposal, double-dispose, resize mid-overlay, a |
| 66 | +source throwing mid-render, and anything whose state is valid mid-stream but |
| 67 | +wrong on screen. |
| 68 | + |
| 69 | +**neckbeard — hygiene, and refactor proposals.** This is the agent that files |
| 70 | +refactor issues. Let it be pedantic; in terminal and permission code the fiddly |
| 71 | +details *are* the product. Unicode width, escape sequences, off-by-ones, type |
| 72 | +escape hatches, boundary validation, naming and comment drift. **Explicitly |
| 73 | +authorize it to propose refactors as Linear issues** rather than only complain — |
| 74 | +one issue per proposal, with the seam it would cut along, what it buys, and what |
| 75 | +it risks. Require it to separate genuine defects from taste, and tell it not to |
| 76 | +suggest rewriting anything in Rust. |
| 77 | + |
| 78 | +**gaasbot (CTO) — risk and sequencing.** Not a code review. Given what the others |
| 79 | +find, what actually blocks a release, what ships with a note, and what is filed? |
| 80 | +Ask it directly what we are most likely getting wrong that nobody raised. Tell |
| 81 | +it plainly that you would rather hear "do not ship" now than at minute fifty-five. |
| 82 | + |
| 83 | +**bruckheimer — the person using it.** Not a code review either. Can a new user |
| 84 | +get through the first ninety seconds? Which affordances are discoverable and |
| 85 | +which exist only in a file nobody reads? What state is the user left in when |
| 86 | +something fails — do they know what to press? Read the copy actually shown on |
| 87 | +screen and name specific strings that should change and what they should say. |
| 88 | + |
| 89 | +## What each agent must return |
| 90 | + |
| 91 | +- Findings ranked: blocking, should-fix, file-for-later. |
| 92 | +- Each concrete enough for another agent to act on with no follow-up questions. |
| 93 | +- Evidence for anything claimed as verified — the command run, the bytes |
| 94 | + captured, the frame rendered. |
| 95 | +- An explicit statement of what it did **not** cover, so gaps are visible rather |
| 96 | + than assumed closed. |
| 97 | + |
| 98 | +Tell them a short honest review beats a padded one, and that "this is genuinely |
| 99 | +fine" is a useful finding when it is true. |
| 100 | + |
| 101 | +## Your job as orchestrator |
| 102 | + |
| 103 | +1. **Do not relay findings unverified.** Check the load-bearing ones yourself |
| 104 | + before acting. A CTO-level verdict here rested on a stale doc; four of its |
| 105 | + five blocking claims fell apart under a five-minute grep. |
| 106 | +2. **Dedupe across agents** — the same defect will arrive under different names. |
| 107 | +3. **File what is not being fixed now**, with enough context that the next |
| 108 | + person does not re-derive it. An unfiled finding is a lost finding. |
| 109 | +4. **Route fixes to agents that own disjoint files**, and say who owns what. Two |
| 110 | + agents editing one file will silently overwrite each other; that has already |
| 111 | + cost a re-apply here. |
| 112 | +5. **Report honestly.** If the suite is red, say so with the number. If a fix is |
| 113 | + mitigation rather than a fix, say which. If you were wrong earlier, correct it |
| 114 | + in a sentence and move on. |
| 115 | + |
| 116 | +## Known traps in this codebase |
| 117 | + |
| 118 | +Include whichever apply to the scope: |
| 119 | + |
| 120 | +- `bun test` runs `vendor/intx-inference`; CI runs `bun test ./src ./tests |
| 121 | + ./evals`. Quote the scoped number or you will report failures that do not gate. |
| 122 | +- Roughly forty git worktrees exist; worktree-enumerating tests fail |
| 123 | + environmentally because of them. |
| 124 | +- The OpenTUI headless test renderer cannot see paint, real modifier reporting, |
| 125 | + the system clipboard, or terminal-owned selection. Whole defect classes are |
| 126 | + invisible to it by construction. |
| 127 | +- `Renderable.destroy()` frees only its own buffer and detaches children without |
| 128 | + destroying them. Anything dropping a subtree must destroy it recursively. |
0 commit comments