菜单
Performance lens over a feature's changed code — read-only. Appended to review-and-simplify's lens registry by the ui-review pack. Also usable standalone.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
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 | perf-review |
| description | Performance lens over a feature's changed code — read-only. Appended to review-and-simplify's lens registry by the ui-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 ui-review pack is installed. Also usable standalone for a focused performance pass.
Scope: the changed code only — 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 has no plausible performance surface, report "no perf-relevant changes" and stop — do not manufacture findings.
Output: findings by severity (Critical/Important/Minor) with file:line, reported inline. Makes NO edits.
Flag real, likely-hot regressions the changed code introduces — not micro-optimizations with no measurable impact. Premature optimization is itself a finding-worthy smell; call it out rather than rewarding it.
Weigh cost against likelihood and hotness: an N+1 on a per-request endpoint is Critical; a redundant .map over a 3-element constant is not a finding. Do not duplicate what a bundler/profiler gate already measures — this lens is for the judgment those tools don't make (is this path actually hot? does this abstraction earn its cost?).
When a finding needs a concrete threshold (Core Web Vitals target, bundle size, p95, font/image tactic), cite performance-budgets.md (sibling companion) rather than inventing a number — it carries the numeric budgets and remediation tactics this lens references.
Next: findings return to review-and-simplify, which aggregates them with the other lenses; Critical/Important must be fixed before the pre-commit gate.
