القائمة
Create concise, architectural implementation plans using the RFC-Lite format. STRICTLY LIMITED VERBOSITY.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when you need to act as an Elite Software Architect (Maestro) to manage complex repositories. It enforces a "Why over How" philosophy, maintains a persistent project memory (Brain), and orchestrates specialized sub-skills through a Plan-Act-Verify lifecycle.
Elite Tier Backend standards, including Vertical Slice Architecture, Zero Trust Security, and High-Performance API protocols.
Design-first methodology. Explore user intent, requirements and design before implementation. Turn ideas into fully formed specs through collaborative dialogue.
Master specialized skill for building 2025/2026-grade browser extensions. Deep expertise in Manifest v3, Service Worker persistence (Alarms, Offscreen API), Side Panel API, and Cross-Browser compatibility.
The Foundation Skill. LLM Firewall + 2025 Security + Cross-Skill Coordination. Use for ALL code output - prevents hallucinations, enforces security, ensures quality.
Systematic debugging methodology with 4-phase process, root cause tracing, and elite observability standards. No fixes without investigation.
| name | planning-mastery |
| description | Create concise, architectural implementation plans using the RFC-Lite format. STRICTLY LIMITED VERBOSITY. |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash |
<domain_overview>
The 300-Line Limit: If your plan exceeds 300 lines, YOU HAVE FAILED. Rule: Code belongs in files, not plans. Do not write pseudo-code. Do not paste entire file contents. Focus: Define What (Files), How (Logic Strategy), and Success (Verification).
DEPENDENCY FORECASTING MANDATE (CRITICAL): Never propose a change without mapping its "Blast Radius". AI-generated plans frequently fail by ignoring downstream effects on coupled modules. Before defining file changes, you MUST explicitly identify which existing features or tests might break. If a change requires "Shotgun Surgery" (modifying more than 5 files for one feature), you MUST pause and propose an architectural abstraction instead. </domain_overview>
Understanding comes before implementation. A well-designed solution is half-implemented. Never code without a clear design. <template_enforcement>
# [Task/Feature Name] - Implementation Plan
## 1. 🎯 Objective
[1-2 sentences strictly defining the goal.]
## 2. 🏗️ Tech Strategy
- **Pattern:** [e.g. Composition vs Inheritance]
- **State:** [e.g. Global Store vs Local Hook]
- **Constraints:** [e.g. "Must use LCH colors", "No external libs"]
## 3. 📂 File Changes
| Action | File Path | Brief Purpose |
|:-------|:----------|:--------------|
| [NEW] | `src/components/MyComp.tsx` | Visual shell |
| [MOD] | `src/App.tsx` | Routing integration |
## 4. 👣 Execution Sequence
1. **Scaffold:** Create component files with types (No logic yet).
2. **Logic:** Implement `useLogic.ts` hook with TDD.
3. **Visuals:** Apply LCH gradients & Glassmorphism.
4. **Connect:** Wire up to parent component.
## 5. ✅ Verification Standards
- [ ] **Visual:** Check against `frontend_reference.md` (no flat colors).
- [ ] **Interaction:** Verify `scale(0.97)` tap effect.
- [ ] **Console:** Zero errors during flow.
</template_enforcement> <strict_rules>