A first Claude session needs a fixed brief, a clean project and a bounded repair budget. The useful deliverable is not a confident transcript: it is a diff whose build and behavior can be inspected.

Empty task list → Add valid title → Save locally → Relaunch and verify
  1. 1Empty task list
  2. 2Add valid title
  3. 3Save locally
  4. 4Relaunch and verify

Work through the example

Ask Claude to preserve the acceptance checks while implementing title validation, completion and persistence. Reject a repair that merely weakens a test.

Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.

Implementation reference

The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.

Plan and implement your own app

Start with a project, an app brief, and trusted executable acceptance checks. Use the demo JSON files as a schema example. Each criterion maps to existing check IDs; screen names map to screenshot-producing checks. Check commands run directly with argument arrays, without a shell, in the project directory. You must author meaningful tests for your intended behavior; a successful process alone cannot establish that an arbitrary brief is satisfied.

node /path/to/ios-agent-skill/mcp-server/dist/unified.js loop init --project /path/to/app --brief BRIEF.md --checks checks.json --attempts 3
node /path/to/ios-agent-skill/mcp-server/dist/unified.js loop resume --project /path/to/app

Without --plan, init asks the installed, authenticated claude CLI for a structured plan. Review .ios-agent/loop/state.json before resuming. Resume runs checks first, sends failing log tails and the plan to Claude, then reruns checks after edits. Repairs are limited to 1–10 attempts, 12 Claude turns per attempt, and a ten-minute timeout per Claude invocation. Each check has its own timeout (maximum 30 minutes). This bounds attempts and time, not monetary cost. Claude subscription/API usage is governed by your own local CLI configuration.

The repair adapter exposes Read, Glob, Grep, Edit and Write; it disables external MCP connections and does not grant shell commands. Your configured acceptance commands run with your local user permissions. Inspect them before running; this workflow is not a security sandbox. List tests, scripts and project settings in protectedFiles so the loop detects changed acceptance files instead of accepting weakened tests. Dependencies must already be installed.

Acceptance and failure review

Checkpoint What to inspect If it does not match
Empty task list Confirm the input and environment Preserve the failure and return to this step
Add valid title Inspect the intermediate artifact Preserve the failure and return to this step
Save locally Run the focused check Preserve the failure and return to this step
Relaunch and verify Record the observed result Preserve the failure and return to this step

Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.

Evidence and limits

A timed Claude to-do app run has not been completed. The Reading List run is a separate reference, not this experiment.

This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.

Inspect the source used in this lesson.

What to do next

Next: Compare the same to-do app task in Codex without changing the acceptance criteria