planning

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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.

From CodeAndCanvasLabs/Daemora, AGPL-3.0.

More from CodeAndCanvasLabs/Daemora