loop-contractlisted

# Create (or revise) a Product Contract for a loop You are defining a **contract-based autonomous loop**. The skill argument is the task instruction (or starts with `revise:` — see below). Your output is a complete loop definition the human will approve: `.loop/docs/product-contract.md` (fixed requirements) + `loop.config.sh` (stop conditions the external evaluator enforces). Guiding principle: **implementation steps stay flexible; success conditions stay explicit.** A good contract says WHAT must be true when the loop stops, never HOW to build it. File layout, component split, naming, internal architecture are the loop's freedom — do not pin them here. If the argument starts with `revise:`: read the existing contract and config, ask the user what should change, apply it, then jump to Step 5. If the argument starts with `auto:`: you are running HEADLESSLY — there is no user to ask. Skip Step 2 entirely: make conservative default decisions yourself, and record every decision a human would normally be asked about in a section `## Assumptions (auto mode)` inside the contract (scope boundaries chosen, non-goals assumed, denied/escalate paths picked, budget defaults). Prefer inferring verification commands from manifests/CI config over running them; if a command was not actually executed, note it as unverified in the assumptions. The acceptance-gate classification stays mandatory on this path: classify every VERIFY_COMMAND red→green vs stays-green from what Step 1 actually obs