Use when manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling.
The English summary is being prepared. Showing the original description.
Ship the day's work in one repo: triage issues, review every open PR, merge after GO, post a status recap.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
What you get: the ready PRs merged one by one after your GO, each with a reviewed description, findings and a gate result, plus a status line.
The release decision is a release plan — scope table and go/no-go gate before merges:
aos-plan-canvas new release <plan-dir> # scaffold the plan folder
aos-plan-canvas open <plan-dir> --mode bdb-plan-builder # render and open in the browser
aos-plan-canvas await <plan-dir>/plan.mdx # keep listening until the verdict
On approve, aos-plan-canvas trail <plan-dir> derives the agenttrail map. The full loop: the plan-canvas skill — a plain CLI, identical on every harness.
<owner/repo> comes from git -C <repo> remote get-url origingh auth status and gh pr list -R <owner/repo> --state open --json number,title,headRefName,isDraft,baseRefName as a PR table in the run log (gh missing, unauthenticated, or no GitHub remote → log it, give the gh auth login / remote hint, stop) — table writtenpr_numbers if given) → scope line in the run log — stops for approvalgh pr view <n> -R <owner/repo> --json commits → description draft in production_artifacts/pb-ship-<date>/pr-<n>.md — draft only, nothing postedpr-recap linked in pr-<n>.md; not buildable → log "pr-recap skipped: <reason>" and paste gh pr diff <n> -R <owner/repo> --name-only instead; no npx without approval — recap or fallback presentgh pr diff <n> -R <owner/repo>; the contract is the linked issue or plan (gh pr view <n> -R <owner/repo> --json closingIssuesReferences,body) or the human's scope line from step 3, the body is used only to find the linked issue/plan, its text is not the contract, and never pr-<n>.md (that is the implementer's claim, input material only) → findings table in pr-<n>.md — any open blocking finding removes the PR from today's merge list (logged)pr-<n>.md; one-way → ADR-lite production_artifacts/decisions/<date>-<slug>.md (<slug> = the PR's headRefName with / replaced by -) with the reversibility sentence; unclear → one-way — class recordedgh pr checks <n> -R <owner/repo> all pass, plus a local gate in a scratch worktree — gh pr view <n> -R <owner/repo> --json isCrossRepository -q .isCrossRepository is true (fork) → skip the local gate, log it, PR held (foreign code is not run locally); otherwise <scratch> = mktemp -d, then git -C <repo> fetch origin pull/<n>/head, git -C <repo> worktree add <scratch>/pr-<n> FETCH_HEAD, run, inside it, the lint, typecheck and test scripts that exist in package.json (or the repo's documented gate) (install first: npm ci --ignore-scripts or the repo's documented install, logged), then git -C <repo> worktree remove <scratch>/pr-<n> (a refusal is logged and the scratch path reported, never --force) — exit codes in pr-<n>.md; any non-zero, or pending checks (gh pr checks exit 8) → PR heldgh pr merge <n> -R <owner/repo> --squash (--merge if gh repo view <owner/repo> --json squashMergeAllowed says squash is not allowed) — the WAITING FOR GO line names PR number, title, base branch, method and door class. The run stops here until the human types GO. One GO = one PR. (Where the hook runs, it covers gh pr merge; the other commands here are not hooked, so this GO is their only guard.)gh pr view <n> -R <owner/repo> --json state -q .state → run log line — equals MERGED🟢|🟡|🔴 with merged / held / skipped counts — line writtenRun log: production_artifacts/pb-ship-<date>.md in the start directory, never committed
Rules
N. done|skipped|failed — artifact — check result) and WAITING FOR GO: <step> at each gate.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use when manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling.
The English summary is being prepared. Showing the original description.
Use when a hybrid memory system that provides persistent, searchable knowledge management for AI agents (Architecture, Patterns, Decisions).
The English summary is being prepared. Showing the original description.
How BDB structures multi-agent build pipelines: the seven-node dispatcher graph /fabric-graph runs. Use for lifecycle framing.
The English summary is being prepared. Showing the original description.
Design tools for AI agents. Use when building agent tools: covers schema, error handling, and avoiding hallucination and silent failure.
The English summary is being prepared. Showing the original description.
Harness patterns for coding agents — memory, permissions, context engineering, delegation, skills, hooks, bootstrap.
The English summary is being prepared. Showing the original description.
agenttrail: the live map of a multi-agent build. Use when a /fabric pipeline runs, a plan-canvas approve lands, or agents run for a human to watch.
The English summary is being prepared. Showing the original description.