메뉴
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]