/planning-mastery
Create concise, architectural implementation plans using the RFC-Lite format. STRICTLY LIMITED VERBOSITY.
$ npx -y skills add xenitv1/claude-code-maestro --skill planning-mastery --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition โ
- You can call itInvoke it directly when you want it.
- Slash command
/planning-mastery
Context preview
The summary Claude sees to decide when to auto-load this skill.
Create concise, architectural implementation plans using the RFC-Lite format. STRICTLY LIMITED VERBOSITY.
SKILL.md
planning-mastery.SKILL.mdname: 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>
๐ RFC-Lite Planning Protocol
> **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> <philosophy>
๐ฏ CORE PHILOSOPHY
Understanding comes before implementation. A well-designed solution is half-implemented. Never code without a clear design. </philosophy> <template_enforcement>
๐ MANDATORY TEMPLATE (Copy & Fill)
# [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>
โ ZERO TOLERANCE RULES
1. **NO CODE BLOCKS:** Do not write function bodies in the plan. 2. **NO EXPLANATIONS:** Do not teach the user *why* React is good. 3. **NO CONVERSATION:** Do not talk to the user in the plan. 4. **STAY HIGH LEVEL:** "Implement Auth" is better than "Write function login() { ... }". </strict_rules> <audit_and_reference>
๐ COGNITIVE AUDIT CYCLE
1. Does the plan exceed 300 lines? 2. Are all breaking changes identified? 3. Is it RFC-Lite compliant? 4. Are verification steps actionable commands? </audit_and_reference>
Read more
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>
๐ RFC-Lite Planning Protocol
> **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> <philosophy>
๐ฏ CORE PHILOSOPHY
Understanding comes before implementation. A well-designed solution is half-implemented. Never code without a clear design. </philosophy> <template_enforcement>
๐ MANDATORY TEMPLATE (Copy & Fill)
# [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>
โ ZERO TOLERANCE RULES
1. **NO CODE BLOCKS:** Do not write function bodies in the plan. 2. **NO EXPLANATIONS:** Do not teach the user *why* React is good. 3. **NO CONVERSATION:** Do not talk to the user in the plan. 4. **STAY HIGH LEVEL:** "Implement Auth" is better than "Write function login() { ... }". </strict_rules> <audit_and_reference>
๐ COGNITIVE AUDIT CYCLE
1. Does the plan exceed 300 lines? 2. Are all breaking changes identified? 3. Is it RFC-Lite compliant? 4. Are verification steps actionable commands? </audit_and_reference>
Elite-tier orchestration framework for Claude Code CLI. Supercharges AI development through specialized agents, modular skills, intelligent hooks, and persistent memory systems. Author: xenitV1 โข X/Twitter Philosophy: "Why over How.
Repo: xenitv1/claude-code-maestro
Other skills on maestro.
- /backend-design
Elite Tier Backend standards, including Vertical Slice Architecture, Zero Trust Security, and High-Performance API protocols.
Open skill - /brainstorming
Design-first methodology. Explore user intent, requirements and design before implementation. Turn ideas into fully formed specs through collaborative dialogue.
Open skill - /browser-extension
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.
Open skill - /clean-code
The Foundation Skill. LLM Firewall + 2025 Security + Cross-Skill Coordination. Use for ALL code output - prevents hallucinations, enforces security, ensures quality.
Open skill - /debug-mastery
Systematic debugging methodology with 4-phase process, root cause tracing, and elite observability standards. No fixes without investigation.
Open skill - /frontend-design
Elite Tier Web UI standards, including pixel-perfect retro aesthetics, immersive layouts, and UX psychology protocols.
Open skill

