菜单
REST/HTTP API contract lens over a feature's changed endpoints — read-only. Appended to review-and-simplify's lens registry by the api-review pack. Also usable standalone.
用 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 | api-contract |
| description | REST/HTTP API contract lens over a feature's changed endpoints — read-only. Appended to review-and-simplify's lens registry by the api-review pack. Also usable standalone. |
When: dispatched by review-and-simplify as one of its parallel lenses, on the feature's diff, in projects where the api-review pack is installed. Also usable standalone for a focused API-design pass.
Scope: the changed API surface only — controllers/handlers/routes/DTOs in the feature's tree-snapshot diff (git diff BASE_TREE HEAD_TREE, per subagent-driven-development's no-commit-rule snapshotting) or, if no snapshots exist, the working tree diff. Never the whole repo. If the diff touches no HTTP surface, report "no API-contract-relevant changes" and stop — do not manufacture findings.
Output: findings by severity (Critical/Important/Minor) with file:line, reported inline. Makes NO edits.
Judge the contract the changed endpoints expose — not internal implementation (that is code-review's and perf-review's territory). Flag only what the diff introduces or regresses.
200 on a create that should be 201, 200 with an empty body where 204 fits, 200 masking an error, 404 vs 403 leaking existence, non-4xx on client error. A mutation that always returns 200 regardless of outcome is a finding.class-validator/schema) — untrusted input reaching logic unchecked. Cross-reference security-review for injection; here the concern is the contract (is the shape declared and enforced?).GET with side effects, POST for a pure read); non-idempotent PUT/DELETE; action verbs baked into paths where a resource noun belongs; inconsistent pluralization/casing versus sibling routes.Weigh contract risk realistically: a public mutation returning the wrong status or accepting unvalidated input is Critical/Important; a casing nit on a brand-new internal route is Minor. Do not restate what an OpenAPI/schema gate already enforces mechanically — this lens is for the judgment those cannot make (is this the right status? is the error envelope consistent with the rest of the API?).
Next: findings return to review-and-simplify, which aggregates them with the other lenses; Critical/Important must be fixed before the pre-commit gate.