Menu
Use this skill to perform a code review. This should be done every time a task involving new feature development is completed
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use this skill when writing tests that need to exercise the system as whole. Also known as end to end tests.
Use this skill when writing Elixir context functions that involve multi-step operations, external API calls, or database operations. Covers using `with` statements, proper error handling, and organizing code in Phoenix contexts.
This skill describes how to use the Elixir test runner
Use this skill when writing tests for code that interacts with external APIs, third-party services, or LLMs. Covers the behaviour/fake module pattern with configurable implementations.
Use this skill at the beginning and end of a coding session in a Sprite VM. At session start, it checks out main and pulls latest. At session end, it ensures tests pass, commits on a branch, and creates a PR. Invoke this skill when the user starts a session, says they're done, wants to wrap up, or asks to create a PR for their work.
Use this skill when working on any new feature. It enforces a strict test-driven development workflow where tests are written before implementation code.
| name | code-review |
| description | Use this skill to perform a code review. This should be done every time a task involving new feature development is completed |
When you finish writing the code and running all the tests, here are some things to consider:
Above all else, the code should, in the words of Kent Beck, clearly communicate it's intent. When you read it, it should as easy as possible to understand what it does.
For every new or modified public function in the diff:
Find the corresponding test file
Verify there is at least one test that calls that function directly (not just as a side-effect of testing something else)
If a context module gained new public functions, those functions need their own describe block with direct tests
How are the tests? Too many? Not enough? Do the tests actually test the feature or is there so much mocking the tests are meaningless
Always evaluate whether acceptance/e2e tests are needed. Ask:
If ANY of these are true, invoke the acceptance-testing skill to write Playwright browser tests.
Existing browser tests are in test/waylo_web/features/*_browser_test.exs. Review these to see patterns and ensure the new feature has appropriate coverage.
mix test and npm run test --prefix assets)