goal-contract-writer

Original：🇺🇸 English

Translated

Use when the user asks to define a goal, create a Goal Contract, or clarify a concrete task's goal, scope, success criteria, evidence, or guardrails before planning or execution.

4installs

Sourcemax0max/goal-driven

Added on2026-05-23

NPX Install

npx skill4agent add max0max/goal-driven goal-contract-writer

SKILL.md Content

View Translation Comparison →

Goal Contract Writer

Overview

goal-contract-writer

turns ambiguous work into a standard Goal Contract.

Clarify only what is required to define the work. Then return the canonical contract. Conversation is not the product.

This skill does not implement, run, or manage a Goal-Driven agent loop. It defines the upstream contract that a loop, workflow engine, host goal system, or human operator can execute and verify.

goal-contract-writer

is the only normal user-facing entrypoint. The paired

goal-contract-verifier

skill exists for runtimes or operators that need fresh-subagent verification of execution state, but verifier behavior is not part of this skill's required output.

When to Use

Use this skill when:

the request has a concrete outcome but starts ambiguous
the next agent, system, or person needs a stable goal artifact
success must be judged by observable evidence

Do not use it for open-ended ideation or as a replacement for execution workflows.

Core Output

Produce exactly one canonical artifact:

```
Goal Contract
```

Goal Contract

must contain exactly these fields:

```
goal
```
```
scope
```
```
success_criteria
```
```
evidence
```
```
guardrails
```

Do not add runtime verdicts, adapter metadata, or workflow prose to the contract body.

Use

references/canonical-goal-contract.md

for the canonical contract schema.

Contract Generation Flow

Clarify until
```
goal
```
and
```
scope
```
can be written without guesswork.
Write
```
success_criteria
```
that fully cover the
```
goal
```
and can be checked without subjective judgment.
Write matching
```
evidence
```
that proves or disproves each criterion without adding hidden acceptance rules.
Record
```
guardrails
```
that prevent scope drift, unsafe assumptions, or missing approvals.
Return the canonical Goal Contract and stop.

Use

references/contract-elicitation-protocol.md

for clarification rules and

examples/

for concrete model contracts.

Hard Rules

Do not replace the contract with free-form advice or host-specific prose.
Do not use subjective completion language.
Do not add verifier workflow, execution routing, owners, priorities, or next steps to the canonical contract.
Do not let
```
evidence
```
smuggle in acceptance rules that are missing from
```
success_criteria
```
.
Do not let any adapter redefine the canonical contract fields.
Do not continue into planning or execution unless the user explicitly starts a separate task.
Keep the contract execution-neutral.

Downstream Consumption

Downstream systems consume the contract after this skill defines it.

A host-native goal system may use it as durable input.
A workflow system may use it for planning, execution, verification, or review.
A specification system may use it for persistent spec or task assets.
A human operator may execute directly from it.
Adapter-specific routing, ownership, runtime state, or verifier artifacts belong outside the canonical contract.
Runtimes or operators may invoke the paired
```
goal-contract-verifier
```
to verify execution state, but that verification flow does not change what
```
goal-contract-writer
```
returns.

Use

references/downstream-adapters.md

for adapter rules and examples.

References

```
references/canonical-goal-contract.md
```

references/contract-elicitation-protocol.md

```
references/evidence-patterns.md
```
```
references/downstream-adapters.md
```
```
examples/README.md
```

Resource Use

Keep the canonical schema and pattern references in
```
references/
```
.
Keep complete before-and-after examples in
```
examples/
```
.
Keep interface metadata in
```
agents/
```
.