القائمة
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."