| 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.mdlegacy/ecc-source/skills/agent-harness-construction/SKILL.mdlegacy/ecc-source/skills/api-design/SKILL.mdlegacy/ecc-source/skills/backend-patterns/SKILL.mdlegacy/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
