planning

name	planning
description	Produce structured executable plans from a user goal — any domain. Make sure to use this skill whenever the user (or another agent) needs a plan, strategy, roadmap, or breakdown of how a multi-step task will be done — even if the word "plan" isn't used. Pairs with the task-decomposition skill.
triggers	["plan","strategy","roadmap","breakdown","step by step","phases","how would you","what's the approach"]
requires_tools	[]
version	1.0.0
enabled	true

Planning

Turn a goal into an executable plan. Never execute from this skill — hand the plan back for the caller to run.

When to apply

Whenever the work is multi-step, multi-day, or coordinated across multiple owners (crews, sub-agents, MCP servers, the main agent itself). Skip planning for a single-action task.

What every plan contains

# Plan: <one-line goal>

## Goal & success criteria
- Observable definition of done
- 2–3 falsifiable checks

## Assumptions & prerequisites
- Crews / skills / MCP servers / integrations / API keys needed
- Open questions for the user

## Phases
1. <Phase name — 1-line outcome>
   - Owner: <crew | sub-agent | MCP server | main agent>
   - Tool(s) / skill(s): <names from the live inventory>
   - Steps: <numbered, concrete>
   - Output: <artifact / record / message>
   - Cadence: <one-shot | recurring with cron expression>

## Schedule (cron, if any)
| name | cron | runs |
|---|---|---|

## Risks & mitigations
- Likely failure modes + how the plan reacts

## Approval gate
Reply 'go' to start. Reply 'tweak <part>' to revise.

Skip sections that don't apply. Don't pad.

How to think

Map to real names

Every owner / tool / skill / server you reference must already exist in the running daemora install. Look them up first. If something isn't there, list it as a prerequisite the user must add.

Outcome cuts, not activity cuts

A phase = a thing you can point at when done. Phase names with verbs ("research", "build", "optimize") rarely produce evidence; phase names with outcomes do.

Schedule with commitment

If the work is recurring, write the cron expression. "Daily" alone is not a schedule.

Surface unknowns honestly

If the goal as stated doesn't give you enough to commit, list the gaps in Open questions rather than guessing.

Right-size

A small plan that ships beats a long plan that doesn't. Cut every line that doesn't change a decision.

Stay generic

Plans should work for any domain — code, content, research, ops, monitoring, comms, infrastructure, anything. Don't infer a domain from a few keywords; mirror the user's vocabulary.

When a plan already exists

If the caller hands you a structured plan, validate, don't regenerate. Confirm every owner/tool/skill/server is real, prerequisites are met, cron expressions parse, success checks are observable. Return one of:

• "Executable as-written. Confirm prerequisites:" + checklist
• "Gaps:" + specific items + a fix per gap

Guardrails

• Reference secrets by vault key name only; never paste values.
• Stay inside the user's stated scope.
• Refuse illegal / deceptive / mass-spam asks in one sentence.