The project
Create a reusable Android review skill with instructions, a reference file, a bounded check script and positive and negative activation tests.
Prerequisites
Complete the six teaching modules and their exercises. Keep the design notes and failure cases: they form the starting evidence for this project.
Build in increments
1. What an agent skill is
Distinguish reusable expertise from tools and model training. Apply the module decision to this project. Your checkpoint: You can explain why the skill exists separately from the tools it uses.
2. Writing the skill entry point
Make the main instructions actionable and easy to follow. Apply the module decision to this project. Your checkpoint: Another engineer can predict the workflow from the entry point alone.
3. References, templates and scripts
Keep specialized detail available without loading everything at once. Apply the module decision to this project. Your checkpoint: Supporting files have clear ownership and observable behavior.
4. Trust and permission boundaries
Prevent a reusable workflow from becoming an unrestricted instruction bundle. Apply the module decision to this project. Your checkpoint: The skill does not expand authority merely because a reference file requests it.
5. Testing activation and outcomes
Evaluate whether the skill improves real engineering work. Apply the module decision to this project. Your checkpoint: You can identify a skill revision that makes performance worse.
6. Packaging and team maintenance
Make the skill understandable and maintainable by someone else. Apply the module decision to this project. Your checkpoint: The package works without undocumented local state.
Acceptance criteria
- The skill activates for intended tasks and stays out of unrelated work
- Scripts report failures without hiding exit codes
- Generated changes follow project conventions and include evidence
Evidence to submit
- A repository or reproducible design artifact with setup instructions and tested tool versions.
- A diagram showing components, data flow, authority and failure boundaries.
- An evaluation table with inputs, expected results, actual results and explanations of failures.
- A demonstration of the normal path and at least two relevant failure paths.
- A short decision record covering alternatives, known limitations and the next improvement.
Review rubric
| Dimension | Ready to demonstrate | Revisit when |
|---|---|---|
| Understanding | Explain each boundary and why it exists | You can only repeat framework terminology |
| Implementation | Reproduce the core behavior from a clean setup | Hidden local state is required |
| Reliability | Show bounded failures and useful recovery | The demo only works on the happy path |
| Evidence | Present observed outcomes and limitations | Success is inferred from a generated answer |
| Ownership | Modify a requirement and explain the consequences | You cannot adapt the implementation independently |
Do not treat a completed reading checklist as proof of project readiness. Revisit any module whose checkpoint you cannot demonstrate.