菜单
Implement a piece of work based on a PRD or set of issues.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
| 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.
