For coding tasks / before implementation
Review the coding work order before the agent starts
A passing test is useful only if the brief asks for the right behavior.
Before handing a feature or bug fix to a coding agent, give its work order a $1 review. The Wringer critiques vague checks, missing failure cases, and scope that leaves room for unrelated changes.
Review my coding brief for $1Pay per audit. A simulated review with no real tools. Code review and execution remain separate.
01 / WORKED EXAMPLE
A CSV export task with something to prove
Before: “Add CSV export for selected orders. Make sure it works.” A test that only sees a download could pass for an empty file or an export of every order.
Repaired work order: In a local fixture with order IDs 101, 102, and 103, select 101 and 102. Export a CSV with exactly the columns order_id and total, one data row per selected order, and totals unchanged from the fixture. Use local test data only. Stop after five attempts and report any unresolved check.
| Check | Failure case | Pass condition |
|---|---|---|
| Contents | A file downloads, but includes 103, omits 102, or has no data rows. | A parser confirms exactly two data rows, IDs 101 and 102, the two named columns, and fixture totals. |
| Empty selection | Export silently downloads every order when nothing is selected. | A test with zero selected orders produces no download. A human checks that the page asks the user to select orders. |
| Regression | The new export breaks the existing order filters. | Run the existing filter tests and report their names, discovered test count, and results alongside the export checks. |
The audit can critique this plan. A developer still needs to adapt the checks to the repository, run them, inspect the diff, and review the result. A predicted pass is not execution evidence.
02 / BUYING DECISION
Use the audit while the brief is still cheap to edit
- Draft for free. Start with your coding task or the bug-fix work order template. Include the failing scenario and the checks you expect to run.
- Pay $1 for a critique. Review the grade, simulated notes, and proposed repairs. Keep the parts that fit your project.
- Hand off a reviewed order. Use your own coding workflow, then collect real test evidence before accepting the implementation.
If a teammate has already reviewed a small, concrete brief, another paid critique may add little. For a completed pull request, use code review and real tests. See the audit walkthrough for the output this product actually provides.
Working on a document or data handoff instead? See the acceptance-criteria review example.
Before you pay
Does the $1 audit review my code or pull request?
No. It reviews the work order you provide. It does not open your repository, inspect a diff, run tests, or certify a fix. Code review and execution checks still belong in your development workflow.
What should I paste into a coding work order?
Include the user-visible outcome, a small input fixture, expected results, regression checks, files or behavior that must stay unchanged, and an attempt limit. Describe any repository context the reviewer needs in the brief.
What do I get for $1?
An AI critique with a grade, predicted exit, simulated dry-run notes, and suggested repairs. When a repaired form is returned, you can apply it to the draft and edit it. The audit uses no real tools, and its predictions are not test results.
Can I use the repaired order with my own coding agent?
Yes. Review the suggestions, then copy the work order into your own workflow. You do not have to buy a separate MECHA execution run. The $1 audit does not include implementation.