Skip to main content
Goal: write a clear task brief. You can do this lesson without running commands. A good task makes it possible to tell whether the work is finished. “Look over my project” leaves many questions open. “Check whether the greeting file matches this requirement and report the mismatch” gives the reviewer a specific job.

​
1. Say what you want to know

For the practice project, imagine the required greeting is exactly “Hello from PeopleBot.” Your current saved greeting is different. The job is to check that mismatch and explain it.

​
2. Provide the information needed

Use the full commit code shown by Git or the earlier tutorial. A full commit ID identifies the saved version. A path identifies a file within it. You can get the current full code with:
If a reviewer needs a written requirement, make that requirement part of the supplied task material. Do not expect it to know an earlier conversation it has not received.

​
3. Write the brief

Here is a complete example. Replace the bracketed commit instruction with the real full code from your project before using it:
This is a human-readable task brief, not a PeopleBot configuration file. The 0.1.0a3 review adapter still needs the explicit runtime setup and context bindings. Pasting this text alone does not start it.

​
4. Practice judging the answer

A confidently worded answer is not a substitute for checking the cited material. You can verify this example yourself with git show from lesson 2.

​
5. Decide the next task separately

A review and a correction are different jobs. If you want the greeting changed afterward, specify that change and how to verify it. A review request does not automatically authorize edits or publication. For a larger project, use the same pattern: goal, exact inputs, expected result, allowed actions, and stopping point. Keep the first task small enough that you can recognize success. You have completed the beginner path. Continue with project reviews, memory and recovery, or troubleshooting as needed.