メニュー
Use after implement-and-evaluate confirms acceptance criteria and gates are green, for a final pre-merge review against the constitution and the checklist template.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/CaioWF/keel --skill code-reviewコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Use when designing the structure of a feature or module (in the plan phase, or when refactoring) to apply language-agnostic engineering principles — Clean Architecture, SOLID, testing strategy, and tactical DDD. Container of guides; each concept is a companion.
Use when implementation is complete, gates pass, and you need to decide how to integrate the work — presents structured options (merge, PR, keep, discard) and handles the chosen workflow, including worktree cleanup. Closes the SDD cycle after review-and-simplify.
Use when PAUSING/ending a session (writes the current state to docs/STATE.md to resume later) or when RESUMING (reads docs/STATE.md and the active spec, recomposes context, and proposes the next step). Maintains continuity across human and agent sessions.
SOC 職業分類に基づく
SKILL.md を表示中
| name | code-review |
| description | Use after implement-and-evaluate confirms acceptance criteria and gates are green, for a final pre-merge review against the constitution and the checklist template. |
This is one lens orchestrated by review-and-simplify (dispatched in parallel alongside security-review as part of the mandatory pre-commit step) — it is also usable standalone for an ad-hoc review.
When: implement-and-evaluate has finished — all tasks.md boxes checked, all Acceptance Criteria passing, gates green — and the feature is otherwise ready to propose for commit.
Template: .specify/templates/checklist-template.md.
Output: the checklist filled out against the actual diff, reported inline (and optionally saved alongside the feature's specs if the user wants a persistent record) — plus a list of any findings that must be fixed before merge.
A finding may only block the merge if you can quote the rule it breaks — a line of the constitution, an AC-N from the spec, a checklist item, or a gate that actually fails. Everything else is a suggestion: report it, label it as such, and let the author decide.
This is what keeps review anchored to the project's agreed rules instead of the reviewer's taste, and it gives the author something concrete to argue with — a quoted rule can be discussed, changed, or shown not to apply; "I'd have written this differently" cannot. If you believe a rule is missing, say so and propose it for the constitution; do not enforce it retroactively as if it were already there.
Steps:
.specify/state (fallback: newest dir under specs/)..specify/memory/constitution.md (principles, code patterns, SDD process) and hold the diff against it — flag any violation of a stated principle or code pattern. Cite the rule that was broken: quote the constitution text (or the spec's AC-N) verbatim, with its section heading, next to the finding..specify/templates/checklist-template.md and walk every item (Tests, Quality Gates, Documentation, Code Review, Deploy) against the actual state of the repo — do not assume an item is satisfied just because gates passed; verify (e.g. check for stray console.log/debug statements, confirm spec.md reflects the final implementation).Next: human review and approval, then commit (proposed by you, executed only after explicit approval).