Illustrative and real-world CRDs
Worked examples
Two illustrative examples show that the Capability MLE test applies across visibility and realization modes. A second pair — GitHub's own pull request lifecycle — is grounded in a real, public system instead: extracted from GitHub's own documentation and independently blind-audited, rather than synthetic. A fifth and sixth example put an agent in control of the flow — one shows an agent operating a capability directly, the other shows an agent's own construction becoming a lasting realization.
Learn the boundary
Illustrative examples, synthetic by design.
See CRD extracted from real software
The framework's flagship pair.
GitHub's own pull request lifecycle, extracted from GitHub's public documentation and independently blind-audited — not invented to illustrate CRD syntax.
Open a pull request
Real-world capability extracted from GitHub's own public docs; multiple known realizations, tags, and audited provenance.
Explore →Merge a pull request
The flagship example: branch-protection policies, a confirmed automated realization, and audited provenance — capability meaning stays simple while realization complexity grows.
Explore →Too broad, vs. the correct Capability MLEs. GitHub's own documentation separates opening a pull request from reviewing and merging it — opening proposes a change; merging incorporates it into the base branch, subject to entirely separate rules and permissions. Treating pull-request management as one capability collapses that distinction:
Too broad:
Manage pull requests
Capability MLEs:
Open pull request
Review pull request
Merge pull request
Close pull request
Change draft/review state
...Each of those has its own actor, command, current state, and determinable result — the exact test in the specification's §3.1. Open and Merge are the two extracted and audited here; the rest are plausible siblings, not yet extracted.
Agentic realizations
Making the agentic thesis concrete.
Schedule a meeting
One capability, two realizations — agent-primary-using-software and software-primary — with an explicit approval boundary between them.
Explore →Generate a recurring report
One capability, one contract, served first by an agent that builds and validates an implementation, then by that implementation running as ordinary software — construction provenance and execution mode, shown as separate questions.
Explore →