---
name: first-loop
description: "Scaffold a Loopmaster task-contract.yaml and pass log for one bounded task loop, then run one checked pass and record the evidence."
category: authoring
requirements:
  - one bounded task with a command-verifiable check
  - repository or working directory where loop artifacts may be written
  - approval before public, destructive, credential, spending, production, or scheduled changes
deploys-template:
backends:
  - agent_kanban
---

# First Loop

Use this skill when a human wants to turn one bounded task into a Loopmaster task loop. Your job is to create durable working state first, run at most one pass unless the human or harness has given a larger budget, and record evidence in the pass log.

This skill uses the K3 artifacts:

- `spec/task-contract-v0.md`
- `spec/task-contract.schema.json`
- `templates/contracts/task-contract.template.yaml`
- `spec/pass-log-format-v0.md`
- `templates/contracts/pass-log.template.md`

## Preconditions

Proceed only when the task can be checked by one command whose exit code is the success rule. If the outcome needs several tasks, a human rubric, or a long plan, stop and suggest a goal contract instead.

Never ask for credential values. Never schedule, publish, spend, delete, change credentials, or mutate production without explicit approval.

## Steps

1. Name the loop in kebab-case from the task, for example `fix-flaky-auth-test`.
2. Copy `templates/contracts/task-contract.template.yaml` to a repo-local contract path and edit every value. In this repo use `loops/contracts/<loop-id>.task-contract.yaml`; in another repo use the closest documented contracts directory.
3. Set `contract_version: "0"`, `layer: task`, the bounded `task`, `check.command`, `budget`, `on_blocked`, and `log` path. The `loop` field must match the filename stem when using `<loop-id>.task-contract.yaml`.
4. Create the pass-log file from `templates/contracts/pass-log.template.md`; keep `Format: spec/pass-log-format-v0.md` and point `Contract:` at the contract.
5. Read the contract back before acting. The check command, budget, blocked rule, and log path are now the source of truth.
6. Run one pass: act on the task, then run `check.command` exactly as written.
7. Append one entry to the pass log using `spec/pass-log-format-v0.md`: state read, did, check, evidence, state written, verdict, next / escalation, autonomy.
8. Stop with one of these verdicts:
   - `done` when the command exits 0 and evidence is recorded.
   - `blocked` when input is needed; include one specific question and evidence so far.
   - `exhausted` when the pass or time budget is spent.
   - `interrupted` when a human or harness stops the run.
   - `continue` only when the contract budget allows another pass and the harness explicitly owns repetition.

## Output

Return a short handoff with:

- contract path
- pass-log path
- check command and result
- verdict
- next step or blocked question

Do not claim the loop is reusable or proven unless the pass log contains real evidence from the check command.