Leads

A lead looks after a project.

• A long-running session One agent session that works a whole project and asks you only what takes a person.
• Asleep until there's work Each lead wakes when its own kind of work shows up on its project, and works only on that.
• Within the project's mode A lead goes only as far as the project's mode allows.
• Kept running While a lead is On, Overhand restarts it after it exits, gives up after repeated crashes, and waits while its account is at its usage limit.

Ready-made leads.

• Answer review comments Answer the review comments on this project's open pull requests: make each requested change, reply to the comment, and keep the checks green until the reviewer is satisfied.
• Keep CI green Keep CI green: when a build on the default branch, a pull request's checks or a production deploy goes red, find the root cause (flaky tests included) and fix it; never just retry or skip a test.
• Fix new errors Fix new production errors: reproduce each one, find the cause, and fix it with a test that covers it.
• Keep dependencies safe Keep dependencies safe: for each open security advisory, upgrade the affected package to the smallest version that fixes it, on its own branch with one pull request per advisory, and keep the repo's checks green. When no fixed version exists yet, say so instead of changing anything.
• Keep dependencies current Keep dependencies current: update the direct dependencies that have patch or minor updates, all together in one pull request at most once a week. Never apply a major update; list each one in that pull request's description for the owner to decide.
• Test what's untested Test what's untested: of the files listed (changed most in the last 30 days, and no test names them), pick the riskiest few and add tests that pin down what they do today, in the repo's own test style. Don't change their behaviour; when a test finds a bug, report it rather than fix it in the same pull request.
• Clear the TODOs Clear the TODOs: do the small, safe TODO, FIXME and HACK notes in the files listed. File each one that's bigger, or needs a decision, as a ticket in the project's tracker; when the project has no tracker, list them in the pull request's description instead.
• Work the backlog Work the backlog: take the tickets marked for agents, smallest first, one pull request each.

A project's view in Crew suggests them from its own work, each with the count behind it. The first click previews what it watches and does; Start this lead is the second.

How every lead works.

• Whatever its goal Every lead's prompt, ready-made, generic or your own skill, carries the same lines, written once in Overhand. How to work: read the repo's own rules first (AGENTS.md, CLAUDE.md, CONTRIBUTING) and match its style and commit conventions. Make the smallest change that fixes the root cause. Open one pull request per change, with a description that says what changed and why. Add or adjust a test for every change in behaviour, and run the project's own checks before opening it. Never skip a test, disable a check or force-push. When a choice is a product decision, ask.

When a lead asks.

• Under Needs you Answer in place, from your phone's notification, or from a terminal with overhand answer <lead> "your answer".
• Its default A question ends with what the lead will do if nobody answers. After the wait you set for that lead (Settings → Leads), Overhand goes with it and tells you. A question with no default, or a wait of 0, waits for you.
• Answered somewhere else I answered elsewhere resumes the lead when you settled it outside Overhand.

Your own lead.

• The generic lead Add one in Settings → Leads with no instruction of its own: it works the project's open issues and pull requests in priority order, with its notes kept in ~/.overhand, never in your repo.
• A project's own lead skill Point it at the skill, and have the skill keep a lock file and a questions file so Overhand can supervise it. LEADS.md has both formats and a snippet to paste.