abrahamferga/plenipo
The front door. Eight loop verbs that drive every other plugin so you never have to remember the rest: setup (make a repo loop-ready), launch (nothing to a Ready backlog), define (keep the backlog full), deliver (next issue to a PR), test (sweep end to end and file the bugs), ship (review, gate, merge), steward (the platform's own request queue, behind a consumer-conformance gate), fleet (one tick across many products). Each verb is one bounded tick with a named terminal state, so it runs the same typed on demand or as /loop <interval> /plenipo:<verb>. Enable this plus every other plugin when you intend to run unattended.
One backlog tick that keeps a build loop fed: count what is actually Ready, promote shaped items out of Backlog, triage the enhancement issues real usage produced, and — only when the queue would otherwise run dry — extend the plan by one epic drawn from the spec's own deferred scope rather than from imagination. Every new capability must cite where it came from, which is what stops an unattended loop from inventing work forever. USE FOR: /loop 6h /plenipo:define, refilling a board the build loop drained, promoting Backlog to Ready. DO NOT USE FOR: the first plan of a new product (../launch/SKILL.md), implementing an issue (../deliver/SKILL.md), or filing defects found by a sweep (../test/SKILL.md).
One build tick, safe to fire on a timer: decide whether building is even the right move right now — a rejected PR to fix first, a p0 bug ahead of features, or too many PRs already waiting on review — then delegate the chosen item to the Opus 5 deliver:product-developer agent and journal the tick so a repeated timer cannot spin invisibly. Admission control and stagnation detection stay cheap in this context; /deliver:work-next-issue still owns the branch → code → runtime proof → PR procedure inside the worker. USE FOR: /loop 20m /plenipo:deliver, a single unattended build tick, resuming after a PR merged. DO NOT USE FOR: the implementation procedure itself (/deliver:work-next-issue), reviewing or merging what a tick produced (../ship/SKILL.md), or filling an empty board (../define/SKILL.md).
One tick across many products: read each repo's board, pull requests and last-swept state, score which single product most needs attention right now, run exactly one verb there, and journal it — so /loop 20m /plenipo:fleet is the only command needed to keep a portfolio moving. Serves the least-recently-served product on ties, quarantines any product that fails three ticks in a row instead of letting it eat the whole night, and answers "what is the state of everything?" in report mode without touching anything. USE FOR: driving more than one product from one machine, the nightly portfolio dashboard. DO NOT USE FOR: a single product (invoke that verb directly), or creating a new product (../launch/SKILL.md).
Take a product from nothing to a repo with a Ready backlog in one attended run, driving the whole scout → define → shape → scaffold chain through the conductor rather than restating it, and pausing at exactly one human decision: the go/no-go on the vertical and the brand name. Everything after that pause is automatic, and the run ends by making the repo loop-ready so the timers can take over. USE FOR: starting a new product, optionally from an industry you name, resuming a half-built one. DO NOT USE FOR: steady-state work on a product that already has a board (../deliver/SKILL.md, ../define/SKILL.md), or driving many products at once (../fleet/SKILL.md).
Make one repo safe to leave a timer pointed at: the run-and-prove surface, the label vocabulary, the autonomy block recording what this product has earned, two deterministic gate scripts and the workflows that run them, CODEOWNERS, branch protection, and a permission allow-list so a tick never blocks on a prompt nobody is there to answer. Run once per repo; re-run after a platform upgrade or when raising the autonomy level. USE FOR: preparing a product for unattended loops, auditing which pieces of that surface are missing. DO NOT USE FOR: creating the repo itself (../launch/SKILL.md), reviewing or merging pull requests (../ship/SKILL.md), or config-only validation of an existing product (/harness:validate-product).
One merge tick: for every open pull request the loop produced, merge only what clears a fixed list of deterministic gates at or below the autonomy level this repo has actually earned. Delegate an adversarial second opinion to plenipo:pr-reviewer only when a person asks or the evidence is ambiguous; model availability is never a merge prerequisite. A diff that removes a query filter, approval flag or permission grant, or edits the merge-policy trust root itself, stops for an owner bootstrap; ordinary protected changes are re-evaluated by the protected-base gate. USE FOR: /loop 30m /plenipo:ship, clearing a review backlog, letting a product merge without you. DO NOT USE FOR: writing or fixing the code under review (../deliver/SKILL.md), installing the branch protection and CI gates this depends on (../setup/SKILL.md), or merging platform changes — those need a conformance run across every consumer, which is ../steward/SKILL.md.
One platform tick, safe to fire on a timer or on demand: work the queue the products filed — verdict what is untriaged, implement one accepted request, announce a tagged release — and merge only behind a conformance gate that rebuilds every consumer in consumers.json against the candidate. Repair rejected platform pull requests before taking new queue work. The platform is the one repo whose blast radius is every product built on it, so its merge bar is not the product bar plus care, it is a different gate: green conformance across all registered consumers, or nothing merges. USE FOR: /loop 45m /plenipo:steward, a session pointed at the Plenipo platform repo, clearing the request backlog from several products at once. DO NOT USE FOR: a product repo (../deliver/SKILL.md and ../ship/SKILL.md own those), filing a request from a product (/deliver:request-platform-change), or consuming a release inside a product (/deliver:upgrade-platform).
One sweep tick: boot the product, delegate an end-to-end hunt to the deliver:e2e-tester agent, then turn what it observed into deduplicated GitHub bug issues that the build loop will pick up — each with a reproduction, a stable fingerprint key so tonight's sweep does not refile last night's bug, and a priority derived from consequence rather than from how easy it was to describe. Skips entirely when nothing has merged since the last sweep. USE FOR: /loop 3h /plenipo:test, sweeping after a merge or an upgrade, converting observed breakage into board work. DO NOT USE FOR: debugging one known failure (/deliver:verify-runtime), proving a single change works before its PR (that is inside /deliver:work-next-issue), or inventing improvements from reading code (the deliver:product-improver agent).