My first Claude Code pull request had 200 files. No documented standards, no workflow, no clear direction. Two weeks of patching later, I understood why and overhauled everything.
How Do You End Up With a 200-File PR?
I had just joined a new team working on a greenfield project. Processes were still forming. Standards existed mainly in people's heads. Mine included.
I needed to implement a feature that already existed in another product. My plan: give Claude a link to the source repo and ask it to replicate the feature, adapted to our new project's conventions.
It finished in minutes. I felt pleased with myself.
Then I opened the first file.
It didn't meet the quality I'd always held my own code to. But the PR was already "done". And I made the classic mistake. Instead of stepping back and rethinking the approach, I started patching.
Prompt after prompt. Fix after fix. Two weeks of incremental corrections, each one slightly off because I still wasn't giving Claude any real direction.
Code review confirmed what I already suspected. The quality wasn't there. And I had no idea how to fix 200 files that shouldn't have existed in that form.
The Real Problem Wasn't Claude Code
Claude had no way of knowing my standards. Because I hadn't written them down.
When I work manually, I follow a consistent process: analyse business requirements in detail, ask clarifying questions, break work into Jira tickets, align with the team, then implement against known conventions.
With Claude Code, I skipped every single step.
The excitement of a fast, capable tool made me impatient. I jumped straight to implementation without giving the tool the context it needed to do its job properly.
That is the root cause. Not the tool but the missing structure around it.
What the Workflow Looks Like Now
The first thing I do now in any new project is run /init. Claude analyses the codebase and generates CLAUDE.md - a central configuration file that works as the project's memory. Build commands, coding conventions, architecture decisions, naming patterns. Everything Claude would otherwise need you to re-explain every session.
Next, I populate .claude/rules/. This is Claude Code's built-in mechanism for organising project rules. Each .md file covers one topic: code-style.md, testing.md, security.md. You can assign rules to specific file paths via YAML frontmatter, so frontend rules don't load when Claude is working on backend code.
I also run quality checks - static analysis, style consistency, tests via a Stop hook configured in .claude/settings.json. The hook fires a subagent that runs the checks in a separate context, so it doesn't consume tokens from the active session.
Before any implementation, I plan. I use the brainstorming skill from Superpowers to think through the approach, then Grill Me - a separate skill that probes for contradictions, gaps, and missing assumptions, question by question. Once I'm satisfied, I save the result as a PRD and move to writing-plans (also from Superpowers), which produces a detailed implementation plan: class names, properties, architecture, tests.
Large features often touch dozens of files. Instead of letting that become one unmanageable PR, I ask Claude to divide the plan into vertical slices - semantically cohesive, independently reviewable units.
Implementation runs in a clean session via executing-plans (Superpowers).
Once the code is written, I run the quality check and then requesting-code-review (Superpowers) to verify the output against the plan. When everything passes, I create the pull request, sometimes asking Claude to open it directly, based on a Jira ticket number.
If a PR ends up too large, I ask Claude to split it into stacked PRs: the first branching from main, each subsequent one branching from the previous.
When team review surfaces something worth keeping as a standard, I ask Claude to update the relevant file in .claude/rules/. Next time, it applies that standard automatically.
The Shift Nobody Mentions
Beyond workflow, Claude Code changes what a developer actually does.
When the tool handles implementation, you spend more time thinking upstream - about what to build and why. You design features with business value in mind, rather than waiting for a fully-specced ticket to arrive.
In practice, you become something closer to a product engineer.
That is the real change. And it is worth being deliberate about.
Start Here Before Your First Prompt
The quality of Claude Code's output is a direct function of the quality of context you provide.
If the results disappoint, the question to ask is not "what prompt should I write?" It is "what have I not told it yet?"
CLAUDE.md, rules files, a proper plan, vertical slices - these are the answers.
Build that foundation first. The prompts will follow naturally.
What does your Claude Code workflow look like?
Top comments (1)
One thing I've learned over the past month is that a custom skill tailored to a specific project is much better than a generic skill from a public GitHub repository, since every project has different priorities and operating environments. So the idea is create meta prompts that creates this custom skills instead: e.g. voku.github.io/BlindSpotMetaSkillApp/