abrahamferga/deliver
The build and verification loops: take one Ready issue at a time from the board to a merged PR, and prove each change at runtime rather than at compile time. Ships the Plenipo module and connector SDK references Claude reaches for while coding, the runbook installer that gives a product its execution + verification surface, and the run -> exercise -> observe -> diagnose -> fix -> lock-in loop. The default coding-loop plugin.
Install the execution + verification surface into a Plenipo product repo so any agent can run it and prove a change works without rediscovering anything: RUNBOOK.md, a discoverable .claude/skills/run-<product> skill, the Testcontainers integration fixture, the golden-eval harness, the committed .http request catalog, and .claude/launch.json. Re-runnable — it reconciles what exists and reports drift instead of clobbering. USE FOR: a product with no runbook, a product whose runbook has gone stale, or standardizing a repo that predates this contract. DO NOT USE FOR: running or debugging the product (the installed runbook does that), or platform-level Plenipo work (the Plenipo repo has its own run skill).
Member-by-member reference for authoring a Plenipo domain module in C#: IModule, the ModuleManifest record and every field it accepts, ToolDescriptor versus ModuleTool and why a tool needs both, IModuleToolSource, TabDescriptor and its camelCase field binding, ModuleDbContext with per-entity HasQueryFilter, and Permissions.ForTool. Reach for it while writing module code — declaring a tool, adding a tab, wiring a DbContext, or chasing a tool the agent never calls. USE FOR: exact type names, required versus optional manifest fields, the two-place tool registration, tab data binding, startup-validation rules. DO NOT USE FOR: what the platform already supplies and must not be rebuilt (plenipo-platform), or running and testing the result (plenipo-runbook).
Handle a gap where the Plenipo platform cannot do what a product needs: climb the escalation ladder first, apply a tagged local shim so the product loop keeps moving, and only then file a structured platform request that the steward can triage without a human relaying it. Never edits the platform and never blocks on it. USE FOR: a compile error against a platform type, a missing seam, a platform bug, an invariant that blocks a feature. DO NOT USE FOR: consuming a platform release and unwinding shims (../upgrade-platform/SKILL.md), or triaging the queue (/steward:triage-requests).
Close the loop on a pull request that came back — review comments, requested changes, a failing check, or a merge conflict. Reads every thread, classifies each point as must-fix, discuss, or out-of-scope, fixes what it accepts, re-proves it at runtime, and replies to every thread so the reviewer can see what happened without re-reading the diff. USE FOR: a PR with unresolved review threads, CHANGES_REQUESTED, red checks, or a conflict. DO NOT USE FOR: starting the next backlog item (../work-next-issue/SKILL.md) or the first-pass verification of a change you just wrote (../verify-runtime/SKILL.md).
Create a brand-new product repo on the Plenipo platform: the four-project skeleton — Aspire AppHost, thin Host, the domain module that holds all the real code, optional product-owned connectors — plus the two test projects, the vendored .packages/ NuGet feed with source mapping, and the root governance files. A deliberately thin scaffolder: the platform is the foundation, so there is no backbone to generate. USE FOR: turning a decided brand name and domain into a repo that builds, boots under Aspire, and lists its module id. DO NOT USE FOR: adding tools, entities or tabs to a module that already exists (../plenipo-module-sdk/SKILL.md), or fitting the run-and-prove surface onto a repo that already has the skeleton (../install-runbook/SKILL.md).
Move a product onto a newer Plenipo release deliberately: re-vendor the platform packages, bump the single version property, unwind the TODO(plenipo#N) shims whose requests that release closed, and prove the whole test ladder still passes before the PR opens. Upgrades are never automatic — one bad release must not break every product at once. USE FOR: consuming a platform release, retiring a shim after a request lands, recovering a product that has drifted versions behind. DO NOT USE FOR: filing a new request (../request-platform-change/SKILL.md) or platform-side triage (/steward:triage-requests).
Drive one change on a Plenipo product from symptom to proof: reproduce through the narrowest surface, diagnose from telemetry before source, fix one variable per turn, then lock the behaviour in with a regression test seen red before the fix and green after. Refuses to call anything done that was not observed working at runtime, and refuses to let an assertion move instead of the code. USE FOR: proving a specific fix or feature actually works, debugging a failing chat turn, endpoint, or approval gate, picking which test rung locks a fix in, catching an agent that gamed a pinned assertion. DO NOT USE FOR: standing up the verification surface in a repo that has none (../install-runbook/SKILL.md), or the product-independent run and test contract (plenipo-runbook).
Take exactly one Ready issue off the GitHub project board and drive it to an open pull request: select the top item by build order, move the card to In Progress, cut a branch, implement it against the platform contract, climb the test ladder, prove the change at runtime, then open a PR that closes the issue and leave the card In Review. Never more than one issue in flight — a second run resumes the one already started instead of opening another. USE FOR: implementing the next feature off the board, resuming an interrupted issue, running the branch → code → runtime proof → PR cycle. DO NOT USE FOR: creating or ordering the backlog (/define:sync-backlog), deciding architecture or moving cards Backlog → Ready (the shape loop), or debugging behaviour that has no issue behind it (../verify-runtime).