Menu
Explore several design solutions for a task and compare their trade-offs without implementing anything. Use when the user wants to weigh approaches before committing, asks to "explore options", "compare designs", or "what are my options" for a change.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Diagnose and fix a failing SonarQube quality gate on the current branch's merge request — resolves the project + PR, reads the failing conditions, then fixes new violations and coverage gaps. Use when the user says "fix the sonarqube gate", "the sonar quality gate is failing", or after a pipeline reports a red SonarQube check.
Generate conventional commit with staged changes
Review a merge request for security, performance, architecture, style, and improvements
Research a task and write a phased plan to .plan/<slug>.md without implementing it. Use when the user wants to plan a feature or change before building, asks to "make a plan", or when a task is large enough to design before touching code. Replaces built-in plan mode.
Implement a piece of work based on a spec or set of tickets.
Create unpublished inline DRAFT review comments on a GitLab merge request diff via the GitLab API. Use when a code review has produced findings that should be attached to exact diff lines as drafts (not published) so the human can review and submit them in one batch. Carries a ready-to-post dataset for Phoenix MR !145 (View360 view-based rework).
| name | explore |
| description | Explore several design solutions for a task and compare their trade-offs without implementing anything. Use when the user wants to weigh approaches before committing, asks to "explore options", "compare designs", or "what are my options" for a change. |
Lay out the viable ways to solve the task and compare them. You are exploring, not building — no code changes, no plan file.
Read the request and the code it touches. State the goal, constraints, and what "good" means in one paragraph. If scope or acceptance is unclear, ask — don't assume.
Identify 2–4 genuinely distinct approaches (not variations of one). For each, ground it in the real code it would touch (path:line). Drop any option that doesn't actually fit the constraints.
For each option give: how it works (2–3 lines), main trade-offs (complexity, blast radius, deps, reversibility), and when it's the right pick.
Name the option you'd choose and why, in one paragraph. Do not implement.
