Your First Task: Reading and Editing Code

The goal

Walk the whole loop on a real task: add error handling to an existing project.

No “Hello World” demos — those teach nothing.

Setup

Pick a small project of your own (git-backed is better, so you can roll back). Otherwise clone anything:

git clone <your-repo-url> ~/WorkBuddy/demo-project

Set that directory as your workspace.

Task 1: make it read the project first

Don’t start with “edit the code.” Verify it understands the structure, or the edits will land somewhere odd.

Read this project and tell me:

1. What the tech stack is
2. Where the entry point is
3. How data flows (request in → response out)
4. Whether error handling exists today, and where

Use Ask mode — read-only, zero risk.

Acceptance: it names concrete files and functions, not “this is a web application.” If it can’t be specific, your context is too thin — see Context and Files.

Task 2: have it locate specifics

Find every external API call that doesn’t handle request failures. List file names and line numbers.

This should produce a checklist you can eyeball. This is your cheapest moment to intervene.

Task 3: make the change (Agent mode)

For each item above, add error handling:

• 10 second timeout
• retry twice on failure
• on final failure, log it and return a friendly error — never crash
• don’t touch code unrelated to error handling

That last line matters. Without it, you’ll get unsolicited “improvements” and an unreviewable diff.

Task 4: verify

Three things, in order:

1. Read the change list Files touched. Count matches expectations? Anything it shouldn’t have opened?

2. Read the diff Look for deleted logic, unnecessary new dependencies, naming that doesn’t match the project.

3. Run the tests

cd ~/WorkBuddy/demo-project && npm test

Or have it run them and fix failures.

Reusable prompt template

Task: [one sentence]

Context:
- Stack: [xxx]
- Relevant files: [xxx]
- Current problem: [xxx]

Requirements:
1. [requirement]
2. [requirement]
3. Don't change code unrelated to this task

Done means: [how you'll verify]

Three beginner mistakes

1. Task descriptions too short “Optimize this code” — optimized for what? Name the metric.

2. Merging without reading the diff Especially in areas you don’t know well. At minimum scan the key lines.

3. Batching too much into one run “Refactor + tests + docs” means one failure poisons everything. Split it into three verifiable runs.

Next

Context and Files.