一键导入
prepare-atomic-changes
Use when a task spans multiple logical changes and the user wants the working tree prepared for review or later commits.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when a task spans multiple logical changes and the user wants the working tree prepared for review or later commits.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when refactoring code to improve testability, separate side effects, remove hidden dependencies, or introduce dependency injection.
Use when the user proposes a technical solution, asks for architectural feedback, asks whether an approach is good, or wants a Staff+/Principal-level engineering review. Do not use for small mechanical edits.
Use when creating a human-facing report, implementation plan, architecture comparison, codebase review, PR review, migration analysis, testability audit, performance investigation, or stakeholder summary where visual structure, diagrams, tables, or collapsible sections make the result easier to review. Do not use for canonical repository documentation, small answers, README files, AGENTS.md, SKILL.md, or files intended for clean git diffs.
Use when writing, updating, or reviewing automated tests. Use for unit tests, behavior changes, regression tests, and testability refactors.
| name | prepare-atomic-changes |
| description | Use when a task spans multiple logical changes and the user wants the working tree prepared for review or later commits. |
Structure changes as if they could be committed independently.
Do not run git commit.
Do not modify history or refs.
Do not create, delete, rename, or switch branches unless explicitly requested.
Separate:
Avoid mixing unrelated concerns.
Prefer small, reviewable changes.
Keep each logical change understandable on its own.
After the work, summarize the suggested commit sequence.
For each suggested commit, provide:
Use clear imperative commit subjects.
Avoid Conventional Commit prefixes unless explicitly requested.
Prefer commit subjects like:
Avoid vague subjects like:
Before finishing, show the current git status.
Do not stage files unless explicitly requested.