🧪Lesson 07AI Engineer Loopcraft Workshop 2026

Ask for review without handing over the repo

Ask a small reviewer for help without letting another agent edit the app files.

A reviewer is useful when your main script decides what to ask, writes the input file, saves the review note, and waits for you before changing anything. It is dangerous when it becomes a second implementation path. This lesson keeps the reviewer read-only until you approve what happens next.

Your next move

You already have

One selected issue, local state, dry-run discipline, and productChangedFiles checks.
A reason to ask for help without creating a second implementation path.

Add now

A role contract that says what the reviewer may read, produce, and refuse.
One reviewer input file built from issue state and acceptance criteria.
One review note and receipt that keep productChangedFiles empty.

Stop before

Making implementer the default helper role.
Letting the reviewer edit product files or roam the repo without a bounded question.

Tiny review receipt shape

issueId: ISSUE-001
role: reviewer
inputPath: reviews/ISSUE-001-input.md
outputPath: reviews/ISSUE-001-review.md
productChangedFiles: []
decisionNeeded: approve, reject, or ask for more
nextAllowedAction: human decides before implementation

Starter prompt

Add one read-only reviewer path controlled by the main script. Create a small input file from the issue and acceptance criteria, run or fake the reviewer, save its output, and write a receipt that links the issue, input file, output file, productChangedFiles, and next decision. By default, the reviewer must not edit product files.

Build checklist

0/4 done

Pick one role

Use scout or reviewer first. Do not add implementer as the default role.

Generate an input file

Create a small file from issue state, relevant files, constraints, and acceptance criteria.

Run or fake read-only help

Save the review output under a predictable path. Do not let it edit product files.

Review before action

Compare the review output to the issue and record what you can approve, reject, or ask next.

Proof to save

Save proof that the reviewer got a bounded input file, produced a review note, and did not edit product files.

A role contract says what the reviewer may read, produce, and refuse.
An input file is generated from issue state and acceptance criteria.
The reviewer run or saved fake output writes a review note, not product changes.
A receipt links issue id, input file path, review output path, model/tool used, productChangedFiles, and next decision.

issueId: issue reviewed
role: scout or reviewer
inputPath: reviewer input file saved
outputPath: review output saved
productChangedFiles: []
decisionNeeded: approve / reject / ask more
nextAllowedAction: what may happen after review

Done when

One review note exists, links to one issue and input file, and the receipt shows productChangedFiles: [].

Why it matters

Risk reduced: review output cannot silently become a second implementation path.
Temptation avoided: handing the repo to another agent because review feels helpful.
Do not automate yet: default implementer roles, product file edits, or automatic follow-up work.

Try this 🔨

Classify a request as scout, reviewer, implementer, or do-not-run, then explain why.

Exploration prompts

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

Shape the input file

Choose one issue and build a read-only reviewer input file: role, question, files to inspect, acceptance criteria, output path, and stop rules. Do not let the reviewer edit product files.

Review the output

Inspect a review note and compare it to the issue acceptance criteria. Summarize useful evidence, unsupported claims, and what you would do next.

Classify the role

For this request, decide whether the helper should be a scout, reviewer, implementer, or no-run. Explain the choice and the risk you are avoiding.