design-child-contract

Name: design-child-contract
Availability: InStock
Author: Siarhei

Compares alternative contract shapes and writes the chosen direction into CONTRACT_DECISION.md.

2|Updated Apr 29, 2026

Search Tags:#workflow #planning #api design #design documentation #contract design #task packet #interface decision

Ready to run

npx skills add https://github.com/siarhei-belavus/agent-public --skill design-child-contract-siarhei-belavus

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: design-child-contract
Source: https://github.com/siarhei-belavus/agent-public/tree/main/skills/atelier-workflow/design-child-contract
Command: npx skills add https://github.com/siarhei-belavus/agent-public --skill design-child-contract-siarhei-belavus

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a child task packet owns an ambiguous API, config, storage, hook, or module contract, planning stalls or drifts. This Skill forces an explicit, documented contract decision before planning begins. ## Core Features & Use Cases - Contract Shape Comparison: Generates 2-3 materially different contract shapes and compares them on simplicity, coupling, flexibility, validation fit, and misuse risk. - Decision Recording: Writes the chosen direction, rejected alternatives, and rationale into CONTRACT_DECISION.md, then updates the child INDEX.md to the contract_decided phase. - Use Case: A child packet needs a storage interface but the brief leaves the shape open. Use this Skill to evaluate candidate interfaces, pick one, and record the decision so downstream planning works from a single canonical contract vocabulary. ## Quick Start Use the design-child-contract skill to resolve the ambiguous storage contract in this child packet and write the decision to CONTRACT_DECISION.md.

Frequently Asked Questions about design-child-contract

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I document an API contract decision before planning?▼

Generate 2-3 materially different contract shapes, compare them on simplicity, coupling, flexibility, validation fit, and misuse risk, then write the chosen direction with rejected alternatives into CONTRACT_DECISION.md. Update the child INDEX.md to the contract_decided phase afterward.

When should I use a contract decision step in a task packet workflow?▼

Use it only when the child owns an ambiguous API, config, storage, hook, or module contract. If the packet already has a clear contract surface, skip it to avoid contract churn.

What criteria should I use to compare interface design alternatives?▼

Compare candidate shapes on simplicity, coupling, flexibility, validation fit, and misuse risk. Choose one direction explicitly and record the rationale so downstream planning uses a single canonical vocabulary.

Should old contract alternatives stay in the packet after a decision?▼

No. Write the chosen contract as the current local design decision and remove competing contract vocabularies from the canonical child packet. Rejected alternatives belong only in CONTRACT_DECISION.md as rationale.

What are the limitations of a contract decision skill?▼

It does not write implementation code and should not run when the contract surface is already clear. It only produces a documented decision artifact, not executable interfaces or validation logic.