Skip to content

Teach dormouse-bot to judge necessity before correctness #921

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
nedtwigg merged 2 commits into from
Oct 2, 2026
Merged

Teach dormouse-bot to judge necessity before correctness #921

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2224076
Teach dormouse-bot to judge necessity before correctness
nedtwigg Oct 2, 2026
1cf0154
Cut tend review guidance to the two necessity rules
nedtwigg Oct 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion .claude/skills/running-tend/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,16 @@ name: running-tend
description: Project-specific guidance for tend workflows running on this repo.
---

No project-specific tend preferences yet beyond the notes below. Add guidance here as needed — this file is loaded by tend workflows alongside AGENTS.md.
Project-specific guidance for tend workflows. Add to it as needed; tend workflows load this file alongside AGENTS.md.

## Reviewing PRs: judge necessity before correctness

Ask whether a change carries its weight before asking whether it is correct. Apply these checks in **Review**, and fold what they find into the same review:

- **Must name the trigger for every new guard, retry, fallback, or state.** Name the actor (user action, peer, Relay, local same-user process) and the shipping configuration that reaches it, and cite the caller. If nothing reachable triggers it, that is the finding: drop it, or file an issue. Do not review the robustness of a mechanism that should not exist. Code no CI job runs (Windows-only paths, PowerShell) needs a proportionally stronger trigger.
- **Never answer a gap in a hardening mechanism by asking for more of it.** When a fix needs a fix (an unbounded retry, a missed owner case, a stuck state), first ask whether a smaller design avoids the problem, and propose that instead. For example, write the journal before ownership moves and refuse the move on failure, rather than adding phases, retries, and parking.

When these checks are the only findings, submit `COMMENT`, not `APPROVE`.

## Filing issues in other repos

Expand Down
Loading