🧪Lesson 05AI Engineer Loopcraft Workshop 2026

Claim one ready issue without changing product files

Pick one ready issue, write a claim, run a dry-run, and prove no product files changed.

A ready issue is not permission to change product files. First, the script checks the issue state, writes one claim event, runs only dry-run or memory mode, and saves a receipt that proves what happened.

Your next move

You already have

Ready, approval-required, and input-required classifications.
Status visibility from Pi, Herdr, Lakebed, and receipts.

Add now

A rule decision for one selected ready issue.
A claim event written before any work attempt.
A dry-run or memory-mode receipt proving productChangedFiles is empty.

Stop before

Editing product files after seeing “ready.”
Calling an LLM API, GitHub API, or any network service.

Tiny dispatch receipt shape

issueId: ISSUE-001
decision: claim allowed — issue is ready and unclaimed
claimEvent: evt-claim-001
mode: dry-run
refusedActions: product edits, network calls
productChangedFiles: []
nextAllowedAction: ask for approval before implementation

Starter prompt

Use one ready issue from the local check. Add rules that say yes/no for the selected issue, write a claim event before any work attempt, run only in dry-run or memory mode, and save a receipt that links the rule decision, claim event, dry-run result, refused actions, productChangedFiles, and next action. Prove productChangedFiles is empty. Do not call an LLM API, GitHub API, or any network service yet.

Build checklist

0/4 done

Choose one ready issue

Use the Lesson 02/03 check output. Do not pick approval-required or input-required work.

Add rules and claim

Only ready issues can be claimed. Approval-required and input-required issues must say no and explain why. Record a claim event before the dry-run can start.

Run dry-run only

Use dry-run or memory mode. The result may describe intended work, not edit product files.

Inspect the trail

Open the events file before and after the claim, then compare the new claim line with the receipt.

Proof to save

Save proof that one ready issue was claimed, the run stayed dry, and no product files changed.

A rule check says whether an issue may be claimed and why.
A claim event is written before any work attempt.
The run stays in dry-run or memory mode and does not change product files.
The receipt links the rule decision, claim event, dry-run result, refused actions, productChangedFiles, and next action.

issueId: ready issue selected
decision: claim allowed / refused plus reason
claimEvent: event id or file offset
mode: dry-run or memory
productChangedFiles: []
receiptPath: saved receipt
nextAllowedAction: decision after dry-run

Done when

One ready issue has a yes/no decision, claim event, dry-run result, saved receipt, and productChangedFiles: [].

Why it matters

Risk reduced: ready work cannot skip the claim and dry-run checks.
Temptation avoided: “just run an agent” before ownership and refusal are proven.
Do not automate yet: product file edits, LLM API calls, GitHub API calls, or any network service.

Try this 🔨

For a candidate issue, say whether it can be claimed, what would be refused, and what evidence you need before real work.

Exploration prompts

Use these when you want to ask an agent for a narrower pass instead of handing it the whole lesson.

Check whether it can be claimed

Given one ready issue, check whether it can actually be claimed. List the rule checks, required claim event fields, refused actions, and the dry-run result.

Threat-model the claim

Review the claim flow. How could duplicate claims, dirty state, missing approval, or stale issue data cause harm? Suggest checks before execution.

Receipt before files change

Draft a receipt that proves the checker stayed in dry-run or memory mode, wrote a claim event, refused unsafe work, and named the next action.