Give Claude the why, not just the what
The one change that made Claude's output better on the Check In App: context and reasoning up front.
The more context Claude starts with, the less I fix afterward.
By May, the Check In App had a PRD and wireframes for every screen. But when I sat down with Claude to build the design system and style screens, I'd prompt with just the task: create these components, apply these colors. Claude moved fast, but I spent a lot of time afterward fixing things, especially how design tokens were applied.
Looking back, the problem wasn't Claude. The plan existed. It just wasn't in the conversation. I was handing over the what (build this) without the why (who it's for, how it should feel, what matters most).
So now I start differently:
- Put the plan in the conversation at the start of every session, not just in my head
- Explain the why behind the request, not just the task
- Front-load as much context as I can: the users, the constraints, the decisions already made
It's the same thing I'd do for a teammate. A good brief gets better work, and that turns out to be true for AI too.
What worked
What didn't
The more context Claude starts with, the less I fix afterward.