菜单
Record a place where the code forced a deviation from the agreed plan. Use mid-implementation whenever reality contradicts the plan, or when the user says "log this deviation". The log feeds future planning and the merge quiz.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Pre-merge comprehension gate that quizzes the USER on the riskiest parts of the branch diff. Use before merging or opening a PR, or when the user says "merge quiz", "am I ready to merge", or "quiz me on this diff".
Build a throwaway interactive prototype to validate one unresolved interaction or behavior before writing production code. Use when the user explicitly asks to "mock it up first" or "prototype this", or when competing UI behaviors need a disposable hands-on comparison.
Comprehension gate before porting, copying, or adapting an existing implementation. Proves understanding of the reference code before any new code is written. Use when the task is "port X", "copy how Y does it", "adapt Z", or reimplementing existing behavior.
Lifecycle orchestrator for the unknowns plugin. Detects the current phase of work (pre-implementation, mid-implementation, pre-merge) and routes to the right technique skill. Use when the user says "/unknowns", "know my unknowns", or is unsure which unknowns skill applies.
Read-only reconnaissance pass over an unfamiliar codebase, system, or feature area to surface hidden risks before any code is written. Use when starting work in unfamiliar territory, before a risky change, or when the user says "blindspot pass", "what am I missing", or "scan for risks".
| name | log-deviation |
| description | Record a place where the code forced a deviation from the agreed plan. Use mid-implementation whenever reality contradicts the plan, or when the user says "log this deviation". The log feeds future planning and the merge quiz. |
| version | 1.0.0 |
| author | Hien Dinh |
| license | MIT |
The plan said one thing; the code demanded another. Record it while it's fresh — these entries are the highest-value input to the next plan.
docs/deviations/YYYY-MM-DD-<task-slug>.md at the repo root
(create docs/deviations/ if needed). <task-slug> = short kebab-case name
of the current task. Slugs are minted freely, so two sessions will name the
same task differently: before creating a new file, list what already exists
in docs/deviations/ and reuse the slug of any file that is plausibly this
task — appending to it even if it's from an earlier day/session — rather than
minting a near-duplicate.## <YYYY-MM-DD HH:MM> — <one-line summary>
- **Plan said:** <what the plan/spec assumed>
- **Code forced:** <what was actually done instead>
- **Why:** <the real-world constraint that made the plan wrong>
- **Ripple:** <other plan steps this invalidates, or "none">
The heading carries the full date: the file spans days by design, and HH:MM
alone goes ambiguous on the second session.
Not every deviation is caught live. When work reveals that plans or docs already disagree with the shipped code (a stale roadmap item, a doc promising a design the code abandoned), log it with the same fields plus one more:
- **Found while:** <the current activity that surfaced it>
Date the heading with the discovery time; if the deviation's original date is known, name it in Code forced.