القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Ingest a raw source into the project's OKF knowledge bundle — distill it into concept pages, refresh the index, and log the change. keel's compounding "LLM wiki" loop.
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 executing implementation plans with independent tasks in the current session
Orchestrates the implement-feature, evaluator, fix-runner loop for the active feature until all Criterios de Aceitacao are met and quality gates are green.
Use after the plan is approved to break the active feature's plan into a concrete task checklist, written into specs/<feature>/tasks.md from the tasks template.
Use while implementing a feature that has retries, queues, background jobs, external calls, or any critical path an on-call engineer will need to reason about in production. Invoke when adding a new endpoint, dependency, or async flow, and before considering such a feature done — instrumentation is developed alongside the code, like tests, not bolted on after.
| 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 Critérios de Aceitação 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.
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..specify/templates/checklist-template.md and walk every item (Testes, Quality Gates, Documentação, 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).