메뉴
Use this skill to perform a code review. This should be done every time a task involving new feature development is completed
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
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.
SOC 직업 분류 기준
| 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)