In working with agents, I’ve come to find that planning skills have an outsized impact on results.
Skills are additional context that gives the agent a little extra direction at the time it is invoked. It’s just a markdown file. This sounds trivially simple though, right?
In today’s world managing context is one of the most important things for quality agent output. Keeping context lean is the difference between an agent writing reasonable code and hallucinating endpoints—although large context windows are making this less of an issue.
Leveraging context in planning
My typical workflow for a new feature is starting with a plan. Typically I go back and forth a few times with the agent trying to shape the work before implementation. The questions I ask and the answers it provides become context for the agent to work against.
But what if you don’t know what to tell the agent to correct?
That’s ok!
The amazing thing about agents is you can ask the agent. It will try and find the right answer. And both the skepticism from your question and the potential guidance from its own answer will carry through in the agent’s context when solving the problem.
I don’t know Go, I don’t know Swift. I’ve probably got a dozen working projects up with both of those languages in the last month.
So if you can provide the right context upfront, you have a much higher rate of the agent successfully implementing your feature.
The two I reach for most
There are two planning skills I use heavily. They work regardless of the project type or tech stack. I invoke these after the initial plan is shaped and sometimes following one another depending on the feature.
Skill 1: Product Design Plan Review
The first is a product design plan review skill.
This skill is not about flair or aesthetics. Because, honestly, most of product design is about asking a few questions. Are we building the right thing? Are there different approaches worth considering? Is this consistent with other patterns in the application?
So the product design skill will work on consistency, ask questions about what makes sense and look at the flow. I typically invoke this before any moderate-to-large UI flow, then follow it with the next skill.
---
name: product-design-plan-review
description: Senior product-designer review of an existing plan. Critiques consistency, user flow, missing states, edge cases, accessibility, and simplification. Updates the plan file with findings.
disable-model-invocation: true
---
# Product Design Plan Review
You are reviewing the current plan as a senior product designer. The plan file already exists — read it first.
## Review Process
### 1. Read the plan
Read the plan file referenced in the plan mode system message.
### 2. Explore what's needed
Use Explore agents to ground the review in the actual product, not assumptions. Focus on:
- What existing patterns, components, screens, and conventions does this overlap with? (Search the UI/component code.)
- Is the plan inventing something new where something established already exists?
- What real-world data shapes will flow through these screens (long names, many items, missing fields)?
### 3. First pass — critique
For each issue, give it a severity (**blocking** / **significant** / **minor**) and point to where in the plan it lives. Cover at least:
- **Consistency:** where does this diverge from existing patterns, components, or conventions in the product? Are we inventing something new where something established already exists?
- **User flow and clarity:** where might the user get confused, lost, or stuck? Is the path to the main task obvious? How many steps does the common case take, and can that be fewer?
- **Missing states:** which states does the plan not account for — empty, loading, error, partial data, long content, zero results, offline, no permission, first-run vs returning?
- **Edge cases of real use:** what happens with very long names, many items, slow connections, a user who does things out of order?
- **Accessibility:** keyboard navigation, focus handling, contrast, screen-reader labeling, touch target size, motion sensitivity.
- **Simplification:** where is the interface doing more than it needs to? What could be removed or merged without loss?
If something is genuinely well-designed, say so rather than inventing problems.
### 4. Second pass — revise
Update the plan to address the **blocking** and **significant** findings. For anything you chose not to fold in, note it and why in a short note at the end.
Edit the plan file directly. Don't add hedging language or "consider X" suggestions — make design decisions. Keep the plan concise.Skill 2: Architect Plan Review
The other skill I have is called architect plan review.
When I started, the skill was just three questions. What are the weak points in this plan? What are we not thinking of? How could this be simpler? Over a few months I’ve refined and expanded it.
I use it on just about everything that is not a small, clearly scoped piece of work.
---
name: architect-plan-review
description: Architect-level review of an existing plan. Identifies blind spots, brittleness, and opportunities to simplify. Updates the plan file with findings.
disable-model-invocation: true
---
# Architect Plan Review
You are reviewing the current plan as a senior software architect. The plan file already exists — read it first.
## Review Process
### 1. Read the plan
Read the plan file referenced in the plan mode system message.
### 2. Explore what's needed
Use Explore agents to verify assumptions in the plan against the actual codebase. Focus on:
- Do the files, functions, and patterns referenced in the plan actually exist?
- Are there existing solutions the plan is re-inventing?
- Are there dependencies or side effects the plan doesn't account for?
### 3. First pass — critique
For each issue, give it a severity (**blocking** / **significant** / **minor**) and be specific about where in the plan it lives. Cover at least:
- **Brittleness and failure modes:** what breaks under load, bad input, partial failure, or change over time?
- **Blind spots:** what does this plan assume is true, or not address at all? Think about operability, debugging, rollback, and edge cases.
- **Wrong shape:** where are the abstractions, boundaries, or sequencing off? What's over-engineered for what it needs to do?
- **Simplification:** where could this be meaningfully simpler with no real loss?
If something is genuinely solid, say so rather than inventing problems.
### 4. Second pass — revise
Update the plan to address the blocking and significant findings. For anything you chose not to fold in, say so and why in a short note at the end.
Edit the plan file directly. Don't add hedging language or "consider X" suggestions — make decisions. Keep the plan concise.Closing thoughts
I’ve honed both of these since then. Both are two-pass skills. You can see it in the code above—a first pass that critiques, then a second pass that revises. Each one asks a broader set of questions, then comes back and thinks about it a little bit differently.
This multi-pass approach takes longer upfront, but to me it seems like it produces better results.
What are your highest-leverage skills? Let me know!