home / skills / simhacker / moollm / planning

planning skill

safe

/skills/planning

This skill helps break down large goals into actionable steps and track living plans that adapt as you learn.

npx playbooks add skill simhacker/moollm --skill planning

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

Files (7)

SKILL.md

3.1 KB

---
name: planning
description: "Structured task decomposition and tracking."
license: MIT
tier: 1
allowed-tools:
  - read_file
  - write_file
related: [play-learn-lift, scratchpad, plan-then-execute, action-queue, sister-script, debugging, session-log]
tags: [moollm, decomposition, tracking, tasks, strategy]
---

# Planning

> *Structured task decomposition and tracking.*

Turn complex goals into actionable steps.

> [!TIP]
> **Plans here are living documents.** Unlike [plan-then-execute](../plan-then-execute/), these evolve as you learn.

---

## What This Is

A flexible planning system for:
- Breaking down large tasks
- Tracking progress
- Adapting as you learn
- Documenting decisions

**Unlike [plan-then-execute/](../plan-then-execute/)**: Plans here are **living documents** that evolve.

---

## Structure

```yaml
# PLAN.yml
plan:
  goal: "Implement authentication system"
  status: in_progress
  
  tasks:
    - id: 1
      name: "Design auth flow"
      status: done
      
    - id: 2
      name: "Implement login endpoint"
      status: in_progress
      subtasks:
        - "Create route handler"
        - "Add validation"
        - "Write tests"
        
    - id: 3
      name: "Add session management"
      status: blocked
      blocked_by: 2
```

---

## Key Difference from plan-then-execute

| Planning | Plan-Then-Execute |
|----------|-------------------|
| Plans evolve | Plans are frozen |
| Flexible | Auditable |
| For exploration | For security |
| Adapts to findings | Requires approval gate |

Use **planning/** when you need to adapt.
Use **plan-then-execute/** when you need control.

---

## Contents

| File | Purpose |
|------|---------|
| [SKILL.md](./SKILL.md) | Full protocol documentation |
| [PLAN.yml.tmpl](./PLAN.yml.tmpl) | Plan template |
| [PROGRESS.md.tmpl](./PROGRESS.md.tmpl) | Progress template |

---

## The Intertwingularity

Planning is [play-learn-lift](../play-learn-lift/) applied to task decomposition.

```mermaid
graph LR
    PL[🗂️ planning] -->|LEARN stage of| PLL[🎮📚🚀 play-learn-lift]
    PL -->|frozen variant| PTE[📋 plan-then-execute]
    PL -->|thinking in| SP[📝 scratchpad]
    PL -->|logs to| SL[📜 session-log]
```

---

## Dovetails With

### Sister Skills
| Skill | Relationship |
|-------|--------------|
| [plan-then-execute/](../plan-then-execute/) | Frozen, auditable plans |
| [play-learn-lift/](../play-learn-lift/) | Planning IS LEARN stage |
| [scratchpad/](../scratchpad/) | For freeform thinking |
| [session-log/](../session-log/) | Track planning progress |
| [roberts-rules/](../roberts-rules/) | **Structured deliberation** for planning decisions |
| [adversarial-committee/](../adversarial-committee/) | Multiple perspectives on plan viability |

### Protocol Symbols
| Symbol | Link |
|--------|------|
| `PLAY-LEARN-LIFT` | [PROTOCOLS.yml](../../PROTOCOLS.yml#PLAY-LEARN-LIFT) |

### Navigation
| Direction | Destination |
|-----------|-------------|
| ⬆️ Up | [skills/](../) |
| ⬆️⬆️ Root | [Project Root](../../) |
| 📋 Sister | [plan-then-execute/](../plan-then-execute/) |
| 🎮 Sister | [play-learn-lift/](../play-learn-lift/) |

Overview

This skill provides a lightweight, structured system for decomposing complex goals into actionable tasks and tracking progress. Plans are treated as living documents that evolve as you learn, enabling adaptation and continuous refinement. It emphasizes traceable decisions and simple status flow for tasks and subtasks.

How this skill works

You declare a goal and break it into tasks with statuses, dependencies, and optional subtasks. The system tracks progress, blocked items, and relationships (e.g., blocked_by) so you can prioritize work and remove impediments. Plans are updated iteratively: you revise tasks, add findings, and record decisions as new information arrives.

When to use it

When a large goal needs to be broken into manageable, testable steps
When requirements will change and the plan must adapt
When you need a concise record of decisions and current impediments
When you want lightweight tracking without heavy approval gates
During exploratory or learning phases of a project

Best practices

Keep each task focused and small enough to complete in a single work session
Mark statuses explicitly (e.g., todo, in_progress, done, blocked) and record blockers with links to dependent tasks
Treat the plan as a living document—update it when assumptions change or new risks appear
Use subtasks for implementation detail and keep the top-level list goal-oriented
Log decisions and experiment outcomes adjacent to task entries so context is preserved

Example use cases

Design and implement an authentication system, tracking design, endpoints, and session work as discrete tasks
Onboard a new feature: decompose discovery, prototyping, implementation, and rollout into iterative tasks
Investigate a performance issue: create investigative tasks, experiments, and follow-up fixes that update as findings appear
Coordinate a small team on a release, showing blocked tasks and dependencies to unblock work

FAQ

How is this different from a frozen plan workflow?

This approach treats plans as evolving artifacts you update as you learn, whereas frozen-plan workflows lock the plan for auditability and require approval gates before changes.

What minimal fields should each task have?

At minimum, give each task an id, name, and status. Optionally include subtasks, blocked_by references, and short notes on decisions or assumptions.