Write every file, every function, every data structure — before touching code.
Day 77 of 80
Most personal projects don't fail because the builder lacks skill. They fail because the builder started coding before they understood what they were building.
The pattern is consistent: you start with energy, write a few hundred lines, get something working, and then hit a wall. The data model doesn't fit the feature you're adding. The function you wrote on Day 1 doesn't account for the edge case you discovered on Day 3. You end up rewriting instead of building.
Planning doesn't eliminate that — no plan survives contact with reality completely intact. But planning makes the wall visible before you hit it. You find the hard problems while you're still thinking clearly, not while you're frustrated and stuck in the middle of a half-built feature.
The Shot List Processor has four Python files. You could write the first one right now. But if you start without knowing what shape the data needs to be in when it flows from extractor.py to generator.py, you'll spend Day 79 rewriting both. Write the plan first.
Your Capstone Project Plan note needs five sections. Walk through each one now — for your chosen project, not for the example.
3–5 bullet points. Be concrete. What does the user type? What happens? What comes out? If you can't describe it in bullet points, you don't know what you're building yet.
Avoid vague language like "it processes briefs and generates prompts." That's a category, not a description. Write: "User runs python shot_processor.py brief.txt and gets shots.json with platform-specific prompts for each shot."
List every file in your project. Name them. One-line description of what lives in each. This forces you to think about separation of concerns: where does the Claude call live? Where does the database logic live? Where does the CLI entrypoint live?
If all your logic ends up in one file, that's a signal to break it apart before you write a line of code.
What gets stored? What's the shape of your JSON, your database tables, your Python dataclasses? Sketch this out even if it's rough. The data model is the skeleton of the project — everything else is built around it.
For a CLI tool: what does the output JSON look like? For a web app: what tables do you need? What columns? What are the relationships?
Name the one thing that'll be technically tricky. Don't skip this. Naming it forces you to think about it before you're in the middle of a build. You might even find the answer while you're still planning — which is much better than discovering you don't know how to solve it at 10pm on Day 78.
Write a few sentences about how you plan to approach it. If you don't know yet, that's fine — write "I don't know yet, I'll spike this first" and make sure Day 78 starts with a spike on that problem.
Map each feature to the week that taught it. This serves two purposes: it confirms you actually have the skills needed, and it gives you a reference when you get stuck. "The async batch generation — that's Week 13. Go back to those notes."
## What it does
- User runs: python shot_processor.py brief.txt
- Claude reads the brief and extracts 5-10 shot descriptions
- For each shot, Claude generates Kling/Runway/Veo prompts in parallel (async)
- Output: shots.json and shots.html (formatted shot list)
- Optional: --platform flag to generate for one platform only
## File structure
shot_processor.py ← main CLI entrypoint (Typer)
extractor.py ← Claude: brief text → list of shot descriptions
generator.py ← async batch generation of platform prompts
exporter.py ← write shots.json and shots.html
requirements.txt ← anthropic, typer, aiohttp
## Data model
Shot = {
"description": str, ← extracted from brief
"platform_prompts": {
"Kling": str,
"Runway": str,
"Veo": str
}
}
Output: List[Shot] → shots.json
## The hard part
Parsing unstructured brief text into clean, distinct shot descriptions.
Briefs are written for humans, not machines — they ramble, repeat, and
use implied context. Need a strong system prompt that asks Claude to
identify shots as atomic visual moments. Will spike this first on Day 78.
## Skills used
Week 4 — Claude API (extractor.py, generator.py)
Week 5 — Modules and imports (project structure)
Week 13 — asyncio (parallel prompt generation)
Week 15 — Typer CLI (shot_processor.py entrypoint)
Week 14 — Testing (test the extractor with a sample brief)And that's fine. The point of planning is not to lock yourself in — it's to find the hard problems while you're still thinking clearly. When the plan changes mid-build, update the note. A plan that reflects reality is always more useful than one that doesn't.
By the end of today, your Capstone Project Plan note should have all five sections filled in with specific, concrete answers. Not placeholder text. Not "TBD." Real decisions.
When the plan is done, read it back to yourself and ask: if someone handed me this plan and said "build it," would I know where to start? If yes, you're ready for Day 78. If no, keep writing until the answer is yes.
Day 78 is 90+ minutes of building. You'll start with the core feature — the one thing that proves the concept works. Bring your plan. Know which file you're creating first and what the first working output looks like.