菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
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).
基于 SOC 职业分类
| 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.
