메뉴
Implement a piece of work based on a PRD or set of issues.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Ensures markdown files conform to rumdl linting rules and personal formatting preferences. Use when creating or editing .md files, or when user mentions formatting, linting, or rumdl.
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Reference for writing and editing skills well - the vocabulary and principles that make a skill predictable.
Ensures issue titles conform with a specific style. Use when creating or editing an issue.
Ensures PR (Pull Request) titles conform with a specific style. Use when creating or editing a PR.
SOC 직업 분류 기준
| description | Implement a piece of work based on a PRD or set of issues. |
| disable-model-invocation | true |
| name | implement |
Implement the work described by the user in the PRD or issues.
Use /tdd where possible, at pre-agreed seams.
Run typechecking regularly, single test files regularly, and the full test suite once at the end.
Make implementations on a new branch and create a dedicated pull request if there isn't one, otherwise commit your work to the current branch which should be a feature branch already.
Do not add labels to the pull request, since labels are added to issues already. No need to duplicate. Just make issue labels the single source of truth. The same is true for milestones - do not set the milestone for pull requests.
When writing or editing the PR's description do not duplicate those already existing in the issue. Do not include changes in detail (a short summary is OK), since the code diff reveals all details and is the single source of truth. Keep PR's description concise. Treat it as part of the commit message. Assume that the PR will be squash merged with PR title and description as the commit message.
Once done, use /review to review the work.
