chernabog |
The live view |
status |
Repos, schedules and trust, runs in flight, recent runs, why ticks were skipped. A manual flow shows as manual, with how to start it |
run <flow> --repo <repo> |
One run now, skipping gates, through the daemon; follows its log |
rehearse <flow> --repo <repo> --scenario <file> |
Rehearse the flow end to end on a seeded repo, with stand-ins where the agent would be; then clean up what it seeded |
trigger <flow> --repo <repo> |
A tick now, with its gates, as if the schedule came due. A manual flow has no schedule, so this fails and says how to start it |
cancel <run>, cancel <repo> <item> |
End a run in flight for good, waiting or mid-step, through the daemon or, with it stopped, here. It’s recorded as cancelled, its worktrees are removed (any with uncommitted or unpushed work is kept and named), and its claim is released: its claim ref (on its issue or pull request) is deleted, auto:in-progress and the assignment come off, and the claim branch is deleted unless it has commits or a pull request. A run that has already ended keeps its ending: cancelling it deletes only a claim ref that still names it, which a flow baked before claims were refs leaves behind, and is refused when there is none. It never comments, reviews, or closes or merges a pull request. --flow and --as pick among several runs on one item; --close-session also closes its agent sessions through their launcher, which are otherwise left to you |
logs <run> [-f] |
A run’s log; -f follows it. <run> is its id, or enough of it to name one run, such as the 8 characters status shows |
attach <run> |
Open the run’s agent session |
start <issue> |
Run the repo’s entry flow, the one that declares defineFlow({ start: true }) (the human-initiated recipe does), on the issue, whatever its labels, through the daemon (which must be running), and bring its session up here: the Orca tab, or tmux attach. On an issue whose run is in flight, bring up that run’s session |
open-pr --title <title> |
From inside the session chernabog start opened: check the worktree is clean, and hand the work to chernabog, which runs the local gate, pushes, opens the pull request, waits for CI and asks a reviewer. The session stays open for you to close. With --draft, which the agent uses, it keeps the pull request as a draft and prints a question for the agent to ask you; your Yes hands it over |
pause <repo>, resume <repo> |
Start no new runs in a repo; runs in flight continue |
trust [repo] |
Show what changed in .chernabog/ since last trusted, and trust it |
labels [repo] |
Create or correct the repo’s labels |
doctor |
Check logins, gh scopes, labels, trust, each repo’s launcher, that each reviewer this machine acts as can merge, and the daemon; and print the warnings the repo’s flows contribute (defineFlow({ doctor })), such as the recipes’ reviewer-pool checks |
setup |
Choose the GitHub personas this machine acts as, and add AI accounts; safe to run again |
init [path] |
Scaffold .chernabog/, or refresh its schemas and pins, add @chernabog/recipes there, copy the recipes chosen, then enroll the repo once it has a flow |
recipes list [path] |
The recipes of each recipe package installed in .chernabog/, with their descriptions and docs pages: ✓ by the ones the repo copied, → by the ones it imports |
recipes add [names…] |
Copy recipes into this repo’s .chernabog/, recording the version each came from; asked in a terminal when none is named. Never overwrites a file the repo has. A name is <package>/<recipe>, or a bare name from @chernabog/recipes |
recipes add --import [names…] |
Import recipes instead: write flows.<name>.from in config.yaml and move the package to dependencies, copying nothing |
recipes eject <flow> |
Copy an imported flow, with its prompts and steps, into the repo, and remove its from; it runs on under the same name |
recipes diff [names…] |
How this repo’s copied flows, and the prompts their recipes render, differ from the versions of the recipes they came from |
recipes update [names…] |
Move each recipe package to its newest version for the repo’s SDK, and merge its changes into the copied recipes, keeping your edits and marking conflicts; in the working tree |
recipes upgrade |
Move this repo’s .chernabog/ to the SDK released with this binary, and its core and effect pins to the binary’s, then its copied recipes to the newest versions for that SDK |
enroll [path] |
Add a repo to this machine’s config: which personas work in it, which flows each runs, which accounts they spend |
install, uninstall |
Run setup, then register the daemon with launchd or systemd and start it; or remove it |
start, stop |
Start or stop the daemon; runs in flight resume when it starts again. start with an issue is the hybrid path, above |
daemon |
Run the daemon in the foreground (what the service runs) |
