القائمة
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]