Ready

Check a task is fit to hand to a coding agent, before the agent starts.

Most agent runs that go wrong were doomed at dispatch. "Checkout broken, pls fix" turns into a confident PR for the wrong file. Ready reads a new issue or task the moment it's opened, and does one of two things:

• agent-ready: it posts where the fix most likely lives (searched from the live checkout), which tests cover it, and how this repo runs them.
• needs-human: it asks the one question only a person can answer, and holds the task back until it's answered.

It was built for Alan during the OpenFire hackathon, and runs as an Alan skill, an MCP server any agent can call, and a GitHub Action.

Why this and not a prompt

Alan's PM Agent shapes requirements, but it can't run commands. Ready reads the working tree: the error string's definition site, the test file next to it, and the repo's own test command.

Results

Evaluated on real, closed GitHub issues that were fixed by a merged PR. Ready sees only the issue text as filed. Its predicted files are compared with the files the PR actually changed, from git, not from labels anyone wrote.

Where the fix lives. Does a file the real PR changed appear in Ready's top k? Repo search only, no model. Engine commit 6783148.

Is it ready. This is the weak part, and it is reported as measured. On the held-out set, Ready holds back 4 of the 10 issues that maintainers explicitly labelled "needs more info" or "awaiting response". It also flags 27% of ordinary issues that were fixed without anyone asking a question. On the dev set, which it was calibrated on, the false-alarm rate is 10%. The rules lean cautious: a false "needs-human" costs one question, while a false "agent-ready" costs a wasted run.

Red team. Seven hostile issues in redteam/cases.yaml, all run as tests:

• instructions aimed at the agent
• fake system prompts
• an injection inside an otherwise good issue
• a planted path that doesn't exist in the repo
• a benign issue that merely mentions AI, which must not be flagged

The injection check fired on 0 of the 60 real dev issues.

Full tables, per-repo numbers and the worst misses are in evidence/results.md. What went wrong while building it is in what-broke.md, including a change that made the held-out numbers worse and was rolled back.

Use it

uv tool install git+https://github.com/SirjanSingh/ready
ready check https://github.com/owner/repo/issues/42 --repo path/to/checkout          # prints the verdict
ready check https://github.com/owner/repo/issues/42 --repo path/to/checkout --post   # comments + labels
ready plan  URL1 URL2 URL3 --repo path/to/checkout                                 # which can run in parallel

In Alan. Add Ready as a custom connector: Settings -> Plugins -> MCP -> Add custom connector -> Command.

Alan starts it inside each agent run, on your computer or in the cloud sandbox. Then give agents the skill in one of two ways:

• import skills/ready as a team skill (Skills -> Import -> From GitHub)
• drop it into a project as .claude/skills/ready/SKILL.md, as ready-demo does with its .mcp.json and AGENTS.md

To run the server yourself:

ready-mcp                      # stdio
ready-mcp --http --port 8765   # Streamable HTTP

Tools: check_readiness(issue, repo_path, post) and predict_footprint(issue, repo_path, k). With the skill installed, an agent calls check_readiness before it starts work and stops with the question if the issue isn't ready.

On every new issue. Copy .github/workflows/ready.yml into your repo.

Model. Any OpenAI-compatible endpoint serving an open model: set READY_BASE_URL, READY_MODEL and READY_API_KEY (see .env.example). Without a key, Ready still works on repo search alone.

What Ready will not do

It never edits the issue body, closes or assigns issues, or touches code. It posts one comment per issue, updated in place, and one label. It never invents acceptance criteria: the "Done when" list is quoted or directly implied by the issue, or left out.

Licence

MIT