Planning a Complex Project: The Setup

A lot of things you’ll ask an LLM to do are easy; they’re one off tasks that can be knocked out quickly, and they have a narrow enough scope that they never need more than a single context window. But if you’re deeply embedding Claude in your workflow to get the maximum benefit, you’re going to need to understand how to set up more complex multi-session projects, and that means you need to learn how to plan for them. There’s an old saying: “measure twice, cut once”. In project planning with an LLM, measure five times. It’s worth the effort.

Most of my documented sessions involve focused tasks—a blog template, a featured image, a documentation workflow. This one was different. I wanted to plan an entire WordPress plugin from scratch: a learning management system for TheClaudefather site.

The existing LMS options for WordPress are overengineered and expensive. I needed something simpler—courses, lessons, quizzes, student profiles, progress tracking. Complex enough to require real architecture decisions, but scoped to what I’d actually use.

This post is the first of three covering how that planning session unfolded. Not the plugin itself—the process of scoping it with Claude.

The Orienting Questions

I opened with context about what was coming:

OK, let's take on something a little heavier for our tenth post, which will round out our initial homepage display. Starting with the 11th post, we'll have pagination appearing, and we'll start to do an aggressive mobile resolution testing cycle. But first, we're going to go through the process of planning a larger software project in the form of a WordPress plugin. 

Rebuild your context from the project files, and let me know when you are ready.

Claude’s response didn’t jump straight to “what features do you want?” Instead, it asked four orienting questions:

1. What does the plugin do?
2. Is this a real project or a demonstration?
3. What’s the target complexity level?
4. What’s your experience level with WordPress development?

The fourth question matters more than it might seem. Claude calibrates explanation depth based on expertise. An experienced developer doesn’t need hand-holding through basic concepts; a beginner doesn’t benefit from unexplained jargon. Asking upfront prevents mismatched responses throughout the session.

The Meta-Question

My answer addressed each question but also raised something beyond them:

Great questions! Your context awareness really shows when you lead off with not just feature questions, but relevant questions about both intention, and the skill level of the person you're answering. 

1. The plugin is going to be a learning management system. There are existing solutions out there for WordPress, like the Sensei plugin, but they're all overengineered and too expensive for our purposes. Which leads to our next question...
2. Yep! We're going to build this out for the Claudefather site to allow us to synthesize post content into learning paths that teach a number of the fundamental skills outlined in the posts. We'll spend a lot of time later talking about our approach to educational design. 
3. This is going to be more complex than a focused single purpose plugin, and will require an admin UI, and multiple features. It will use at least one each of a custom post type and a custom taxonomy, along with custom meta values. It will likely need a number of custom Gutenberg blocks as well to support the various content types.
4. I am a very experienced WordPress plugin developer who has built complex web applications for WordPress. However, I want to rely on your skill as much as possible in this project, while providing qualified oversight, in order to demonstrate what is possible with good interaction with you. 

There's one final consideration here at the beginning of planning: project organization. Typically, I would create a standalone project for something like this, in order to keep the project context tightly focused on the desired outcome. However, it's important for the purposes of Claudefather to be able to deeply understand and synthesize the conversations that are occurring, and how the project itself is setup. Is our session capture skill developed enough to completely take on documenting a full project setup from scratch, including the project file inclusions, template creations, and all of the individual decision making utilizing the greater project context, or should we spend a little more time refining that before we dive into creating a planning doc that we will use to seed the new project?

This raised a meta-question: should we plan the plugin in a new Claude project (focused context) or in the Claudefather project (rich documentation context)?

Claude’s assessment was honest. The session-capture skill I’d built could handle individual sessions, but it had gaps for cross-session threading, architecture artifacts, and context depth. The recommendation: do planning work here where context is rich, then use session-capture for individual build sessions in the standalone project.

This kind of honest capability assessment—acknowledging what a tool can and can’t do before committing to a workflow—prevents over-promising and mid-project pivots.

The Requirements Brief

With project organization settled, I provided a comprehensive brief:

So, let's continue with planning. Consider the expected functionality of an LMS. There are "hard requirements" that are likely definitely needed: 

* Lessons (as a core custom post type)
* Quizzes
* Taxonomies
* Meta-organization (Lessons contained within a Course)
* Support for file attachments, especially markdown files given their use in Claude
* A completion system which accounts for engagement with each lesson in a course, along with any associated quizzes, and prompts user behavior based on expected learning outcomes.
* Front-end "student profiles" which are account based, and capable of displaying relevant course status such as assigned, course progress, completions, etc.
* Lesson sidebars with relevant information to the lesson in question, including potentially lesson resources like files, or other key lesson data.

Then there are "soft requirements" which should probably be accounted for as part of scalability, but not immediately required: 

* Paid courses with a checkout system that supports credit card payments.
* Integration with accreditation systems or learning formats such as SCORM/xAPI.
* A mechanism for direct Claude integration into the LMS itself for "live chats" with students.

A proof of concept would be a learning system that covers the ability to self assign a course, progress through lessons, and complete a lesson quiz. An MVP would include the student profile with relevant data and metrics (like time spent, quiz scores, overall grade, etc.). And a phase 1 finished product would include all of the "hard requirements" spelled out above.

The hard/soft separation does specific work. Hard requirements define the MVP—what must exist for the plugin to be useful. Soft requirements document future possibilities without letting them creep into current scope. Without this separation, “wouldn’t it be nice if…” ideas gradually become assumed features.

The milestones are defined by user capability rather than feature count:

Proof of concept: Self-assign a course, progress through lessons, complete a quiz
MVP: Student profile with relevant data and metrics
Phase 1: All hard requirements complete

The architectural constraints went in upfront—WordPress-native methods, Gutenberg blocks, graceful style inheritance. These constraints shape everything that follows. Stating them early, before architecture questions begin, prevents wasted exploration of approaches that were never viable.

What This Setup Enabled

Seven exchanges total. No corrections. A 500-line project plan covering data models, user roles, REST API endpoints, Gutenberg blocks, file structure, and a 10-sprint development sequence.

That efficiency came from the setup work: orienting questions that calibrated the conversation, an honest assessment of tooling capabilities, a structured brief with clear scope boundaries, and constraints stated before architecture began.

The next post covers what happened after the brief—how Claude organized the gaps, presented architecture options, and worked through the decisions that shaped the plugin’s design.