Open the winner as a draft pull request — cyberine apply --pr / cyberine run --pr
cyberine apply lands a run's judged winner on your working tree. --pr sends the same winning diff to GitHub instead: it pushes a new branch and opens a DRAFT pull request whose body summarizes the judging. Your working tree and current branch are never touched.
cyberine apply <runId> --pr --dry-run # print the branch, base, title and PR body; check the diff applies; push nothing
cyberine apply <runId> --pr # push the branch, open the draft PR, print its URL
cyberine apply <runId> --pr --base release/1.4 # open it against another base (default: the default branch of origin)
cyberine apply <runId> --pr --step implement # pick a specific workflow step, as for plain apply
cyberine run --pr "add a health check to the web server" # foreground build-fleet run, then open the draft PR for the judged winner
cyberine run --pr --base develop --fleet codex,muse "<task>"What it does, in order: it picks the winning diff exactly as cyberine apply does (the implement step, else the last step with a winning diff) and refuses when there is none. It then checks, before anything is created or pushed, that the repository has a commit, that origin is a GitHub remote (github.com, or the host named in GH_HOST), that gh is installed and authenticated for that host, that the base branch exists on origin, and that the target branch name is free. It adds a disposable git worktree off the current HEAD, creates branch cyberine/<first 8 of the runId>-<short slug of the task> there, applies the diff, and commits it as feat(cyberine): <short task summary> (50 characters at most, no attribution trailer). It pushes with git push -u origin <branch> and runs gh pr create --draft --base <base> --head <branch> --title <title> --body-file <tmp>. The worktree and the local copy of the branch are removed in a finally; the pushed branch stays on origin.
The PR body carries the task prompt (trimmed), the run id, the step and winner, the judge method, agreement and rationale, the trust-gate outcome, the diffstat, four labelled evidence sections (the per-candidate verdict table with outcome, rank, cost and time; DiffJudge apply and typecheck outcome per worker; the SecurityJudge result, or a line saying it did not run; the run cost) and the line cyberine digest <runId> to reproduce the view. The body and the commit subject pass through the same secret redaction as persisted conversations (src/core/redact.ts).
Safety refusals, all before any push: no winning diff; origin is not GitHub; gh missing or not logged in; no default branch resolvable (pass --base); base branch absent on origin; the branch name equals the base or default branch, already exists locally, or already exists on origin. The push is never forced and never overwrites a branch.
--pr cannot be combined with --commit or -m (apply) or with --bg, --compare, --print or --image (run). run --pr checks gh, origin and the base branch before it dispatches, so a missing prerequisite fails before any quota is spent; if the run succeeds but opening the PR fails, the run is kept and the message tells you to retry with cyberine apply <runId> --pr. For a --bg run, wait for it and then use cyberine apply <runId> --pr.
Known Limitations and Deferred Work: GitHub only, through gh; there is no GitLab or Bitbucket path. The pull request is always a draft and Cyberine never marks it ready, never merges it and never enables auto-merge; the branch is left on origin for you to review, merge or delete. The branch starts from the current HEAD of the repository the run was dispatched in, so unpushed commits already on that HEAD are part of the pull request's history; check out the intended base before running --pr. A second --pr for the same run is refused because the branch name is derived from the run id and the task title. A run whose winner is a text answer has no diff and cannot become a pull request. run --pr covers the foreground engine path only: a run with no build fleet, --compare, --image and --bg are rejected.
Batch-integrate finished runs — cyberine land
cyberine land waits for each run independently and commits each ready winner without waiting for another run's checks. Each winner is classified by its touched paths before publication. Except for...
See what's runnable + dispatch by id — cyberine next
cyberine next derives the runnable / blocked / waiting sets from the project task manifest (.claude/TASKS.md or .local/tasks/ACTIVE.md) — the same deps + blocker logic cyberine tasks run uses, so...