Plan

Skill: pageship-plan

A plan tells the reader where the work is going, what is decided, which steps to take in what order, what is still open and what it leaves out. The reader acts on it, so every commitment keeps the strength, order and wording its author gave it. The plan is the author’s plan made easier to follow, never a bigger one.

Your agent picks a plan when the reader wants to know what will happen next and who does it, such as an implementation plan, a rollout or a migration.

What the reader gets

The parts come in this order:

1. Title and goal. The plan’s name, then the goal and the main decisions in the source’s words, with the date and author when the source gives them.
2. Decisions. What the source says is decided or agreed, with who decided and when.
3. Steps. An ordered list, or a table when most steps share fields such as owner, date and dependency. When dependencies branch or join, a diagram may sit beside the list, never in place of it.
4. Assumptions. What the source takes as true without checking.
5. Open questions. What the source doesn’t know, and every gap a reader would need closed to act.
6. Out of scope. What the source says the plan won’t do.

What the skill works from

The agent first takes an inventory of the source: every goal, decision, assumption, step, owner, date, dependency, question, exclusion, supporting fact and hedge.

Then it keeps each item as strong as the source made it:

• A hedged action, such as “if there’s time”, stays in the plan with its hedge beside it.
• An offer, such as “I can take the export”, stays an offer. It doesn’t make that person the owner.
• Steps keep the source’s order and numbers. When the source has no numbers, the agent numbers them and tells you so.
• A step shows a dependency only when the source states one, and a date only when the source gives one, at the source’s precision. “In spring” stays “in spring”.

A timeline, progress bar, status badge or priority appears only when the source gives the facts behind it. Without them, the plan is plain lists and tables.

Patterns it often uses

• Tables for steps that share owner, date and dependency fields.
• Diagrams for dependencies that branch or join.

Example request

Turn my notes in migration-notes.md into a plan for moving billing to the new queue.
Keep my open questions as they are.