The project
Apply one Android skill to a scoped improvement, then produce a reviewed patch with before-and-after verification.
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 Android skills add
Understand domain guidance for coding agents. Apply the module decision to this project. Your checkpoint: You can explain why a selected skill applies to the specific change.
2. Discovery and installation
Build a reproducible skill setup. Apply the module decision to this project. Your checkpoint: A teammate can reproduce the same setup and understand its prerequisites.
3. Preparing repository context
Give the agent the constraints it needs to make a focused change. Apply the module decision to this project. Your checkpoint: The agent has a concrete acceptance condition and a known baseline.
4. Executing and reviewing a skill workflow
Keep implementation choices tied to the project. Apply the module decision to this project. Your checkpoint: Every modified file has a clear relationship to the requested outcome.
5. Verifying behavior on Android
Use more than a successful code-generation message as evidence. Apply the module decision to this project. Your checkpoint: Your evidence demonstrates behavior rather than merely successful generation.
6. Maintaining a reliable skills workflow
Turn a one-off success into a repeatable team practice. Apply the module decision to this project. Your checkpoint: The workflow can detect when a skill stops helping the project.
Acceptance criteria
- Record the selected skill and why it applies
- Review every modified file for scope and correctness
- Demonstrate a meaningful build or test result, including limitations
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.