Queued
Capture the repository, branch, issue statement, expected result, and optional reference command before any runner work begins.
Paste a repo and issue. Patchflow reproduces the failure, writes the smallest safe patch, validates it, then opens a reviewable Pull Request.
Every red CI build should be handled by a repeatable repair pipeline: reproduce the failure, make the smallest safe change, prove it with tests, then ship a pull request.
Capture the repository, branch, issue statement, expected result, and optional reference command before any runner work begins.
The System prepares the repository in a local sandbox and inspects the reported failure before editing code.
Patchflow pushes the smallest defensible code change. The product bias is a readable diff, not broad refactoring.
An automated review gate checks the proposed change without executing requester-supplied commands, then records user-visible logs and artifacts.
When the run succeeds, the GitHub App creates a branch and pull request so the user keeps final merge control.
The value is not just writing code. The value is restricting the change to the exact failure, making the diff readable, and keeping merge authority with the repository owner.
// parseLocale can return undefined after dependency updateexport function formatPrice(input: string) { const locale = parseLocale(input).locale; const { locale = DEFAULT_LOCALE } = parseLocale(input) ?? {}; return new Intl.NumberFormat(locale, opts);}PRs only after review
observable repair stages
credit per repair attempt
seat pricing or subscription lock-in
Runner work starts by narrowing the failure in an isolated checkout.
Changes stay inside the issue scope with no opportunistic rewrites.
Every successful fix lands as a GitHub branch and reviewable PR.
Task packets are processed by the System instead of browser-triggered shell execution.
Clone, analysis, patch, review, and delivery events are visible to the user.
$ patchflow fix https://github.com/your-org/your-repo