My Claude Code Workflow
(Yes, with Dinosaurs)
Discussion → Handoff → Review → Best-idea → Improve → Implement → Code-review
TL;DR
Seven phases from idea to shipped code. Claude asks questions until it understands, writes an exhaustive plan, then sub-agents execute in parallel while you context-switch to other work. Fresh reviewers catch what the implementers missed.
Discussion — Claude asks questions one at a time until ready to plan
Handoff — Break large plans into agent-sized task files
Plan Review — Fresh context reviews plan for gaps
Best Idea — Research alternatives when uncertain
Improve Idea — Simplify, strengthen, "wouldn't it be cool if"
Implementation — Sub-agents execute in parallel
Code Review — Fresh context reviews commits
The Workflow That Brought Jurassic Park to Life
I think out loud. Claude writes plans. We merge until the bugs are caught before they exist. The code is almost an afterthought. And somewhere in the discussion, ideas surface that I never would have prompted for.
The upfront investment is real. But it pays back in code that doesn't need to be rewritten.
I could walk you through each phase with bullet points. Instead, let's talk about dinosaurs.
(If you don't like fun, there's a "no dinos" toggle just for you.)
Phase 1: Discussion
The common advice is "start in plan mode." Even the Claude Code team recommends it. But plan mode is still rushing toward a plan; it might ask a question or two, then it's off to the races.
Instead I just write up what problem I am trying to solve and end it with:
Ask me questions one at a time until you're ready to write a plan.
No special prompt. Claude stops trying to solve immediately and starts asking questions. Once we've actually talked it through, then I drop into plan mode to write it up.
Skip this step and life, uh, finds a way... of punishing you later.
I've attached the full park documentation: containment systems, tour design, staffing, and operations. We've spared no expense on planning. Just need a fresh set of eyes before we announce to investors. Ask me questions one at a time until we're ready to finalize the implementation plan.
I've reviewed the documentation. Strong vision, and the technical specs are more detailed than most projects I see at this stage.
Before I write the implementation plan, I need to clarify a few things.
First question: What's the core guest experience you're optimizing for?
I see three possible framings in your materials:
- Investor deck emphasizes "real science" and "witnessing evolution"
- Longer exhibit times, interpretive signage, guided tours with paleontologists
- Tour route prioritizes dramatic reveals
- T-Rex paddock positioned for maximum impact
- Optimizing for awe over information
- Containment language implies controlled danger as a feature
- "Experience creatures that ruled the earth"
- Different safety calculus
Which framing should I prioritize when decisions conflict?
Spectacle, absolutely. I want a child to look up at a Brachiosaurus and forget that extinction was ever a thing. Wonder is what they're paying for.
That clarifies several things in your tour design. The vehicle pacing makes sense now; you're controlling the reveal timing, not just moving people through efficiently.
Next question...
I have enough to draft the plan.
Here's what we've decided:
- Spectacle-first guest experience, science as supporting credibility
- Tour pacing optimized for dramatic reveals, not throughput
- Species separation to reduce predator-prey stress
- Veterinary facilities scaled for current population plus 20% growth
- Visitor center positioned as emergency centralization point
- "Kids love dinosaurs" confirmed as core marketing thesis
Anything else before I write this up?
I think that covers everything. We've spared no expense.
Ready for the plan.
Phase 2: Handoff
Once Claude runs out of questions, I switch to plan mode. Instead of accepting the plan to begin implementation I run:
/plan:handoff
This creates a folder in docs/, splitting up the plan into task files scoped for smaller agents like Sonnet (faster, cheaper, and they don't need the whole picture), plus a README with the high-level view.
Full handoff prompt
Phase 3: Plan Review
Once the planning documents have been created, I clear the context and run:
/plan:review docs/[plan-name]
This reviewer doesn't remember you talking yourself into "it'll probably be fine." It just sees the plan and asks: does this actually make sense?
Plan Review: Jurassic Park Implementation Plan
Summary
Ambitious vision with solid containment specs and clear guest experience priorities. The main risks are infrastructure interdependencies: unified power systems and concentrated IT access create correlated failure modes.
Findings
Main power grid and diesel backup share infrastructure. A tropical storm that damages primary power could simultaneously flood the generator building.
Impact: All electric fencing fails simultaneously across every paddock.
One employee (Nedry) holds system-wide credentials across security, containment, communications, and life support.
Impact: Disgruntled employee, compromised account, or simple human error could disable all systems simultaneously.
Current containment (12-foot fences, standard feeding) treats raptors as physical threats. Field observations suggest cognitive threats: systematic fence testing, pattern learning, coordinated behavior.
Impact: Fence height becomes irrelevant if they're probing for weaknesses, not trying to jump.
T-Rex and raptor paddocks have ground-level viewing platforms.
Impact: Guests within reach if barrier fails.
What the Plan Gets Right
- Spectacle-first experience with clear priority hierarchy
- Species separation prevents predator-prey stress
- Visitor center positioned for emergency centralization
Questions Requiring Clarification
- What's Nedry's compensation relative to market rate?
- What is the latching mechanism on interior doors?
- Has the all-female population been independently verified?
Ready to walk through findings. Say "go" to start one-at-a-time review.
Go.
Categorizing findings:
Autosolve (≥90% confidence): 6 findings
- Power Systems: Underground backup generator, physically separated from operations
- IT Access: Role separation plus market-rate adjustment for Nedry, since concentrated access and underpayment is a flight risk
- Guest Evacuation: Zone-based bunkers every 500m, because "return to visitor center" assumes you can
- Tour Vehicles: Auto-unlock on power loss, so guests aren't served adjacent to the T-Rex
- Behavioral Monitoring: Hire an ethologist, someone should notice if the animals are planning something
- Breeding Controls: Ecosystem audit for alternative lysine sources, since life finds a way
Discussion (<90%): 2 findings
- Finding 3: Raptor Containment
- Finding 4: Viewing Areas
Starting with Finding 4.
Finding 4: Viewing Areas (MEDIUM)
T-Rex and raptor paddocks have ground-level viewing platforms. Guests within reach if barrier fails.
- Maximum safety margin, eliminates ground-level failure mode
- Reduces visceral experience, guests feel distant
- Maintains spectacle while adding safety margin
- Still requires emergency descent planning
Recommended: Option 1. Eliminates the failure mode entirely. Still provides dramatic views. (88% confidence)
No. Option 2.
The whole point is feeling the ground shake when the T-Rex walks. You can't experience that through twenty feet of steel scaffolding. We need elevation for safety, but the experience has to stay visceral. Open air, close enough to feel it.
Understood. Spectacle as primary driver; I should have weighted it higher.
Proposed solution:
- Elevated platforms with rapid-descent emergency exits
- Immersive experience during normal operation
- Drop to bunker level in under 30 seconds if containment fails
- Safety infrastructure stays invisible until needed
Moving to Finding 3.
Plan-review surfaces findings, and Claude gives options in tiers (usually simple to complex, or safe to aggressive). Its recommendations are reasonable given what it knows. But it doesn't know everything.
It might suggest skipping a feature to reduce complexity, but I know users have been asking for it for months. Or it recommends the robust solution when I just need something working by Friday.
This happens constantly. Claude optimizes for what it can see. You fill in what it can't.
Finding 3: Raptor Containment (HIGH)
Current containment treats raptors as physical threats. Field observations suggest cognitive threats: systematic fence testing, pattern learning, coordinated behavior.
- Straightforward implementation, higher fences with moat
- Addresses symptoms, not cause
- Addresses cognitive threat model with randomized feeding, multiple barrier types
- More complex, requires ongoing operational changes
- Understand what we're containing before finalizing design
- Delays implementation
Recommended: Option 2. (72% confidence)
Physical barriers assume they're trying to overpower containment. If they're probing for weaknesses instead, unpredictability matters more than height.
But confidence is low. I don't have hard data on raptor capabilities. How high can they jump? Can they climb? How coordinated is pack behavior?
/plan:best-idea What about a moat system combined with randomized feeding? The field reports mention they avoid water.
Full plan-review prompt
Phase 4: Best Idea
/plan:best-idea is for when findings aren't clear, or you have an inkling there's a better way.
Run the command with your half-formed thought. Claude does extra research and either confirms its recommendation or finds something it completely missed: a package that already solves it, a simpler structure, the thing you were overcomplicating.
Best-Idea Evaluation: Raptor Containment
Research Summary
After reviewing paleontological behavior studies, modern apex predator containment standards, and field incident reports:
Key findings about Velociraptors:
- Problem-solving intelligence comparable to primates. They don't just react; they experiment. Systematic fence testing is consistent with cognitive mapping behavior seen in great apes.
- Can jump 10+ feet vertically from standing. 12-foot fences provide less than 2 feet of margin.
- Test barriers systematically and remember weak points. They return to the same sections because they're tracking results over time.
- Learn from observation. Field reports note they watch handlers during feeding. Not tracking food. Studying process.
Current plan gap: Treats raptors as physical threats requiring physical barriers. Doesn't account for cognitive capabilities.
Hammond's Hypothesis Evaluated
Moat system + randomized feeding
The instinct is partially right: - Moats provide a barrier that works without power - Randomization prevents pattern learning - Water aversion is real But incomplete. Moat alone doesn't address climbing or jumping. Randomized feeding doesn't help if they're also learning handler schedules, patrol routes, gate procedures. Higher fences and electrified ceilings have the same problem: they assume physical containment is enough. If they're probing for weaknesses, single barriers of any type are insufficient.
Recommendation
Multi-layer containment with behavioral countermeasures (87% confidence)
- Outer fence: 24-foot, angled inward at top
- Inner fence: Separate power system from main grid
- Moat between fences: Leverages water aversion, works without power
- Randomized feeding: Locations AND schedules vary
- Randomized patrol routes: Predictable security is exploitable security
- Double-airlock entry: No direct human access to enclosure, ever
Hammond's moat instinct was right, but it needs to be part of a layered system. The key insight isn't height or voltage. It's that they're testing you as much as you're containing them.
They remember weak points? They watch handlers?
They return to the same fence sections repeatedly. They're not testing randomly; they're running experiments. And during feeding, they track handler movements rather than just the food. Your containment staff are being studied.
Full best-idea prompt
Phase 5: Improve Idea
/plan:improve-idea asks three questions: What can we simplify? What should we strengthen? And "wouldn't it be cool if..."
The wild ideas aren't always practical, but sometimes they're exactly what the project needs. They can also just be fun, and what takes a B plan to an A.
Idea Improvement: Jurassic Park Implementation Plan
1. Simplify
Single "lockdown" command Currently requires per-paddock activation. One command triggers all containment protocols simultaneously.
2. Strengthen
Puzzle feeders for raptors Mental stimulation reduces escape motivation. Bored apex predators find their own entertainment. Give them problems to solve that aren't "how do I get out."
Environmental enrichment for T-Rex paddock Currently barren. One goat on a chain isn't enrichment. Varied terrain, hunting simulations, environmental complexity. Recommend starting with a big red ball.
3. Stretch
Gallimimus stampede experience Guests stand in designated "safe zone" while the herd thunders past during feeding time. High spectacle, moderate risk.
Compy petting zoo They're small. How dangerous could they be? Family-friendly, high engagement.
Dinosaur dung exhibit Educational value. Dr. Sattler approved. Gift shop sells bags for home gardens.
The compy petting zoo. I love those little guys. Had one nibble at me once. Are we sure they're safe?
Researching... Only two reported cases of compys inflicting life-threatening injuries.
Full improve-idea prompt
Phase 6: Implementation
Once the plan is solid, clear context and run /plan:start-implementation. Sub-agents spin up in parallel, each working from its task file, no context bleed between them.
I set it running and context-switch to other work. Come back when it's done. (Assuming you've set up the permissions. Ask me how I learned that.)
Full start-implementation prompt
Phase 7: Code Review
After implementation, clear context and run /plan:code-review. It catches the gap between what the plan said and what got built.
The agent that implemented knew the intent. A fresh reviewer just sees code. Most findings are syntax or type errors, but you'll be surprised how often it catches a wrong assumption or a cleaner way to do something.
Code Review: Jurassic Park Implementation
Finding 1 (MEDIUM): Autosolve
Location: Kitchen, Visitor Center Standard door handles installed throughout facility. Why this matters: If any animal demonstrates the ability to operate lever-style handles, every interior door becomes a breach point. Fix: Replace with round knobs or push-bar mechanisms.
New role-based access controls have been added, but existing credentials were left unchanged. Nedry still has system-wide access across security, containment, communications, and life support.
Additionally: compensation data shows Nedry at 15% below market rate for his role. Concentrated access plus underpayment is a flight risk.
- Immediate salary adjustment to market rate, reduces flight risk
- Doesn't address single point of failure
- Hire second systems engineer, implement credential handoff
- Doesn't address compensation gap motivation
- Address motivation and eliminate single point of failure
- Highest cost and implementation complexity
Recommended: Option 3. (95% confidence)
The fences don't matter if the person controlling them has a better offer.
Full code-review prompt
Outro
Claude can one-shot many things. But one-shotting isn't the ceiling. It's the floor. When you take the time to discuss each piece, push back on recommendations, and review with fresh eyes, you're not just using Claude. You're combining what you know with what Claude knows.
Claude sees patterns across millions of codebases. You see the user who's been asking for that feature for six months. Neither perspective is complete. The workflow exists to collide them.
The hours of upfront discussion feel slow. Turns out, they pay back in code that doesn't need to be rewritten.
Skip the workflow and: Developer writes prompt. Prompt creates AI agent. AI agent writes code. Code breaks production. Tech debt inherits the earth.
Hammond's original plan would have worked perfectly, assuming nothing went wrong. This workflow exists because things go wrong, and the best time to find that out is before you've written a single line of code.
