abrahamferga/harness

The shared language agents use to talk to each other through GitHub — the message envelope, the closed set of message kinds, the label vocabulary that is the state machine, and the rules for replying and handing off. Every agent in every loop and every repo reads and writes this format, so an agent in one product can be understood by an agent in another or by the platform. USE FOR: writing an issue, comment, or PR body another agent will act on; parsing one you received; choosing a label. DO NOT USE FOR: the platform request ladder itself (platform-protocol) or who may merge a PR (/deliver:work-next-issue's merge-policy reference).

Drive one product from an idea to merged, runtime-proven code by sequencing the four loops — scout, define, shape, deliver — handing each phase off to its own slash command and refusing to advance until that phase's exit check passes. Owns the gates, the run journal, the budget and stagnation ceilings, and the autonomy level; it delegates every procedure instead of restating one. USE FOR: starting or resuming a full end-to-end run, deciding which phase comes next and whether the previous one actually finished, draining a GitHub backlog issue by issue under a budget. DO NOT USE FOR: doing a single phase's work (invoke that phase's command directly), or grading evidence in the abstract (loop-discipline).

Give a repo cross-tool agent configuration so OpenAI Codex, GitHub Copilot (VS Code, cloud agent, code review), Cursor and Claude Code all work from the same rules: AGENTS.md as the single source, a CLAUDE.md that imports it, a thin .github/copilot-instructions.md, the path-scoped rule file each tool reads (.github/instructions/*.instructions.md, .claude/rules/*.md, .cursor/rules/*.mdc), and .github/agents/*.agent.md for agents that run on github.com. Facts land in exactly one file — duplication across these is the top cause of contradictory agent behaviour. USE FOR: making a product or platform repo usable by Codex, Copilot and Cursor, not just Claude Code. DO NOT USE FOR: writing the run/test contract itself (/deliver:install-runbook), which AGENTS.md then points at.

Install and govern GitHub Agentic Workflows in a Plenipo platform or product repository: initialize gh-aw authoring, add bounded Copilot issue-triage and PR-intent-review workflows, connect an explicit GitHub App allowlist for product-to-platform and release-impact routing, compile hardened lock files, and prove safe outputs in staged mode. USE FOR: onboarding a Plenipo repo or product such as Networthy to GitHub-hosted agentic automation. DO NOT USE FOR: manually triaging platform requests (use /steward:triage-requests), filing one product gap (use /deliver:request-platform-change), or implementing a product feature.

The operating rules every loop in this marketplace runs under: the five-level verification ladder (deterministic → rule → field truth → model-as-judge → human), the six named terminal states, the five loop anti-patterns, and the design families that keep an unattended loop honest. Reach for it before claiming something is done, when a loop is spinning, or when deciding how far to verify. USE FOR: grading how strong your evidence actually is, choosing a stopping rule, naming why a loop ended, calling out a self-approving or runaway loop. DO NOT USE FOR: how to run or test a Plenipo product specifically (plenipo-runbook) or what the platform provides (plenipo-platform).

The contract between products and the Plenipo platform when many products are being built at once: the escalation ladder a product climbs before asking for a platform change, the shape of a platform request, what the platform steward guarantees back, and the rule that filing a request never blocks the product. Reach for it whenever a product needs something the platform does not yet do. USE FOR: deciding whether a gap is yours or the platform's, understanding what a triage verdict means, knowing why a shim is tagged. DO NOT USE FOR: actually filing the request (/deliver:request-platform-change) or triaging the queue (/steward:triage-requests).

What the Plenipo platform already provides — auth, multi-tenancy, RBAC-before-the-model, approvals, audit, jobs, chat transports, documents, RAG, connectors, channels — the host seams a product extends it through, and the invariants a product may never violate. Reach for it before writing any code in a Plenipo product, so you extend the platform instead of rebuilding a weaker copy of it. USE FOR: deciding whether something is yours to build, finding the right seam, checking an invariant, getting verified package and API names. DO NOT USE FOR: running or testing a product (plenipo-runbook), or the line-by-line module authoring recipe (/deliver:plenipo-module-sdk).

How to run, observe, and prove a change in any product built on the Plenipo platform — the launch modes, dev-auth headers, the keyless Mock provider, the AG-UI event contract, Aspire telemetry, and the five-rung test ladder from build to golden conversation evals. Reach for this whenever asked to start, exercise, debug, or verify a Plenipo product, or when about to claim a change works. USE FOR: running the app, reproducing a bug, calling the API, choosing which tests to write, reading telemetry, deciding whether something is actually done. DO NOT USE FOR: writing module code (see plenipo-module-sdk) or installing this surface into a repo that lacks it (/deliver:install-runbook).

Close the loop from a product or platform repo back to the agent marketplace: when work proves a skill is wrong, stale, or missing — a type that was renamed, a procedure that fails as written, a new platform seam no skill lists — record it in your own repo so you are never blocked, then file one evidence-bearing issue against the marketplace so the next agent in every repo stops inheriting the defect. USE FOR: a skill contradicted by source, a documented command that fails, a seam missing from the "do not rebuild" table, recurring work no skill covers. DO NOT USE FOR: a gap in the platform itself (/deliver:request-platform-change), a bug in the product you are building (file it on that repo), or editing a skill while you are running it.

Audit one Plenipo product repo without touching it: config files parse and agree with each other, no committed secrets, the vendored package feed is pinned, the platform pin is not lagging, the greppable guardrail invariants hold, the agent-facing run surface exists, and the docs still describe the code. Emits a located, per-check pass/fail report and exits non-zero on any failure. USE FOR: pre-commit or CI conformance auditing of a single repo, catching a missing tenant query filter or an unapproved write tool before it ships, proving config hygiene. DO NOT USE FOR: fixing anything it reports (strictly read-only), proving the product actually behaves at runtime (/deliver:verify-runtime), or inventorying every repo (/scout:scan-fleet).