Muse for Engineers: Code Review, Repo Hygiene, and the Nightly Audit
Give Muse read access to your repos and a nightly slot: dead-code sweeps, failing-check flags, and PR summaries with line citations. Humans stay on the merge
By Professor Muse7 min read
Engineers do not need Muse to write more code. Most repos already have too much code. What engineers need is someone to do the janitorial work around it: the pull request that has sat unreviewed for six days because reading it takes an hour nobody has, the CI check that has been red since Thursday and nobody owns, the dead module that three people are afraid to delete because nobody is sure it is dead.
I run Muse against my repos as a caretaker. Every night it reads the state of the codebase and produces a short brief I read before standup: what broke, what is stale, what looks dead. It never merges, never pushes, never deletes. It finds the rot. I hold the delete key. That division of labor is the entire lesson.
The Setup: The Night Watch
It is a scheduled routine that runs every night at 2am against one repo: the one you actively work in. It reads the repo through the GitHub connector, which is now in Muse’s connector directory, and produces a morning brief with three sections.
Section one: what broke. Which checks are failing on the default branch and on open PRs. Not just the names: the failing test or step, the file and line if it can find them, and the tail of the error log. A red check that says “build failed” is a chore. A red check that says “integration test checkout_total failed in payments/orders.py:212, Stripe mock returned a 402” is a ten-minute fix.
Section two: what is stale. Open PRs older than three days with no activity, each with a one-line summary of what the PR does and what it is waiting on. Stale PRs die from ambiguity, so the brief names the blocker: waiting on review, waiting on CI, waiting on the author.
Section three: dead-code candidates. Functions, files, and modules that appear unreferenced: nothing imports them, no route points at them, no test exercises them. Candidates, not verdicts. The Night Watch proposes; you delete.
The specialist pattern is what makes this safe. The Night Watch is a read-only specialist: its entire job description is “report, never touch.” Writing code, pushing branches, and merging are separate jobs for separate sessions, gated by approval lines. Scheduled work should never have write access to a repo. That rule is load-bearing. An overnight job with a delete key is a liability.
The short version
- Point a nightly scheduled routine at one repo. Its output is a morning brief: broken checks, stale PRs, dead-code candidates.
- PR summaries work when every claim carries a proof: file and line from the actual diff, or it does not go in the review.
- Dead-code sweeps detect; they do not delete. Dynamic imports, generated code, and feature flags will fool any agent.
- The approval line is absolute: Muse never merges. Merges are the one button that stays human.
PR Summaries: Reviews With Receipts
Code review is the highest-leverage place Muse earns its keep, and the place where sloppy use does the most damage. A review that says “looks good to me” from an agent is worse than no review, because it wears the costume of diligence.
The practitioner version starts with the brief. When a PR needs review, point Muse at it and ask for four things: what the PR changes and why (from the PR description and the commits), the files with the most churn, the risk areas (anything touching auth, payments, migrations, or concurrency), and whether tests cover the change. The non-negotiable part is the proof requirement, straight from the task-brief rules: every claim cites the file and line it came from. “This changes the checkout flow” is worthless without the diff lines that show it. If a claim cannot trace to a line in the diff, it does not go in the summary.
The second rule is about scope. Muse summarizes and flags; it does not approve. An agent’s “LGTM” carries no accountability, and accountability is the entire point of review. The summary lands in front of you, you read the diff it cites, and you are the one who presses approve. The agent did the reading. The judgment is still yours.
| Engineering chore | Before Muse | With the Night Watch |
|---|---|---|
| Unreviewed PRs | Read the whole diff cold, or skip it | Summary with cited risk areas; you read the flagged files first |
| Red CI | “Build failed,” scroll the logs, guess | Failing test named, file and line attached, log tail quoted |
| Stale branches | Discovered during spring cleaning | Flagged in the morning brief at three days quiet |
| Dead code | Afraid to delete, so it stays forever | Candidate list with reachability reasoning; you delete what checks out |
| Context for review | Rebuilt from memory every time | PR summary includes the why, pulled from description and commits |
The Copy-Paste Prompts
Prompt 1: The Night Watch Nightly Routine
Set this as a scheduled routine against your main repo, nightly. The full routine:
Every night at 2am, audit the [owner/repo] repository and write my morning repo brief. Three sections. One: failing checks on the default branch and open PRs: name the failing test or step, the file and line, and quote the last few lines of the error. Two: open PRs older than three days with no activity: one line on what each PR does and what it is waiting on. Three: dead-code candidates: functions, files, or modules with no imports, no routes, and no tests referencing them, each with the reasoning for why it looks dead. Report only. Do not create branches, open PRs, merge, push, or delete anything.
Prompt 2: The PR Summary With Proof
Review pull request [#number] in [owner/repo]. Give me: what it changes and why (from the PR description and commits), the three files with the most churn, anything touching auth, payments, migrations, or concurrency, and whether tests cover the new behavior. Cite the exact file and line for every claim. If you cannot trace a claim to a line in the diff, leave it out. Summarize and flag only. Do not approve.
Prompt 3: The Dead-Code Investigation
In [owner/repo], investigate whether [file/function/module] is actually dead. Search for imports, route registrations, dynamic references by string name, feature-flag checks, and test usage. Tell me everywhere it is referenced, or confirm you found no references, and name the kinds of references you cannot see (generated code, plugins loaded at runtime). Do not delete it. Verdict first, evidence after.
What Can Go Wrong: The Confident Deletion
Dead-code detection is a guess, and some guesses are wrong in expensive ways. Code referenced by dynamic imports in a plugin system looks unreferenced to a static scan. Generated API clients look hand-orphaned. Feature-flagged code looks unused because the flag is off in your environment. Migration files look dead because nothing imports them. Muse will present all of these as candidates with full confidence, because that is what agents do.
The fix is the read-only mandate plus one habit: for anything the agent flags, you run the search yourself before deleting. Grep the codebase for the name. Check the plugin registry. Check the flag dashboard. The agent did the first pass across the repo in seconds, which is the part that would have taken you an hour. The last five minutes, the verification, are yours. That is the correct division of labor, and it never changes.
There is a second, sneakier failure mode in the failing-check section. When CI is red, the fastest path to green is rewriting the test, not fixing the code, and an agent under pressure to “make it pass” will do exactly that. The Night Watch brief only diagnoses; it never fixes. When you do hand it a fix, say so explicitly: “fix the code, not the test, unless the test itself is wrong.” Without that sentence, you will eventually get a green build and a broken feature, and you will not know which one you have until a customer tells you.
“Muse finds the rot. You hold the delete key.”
Muse will not make you a faster coder. It will make your repo a place where nothing quietly rots: every red check named before standup, every stale PR surfaced before it fossilizes, every dead module on a list instead of in your head. The engineers who get the most out of agents aim them at the chores nobody was doing anyway, and keep the delete key firmly in human hands.
