菜单
Ensures problem-first framing before solutioning. Use when defining work, discussing features, handling requests that sound like solutions, or when someone says "we should add" or "let's build".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Ensures tech-stack-aware behavior during workflows. Auto-activates when stack profile rules exist in .claude/rules/stack-*.md. Activates during /arch:init, /context:load, /context:refresh, /deliver, /discern, /diagnose, and /handoff.
Enforces code quality standards when writing or editing code. Use when implementing features, fixing bugs, or refactoring. Ensures error handling, no hardcoded values, proper patterns, and security considerations.
Enforces project patterns and architecture conventions. Use when designing systems, implementing features, or reviewing code structure. Ensures consistency with established patterns.
Structured root cause investigation when tests fail unexpectedly or fixes don't resolve the issue. Use when a test fails that you expected to pass, when a previous fix attempt didn't work, or when an error occurs during implementation.
Enforces test-driven development with Red-Green-Refactor cycle. Use when writing new code, implementing features, fixing bugs, or when tests are mentioned. Ensures tests are written before implementation.
Ensures brand-consistent behavior during workflows. Auto-activates when brand guide exists and "brand", "brand spec", "design tokens", "brand consistent", or "visual identity" are mentioned. Activates during /brand, /brand:image, /brand:tokens, /design, /deliver, /discern, /handoff, /context:load, and /context:refresh.
| name | problem-first |
| description | Ensures problem-first framing before solutioning. Use when defining work, discussing features, handling requests that sound like solutions, or when someone says "we should add" or "let's build". |
| allowed-tools | Read, Glob, Grep |
Reframe solution-loaded requests as problems before proceeding.
"What is true?" before "What should we do?"
| Input Pattern | Response |
|---|---|
| "We should add caching" | "What performance problems are users experiencing?" |
| "Let's build a dashboard" | "What decisions do users need to make? What data do they need?" |
| "Add a button for X" | "What task are users trying to accomplish?" |
| "We need microservices" | "What scaling or development problems are we facing?" |
When the request involves users, apply Jobs-to-be-Done:
"When [situation], [user] wants to [motivation] so they can [outcome]."
Example:
When reframing, structure as:
## Original Request
[What was asked]
## Reframed Problem
[Problem-focused version]
## Assumptions to Validate
- [Assumption 1]
- [Assumption 2]
## Questions to Answer
- [Question 1]
- [Question 2]
## Suggested Next Step
[Discovery, clarification, or proceed if problem is clear]