How I Build AI Planning Commands That Actually Work

I've been using Claude Code to build a full-stack AI agent. Along the way, I noticed something: every time I planned a new feature, I was doing the same thing manually. Prime the codebase, research the docs, steer the direction, generate a plan.

It worked. But it was repetitive. So I turned the whole workflow into reusable slash commands.

Here's how I did it and what I learned.

The Manual Workflow That Worked

Before I automated anything, I planned features through a multi-step conversation with Claude. It looked like this:

1. Prime the codebase - load the full project context
2. Explore options - "what do you think our next steps are?"
3. Steer the direction - "I disagree, let's do X instead"
4. Deep research - "read the PydanticAI docs, look at the source code"
5. Generate a plan - fill a structured template with all that context
6. Review and refine - "do you have those risks in the plan?"

The plans that came out of this were excellent. Detailed enough that another AI agent could execute them without asking questions. Specific file paths, line numbers, code patterns, gotchas, validation commands.

But every feature required the same 6 steps. Same dance, different song.

What I Already Had

I had a plan template - a structured markdown file that defined what a good plan looks like. Sections for feature description, user stories, context references, step-by-step tasks, testing strategy, validation commands. It was solid.

The problem: the template was just a blank form. It didn't do any research. It assumed I'd already figured everything out and just needed a place to write it down.

The Key Insight

The research phase is what makes plans good, not the template.

When I looked at my best plans, the quality didn't come from the template structure. It came from what happened before I filled it in:

• Searching the codebase for similar implementations
• Reading external library docs to understand specific APIs
• Extracting real code patterns with line numbers
• Identifying gotchas that would bite during implementation

The template was just the container. The research was the content.

Building the Command

I built a /plan-feature command that automates the research and fills the template. Here's the structure:

Phase 1: Understand the Feature and Target the Research

The command parses whatever you give it - could be a rich prompt with URLs and constraints, could be a one-liner. Then it figures out what to research by checking three sources:

• Your input - any URLs, library names, or constraints you mentioned
• The project manifest - what dependencies does this feature touch?
• CLAUDE.md - what technologies and docs does the project reference?

This is the step that makes even a lazy prompt like "add semantic search" produce good research. The command already knows the project uses PydanticAI, PostgreSQL, and SQLAlchemy because it read the config.

Phase 2: Parallel Research

Two agents run simultaneously:

Codebase agent searches for similar implementations, maps integration points, and extracts patterns - naming conventions, error handling, logging, testing, the works. Everything with file paths and line numbers.

External research agent works through the target list from Phase 1. It fetches URLs you provided, finds library docs for the specific features you need, and identifies gotchas and version issues.

Phase 3: Fill the Template

All that research feeds into the structured template. Every section gets filled with specifics, not generic placeholders. The output goes to a plan file that another agent can execute top-to-bottom.

What I Learned

Your steering goes into the arguments. The manual workflow was powerful because I was making judgment calls mid-conversation - "use this API, not that one", "read this specific doc page." In the automated version, you front-load that into the command arguments:

/plan-feature Add Google Gemini as an LLM provider.
Read ai.pydantic.dev/models/ for provider patterns.
Extend _build_model() in agent.py. Follow the existing
Ollama/Anthropic switch pattern.

More context in, better plan out. But even a bare feature description works because the command knows how to find context you didn't provide.

Don't re-prime. I also have a /prime command that loads the full codebase context. The plan command assumes that's already happened and doesn't waste time re-exploring. Know what your tools have already done.

The template is the control mechanism. Every phase of research maps to specific sections of the template. This prevents the agent from wandering - it knows exactly what it's trying to fill.

Portability matters. I built these commands to work across projects, not just the one I was building. The prime command discovers the toolchain from manifest files instead of hardcoding paths. The plan command reads whatever CLAUDE.md and project config exist.

The Commands

I'm running two versions side-by-side to see which produces better plans:

v1 follows the instructor's approach - 6 explicit phases, clarifying questions, template skeleton up front.

v2 is mine - 3 phases, no questions (infer from context), research targeting from the project manifest, parallel subagents, and a risks/mitigations section that the instructor's version doesn't have.

Both use the same output template. The difference is how they gather the information to fill it.

Try It Yourself

If you're using Claude Code, the workflow is:

1. Create a CLAUDE.md in your project with your conventions and stack
2. Build a /prime command that loads your codebase context
3. Build a /plan-feature command that researches and fills a plan template
4. Front-load your judgment into the arguments

The goal isn't to remove your thinking from the process. It's to stop repeating the mechanical parts so you can focus on the decisions that actually matter.

---

This is the same kind of systematic thinking I bring to building contractor websites. If you're curious about who's behind this, check out my story.