القائمة
Explore multiple approaches before committing — read context, surface tradeoffs, then decide. Use when user wants to compare options, design an API, or says 'brainstorm'.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
Browser-test handoff via a profile-aware file bus between this dev session and a `claude --chrome` session. Use after frontend work is locally testable or on /chrome-test.
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
A relentless interview to sharpen a plan or design.
| name | brainstorming |
| description | Explore multiple approaches before committing — read context, surface tradeoffs, then decide. Use when user wants to compare options, design an API, or says 'brainstorm'. |
| group | process |
Use when the problem has multiple valid solutions and the choice has long-term consequences: API design, data model, architecture, technology selection.
Before generating options, read:
Produce at least three meaningfully distinct approaches. For each:
Do not evaluate yet. Generate first. If one option is clearly dominant, still generate alternatives — the exercise surfaces the tradeoffs you'd otherwise miss.
If a key technical assumption is unproven, include a spike option: a throwaway implementation to test the risky assumption before committing to a direction.
Filter against the project's real constraints:
Remove options that violate hard constraints. Do not remove options just because they're unfamiliar or non-obvious.
Pick one option. State:
Present the recommendation. Do not begin implementation until the user agrees.
