AI Context Checklist Part 2: What Actually Works
Part 1 was theory. This is what I actually do now.
A few months ago I published the AI Context Checklist — a set of rules for getting better results from AI coding tools. Plan first. Give context. Set guardrails.
The principles held up. But my workflow changed completely. I moved from Copilot prompts inside an IDE to running Claude Code from the terminal as my primary tool. The mental model shifted from “assistant in the corner” to “engineer on the team.”
Here’s the workflow I run today.
Greenfield Projects: Think First, Then Hand Off
For a new project, I follow three phases — and the first one doesn’t involve code at all.
1. Brainstorm in isolation
I open a separate chat — Claude desktop, the web app, whatever gives me the best thinking model (right now that’s Opus 4.6). No repo, no files, no code. Just me explaining the feature or goal in plain language.
I describe what I want to build, who it’s for, and what the constraints are. I go back and forth until the idea is sharp. This is pure thinking time.
2. Turn it into user stories
Once the concept is clear, I ask for a .md file with the work broken into user stories. Not tasks, not tickets — stories. Each one describes a slice of value a user gets, with enough detail that an engineer (human or AI) could pick it up and run.
This file becomes the single source of truth for the project.
3. Plan, then implement
I share that .md file with Claude Code and ask it to plan the implementation — still using Opus for the planning phase. It reads the stories, explores what exists (if anything), and lays out the approach.
Once I have the plan, I ask it to implement. I used to switch to Sonnet for execution to save tokens. Honestly, I’ve been direclty using Opus for everything now since the results are noticeably better. The cost difference stopped mattering when I stopped having to re-do work.
Existing Projects: Context Is Still King
For adding features to a project that already exists, the workflow is shorter but the principle is the same: context before code.
Check 1: Do I have a CLAUDE.md?
If not, I create one. This is the project’s memory — architecture decisions, conventions, file structure, anything Claude needs to understand the codebase without asking me twenty questions.
If I’m starting fresh on an existing repo, I ask Claude to explore the codebase with multiple agents to gather details and write the CLAUDE.md itself. It reads the code, finds the patterns, and documents them. I review and adjust.
Check 2: Share the feature spec
If the CLAUDE.md already exists and the project context is solid, I just share the new feature .md file. Claude Code reads the project context, reads the spec, and gets to work.
That’s it. Two checks. The CLAUDE.md handles all the guardrails I used to configure through .cursorrules or copilot-instructions.md. Same idea, better execution.
What Changed From Part 1
The core principles from the original checklist still hold:
- Plan before code. Still the most important rule. The brainstorm → stories → plan → implement pipeline is just a more structured version of the Plan-First Protocol.
- Context is king. Still true, but now the context lives in CLAUDE.md files instead of
@filereferences in an IDE chat. - The 4-Part Prompt Formula. Mostly absorbed into the CLAUDE.md itself. The role, context, and constraints are defined once, not per-prompt.
What changed is the tool. Moving from IDE-integrated AI to a terminal-based agent meant I stopped thinking about individual prompts and started thinking about workflows. The unit of work isn’t a prompt anymore — it’s a project.
The Takeaway
The checklist was about getting better outputs from AI. This workflow is about getting better outcomes from projects.
Think in isolation. Write the spec as stories. Let the AI plan before it builds. Keep project context in a file that persists across sessions.
Stop prompting. Start directing.