agent-contract-first

name	agent-contract-first
description	Use only before implementation to define the minimum contract for an agent project: endpoint or interface, tool contract, input and output shapes, state flow, error handling, and assumptions. Not for abstract architecture design.

Agent Contract First

Source Lineage

Primary inherited sources:

• legacy/ecc-source/agents/architect.md
• legacy/ecc-source/skills/agent-harness-construction/SKILL.md
• legacy/ecc-source/skills/api-design/SKILL.md
• legacy/ecc-source/skills/backend-patterns/SKILL.md
• legacy/ecc-source/skills/security-review/SKILL.md

Inherited methods:

• keep tool names and entry points explicit
• make inputs schema-first and narrow
• return deterministic output shapes
• define error paths with stop conditions
• validate user input and secrets at the boundary

When To Use

Use this after archetype selection and before touching business logic.

Expected Outputs

• one minimal contract document
• request and response shapes
• tool input and output rules, if tools exist
• state transitions or flow notes
• error cases worth handling in the MVP
• explicit assumptions

Contract Checklist

• What entrypoint exists?
• What input fields are required?
• What output shape is stable enough for tests?
• What state is read, written, or ignored?
• What errors should return cleanly?
• What assumptions keep the implementation small?

Contract Rules

• Keep one inbound interface unless the prompt clearly needs more.
• Prefer one stable success shape and one stable error shape.
• For tool-using tasks, define fixed tool names, tool input, tool output, and failure behavior.
• For retrieval tasks, define how sources or citations appear in the output.
• For workflow tasks, define step status and the stop condition on failure.
• For gateway tasks, define upstream boundary, normalization rules, and auth or allowlist checks.

Security At The Boundary

Apply the compressed ECC security checklist here:

• validate all external input
• avoid hardcoded secrets
• use safe query patterns
• do not leak sensitive error details
• note auth requirements explicitly if the endpoint is protected

Default Bias

• keep one inbound interface
• keep one stable response shape
• keep state explicit and small
• normalize outputs early
• document missing pieces instead of inventing a full abstraction layer

What Not To Do

• do not invent a generalized SDK
• do not define contracts for features outside the MVP
• do not add schema complexity that the prompt does not need
• do not postpone the error contract until after implementation