Source profileQuality 96/100

magnus919/agent-skills/promise-theory/SKILL.md

promise-theory

Design and diagnose coordination in hybrid human + AI agent workforces using promise theory (Burgess/Bergstra): model agents as autonomous, coordination as voluntary offers plus acceptance, and trust as calibrated assessment. Use for delegation modeling, capability manifests and agent contracts, coordination-failure diagnosis, trust/verification calibration, convergent self-healing systems, and converting obligation-based designs to promise-based. Do not use for enforceable centralized control,

Source repository stars
61
Declared platforms
0
Static risk flags
0
Last source update
2026-08-26
Source checked
2026-08-28

Decision brief

What it does: where it fits

Promise theory (Mark Burgess; formalized with Jan Bergstra) is a method of analysis for systems of autonomous agents — humans, LLM agents, APIs, and deterministic automation. It supplies the vocabulary for designing and diagnosing delegation: promises, acceptances, assessments,…

Best for

  • Modeling delegation between humans and agents — decide who may promise what to whom, and who accepts, in a human + AI workforce.
  • Designing capability manifests or agent contracts — declare capabilities and intent with acceptance criteria, verification, and withdrawal semantics.
  • Diagnosing coordination failures — explain unkept promises, refused acceptances, or missing assessments in multi-agent work.

Not for

  • When enforceable centralized control is guaranteed — if you can command and verify compliance directly, promise theory's machinery is overhead, not insight.
  • For simple single-agent prompting — one model and one prompt, with no delegation graph to model, needs no promise vocabulary.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/magnus919/agent-skills --skill "promise-theory"
Safe inspection promptEditorial

Inspect the Agent Skill "promise-theory" from https://github.com/magnus919/agent-skills/blob/531ff6753784823c878c92b988c6e55266ce09a9/promise-theory/SKILL.md at commit 531ff6753784823c878c92b988c6e55266ce09a9. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Quick Start

    Run these commands from the skill directory (promise-theory/); python3 scripts/promise-contract.py --help lists every command and flag.

    Draft a promise manifest. Copy templates/promise-manifest.yaml.tmpl to a working file (for example promise-manifest.yaml) and fill the placeholders: agent ids and roles, at least one promise per agent (body, type, targe…Lint it. Run python3 scripts/promise-contract.py lint promise-manifest.yaml. Exit 0 with full expectation coverage means the manifest is valid; exit 1 names the violations to fix (coverage gaps, dangling acceptances, in…Add --json for machine-readable output. Run python3 scripts/promise-contract.py lint promise-manifest.yaml --json to get a single JSON object on stdout (valid, errors, warnings, coverage, bindings) and nothing else.
  2. 02

    Core model

    A promise is an autonomous declaration of intended, but as yet unverified, behaviour from a promiser to a promisee (body: label Λ, type τ, constraint χ). Agents are autonomous: no agent can promise another's behaviour. Coordination emerges from voluntary cooperation — an offer p…

    A promise is an autonomous declaration of intended, but as yet unverified, behaviour from a promiser to a promisee (body: label Λ, type τ, constraint χ). Agents are autonomous: no agent can promise another's behaviour.…
  3. 03

    When to use

    Load this skill when any of these triggers matches:

    Modeling delegation between humans and agents — decide who may promise what to whom, and who accepts, in a human + AI workforce.Designing capability manifests or agent contracts — declare capabilities and intent with acceptance criteria, verification, and withdrawal semantics.Diagnosing coordination failures — explain unkept promises, refused acceptances, or missing assessments in multi-agent work.
  4. 04

    When not to use

    When enforceable centralized control is guaranteed — if you can command and verify compliance directly, promise theory's machinery is overhead, not insight.

    When enforceable centralized control is guaranteed — if you can command and verify compliance directly, promise theory's machinery is overhead, not insight.For simple single-agent prompting — one model and one prompt, with no delegation graph to model, needs no promise vocabulary.For imperative push-based orchestration scripts that need no consent modeling — a cron job or CI pipeline that runs without acceptance semantics is not a promise system.
  5. 05

    Load By Need

    Review the “Load By Need” section in the pinned source before continuing.

    Review and apply the “Load By Need” source section.

Permission review

Static risk signals and limitations

No configured static risk pattern was detected

This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score96/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars61SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
magnus919/agent-skills
Skill path
promise-theory/SKILL.md
Commit
531ff6753784823c878c92b988c6e55266ce09a9
License
MIT
Collected
2026-08-28
Default branch
main
View the original SKILL.md

Promise Theory

Promise theory (Mark Burgess; formalized with Jan Bergstra) is a method of analysis for systems of autonomous agents — humans, LLM agents, APIs, and deterministic automation. It supplies the vocabulary for designing and diagnosing delegation: promises, acceptances, assessments, breaches, and renegotiation. This skill is a thin router; load the dense material only when a row in Load By Need matches your task.

Core model

A promise is an autonomous declaration of intended, but as yet unverified, behaviour from a promiser to a promisee (body: label Λ, type τ, constraint χ). Agents are autonomous: no agent can promise another's behaviour. Coordination emerges from voluntary cooperation — an offer plus an acceptance (a counter-promise) — never from imposed obligation. Obligations are derived, non-autonomous impositions (imposition + penalty). Agents keep promises via an evaluation loop: observe → assess → act, converging on the promised state. The Downstream Principle: the most downstream party in a promise chain carries the greatest causal responsibility for the outcome.

When to use

Load this skill when any of these triggers matches:

  • Modeling delegation between humans and agents — decide who may promise what to whom, and who accepts, in a human + AI workforce.
  • Designing capability manifests or agent contracts — declare capabilities and intent with acceptance criteria, verification, and withdrawal semantics.
  • Diagnosing coordination failures — explain unkept promises, refused acceptances, or missing assessments in multi-agent work.
  • Calibrating trust and verification — decide how much to verify an agent, at what rate, and at what cost.
  • Designing self-healing or convergent infrastructure — evaluation loops that observe, assess, and act toward a desired state.
  • Converting obligation-based designs to promise-based ones — replace push commands and mandates with voluntary offers and acceptance.

When not to use

  • When enforceable centralized control is guaranteed — if you can command and verify compliance directly, promise theory's machinery is overhead, not insight.
  • For simple single-agent prompting — one model and one prompt, with no delegation graph to model, needs no promise vocabulary.
  • For imperative push-based orchestration scripts that need no consent modeling — a cron job or CI pipeline that runs without acceptance semantics is not a promise system.
  • For legal contracts — promise theory is not contract law; it models voluntary intent and assessment, not enforceable legal instruments. Draft real contracts with legal counsel.
  • When the user needs a specific tool manual — route to the tool's own skill (for example, cli-builder for CLI conventions) instead of framing the tool with promise theory.

Load By Need

NeedLoad
Re-derive a definition or the formal model (promise, imposition, obligation, bindings, trust, Downstream Principle)references/foundations.md
Learn from CFEngine, IaC, or distributed-systems practice before designing convergent infrastructurereferences/applications-infrastructure.md
Design coordination between specific humans and agents (manifests, acceptance handshakes, oversight, authority)references/agent-coordination.md
Apply a named pattern — promise manifest, acceptance handshake, agent contract, evaluation loop, breach→renegotiation, redundancy, trust calibrationreferences/patterns.md
Decide how much to verify an agent, set a starting trust level, or wire assessment into evals and observabilityreferences/trust-and-verification.md
Diagnose a coordination failure, run the breach taxonomy, or check the theory's limitationsreferences/diagnosis-and-debugging.md
Hit an unfamiliar term while applying this skillreferences/glossary.md

Quick Start

Run these commands from the skill directory (promise-theory/); python3 scripts/promise-contract.py --help lists every command and flag.

  1. Draft a promise manifest. Copy templates/promise-manifest.yaml.tmpl to a working file (for example promise-manifest.yaml) and fill the placeholders: agent ids and roles, at least one promise per agent (body, type, target), and at least one expectations entry whose about references a declared promise id.
  2. Lint it. Run python3 scripts/promise-contract.py lint promise-manifest.yaml. Exit 0 with full expectation coverage means the manifest is valid; exit 1 names the violations to fix (coverage gaps, dangling acceptances, invalid enums) or reports a malformed file as a parse error — never a traceback. Re-run after each fix until clean.
  3. Add --json for machine-readable output. Run python3 scripts/promise-contract.py lint promise-manifest.yaml --json to get a single JSON object on stdout (valid, errors, warnings, coverage, bindings) and nothing else.
  4. Add --dry-run to confirm no writes. Run python3 scripts/promise-contract.py lint promise-manifest.yaml --dry-run to repeat the same check; lint is read-only, so nothing is written or modified.

Available Scripts

This skill bundles one script; there are no others to discover. Both commands are read-only (--dry-run is accepted everywhere as a no-op guard).

ScriptPurposeInvocation
scripts/promise-contract.pyValidates and renders promise-theory manifest contracts (restricted-YAML or JSON). lint checks a promise manifest against the promise-manifest v1 schema (exit 0 = valid with full expectation coverage; exit 1 = named lint errors or coverage gaps; exit 2 = usage/IO errors) and render prints a promise-graph summary of agents, promises, bindings, and uncovered expectations. Run lint after drafting or every edit of a manifest until it exits clean, and render when you need a human- or machine-readable view of the coordination model you just built.python3 scripts/promise-contract.py lint promise-manifest.yaml

Append --json for machine-readable output (a single JSON object on stdout); render --json gives the same treatment to the graph summary.

Related Skills

SkillRoute when...
agent-evals-and-observabilityYou need the assessment layer: evals, guardrails, and observability that verify promises are kept (also routed from references/trust-and-verification.md)
agent-councilYou need multi-agent debate as structured promise exchange and convergence (also routed from references/agent-coordination.md)
workflow-architectYou need to design a workflow as a chain of promises (also routed from references/patterns.md)
artifact-pyramidsYou need to structure promise-keeping evidence as summaries → analysis → evidence dossiers (also routed from references/trust-and-verification.md)
agent-skillsYou are authoring or editing an Agent Skills-format skill — the format this skill follows
cli-builderYou are building or refactoring the bundled CLI — scripts/promise-contract.py follows cli-builder conventions (non-interactive, --json, --dry-run)

Gotchas

  1. Provenance honesty. The direct "promise theory + AI agents" literature is thin and recent (Burgess, "Cooperation in Human and Machine Agents," arXiv:2604.10505, 2026). In the references, claims not verified against a primary source carry [UNVERIFIED], and the promise-theory → LLM-agent synthesis is labeled EXTRAPOLATION. Preserve those markers; they are what keep this skill honest.
  2. The theory is "semi-formal." The authors themselves use that term: there is a notation, definitions, lemmas, and rules, but no complete axiomatisation or model theory. The famous ≤50% (impositions) vs ≤100% (promises) claim is an informal heuristic, not a derived result. Use the formalism as a reasoning aid, not a proof system.
  3. Autonomy is a modeling postulate, not an ideology. It does not claim decentralization is morally right or always better; it is chosen because it forces complete documentation of intended behaviour and exposes failure modes.
  4. Promise-keeping must be stored as data. CFEngine's documented gap: it reported whether a promise was kept right now, but promise-keeping was never stored as data, so the evaluation loop was incomplete. In a hybrid workforce, record assessments as versioned data (a promise ledger) or trust cannot accumulate.
  5. Verification loads are an attention/energy budget. The rate at which you check (kinetic mistrust) is spent attention; Burgess & Dunbar model it as a bounded budget. Budget verification cost explicitly and start unknown agents at 50-50 rather than assuming trust or distrust.

Prerequisites

  • Python 3 with standard library only; promise-contract.py requires no third-party packages.
  • A manifest to lint or render: copy templates/promise-manifest.yaml.tmpl and fill the placeholders (see Quick Start) before running either command.

Limitations

  • The CLI validates declaration structure, enum values, expectation coverage, and dangling acceptances — it cannot judge whether the promised behaviour is sensible, achievable, or actually kept; assessments live in your promise ledger, not in this tool.
  • Promise theory is not contract law: nothing the script validates creates an enforceable legal instrument (see When not to use).
  • Lint is a static check at a point in time; it does not observe agents or verify runtime promise-keeping.

Exit Conditions

Stop when the delegation is modeled as a promise set, acceptances and assessments are recorded (or their absence explicitly deferred), and every breach has a renegotiation or escalation path. When diagnosing, stop after three non-converging passes and report the evidence instead of re-litigating the same promises.

Frequently asked questions

What to verify before installation and use

What does the promise-theory source document cover?

Promise theory (Mark Burgess; formalized with Jan Bergstra) is a method of analysis for systems of autonomous agents — humans, LLM agents, APIs, and deterministic automation. It supplies the vocabulary for designing and diagnosing delegation: promises, acceptances, assessments,…

How do I install promise-theory?

The source record exposes this install command: npx skills add https://github.com/magnus919/agent-skills --skill "promise-theory". Inspect the command and pinned source before running it.

Alternatives

Compare before choosing

Computed 10045,960

coreyhaines31/marketingskills

ab-testing

When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

Computed 10045,960

coreyhaines31/marketingskills

churn-prevention

When the user wants to reduce churn, build cancellation flows, set up save offers, recover failed payments, or implement retention strategies. Also use when the user mentions 'churn,' 'cancel flow,' 'offboarding,' 'save offer,' 'dunning,' 'failed payment recovery,' 'win-back,' 'retention,' 'exit survey,' 'pause subscription,' 'involuntary churn,' 'people keep canceling,' 'churn rate is too high,' 'how do I keep users,' or 'customers are leaving.' Use this whenever someone is losing subscribers o

Computed 10014,706

prowler-cloud/prowler

postgresql-indexing

PostgreSQL indexing best practices for Prowler: index design, partial indexes, partitioned table indexing, EXPLAIN ANALYZE validation, concurrent operations, monitoring, and maintenance. Trigger: When creating or modifying PostgreSQL indexes, analyzing query performance with EXPLAIN, debugging slow queries, reviewing index usage statistics, reindexing, dropping indexes, or working with partitioned table indexes. Also trigger when discussing index strategies, partial indexes, or index maintenance

Computed 100147

oaustegard/claude-skills

featuring

Generate hierarchical _FEATURES.md files that describe what a codebase DOES from a user/consumer perspective, anchored to source symbols via tree-sitting. Supports large complex codebases through feature-driven decomposition into sub-feature files. Uses a multi-pass synthesis: orientation → detail → overview rewrite. Use when someone says "what does this do", "document features", "feature inventory", "_FEATURES.md", or needs to understand a codebase's purpose before modifying it. Complements tre