playbooks

home / skills / xenitv1 / claude-code-maestro / planning-mastery

planning-mastery skill

/skills/planning-mastery

This skill generates a concise RFC-Lite implementation plan for planning-mastery, outlining what files, how logic, and verification within strict 300-line

npx playbooks add skill xenitv1/claude-code-maestro --skill planning-mastery

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.7 KB
---
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)
```markdown
# [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>

Overview

This skill creates concise architectural implementation plans using the RFC-Lite format with strict verbosity limits. It enforces a 300-line cap, dependency blast-radius mapping, and a mandatory RFC-Lite template. Plans prioritize file-level changes, logic strategy, and actionable verification criteria.

How this skill works

It inspects a requested feature or task and produces a filled RFC-Lite plan that lists objective, tech strategy, file-level actions, execution sequence, and verification standards. Before proposing file edits it enumerates existing modules, tests, and features that might break and recommends abstractions if changes require modifying more than five files. The output is high-level, avoids code, and is formatted for immediate handoff to engineers and reviewers.

When to use it

  • Designing a new feature that needs a small, reviewable implementation plan
  • Refactoring a component where downstream impact must be assessed
  • Preparing handoff documentation for engineers or contractors
  • Triaging proposed changes that might require broad codebase edits
  • Creating acceptance criteria and verification steps for QA

Best practices

  • Always run the dependency forecast step and list blast-radius candidates
  • Keep plans under 300 lines; split large work into separate RFC-Lite plans
  • List file actions as NEW, MOD, or DEL with concise purpose statements
  • Prefer architectural abstraction if a change touches more than five files
  • Provide clear, actionable verification checks (pass/fail style)

Example use cases

  • Add a feature toggle for a payment method and list affected backend and frontend files
  • Introduce a new reusable UI component with a migration path for existing uses
  • Refactor auth middleware and map affected routes, tests, and services
  • Bundle a backend endpoint change with data-migration steps and test updates
  • Define integration test scope and exact files to update for a performance fix

FAQ

What happens if a plan exceeds 300 lines?

The plan must be split: create smaller RFC-Lite plans or propose an architectural abstraction to reduce scope.

How do you handle widespread coupled changes?

Identify blast-radius items, mark them in the plan, and recommend an abstraction when shotgun surgery (>5 files) is required.

Can I include code snippets or pseudo-code?

No. Plans must stay high-level; code belongs in files and tests, not in the plan.