菜单
Use when requirements are underspecified or the user's stated goal differs from what they actually need. Extracts true intent through one-question-at-a-time dialogue. Critical for the Define phase when users have a vague idea but not a concrete spec.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.
Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when you have a written implementation plan to execute in a separate session with review checkpoints
| name | interview-me |
| description | Use when requirements are underspecified or the user's stated goal differs from what they actually need. Extracts true intent through one-question-at-a-time dialogue. Critical for the Define phase when users have a vague idea but not a concrete spec. |
Users often know what they feel without knowing what they need. This skill extracts what users actually want vs. what they think they should want. It is critical for the Define phase when requirements are underspecified or the user's stated goal differs from the real problem.
Core principle: One question at a time. Let the user think. Don't rush to solutions.
Don't use when:
"Understood — [restate what you heard]. Before I plan or build anything,
I need to understand the problem better. I'll ask a few questions.
If any feel off, tell me — that helps me understand the real issue."
Ask about the problem, not the proposed solution.
❌ "You want me to add a dark mode toggle, right?"
✅ "What's the current experience that needs improving?"
One question. Wait for answer. Then next.
The conversation is done when you can fill this template:
"[User] needs to [action] so that [outcome].
Currently they [existing workaround or pain].
The constraint is [resources, time, technology]."
brainstorming — After interview, when user has a clear goal to explorespec-driven-development — After interview, when user has a clear goal to formalize