Clear answers. Bounded claims.

Goal to Proof is a lightweight closure contract for AI agents. It carries authorized, non-trivial work to an observed outcome and requires direct, scope-matched evidence before completion is claimed. It is distributed as an open Agent Skill and native marketplace packages.

AI agent completion verification means mapping every explicit in-scope requirement to evidence from the latest relevant state. The proof should reach the real target—such as an integration path, audience, rendered artifact, account, device, or public remote—when that boundary is part of the claim. It prevents artifact existence or a proxy check from silently proving something broader.

No. A checklist records completed actions. Goal to Proof asks whether those actions produced the requested result and what observation supports that conclusion. A checklist can be part of the method when each item maps cleanly to outcome evidence.

No. Tests are direct proof when the claim is exactly what they exercise. They may be insufficient for a deployed user path, public release, rendered document, external account state, or research conclusion. The skill chooses proof based on the claim rather than always choosing more tests.

No. A task can be blocked by missing tools, access, information, environment, authority, or an invalid premise. Goal to Proof requires a precise report of what was verified, what remains unverified, why, and the smallest next action. It cannot guarantee model compliance or real-world success.

No. The contract applies to software, research, documents, visual artifacts, demonstrations, operational changes, and other work where completion can be observed. The direct evidence changes by domain: a regression path for a bug, primary sources for current research, a final render for a document, or remote read-back for an external operation.

It should activate for authorized, non-trivial work with dependent steps, a real target boundary, or a meaningful risk of stopping at a plan, partial artifact, isolated component, or proxy check. A non-trivial diagnosis, evidence-backed decision memo, or executable plan can itself be the requested result and still needs appropriate proof.

Simple factual answers, translation or formatting, open-ended ideation, routine self-contained edits with an obvious direct check, and read-only requests whose sole deliverable is an answer and that do not exercise a target workflow should stay proportionate. The key question is not whether the output is a document or plan, but whether the requested deliverable has a non-trivial closure boundary.

No. The user retains goals, values, material choices, authority, risk tolerance, and final decisions. The agent owns method, sequencing, reversible implementation choices, diagnostics, execution, and verification only inside the approved boundary.

Only when the current request already authorizes that exact boundary action and the target is unambiguous. Goal to Proof does not infer permission for publication, deployment, spending, disclosure, irreversible action, or material scope expansion. It also avoids asking twice when the user already granted clear authority.

Repeated approval requests transfer the agent's method and sequencing work back to the user. Once the boundary is clear, the agent should own ordinary, reversible intermediate choices. It pauses for user-owned decisions, missing private information, new authority, or a demonstrated external boundary.

The scope of the evidence matches the scope of the claim. A parser proves syntax, not deployment. A unit test proves the tested behavior, not an unexercised user workflow. A successful push proves data was sent to a remote, not necessarily that an unauthenticated visitor can read the public release.

No. The skill stops at the lowest practical evidence layer that directly proves the requested claim. Extra checks add cost without increasing confidence when a narrower observation already settles the question.

The agent narrows the completion claim. It states what was completed, which layer was observed, what remains unverified, why that evidence is unavailable, and the smallest next action. It must not describe the broader outcome as complete.

A passing check can become stale after another edit, configuration change, publish, or generated artifact. Latest-state evidence reduces the chance that an earlier observation is incorrectly attached to a later result.

Run npx skills add aiopshwang/goal-to-proof and choose a supported agent and scope in the installer. In Codex, explicit invocation is $goal-to-proof. Standalone invocation conventions vary by host.

Add the marketplace with codex plugin marketplace add aiopshwang/goal-to-proof, then install goal-to-proof@goal-to-proof. The repository includes a root-as-plugin catalog and one canonical skill. Check release evidence for host versions actually exercised.

Run claude plugin marketplace add aiopshwang/goal-to-proof and claude plugin install goal-to-proof@goal-to-proof. Managed plugin skills use a namespace, so invoke /goal-to-proof:goal-to-proof. A standalone Agent Skills installation may expose /goal-to-proof.

No. A valid manifest proves package structure. A compatibility claim requires an isolated installation and invocation on a named host and version. Task behavior is another evidence layer beyond installation. The validation page keeps those claims separate.

No. Goal to Proof is an AI-agent completion and verification skill, not a search-ranking product. An agent can use its closure contract to verify an authorized publishing workflow—such as checking canonical URLs, public availability, or a sitemap—but the skill itself makes no ranking claim.

SEO improves how content can be crawled, understood, and surfaced in search. GEO, or generative engine optimization, is a research term for improving visibility in responses synthesized by generative engines. Google's official guidance for generative AI search says established search fundamentals still apply and no special AI schema is required. The original GEO paper studies visibility strategies, but its reported results do not guarantee performance for this website.

It uses descriptive page titles, canonical URLs, crawlable HTML, internal links, a sitemap, direct definitions, natural-language questions and answers, and links to primary sources. Those are transparent content and technical-search practices. They make the project easier to understand; they do not guarantee indexing, citations, or rankings.

No. Goal to Proof does not treat llms.txt as a requirement or proof of AI visibility. Some sites voluntarily publish one as a discovery aid, but Google's guidance does not require a special file or special schema for generative search. This project prioritizes accurate, accessible, crawlable public pages and source-linked claims.

The initial design was distilled from aggregate analysis of prior real working sessions. Repeated operating patterns were abstracted into public instructions, while raw conversations and private corpus metadata were excluded. The source material is design input, not benchmark evidence.

No. Raw conversations, session transcripts, personal names, secrets, private content, and one-off preferences were excluded. The public skill contains generalized behavior rules rather than personal memory.

No telemetry or prompt collection is built into the distributed skill. It is an instruction package that runs inside the host you choose. Your host, package installer, Git provider, and any tools the agent uses have their own data practices; review those separately. See the privacy page.