Talking to agents
You may be thinking you have to craft the perfect prompts but you just need to talk to them.
Prompting's not dead, but I don't see it as my job to get right. My job is to make sure the agent has the instructions it needs to complete the task. And steer it along the way.
Talk or type?
Sometimes I'll type, others I'll use voice-to-text.
I voice dump when I want to ramble: thinking through an idea, brainstorming, or giving a lot of feedback at once. If I feel clear in what I want (or it's a short follow-up), I type.
This is an example of a mini-ramble on a random business idea I had.
I've got an idea for a potential new business for myself, which is thinking about the kind of newsletters that Britannica write. They're kind of just daily newsletters, really simple format, really repeatable. AI could run them. You just get sponsors to advertise in the newsletter. And they do like word of the day type stuff. Like that's kind of vaguely a mechanic I like. There's a website called wisehumans.org that does polls. So it does like, do you shower in the morning or night? And then people vote on that. And then if you vote, you can then add subsequent votes. And like pulls data from where you're voting from and all that kind of crap. And what I'm thinking of is like, who uses this? And it could be several different newsletters. One could be like tech products. So thinking about things like Eight Sleep mattress. Do you use it? Yes, no, want. And then it could have a really simple underneath. It could have like what it does, the price, where you can get it. You could do it for software too. You could say, who uses ChatGPT? Who uses Claude? All those kind of things. […] You could do it obviously for like health and wellness. You could do it for all sorts of things.
Using voice-to-text can give agents a lot of context for what you're trying to do. I think giving agents your thinking, even if it goes back on itself or waffle, can be great for them to understand your connective tissue and where your head's at.
When it’s not getting it
There'll be many a time when the agent's just not getting 'it'. It may be because you're not a developer, and you just can't explain it well enough. But you will run into issues, everyone does. Bugs happen for the most experienced engineers, it's just part of the process. I often escalate my response-type with my frustration.
I don't know why I do this really. You should give specific, detailed, instructions but I find myself 'testing' agents' capabilities, hoping it'll just understand what I mean and all the things in my head that need fixing or tweaking - and sometimes it will. But it'd save time (and tokens) to just say the damn thing.
Agents can break videos down frame by frame and transcribe what you say, to pinpoint what you’re talking about. So I often find a screenrecording while pointing and talking can give a lot of visual detail for context.
Once you're familiar with how agents work you get that it looks at the task it's been given, the context it has and the tools it has available. Can it do the task the way I want it to? Do I need to give it another tool (or can it get one itself)? What would determine if the task is done to my expectations?
The verification step is something I think about a lot with any task. The agent might come up with its own checks, and it may be missing the bits I need. Agents look at things like, does the code run, does the page open - but I look at things like overlapping components, over-use of text and whether spacing looks good.
That’s why, for prototypes, my instructions tell the agent to do a visual pass itself before it sends me the link. To hopefully catch any visual UI/UX issues as a user would.
Why is it done this way?
When I’m planning something I want to build, I talk to the model a lot, back and forth, until we’ve figured out the shape of it. I picked up a couple of extra instructions I find helpful.
## General - questions are requests for an answer, not changes. - Always use ASD-STE100 Simplified Technical English in outputs - Talk to me like I have ADHD. - when writing-great-skills for writing skills - if asked 'grill-me': interview ben one question at a time until shared understanding, give your recommended answer with each question; if a question can be answered by exploring files, explore them instead.
But again, I'm aware there's a skill issue - there will be things I don’t understand. So I question them. I think it's an interesting position to be in, because I'm not technical I may ask questions no engineer would, but it helps my understanding.
explain this to me.
Or one of my favourites, 'thoughts?'.
Then I have it write our decisions to a file, like a plan.
lets put all of this info in a plan.md file.
Text in your session is temporary, the agent only 'remembers' what it can read in its context. And when the session gets lost, it summarises everything when it compacts. In a file it’s saved, it's durable. It lives beyond the session, and I can go and edit it myself.
So if it's important information you want agents to remember in any session for your project, put it in a file.
Grill me
When I don’t really know what I want, I get it to grill me. There’s a skill by Matt Pocock called Grill Me. It asks you questions one-by-one and recommends its own answers, until there's a shared understanding of what you’re actually trying to do.
I adapted it and put it in my instructions instead. I don’t think the agent needs much more than this.
## General
- questions are requests for an answer, not changes.
- Always use ASD-STE100 Simplified Technical English in outputs
- Talk to me like I have ADHD.
- when writing-great-skills for writing skills
- if asked 'grill-me': interview ben one question at a time until shared understanding, give your recommended answer with each question; if a question can be answered by exploring files, explore them instead.grill me about what im thinking of working on. i cant quite figure out the shape of it
Often I don't agree with what it recommends, don’t just go along with it, ask it why - get it to explain it's reasoning. Agents are sycophantic, so sometimes I tell it straight.
I think you're just blowing smoke up my arse. You're looking at what I've said and you're just saying "yeah, looks almost right". Try and help me here. Don't just go along with what I've got.
Tell it how to talk to me
Agents can be very verbose, they often say a lot of words. And each new model comes with its own quirks. So I have a few lines in my agent instructions. If I find myself repeating something in my chats, I may move it to my instructions.
Questions are requests for an answer
Agents are built to complete tasks so sometimes when you send a message that includes a question it might just go off and make the changes. So an instruction I find useful is this one.
## General - questions are requests for an answer, not changes. - Always use ASD-STE100 Simplified Technical English in outputs - Talk to me like I have ADHD. - when writing-great-skills for writing skills - if asked 'grill-me': interview ben one question at a time until shared understanding, give your recommended answer with each question; if a question can be answered by exploring files, explore them instead.
In practice, it can look like this:
should the sign up button stand out more?
nothing in AGENTS.md
I only asked
Yes. I’ve made it orange, made it bigger and moved it up under the heading.
Updated index.html.
with the line
asks before it touches anything
Yes. It’s the same colour as the background, so it’s easy to miss. I’d make it orange and a bit bigger. Want me to do that?
Simplified technical English
This is a simpler way of expressing technical terms.
## General - questions are requests for an answer, not changes. - Always use ASD-STE100 Simplified Technical English in outputs - Talk to me like I have ADHD. - when writing-great-skills for writing skills - if asked 'grill-me': interview ben one question at a time until shared understanding, give your recommended answer with each question; if a question can be answered by exploring files, explore them instead.
I've played with "Use plain English" and "I'm not a developer, explain simply" but sometimes models use analogies that I don't think are helpful. Although as each new model comes out, they're interpretation of these changes.
The same question, with and without simplified technical English.
the agent says the build failed because of a missing dependency. what does that mean?
nothing added
what’s a bundler? a registry?
Your project imports a package that isn’t installed in node_modules, so the bundler couldn’t resolve the module and the build aborted.
Run npm install to fetch it from the registry, or add it to package.json if it isn’t declared.
simplified technical English
what’s wrong, and what to do
Your site uses some code that someone else wrote. That code isn’t on your computer, so the site can’t build.
Tell the agent to install it, then it will build again.
Talk to me like I have ADHD
Even with the simplified English line, this gets agent outputs to the point more concisely.
## General - questions are requests for an answer, not changes. - Always use ASD-STE100 Simplified Technical English in outputs - Talk to me like I have ADHD. - when writing-great-skills for writing skills - if asked 'grill-me': interview ben one question at a time until shared understanding, give your recommended answer with each question; if a question can be answered by exploring files, explore them instead.
Both of these have the simplified English line.
how do i put this site online so my friends can see it?
simplified English only
now I have to choose
There are several ways to put your site online.
- here.now: I publish the folder and you get a link. This is the fastest way.
- Netlify: you drag the folder onto their website. It is free for small sites.
- GitHub Pages: you put the files in a GitHub repository. It is free, but you must make a GitHub account first.
- Vercel: this connects to GitHub and publishes each change. It is good if the site will change often.
After you publish, you get a link. Send the link to your friends.
Later, you can connect your own domain, for example samsbakery.com. You must buy the domain first.
Next steps: pick one option and tell me.
+ like I have ADHD
one thing to do
Ask me to publish it with here.now. You get a link in about a minute. Send that link to your friends.
When I use subagents
A subagent is another agent my agent starts to hand off work. I use them when there’s grunt work like data collection or web searches, when the work can clearly be done in parallel, or when I think something can be done quicker and more efficiently that way.
It's also a good way to keep your context of your session clean. Running a bunch of web searches would pull in every websites text as context, and the info could be wrong and mislead the model throughout the conversation.
For subagent grunt work, a cheaper, faster model is fine. So I'll often ask for those agents to use smaller models.
I don’t write their prompts. I get my agent to. Agents write 'proper' prompt that I'd struggle to write myself. They include the right things like how to do the task, tools to use, and verification steps for completing it.
make a plan, write briefs for subagents to complete the tasks, give very specific design details and verification steps - agents must view their work. spawn luna high subagents. you orchestrate. parallelise the tasks.
This is an example of the kind of prompt it writes for its own subagents. Look at how it’s built. It has all the context it needs: what to read first, what it owns, the specifics it relies on, and the steps to verify its own work before it’s done.
~/repos/style-picker/briefs/look.md
# Brief: look
You own the Look tab: Aesthetic, Typography, Colour, Shape, Layout, Density, Imagery & icons. You grow it from 16 words to about 40, rebuild the minis on shared bases, and give every word a live preview.
Read first: `DESIGN.md`, `CONTRIBUTING.md`, `core/core.js`, `core/sample.js`, `layers/look.js`, `proto-shared.css` (the `.vz.ae .vz.spec .vz.pal .vz.shape` rules), `proto-preview.css` (the `.pp` rules). Then `vocab.js` (v11's 164 terms with `what`, `why`, `seen`, CSS vars, Avoid lines) and `research/aesthetics.md`. Look at `research/v11-shots/` to see how v11 drew aesthetics.
## You own `layers/look.js`, `layers/look.css`, `research/shots/look/`. Prefix: `lk-`. Port: `SHOT_PORT=9411`.
## Target vocabulary Pick from `vocab.js`. Keep the 16 that exist (ids stay the same). Add: - **Aesthetic** 4 → 12. Choose 8 more that are visually distinct at 200 × 118 and useful to a builder of small sites and tools. Good candidates: Bauhaus, Art Deco, Blueprint, Pixel, Letterpress, Riso, Neon, Sketch, Y2K, Vaporwave, Zine, Glass. Not: anything that needs a photo to read. - **Typography** 4 → 8. Add faces and treatments a builder can name: Humanist sans, Geometric sans, Slab serif, Old-style serif, Uppercase tracked, Tight display, Variable weight. Choose 4. - **Colour** 4 → 8. Add 4 from: Duotone, Earth tones, Neon on dark, Paper and ink, Warm greys, Cool greys, Brand block. - **Shape** 4 → 8. Add 4 from: Rounded 8, Hard offset shadow, Inset, Glass blur, Outline only, Tinted surfaces, Chamfer. - **Layout** 0 → 6: Single column, Sidebar and content, Card grid, Masonry, Split screen, Dense table. (Layout minis are wireframes in `--ln`/`--fg`.) - **Density** 0 → 3: Airy, Comfortable, Compact. (Same list mini; only row height changes.) - **Imagery & icons** 0 → 5: Photography, Line illustration, Pixel art, Outline icons, No icons. Draw imagery with CSS or inline SVG. No external images. Every word gets `why`, `seen`, `spec`. Take them from `vocab.js` where they exist; tighten to DESIGN.md text rules. `spec` must be concrete: font names, hex codes, px, radius, shadow values.
## Mini bases (one base per group, only the term changes)
- Aesthetic: a full-bleed mini page (header row with name and two nav words, one display heading, one button, two small boxes). Colours, type, radius, border, shadow come from the aesthetic. Signatures allowed (Swiss grid lines, terminal cursor) but one per aesthetic. Rebuild `V.ae` output as `lkMini.ae()` in your file; do not change core.
- Typography: one display word, 40px, in the face, plus a 9px line under it in the same face: the face's name. The display word is from your pool (DESIGN.md). Background `--sf`.
- Colour: the same small page (heading, button, four-swatch strip) with the palette applied. Keep the strip.
- Shape: the same small panel (heading, button, one input outline) where only corners, border, shadow change.
- Layout: a 200 × 118 wireframe of the page shape in `--ln` blocks with one `--fg` block for the main content.
- Density: the same list of 6 rows; row height 22 / 16 / 11px.
- Imagery: the same card with one figure area; the figure is drawn in the style (photo = soft gradient block with a horizon; line = 1px strokes; pixel = 8 × 6 blocks; icons = three 12px glyphs; none = text only).
All minis: `width:100%;height:100%`, no fixed px widths, readable in light and dark (Look minis may carry their own colours because colour is the idea).
## Previews
- Aesthetic: `samplePage(vars, id)` with a full var set like `AE_VARS`. Define `LK_VARS` in your file. Add `[data-sig=<id>]` signature rules in `look.css`.
- Typography, Colour, Shape: `samplePage(Object.assign({}, NEUTRAL_VARS, yourVars))`.
- Layout: write `lkPage(layoutId, vars)` in your file that renders the Specimen content in that layout. Reuse `.pp` classes; add `.pp.lk-<layout>` rules in `look.css`. Content from `ROWS`.
- Density: the sample page with `--p-gap` and row padding changed; show a 7-row table.
- Imagery: the sample page with a figure block in the hero and a 3-card row with figures, drawn in the style.## Steps 1. Rebuild the 16 existing minis on the bases above. Check, shoot the Look tab light and dark, look at it, fix. 2. Add Aesthetic and Typography words with previews. Check, shoot, look, fix. Commit. 3. Add Colour, Shape, Layout. Check, shoot, look, fix. Commit. 4. Add Density, Imagery. Check, shoot, look, fix. Commit. If time runs short, ship fewer words. Every shipped word has a good mini, a live preview, `why`, `seen`, `spec`.
## Verification ```sh cd ~/repos/style-picker; P=9411; O=research/shots/look; mkdir -p $O node tools/check.mjs --layer look SHOT_PORT=$P SHOT_FULL=1 node research/shot.mjs "file://$PWD/proto-d.html?tab=look" $O/tab.png SHOT_PORT=$P SHOT_FULL=1 SHOT_DARK=1 node research/shot.mjs "file://$PWD/proto-d.html?tab=look" $O/tab-dark.png SHOT_PORT=$P node research/shot.mjs "file://$PWD/proto-d.html?tab=look" $O/tab-390.png 390 844 for id in <every id you own>; do SHOT_PORT=$P node research/shot.mjs "file://$PWD/proto-d.html?tab=look&pv=$id" $O/pv-$id.png; done pkill -f "style-picker-chrome-$P" ``` Open and look at every PNG. Fonts load from Google Fonts; give the shot 3 seconds (`SHOT_WAIT=3000`). Check: minis fill the frame, no clipped text, faces actually render (not a fallback), previews fill the stage, light and dark both read.
## Git `git add layers/look.js layers/look.css research/shots/look && git commit -m "look: …"` after each step.
## Report Ids added, ids changed, files, check summary lines, screenshots viewed, anything skipped, requests for core or shell.
A typical build will usually include a few main sessions, I start new ones when the session has gone on a while or I just want a “fresh” mind to take a step back and look at everything. Then those main sessions often have multiple subagents doing grunt work.
How do you like to talk to agents?
It changes over time. When you find yourself repeating something to an agent over and over, that probably wants to be a written instruction. If that instruction gets too big, it might want to be a skill.
All of these are things for you to test and figure out. Do I like it when it uses simplified technical English? Or is it better if I say talk to me concisely with bullet points?
Notes
- I just talk to them. Voice when I’m rambling, typing when I’m clear.
- When it’s not getting it, I should just say the damn thing. A screen recording helps.
- I think about what done looks like, because its checks aren’t my checks.
- I question it: why, explain this, thoughts? Then the decisions go in a file.
- When I don’t know what I want, it grills me. When it just agrees, I push back.
- Anything I keep repeating goes in my instructions. Grunt work goes to subagents, and my agent writes their prompts.