Guided exercises

Learn by making
one small change.

Four short exercises with a clear result, a way to check it, and recovery steps. Use a disposable folder or practice repository.

1. Explain a repository, without editing

Time: About 5 minutes. You need: A practice repository with a README, attached to a browser session or opened locally.

Read the README and list the project files. Explain the purpose of each in plain English. Define unfamiliar terms. Do not edit, install dependencies, commit, push, or deploy. End with three facts you verified and anything still unknown.

Expected result: A short, evidence-based project tour with file references.

• Open two files it cited and compare the explanation with their contents.
• Confirm there are no changed files in the diff.
• Ask one follow-up about a term you do not understand.

If it goes wrong: Stop the task and ask which evidence supports the claim. If files changed unexpectedly, inspect the diff before deciding how to restore them.

2. Improve a README on a practice branch

Time: About 10 minutes. You need: Your practice repository and a separate branch. Follow GitHub basics if branches are new.

Inspect the README. Propose a short “What this project does” section using only facts in this repository. List any unanswered questions. Do not edit until I approve the wording. Do not commit, push, merge, or deploy.

Review the proposal, then explicitly ask for that README edit.

Expected result: One small documentation diff. Check that no unsupported feature claims were added and no unrelated files changed. If desired, explicitly authorize a commit and a practice pull request, then inspect its Files changed tab.

Recovery: Keep the PR unmerged while learning. Closing an unmerged practice PR leaves the target branch unchanged. For local edits, inspect the diff and restore only the exercise’s changes; do not discard someone else’s work.

3. Build a tiny page and check it

Time: About 15–20 minutes. You need: An empty practice folder or repository.

Plan a single index.html page called “My practice page” with an About paragraph and a button that shows “Hello, learner!” when clicked. Use plain HTML, CSS, and JavaScript in that file. Include a visible keyboard focus style. No packages, accounts, external requests, or deployment. Explain how I can open and verify it. Stop for approval before writing the file.

After approving the plan, request implementation.

Expected result: A page with the heading, paragraph, and functioning button. Open the file locally, or use your environment’s supported preview. A cloud task does not automatically copy the file to your computer.

• Click the button and confirm the message appears.
• Use Tab to focus it, then Enter or Space to activate it.
• Try a narrow window and check for clipped text.
• Read the code and ask Claude to explain the event handler.

Recovery: Keep an original copy before the next exercise. If the result is confusing, ask for a smaller explanation or restart in a new disposable folder.

4. Diagnose an intentional bug

Time: About 10 minutes. You need: A copy of the working page from exercise 3.

In the copied file, change the button’s id attribute without changing the JavaScript selector that refers to it. Open the copy and confirm the button fails.

The practice button no longer works. Expected: activating it shows the greeting. Actual: nothing happens. Inspect the HTML and JavaScript, explain the cause, and propose the smallest repair. Do not edit until I approve. After approval, verify mouse and keyboard activation and report exactly what you tested.

Expected result: Claude identifies the mismatched selector. After approval, the button works again without a redesign.

Recovery: Compare with your untouched working copy. Restore the original button ID or selector in the copied exercise file. Keep the original so you can retry.

Official references: Best practices ↗ · GitHub Hello World ↗ · Getting started with Git ↗ · Checkpoints ↗