Menu
Create concise, architectural implementation plans using the RFC-Lite format. STRICTLY LIMITED VERBOSITY.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional 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>