Capstone: the /plan-week skill

Putting it all together

You now have all the pieces: a creation skill (ch.3), a brand voice (ch.4), an automatic quality gate (ch.5), and parallel publishing (ch.6). Each brick was built and tested in isolation — that's what makes assembling them stress-free. We connect them into a single command that plans an entire week of content: /plan-week.

Take stock of how far Lea has come: in chapter 1, she was discovering that an agent can read her files. Now she's about to type one sentence and get seven days of multi-platform content, in her voice, checked by her guardrail, scheduled at the right slots. It's not magic: it's composition. Each chapter was a function; this chapter writes the main program.

Architecture before code

Before creating the skill, understand its flow — because you're the one who'll have to debug it if something jams. The command chains five phases: topic research, generating a plan written to a file, a human validation pause, parallel execution by subagents, and logging. The pause in the middle isn't a concession: it's the most important architectural point in the chapter.

flowchart LR
  A["Topic"] --> B["Research"]
  B --> C["content-plan.md"]
  C --> D{"Human validation"}
  D -->|"Needs fixes"| C
  D -->|"OK"| E["Subagents in parallel"]
  E --> F["Scheduled posts + log"]

Notice where the validation sits: after the full plan has been produced (the long, tedious work is already done), but before any irreversible action (nothing has been published or scheduled yet). That's the optimal placement for human control: you review a finished document, comfortably, and your decision bears on something concrete. Validating too early (on a vague intention) controls nothing; validating too late (after publication) is useless.

Creating the /plan-week skill

create a "plan-week" skill that:
- accepts a topic, drafts, URLs, or images
- researches the topic and writes a weekly plan to content-plan.md (day, post #, topic, full text, visual yes/no)
- the text must be the complete, well-formatted post, not a summary, adapted per platform
- creates the visual once per day (reused by that day's posts)
- shows me the plan and asks for approval
- after approval, uses parallel subagents to schedule each post
- reuses the voice, config, and log from the /post skill

ask me questions one at a time until 95% confidence.

Two lines in this prompt deserve your attention. "The text must be the complete post, not a summary": without that precision, you'd get a plan of topics — pretty but unusable, since you'd still have to write everything. "Reuse the voice, config, and log from the /post skill": that's composition in action. The new skill reinvents nothing, it builds on the existing bricks — which is why centralizing the voice in brand-voice.md back in chapter 4 pays off.

The file as the working interface

Claude researches the topic, generates content-plan.md, and asks for your go-ahead. This choice — a file rather than a long message in the conversation — is a practice to remember for all your future systems. A file can be reviewed calmly, edited directly, versioned in Git, and it outlives the conversation.

# Content plan — week of June 17

## Monday — Post 1 (LinkedIn)
Topic: why "fragrance-free" is a false friend
Visual: yes (ingredients infographic)
Text:
> We think we're doing the right thing by choosing "fragrance-free"...
> [full post, ready to publish]

## Monday — Post 2 (Twitter)
...

You review; if a draft isn't right, you edit the file directly — no need to describe the change to Claude, you fix the text yourself like in any document — then you say "continue." Claude picks the file up in its current state and launches one subagent per post, in parallel. The file is the interface; the conversation is just the trigger.

When things go wrong: debugging an orchestration

With a system chaining five phases, you need to know how to localize a failure. The method is always the same: identify the phase that produced the problem, and fix it in isolation. The plan is off-topic? That's the research phase — sharpen the brief or the sources in the skill. The texts are good but the tone drifts? It's brand-voice.md that needs enriching (chapter 4). A post is blocked at scheduling? Read the quality gate's message (chapter 5). A single network fails? It's that platform's subagent or API (chapter 6).

Notice the reflex: each brick of the course is also a diagnostic zone. That's the decisive advantage of having built the system piece by piece rather than as a monolith — you know where to look, and you can test each piece separately with the commands from previous chapters.

The pattern to remember: improve the tool, not the output

You stay in command: you approve the plan before any execution. AI and automation handle the repetitive work. And when the gap between what you wanted and what Claude produced is large, don't just fix the file: tell it — and ask it to update the skill so next time is better.

Concretely, after every /plan-week run, ask yourself: "what did I fix by hand in the plan?" Every recurring manual fix is a rule the skill is missing. Three weeks of that reflex and your manual fixes tend toward zero — it's measurable, and it's the objective criterion of a mature system.

What this capstone really taught you

Beyond Lea's marketing, you just executed a universal automation blueprint: decompose a business process into steps, encode each step (skill), secure the non-negotiable (hook), parallelize the independent (subagents), and place human validation at the point of maximum leverage. Swap "posts" for "invoices to chase," "support tickets to triage," or "competitive intel to summarize": the blueprint holds as-is.

One fragility remains: all this knowledge lives in files, but Claude starts from scratch every session and has to rediscover them. The final chapter fixes that — and it's what turns a nice demo into a durable system.