The surprising thing we learned building an agent-friendly planning skill
We thought a planning skill should contain the best advice: how to estimate, how to risk-manage, how to sequence work. That was wrong in practice. What made the skill reliably usable by an agent was discipline — strict, repeatable structure applied to every task.
What we tried
We shipped a planning skill that read like a human playbook: long explanations, examples, flexible guidance. Agents ignored the nuance. They mis-assigned work. They merged tasks. Deadlines drifted.
So we rebuilt it. Four times.
Each rewrite removed prose and added concrete rules. We turned vague checklist items into fields the agent could always find: a single owner, a done-criterion, an explicit duration window. We limited every task to a 2–8 hour sizing. Anything bigger had to be broken until it fit.
What happened — the moment it clicked
On the third rewrite an agent still combined two tasks into one. On the fourth rewrite we enforced three things on each task: one owner, a verifiable done-criterion, and a 2–8 hour expected size. The next run produced a plan with no merged tasks. The agent consistently left tasks intact and assigned them to a single owner.
The turning point was simple: structure made the agent’s decision space small and repeatable. When each task is a discrete unit with a clear completion test, the agent stops improvising. It follows the fields.
The rule that fell out
Every task must be 2–8 hours, have one owner, and a clear done-criterion. Break anything larger than a week. Treat estimates as data fields an agent can read, not prose an agent might ignore.
Three concrete findings from building and testing the skill
1) Task sizing discipline matters. When every task is 2–8 hours the agent assigns work granularly and dependencies resolve predictably. This was enforced in the skill and observed repeatedly during runs.
2) Multiple, explicit estimation methods improve fit. The skill includes three built-in methods: three-point estimation (Expected = (Optimistic + 4×Likely + Pessimistic) / 6), t-shirt sizes that map ranges from under 2 hours to a week, and Fibonacci planning poker for teams. In trials, the agent respected whichever method was present in the task fields and produced coherent total timelines.
3) Buffers and risk tables prevent false precision. The skill forces a 20–30% buffer and a risk table for each plan with impact, probability and mitigation. Plans where the buffer or risks were missing repeatedly underpredicted review time or missed known failure modes. Adding these fields reduced surprise in manual follow-up and made the agent’s output defensible.
Worked example included with the skill
The skill ships with a worked example: a six-week website redesign for a designer and two developers, roughly 210 hours total. It contains milestone tables, phase-by-phase task breakdowns and a computed critical path. That example is not decorative — agents used it as a schema template and reproduced its structure in new plans.
A fair counter-example — the honest limit
This is a planning procedure, not a scheduler. It front-loads structure: define success, identify deliverables, break down tasks, map dependencies, estimate with buffer, then assign and track. The skill does the front half. It does not, and was never designed to, track actual progress or replan as reality drifts. When a real project slipped we had to hand off to people or separate tools to record daily progress and rework estimates. Expect a sturdy plan, not a live timeline manager.
How we proved the method works
We compared two sets of runs: one where plans were prose-rich and permissive, and one where every task included the required fields and sizing. The prose-heavy plans showed merged tasks and ambiguous ownership in the agent’s output. The disciplined plans produced discrete tasks, clear owners, and consistent use of the three estimation methods. The worked example served as a template; agents replicated its structure when given a new project with similar hooks.
When to reach for this skill
Use it when the work involves roadmaps, work breakdown, milestone planning, or when you need an agent to produce an actionable plan you can hand to a team. The skill is MIT-licensed, authored by the awesome-llm-apps project, and packaged in our library as a runnable skill file you can load into an agent.
How we write skills now
Structure beats prose. We learned that by rebuilding a single skill four times before agents stopped misreading it. Now every library skill is organized as discrete fields and minimal prose. Agents prefer fields. People can read them. Both win.
FAQ
Can the skill reschedule work if priorities change?
No. It creates a structured plan and expectations. It does not run continuous progress tracking or automated replanning. You can export its plan into a scheduler or use human review cycles to re-estimate and reassign.
Which estimation method should I pick?
Pick the one your team uses. The skill supports three-point estimation with Expected = (Optimistic + 4×Likely + Pessimistic) / 6, t-shirt sizing for quick single-person tasks, and Fibonacci planning poker for team estimates. The important part is storing the estimate in the plan fields so the agent can use it.
How strict is the 2–8 hour rule?
Strict for agent usability: every task should map into that window. Anything expected to take longer than a week must be broken down. This forces clarity about deliverables and makes ownership and verification simple for the agent and the team.
How we know
The conclusions come from our work packaging the project-planner skill (six-step process, forcing buffer and risk tables, three estimation methods, and the six-week worked example) and from rebuilding a skill four times until agents stopped misinterpreting structure. The planning fields and behaviors described are the runnable behavior of the packaged MIT-licensed skill from the awesome-llm-apps project, which we host in our library.
Sources: the project-planner skill file (planning steps, estimation formulas, buffer and risk requirements, example), and our documented rebuild experience. The file is MIT-licensed and available in the members’ library.
Leave a Reply