菜单
Use when asked to compare or analyze trade-offs between two or more technical solutions, approaches, libraries, or architectures — produces a structured comparison, not just a recommendation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when preparing notes for a 1:1 with a report, drafting written feedback, or summarizing a person's recent work/contributions ahead of a conversation or review cycle.
Use when asked to generate or update architecture diagrams or ER (entity-relationship) diagrams from the codebase — the code is the source of truth, not existing docs.
Use when the user asks how to reduce Claude Code costs, manage token usage, choose the right model for a task, or wants a review of whether a session/workflow is running efficiently.
Use when the user asks for a standup update, daily summary, "what did I work on yesterday", or wants to recap recent commits before a team sync.
Use when investigating a bug, test failure, or unexpected behavior and proposing a fix — always runs investigation in Plan Mode so no code changes happen until the root cause and approach are confirmed.
Use when writing or reviewing code that crosses a trust boundary (user input, external APIs, file/network/DB I/O) — guards against invalid input, injection, unsafe failure modes, and missing validation at the edges without over-defending internal code.
| name | trade-off-analysis |
| description | Use when asked to compare or analyze trade-offs between two or more technical solutions, approaches, libraries, or architectures — produces a structured comparison, not just a recommendation. |
Produces a structured comparison an EM can use in a design discussion or decision doc — not just "I'd pick X".
Make sure the options and the decision criteria are actually clear before analyzing — if the user hasn't stated what matters most (time-to-ship? long-term maintainability? team familiarity? performance?), ask first. An analysis optimized for the wrong criterion is worse than no analysis.
For each option, assess against the same dimensions consistently:
## Option A: <name>
- **Effort to implement:** <estimate + what drives it>
- **Maintenance burden:** <ongoing cost — who owns it, how it ages>
- **Risk:** <what could go wrong, how likely, how bad>
- **Reversibility:** <how hard to undo/migrate away from later>
- **Team fit:** <familiarity, hiring, existing patterns in the codebase>
Be honest about uncertainty — mark assumptions explicitly rather than presenting estimates as facts: "Assuming current traffic patterns hold..."
Close with a recommendation and the condition under which you'd change it: "I'd go with B unless , in which case A is the safer bet."