메뉴
Review a change set for entropy: naming drift, pattern duplication and contagion, error-model and state-model splits, doc staleness. Consistency and drift only, not correctness. Invoke explicitly or via routing from review.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | entropy-review |
| description | Review a change set for entropy: naming drift, pattern duplication and contagion, error-model and state-model splits, doc staleness. Consistency and drift only, not correctness. Invoke explicitly or via routing from review. |
| invocation_posture | manual-first |
| version | 0.2.2 |
Review code changes for entropy introduction — naming drift, error-model fragmentation, dependency-direction violations, documentation staleness, state-model splits, and pattern duplication. This skill focuses on consistency and drift, not correctness or security.
For general code review (correctness, security, performance), use review.
For full-repo entropy scanning, use repo-entropy-audit.
For control-plane infrastructure audit, use control-plane-auditor.
reviewrepo-entropy-auditcontrol-plane-auditorproject-documentationThis skill's effectiveness depends on constraint information in the target repository's instruction files (AGENTS.md, CLAUDE.md, etc.). Before starting, check for:
If these are missing or thin, note this in the report under "Constraint Gaps" and suggest running control-plane-auditor to establish them first. Proceed with what is available — even without formal constraints, structural consistency can be assessed against surrounding code patterns.
Detect what to review:
git diff --cached --name-onlygit diff --name-onlygit diff <base>...<head> --name-onlyFor each affected module/directory:
openspec/glossary.md exists, treat it as the canonical domain glossary (the convention maintained by grill-with-docs); AGENTS.md-level constraints supplement itFor each changed file, read enough surrounding code to understand the local patterns:
Check the change set against eight dimensions. Use the Entropy Checklist for detailed detection guidance.
Compare new identifiers against:
Flag: new variants of existing concepts, mixed casing styles, non-canonical names.
Compare new error handling against:
Flag: new envelope shapes, ad-hoc error codes, silent error swallowing, inconsistent boundary behavior.
Compare new imports against:
Flag: layer violations, bypassed adapters, business logic in util/common.
Check:
Flag: behavioral changes without doc updates, stale instruction file references.
Check:
Flag: shadow state definitions, undocumented state values, inconsistent transitions.
Check:
Flag: reimplemented logic, copied deprecated patterns.
Check whether the change replicates a suboptimal, deprecated, or flagged pattern that future agents may treat as the project standard. The core test is not "is this duplicated?" but "if an agent sees this merged and copies it N more times, is that acceptable?"
Flag: new code modeled on a @deprecated/LEGACY/HACK template, or a weak pattern likely to replicate with no enforcement brake. See the Entropy Checklist.
Check whether the behavioral change can be verified by an agent without human help — via tests, a smoke check, or an observable outcome.
Flag: behavior verifiable only in production, changed routes with no integration/contract test, or config/environment-dependent behavior with no local check. See the Entropy Checklist.
Grades are harm-based, not dimension-coded: any of the eight dimensions can yield any grade. A naming change is E0 when it forks the glossary's canonical term, but E2 when it is a one-off local inconsistency. Grade by the harm the change does, then name the dimension in the finding.
| Level | Name | Meaning | Gate |
|---|---|---|---|
| E0 | Standard Conflict | Direct conflict or fork with an established project standard (error model, state definition, glossary term, dependency rule) | Fails the entropy verdict |
| E1 | Divergent Pattern | Introduces a new divergent pattern with high replication risk | Fix before merge |
| E2 | Localized Inconsistency | Local inconsistency that does not fork a standard | Fix or accept with a note |
| E3 | Doc/Metadata Desync | Documentation or metadata out of sync with the changed behavior | Note |
| — | Suggestion | Not a problem, but could improve consistency | — |
For each finding, tag the grade, name the dimension, cite the location, and give a fix direction. One worked example per grade:
**[E0] Error-model fork** — `apps/api/src/orders/handler.ts:88`
New handler returns `{ error: string }` instead of the project's standard
`{ code, message, details }` envelope (AGENTS.md → Error Model).
→ Fix before merge: return the standard envelope. E0 fails the entropy verdict.
**[E1] Naming Drift** — `apps/api/src/auth/handler.ts:42`
New identifier `fetchUserProfile` uses "User" instead of glossary term "Member".
Surrounding code uses `getMember*` pattern; likely to be copied by later code.
→ Consider: rename to `fetchMemberProfile` before merge.
**[E2] Localized inconsistency** — `apps/api/src/reports/util.ts:15`
Uses `snake_case` keys in a module that is otherwise `camelCase`; no standard is
forked and the impact stays local.
→ Fix or accept with a note: align to `camelCase`.
**[E3] Doc desync** — `apps/api/src/auth/handler.ts:42`
The endpoint signature changed but its API doc still lists the old parameter.
→ Note: update the API doc to match the new signature.
Grade the change by its highest-severity finding, using the tiers distinctly:
To fold these E-grades into a P0/P1/P2/Note cross-review, use the Severity Crosswalk in risk-adaptive-cross-review's references/finding-contract.md (E0 → P1, or P0 if it breaks a selected risk-pack invariant; E1 → P2; E2 → P2; E3 → Note).
If prerequisite constraints were missing, list them at the end:
## Constraint Gaps
The following constraint dimensions are not defined in this repository's
instruction files. Adding them would make future entropy reviews more effective:
- [ ] Glossary (no canonical terms defined)
- [ ] Error Model (no standard envelope documented)
→ Run `control-plane-auditor` to get a full gap analysis and improvement plan.
For each E0 or E1 finding:
For E2 and E3 findings:
Do not offer to apply fixes automatically — this skill is read-only. If the user wants fixes applied, they can use the normal implementation workflow.
review for correctness.Create GitHub issues from PRDs, requirements, or feature descriptions, choosing between a single issue and an epic plus sub-issues using gh CLI labels and dependencies.
对一个已有的 plan、design 或任何待定决策/想法做对抗式压测（不限软件）：沿决策树逐个分支追问，直到与用户达成共同理解。 一次只问一个问题，每个问题都给出你的推荐答案；事实能从环境（codebase、文档、数据）查到的就去查，决策必须交给用户拍板。 触发词："grill me"、"拷问我"、"压测这个计划"、"挑战我的设计"、"stress-test the plan"， 或用户希望在动手前把计划/设计的每个决策点逼到清晰。 不用于开放式头脑风暴、方向选型，或已经明确、无歧义的任务。
grill-me 的领域增强变体：在对抗式压测计划/设计的同时，对齐项目术语、用具体场景探边界、 与代码交叉核对，并把术语 inline 沉淀到 openspec/glossary.md、把够格的长期决策落到 docs/adr/。 触发词："grill with docs"、"对着领域模型压测"、"对齐术语"、"stress-test against the domain"， 或用户希望在压测计划的同时统一项目语言、沉淀长期决策。 不用于不需要术语/决策沉淀的轻量压测（用 grill-me），也不用于纯需求澄清（用 clarify）。
基于“深模块”哲学寻找架构改进点：扫描 codebase，对照 openspec/glossary.md 的领域术语与 docs/adr/ 的决策， 找出 shallow modules 并提出 deepening 重构（把浅模块变深，提升 testability 与 AI 可导航性）， 产出可视化 HTML 评审，再进入 grill 对话逐个落地；落定的 deepening 可经 gh-create-issue / stage-change-pipeline 变成可追踪工作项。 触发词："improve architecture"、"找重构机会"、"合并紧耦合模块"、"让代码更可测"、"架构评审"、"把重构拆成 issue"。 不用于纯需求澄清（用 clarify）或纯方向选型（用 future-aware-architecture）。
本仓库 skills 的路由器——按你当前的处境指路：该用哪个 skill、走哪条流、下一步交给谁。手动调用（/ask-danker），模型不会自动触发。
把当前会话压缩成一份交接文档（handoff.md），让新会话或另一个 agent 无缝接续工作。 适用：上下文将满要开新会话、任务干到一半换 agent/换机器、issue 工作流跨会话续跑。 手动调用（/handoff），可带参数说明下个会话的重点。模型不会自动触发。