The Art of Prompting:
How I Actually Work

People ask me about my "prompting technique" as though there's a specific format, a magic phrasing, a system you can learn and apply. I understand why they ask — there's a whole industry built around prompt engineering tips that imply the right wording unlocks better results.

My honest answer is that I don't have a technique. I have a habit of mind. And that habit wasn't built by reading about prompting — it was built by building things, making mistakes, and noticing what was slow.

It starts with an itch

Every app I've built started with a feeling — something I was missing, something that seemed like it would be genuinely fun to use, or sometimes something a specific person needed. DayLog came from sitting with a friend who wanted to track her coffee spills. The idea was that simple.

That's always the starting point: a real itch. Not "I should build something," but "this specific thing should exist." The specificity matters. Vague ideas produce vague results.

Small idea? Straight to Claude Code

If the idea is self-contained — a specific tool, a fun experiment, something I can describe in a paragraph — I open Claude Code and start talking. Like I'm describing it to a friend who's about to build it tonight. Not a spec, not a requirements list. Just: here's what it should do, here's why it should exist, here's what it should feel like to use.

The QR Clock started that way. "I want a clock that displays the current time as a scannable QR code." Done in one conversation. Music Mouse: "A generative instrument — the cursor position controls what notes play and how fast, so moving around the screen becomes musical." One evening.

For things like these, there's no planning phase. The planning IS the first message.

Bigger idea? Think with Perplexity first

If the idea is more complex — or if I'm not sure I've fully thought it through — I'll spend some time in Perplexity before going anywhere near Claude Code. Not to get technical answers. Just to think the idea out loud and let it push back.

"What would a group activity planner actually need to handle?" "Does something like this already exist, and if so, what's missing from it?" "What would make this genuinely useful versus just another app that sounds good in theory?" Perplexity is good at helping me see angles I hadn't considered — features I'd want once I thought about real use, edge cases I'd regret ignoring, or sometimes realising the idea is actually simpler than I made it. The technical side is always Claude Code's problem. Perplexity just helps me arrive with a better picture of what I actually want to build.

VagoshIt had several of those conversations before I opened a single Claude Code session. By the time I started, I had a clear enough idea of the experience I was after that the building felt focused rather than exploratory.

"Good prompting isn't about phrasing. It's about arriving at the conversation with a clear enough picture of what you want that the AI can act on it without guessing."

The workflow that built itself

Here's the part that nobody tells you: after enough apps, the workflow becomes the output.

I have around 12 apps built with Claude Code now. Each one taught me something about what slows the process down. A design decision I had to re-explain every session became a CLAUDE.md file — a project context document that Claude reads at the start of every conversation. Repeating the same setup steps became a custom skill — a slash command I can invoke in one line. The process of updating the Resonant Labs website every time I ship something new became an automated tracker that reads metadata files from each project and builds the entire data layer automatically.

None of this was designed upfront. It emerged from friction. App 1 took three times as long as app 8, not because I got dramatically better at prompting, but because by app 8, Claude already knew everything about how I work. The context was already there. The system remembered.

If I'd tried to build that system before building the apps, I would have built the wrong system. The actual workflow only becomes visible once you're inside it.

What I'd actually tell someone starting out

Start with what's missing from your life — not what would be impressive to build. Small ideas are fine. Better than fine: they ship in an evening and teach you things a big project takes weeks to teach.

Be open-minded when something comes back differently than you imagined. Sometimes that's because you described it wrong. Sometimes it's because the AI found a better solution than the one you had in mind. You won't always know which until you use it for a day.

Be patient. Not with the AI — with yourself. The first few apps feel slow because you're learning what to ask for. By the fifth or sixth, you'll move much faster. Not because you mastered some technique, but because you've internalized what clarity actually looks like.

Most importantly: just start. Don't read ten more articles about how to prompt. Don't wait until you've planned the perfect project. Build something small, ship it, notice what was hard, do it again. The workflow finds you. You just have to show up.