I Don't Start with a Plan. Here's What I Do First.

The difference between vibe coding and scribe coding is in the instructions.

In the first article of this series, I introduced scribe coding: plan-driven, written-first, deliberate. Where vibe coders feel their way through, scribe coders write their way through. You do the thinking in markdown; the AI does the typing in code. That article showed the skeleton: a four-step plan cycle that keeps work on track across sessions. This article is the muscle: three practices that make the skeleton move.

They matter more now than when I started. Auto mode is how most people run Claude Code today, and it's how I run it. But auto mode without deliberate habits is vibe coding at speed. These three practices are what keep it scribe.

Design before you plan

My first article started the clock at plan creation. In practice, the most important phase happens before that.

Before I create a plan, I feed Claude everything relevant to the task: Jira issues, GitHub threads, existing design docs. Then I tell it to investigate: read the code we'll be touching, trace the interfaces, check how similar problems were solved elsewhere in the codebase. Only after that investigation do I ask for a design.

What comes back isn't a plan. It's a design discussion. Claude presents options with confidence estimates: "70/30, I'd lean toward option A because it reuses the existing middleware." I push back, agree, or ask for a third option. We go back and forth until the approach converges.

This works because of a single instruction in my global CLAUDE.md:

When there are several alternatives, don't automatically assume that the user wants to go for the most likely solution. Show the alternatives to the user with pros and cons and give them a choice. Include your estimated confidence for each option.

Without that instruction, Claude picks the most likely approach and runs with it. With it, the design discussion happens naturally. Claude becomes a collaborator who presents tradeoffs, not an assistant who guesses what you want.

Only when the design has landed do I run /gh-create-plan, a custom skill from claude-plan-skills that turns the conversation into a structured GitHub issue. The plan captures the decisions, the approach, and the steps to execute. Here's what a plan issue looks like after that process: a description with the "what" and "why," a design section with a sequence diagram, implementation steps with checkboxes, and a comment recording a key architectural decision.

The difference is stark. "Implement feature X" with no context leads Claude to guess the design and touch the wrong modules. Full context, code investigation, and a design dialogue leads to a plan that fits the codebase.

Hand over before context fills up

The first practice is about how you do the work. This one is about how you sustain it.

Claude Code conversations have a context window. As it fills, auto-compaction kicks in and silently drops earlier context. The conversation keeps going, but quality degrades: decisions made earlier get forgotten, style drifts, tokens burn on work that no longer aligns with the original intent. You might not notice until the output goes sideways.

I don't let that happen. My statusline shows the current context percentage, and around 45% I trigger a handover. A custom skill packages everything a fresh session needs: the plan issue reference, the repo and branch, a summary of what was done, and the specific next step. I paste that into a new conversation and keep going.

Here's what a handover prompt looks like:

/gh-read-plan myorg/prq#14

Repo: ~/git/prq, branch feature/oauth-login.
The authorization flow works end-to-end. During implementation
we switched from a fixed callback port to random port selection
after hitting conflicts on Linux CI. That change isn't on the
issue yet.

Next: token storage. The encrypted-file-over-keychain decision
is in a comment on the issue.
Gotcha: integration tests need GITHUB_CLIENT_ID in the env.

The plan issue tells the new session what's done and what's next. The handover just points it to the right place and flags the non-obvious stuff. No re-explaining, no context loss, no compaction gambling.

Don't let Claude Code manage session lifespan for you. Compaction is a safety net, not a strategy. By the time it fires, you've already lost context you needed.

The feedback loop

The first two practices shape individual sessions. This one improves the whole system over time.

When something doesn't work in a session, I fix it with Claude. Not the code; the instructions. There are four targets: custom skills, global CLAUDE.md, settings.json, and project-level docs. The fix goes wherever it belongs, and every future session benefits.

A concrete example. Early on, Claude would confidently call API methods that didn't exist. It had seen them in training data, but the API had changed since. The fix was a single instruction in my CLAUDE.md:

Before using a CLI tool, API, or library you are not fully confident about, run chub search "<tool name>" to check if curated docs exist. If they do, fetch them with chub get <id> and use the docs instead of relying on training data.

That rule points Claude at Context Hub, a crowdsourced tool-docs project from DeepLearning.AI. Now instead of hallucinating an API call, Claude fetches current documentation first. One instruction, applied permanently to every future session.

This compounds. Over a few months, I've built over two dozen custom skills, from code review to handover to structured debugging, and continuously refined my instructions. Each edit is small: a rule added after a bad session, a convention captured after a good one. But the cumulative effect is significant. Claude behaves differently for me than it does out of the box, because my instructions encode months of iteration.

The best part: Claude is often the best collaborator on its own setup. When I hit a problem, I describe it and ask Claude to propose a fix to the relevant instruction or skill. It knows the format, the conventions, and the constraints. I review the change, and we move on.

The practice

These three aren't optimizations; they're the practice. Without them, auto mode is vibe coding at speed.

Claude knows Claude best. Scale that up, and single-session scribe coding becomes multi-session orchestration, with Claude writing the instructions for each session. More on that in a future post.

If you want to start now, add one instruction to your CLAUDE.md today. The one about presenting alternatives is a good first choice.