Goal to Proof

Make AI agents do the right work, finish it, and prove it.

한국어 · Website · Methodology · Validation

Goal to Proof is a lightweight closure contract for AI agents. It turns authorized, non-trivial work into an observed outcome instead of a plausible completion claim.

It does not give an agent new permissions, choose your goals, or force a heavyweight process onto simple work. It changes the definition of “done”: each in-scope requirement needs direct, scope-matched evidence from the latest relevant state.

The problem it solves

Agents often stop one boundary too early:

a plan exists, but the requested change was never made;
a component passes, but the real integration path was not exercised;
a file was generated, but the intended audience cannot use it;
a push succeeded, but the public artifact was never read back;
a proxy check passed, so the broader outcome was implied rather than observed.

Goal to Proof keeps the user in control while making the agent responsible for execution and verification inside the approved boundary.

The user owns	The agent owns inside the authorized boundary
Goals, values, authority, risk tolerance, material choices	Method, sequencing, reversible implementation choices, diagnostics, execution, verification

The closure contract

For work that needs real closure, the skill identifies four things:

Result — what must be different when the task is done.
Target — who or what must be able to use or observe it.
Proof — the most direct practical observation that separates success from plausible-looking failure.
Boundaries — what is authorized, excluded, or requires new authority.

The agent then chooses the lightest workflow that can reach that result, completes the dependent steps, and maps every completion claim to evidence.

When to use it

Use Goal to Proof when a deliverable has dependent steps, crosses an integration or publication boundary, or is likely to stop at a plan, partial artifact, isolated component, or proxy check.

Typical examples include:

implementing and exercising a user-visible feature;
fixing a bug and reproducing the original path after the change;
publishing an artifact and reading the remote state back;
producing a document, visual, or curriculum and opening the final render;
completing research whose material claims need traceable primary sources;
delivering a non-trivial diagnosis, evidence-backed decision memo, or executable plan as the requested result;
carrying an approved multi-step operation through its actual target environment.

It should not activate implicitly for simple questions, translation or formatting, open-ended ideation, routine self-contained edits with an obvious direct check, or read-only requests whose sole deliverable is an answer and that do not exercise a target workflow. A plan, diagnosis, or decision document can still be a positive case when that non-trivial artifact is itself the requested result.

Install

Agent Skills installer

Install the canonical Agent Skills package with the portable installer:

npx skills add aiopshwang/goal-to-proof

Choose your agent and installation scope in the prompt. Packaging describes the intended distribution path; consult validation evidence and release notes for the environments actually exercised.

Codex marketplace

codex plugin marketplace add aiopshwang/goal-to-proof
codex plugin add goal-to-proof@goal-to-proof

You can inspect configured sources with codex plugin marketplace list. Codex marketplace packaging follows OpenAI's plugin packaging documentation.

Claude Code marketplace

claude plugin marketplace add aiopshwang/goal-to-proof
claude plugin install goal-to-proof@goal-to-proof

In a Claude Code managed plugin install, the skill is namespaced as /goal-to-proof:goal-to-proof; a standalone Agent Skills install may expose /goal-to-proof. See Anthropic's marketplace and skill documentation.

Invoke

In Codex, invoke it explicitly when you want closure behavior:

Use $goal-to-proof to carry this approved change through the real target and prove it.

The skill may also activate automatically when its description matches a non-trivial closure task. Explicit invocation is useful when the main risk is premature completion.

What changes in practice

Without a closure contract:

“The release was pushed successfully.”

With Goal to Proof:

“The release tag exists on the public remote, the release page is readable without repository credentials, and the published archive contains the expected skill files.”

The second report is stronger only because those observations were actually made. The skill requires precise labels when direct proof is unavailable: verified, partially verified, or not verified.

Design principles

Outcome over artifact: a generated thing is not automatically a usable result.
Claim-shaped proof: test the scope of the claim, not a convenient proxy.
Latest-state evidence: re-check after the final relevant change.
Real boundary when practical: exercise the actual integration, audience, device, account, render, or remote state.
Authority stays with the user: no publication, spending, disclosure, irreversible action, or scope expansion without authorization.
Low ceremony: simple work stays simple; process appears only when it protects closure.
Honest limits: missing access or evidence narrows the completion claim.

Read the full product principles and methodology.

Origin and privacy

The initial behavior model was distilled from aggregate analysis of prior real working sessions. The analysis looked for repeated operating patterns such as intent alignment, scope control, autonomous execution inside approval boundaries, end-to-end verification, durable checkpoints, and evidence-first reporting.

Raw conversations were never included in this repository. Personal names, secrets, one-off preferences, private content, session transcripts, and private corpus metadata were excluded from the published skill. The source material informed the design; it is not a performance benchmark.

Validation and claims

This project separates three different facts:

Package validity: manifests and skill structure satisfy their validators.
Host behavior: a named host can discover, install, and invoke the package in an exercised environment.
Task outcome: an agent using the skill improves closure on a defined evaluation case.

Passing one layer does not prove the next. See Benchmarks & validation for the evaluation contract and scoped evidence. No universal productivity or success-rate claim is made.

Project map

skills/goal-to-proof/          Canonical Agent Skill
.codex-plugin/                 Codex plugin manifest
.agents/plugins/               Codex marketplace catalog
.claude-plugin/                Claude Code plugin and marketplace metadata
evals/                         Behavior cases and evaluation data
tests/                         Package and policy checks
docs/                          GitHub Pages source

The repository root is the plugin root. There is one canonical SKILL.md; platform packages point to it rather than maintaining divergent copies.

Contributing

Issues and focused pull requests are welcome. Behavioral changes should include a case that would fail without the change and should preserve non-trigger behavior for simple work. See CONTRIBUTING.md and the Code of Conduct.

goal-to-proof