Task
Free-form directive, in plain English, out the other end as a pull request.
Sometimes you don't have a finding — you have an instruction. "Migrate this service off the deprecated logger." "Add retry logic to all the outbound HTTP calls in this module." "Refactor the auth middleware to use the new session store." Tasks are how you give Hyrax that kind of work.
How it differs from fix
Fix and task share the entire quality gauntlet — the same isolated worktree, the same test gate, the same diff-size guard, the same reviewer agent, the same revision loop. The difference is the input:
| Fix | Task | |
|---|---|---|
| Input | A finding (HYDRA-…) | A free-form instruction you typed |
| Refinement | None — finding is structured already | A pre-pass refines your prompt into a concrete brief |
| Refs | The finding's existing ref | None — the PR URL is the artifact |
| Branch name | hyrax/fix-… | hyrax/task-… |
| PR title prefix | [Hyrax] fix: | [Hyrax] task: |
Everything else — gauntlet, push, PR machinery — is shared.
When to use task
- You want to ship a change that doesn't map to any single finding.
- You're doing a routine migration and would rather describe it in one sentence than file a finding for every file.
- You want to encode a team decision ("rename
FootoBareverywhere") into an actual PR. - You're cleaning up something an audit would never flag because it's not technically broken.
Writing a good directive
The refinement pre-pass is generous, but a clearer directive gets a tighter PR. Concretely:
- Name the target. "In
services/billing, …" beats "in the billing code." - State the success condition. "Replace all
time.time()calls withmonotonic()and update the existing tests" beats "fix the time-source thing." - Say what to leave alone. "Don't touch the SDK clients." Hyrax will respect explicit scope guards.
If the directive is genuinely ambiguous, the refinement pass surfaces what it had to assume in the PR description, so you can spot a misread before merging.
What it costs
Same envelope as fix: ~$1–3 clean, up to ~$5–10 if the reviewer kicks the diff back and a revision runs.
What task won't do
- Multi-step work that needs human review between steps. If the change requires a design discussion mid-flight, do that first and then file the task.
- Changes that span the diff-size guard. Tasks hit the same 20-file / 2,000-line cap as fix. Break the work into pieces.
- Anything outside one repo. Cross-repo changes need separate tasks, one per repo. Use related repos so each task sees the others' context.
Where the artifact lives
Tasks don't produce findings, refs, or backlog rows. The PR URL is the artifact. If you want a record of "we did this," merge the PR — the GitHub history is your record.