The source corpus
The initial analysis covered prior real task conversations rather than synthetic benchmark prompts. Private corpus contents, counts, and session metadata are not published. The source material informed the design; it does not measure skill quality or establish a success rate.
The analysis asked which operating patterns remained stable across different kinds of work. Recurring themes included understanding the actual requested result, using current evidence when facts could change, separating now/later/out-of-scope work, acting autonomously inside an approved boundary, completing meaningful end-to-end slices, verifying the actual target environment, preserving durable checkpoints, and reporting evidence precisely.
Distillation process
- Separate signal from biography. Behavior that depended on a specific person, project, tool, or temporary preference was removed.
- Find repeatable failure modes. The analysis focused on where work looked complete but failed at the requested boundary: plan instead of change, component instead of integration, local artifact instead of public state, or proxy instead of outcome.
- Assign authority deliberately. Goals, values, material choices, and boundary actions stayed with the user. Method, execution, diagnostics, and verification inside the boundary became the agent's responsibility.
- Reduce to a closure contract. Broad owner philosophy, product discovery, and full software-development methodology were removed from the core. The retained model became Result, Target, Proof, and Boundaries.
- Design positive and negative activation cases. Non-trivial diagnoses, evidence-backed decisions, and executable plans can be final deliverables; simple answers, translation, formatting, open-ended ideation, obvious self-contained edits, and read-only answers with no target workflow should not acquire a heavy workflow.
- Make proof claim-shaped. Completion evidence must match the scope of the claim, come after the latest relevant change, and exercise the real target boundary when practical.
Why a closure contract?
Many agent frameworks improve reasoning, planning, or software-development technique. Those can be valuable, but they solve a broader job. Goal to Proof targets a smaller gap: an agent can follow a good plan and still stop before the requested outcome is observed.
A closure contract creates a practical invariant:
Result, Target, Proof, Boundaries
| Field | Question | Failure it prevents |
|---|---|---|
| Result | What must be different? | Delivering a convenient artifact instead of the requested change. |
| Target | Who or what must use or observe it? | Validating an isolated component while ignoring the real environment. |
| Proof | What direct observation distinguishes success? | Treating artifact existence or a proxy check as outcome evidence. |
| Boundaries | What is authorized, excluded, or user-owned? | Expanding scope or taking an external action without authority. |
The proof ladder
Evidence commonly progresses through five layers: artifact inspection, focused checks, integrated execution, target observation, and outcome evidence. Higher is not automatically better. The right stopping point is the lowest practical layer that directly proves the user's claim.
For example, a syntax check may fully prove that a configuration file parses. It does not prove that the deployed service uses that configuration. A remote read-back may prove that a release is public. It does not prove that users achieved a business outcome unless that was part of the request and evidence exists.
Low ceremony by design
The skill does not require a visible worksheet for every task. If result, target, proof, and boundaries are obvious, the agent can act and verify directly. Planning, root-cause analysis, research, subagents, and checkpoints are used only when they reduce a real risk.
This is also why activation boundaries matter. A short factual answer should remain a short factual answer. A non-trivial executable plan can use the closure contract when the plan itself is the result, but the agent should not infer permission to implement beyond that deliverable.
Standards and primary references
The canonical package follows the open Agent Skills specification. Codex packaging follows OpenAI's official plugin documentation, while Claude Code packaging follows Anthropic's plugin marketplace and skills documentation.
The public website uses conventional crawlable HTML, descriptive titles, canonical URLs, internal links, and source-linked explanations. Google describes optimization for generative AI search as an extension of established search practices and states that no special AI schema is required; see Google Search Central's generative AI guide. The term “GEO” was formalized in the research paper Generative Engine Optimization. Neither source supports a guaranteed ranking claim for this project.
Limitations
- A limited source corpus may encode selection bias even after personal details are removed.
- Instruction quality does not guarantee model compliance, tool access, or task success.
- Host packaging can change; validation evidence must name the host, version, and exercised path.
- Behavior evaluations are sensitive to model, environment, permissions, and task wording.
- The project does not claim universal productivity gains or a general completion percentage.
How the method can evolve
Changes should be driven by reproducible failure cases. A proposed instruction needs both a positive case and an adjacent negative case, plus evidence that it improves closure without broadening authority or adding ceremony to simple work. Release-specific evidence belongs in versioned evaluation artifacts and release notes.