Everything from today's session, plus the on-ramp to try it yourself this week.
v2026.09.08.1330 • 🌐 HOMESTEAD
The one idea
The tool does your work as well as you can describe your work. Writing a skill or a setup doc is the same move you've done your whole career: briefing a vendor, showing the new hire the ropes. The test is simple, how would you hand this off if you were out sick tomorrow? Write that down. Then it stacks, each version sharper, the workflow faster every time.
Intent to pixel
You're building the glue, not always the whole app.
Look at your week for the steps that eat human time and are really just moving text, images, or spreadsheets around a computer. Those are your primitives. Chain a few together, or just glue two tools you already use, and you have a workflow that saves hours. You describe it once; the gap between the idea and the result collapses.
You don't have to build the whole tool. Compose a few primitives, or glue two tools together.
The tool ladder
This is just the next rung.
You've climbed this ladder your whole life. Fingerpaint, then a pencil, then paint, then a full studio. Each tool didn't make you a better artist, it raised the ceiling of what you could attempt and moved where your effort went. Dig with your hands and the digging is the whole job. Pick up an excavator and you can move a mountain, but now the only thing that matters is knowing exactly where the hole goes. That's the shift: as the tool gets more powerful, execution gets cheap and aiming becomes everything. These new tools are the next rung, not a different ladder. You already know how to climb.
Start here
If you're an artist, not an engineer.
Read this first, because it's the part that stops most people. You do not need to be an engineer for any of this. None of it came from a computer science degree. It came from trial and error, breaking things on a safe copy until they worked. That's how you got good at your craft in the first place.
The words are the only scary part, and they're smaller than they sound. Here are the four that trip people up, in terms you already use:
Agent: a new hire who can actually open your files and do the work, not just answer questions. You still art-direct it.
Skill: a style guide you write once, so you stop giving the same note twice.
Context: the reference pile on the desk. Load the right refs and the work comes back right.
Branch: a duplicate layer you can paint on freely and throw away if you hate it. The original never moved.
You brief, you review, you redirect. You've done that your whole career. This just points it at a faster executor.
Remix
Don't start from scratch.
You don't even have to build the glue. The fastest way in is to take a working app and bend it to your job. Google AI Studio's App Gallery is full of small, real apps built on Gemini: browse them, open one that's near what you need, and hit Copy App. Now it's yours to change. Keep the core function, swap in your subject. That's the whole move: you're not inventing the machine, you're redirecting one that already runs. Same as it ever was, just start from someone else's finished work instead of a blank page.
1
Tools
Interfaces: what you talk to
Claude Desktop (Claude Code):claude.ai/download. Chat plus a coding agent that reads and writes your files.
Install any of them as a Claude Code plugin marketplace:
claude plugin marketplace add graysonchalmers/Skills-Public
claude plugin install art-brief@skills-public
⚠ Security first. A skill can run code and read your files. Treat one from an unknown source like any downloaded script: read the SKILL.md and any bundled scripts before installing, or have your agent security-review it first. Stick to official and known authors when you can.
Getting them right
Write skills in your own words, not the tool's. If your team says "brief," don't let the skill say "prompt template."
Build a skill on the second time, not the first. Do it by hand once, then have the agent write the skill from what you just did.
One skill, one job. A skill covering five situations is a maintenance problem, not a shortcut.
Skills go stale like any doc. If it's months old, check it still matches how you work before trusting it.
3
Set the stage
Before you ask for anything, tell it the standing facts, the stuff you'd give a new vendor on day one. It cannot see your setup unless you say so. The more of it you load, the sharper the answer. Load it once at the top (a system prompt, a project doc, a skill) instead of repeating yourself every message. This is "in-context learning" in plain terms.
Same model. The context you load is the whole difference.
Your environment: OS, machine, what's installed. "Windows, PowerShell, Python 3.13."
Your stack: the software and services you actually use.
Your vocabulary: what your team calls things.
Your constraints: budget, engine, house style, and what it must never do.
Your goal and role: what you're trying to do, and who the output is for.
Grow it into a knowledge base
Once you have standing context, let the model keep it. Karpathy's "LLM wiki" pattern: drop your raw notes, docs, and chats in a folder, and have the agent compile them into a set of tidy, linked markdown files it reads back later. A second brain, kept current, instead of re-explaining yourself. (The same instinct shows up in machine-readable standards like llms.txt for websites and schema.org structured data for the web at large.)
4
How to ask
Describe the output shape, not just the topic. "A one-page brief with these five headers" beats "write me a brief."
Give it the constraint that's biting you: budget, deadline, a reference, a thing it must not do.
Ask for the plan before a big task. Catching a misread at the plan stage is free; catching it after a full render is not.
Don't write the prompt, ask for one. Tell it your goal and have it write you the prompt that achieves it, then run that. It knows what it needs to hear better than you do.
Talk, don't type. Saying your intent is faster than typing it, and these drop speech into any text field on your machine:
Built in, free: Apple Dictation (Mac), Windows voice typing with Win+H (PC).
AI cleanup, Mac and PC: Wispr Flow.
Mac, private and offline: Superwhisper.
5
Write it clearly
The instructions above only work if the model can act on them without guessing. Two writing standards, both older than LLMs, both built for a reader who cannot ask a follow-up:
Simplified Technical English (ASD-STE100): the military and aerospace manual standard. Active voice, short sentences, a controlled vocabulary where each word has one meaning. There is even a Claude skill that enforces it.
Information Mapping (Robert Horn): the textbook and training standard. Structure over prose, every chunk under a label, one idea per block.
Takeaway: write your skills and prompts the way these write manuals. Short, structured, one instruction per line, no ambiguous words.
6
Context management
Section 3 was what to load in. This is keeping it from overflowing.
The agent only "remembers" what's in its context window. Long sessions fill up and old context gets dropped. That is "context rot."
So for anything spanning sessions, keep an external "baton" doc: a short state note the agent reads at the start and updates at the end.
Simplest version: one file, HANDOFF.md. Written last each session, read first the next. That's the whole trick.
7
Work in loops
The real payoff of version control isn't "in case your computer dies." It's that you can try things fearlessly. Work in small loops: one change at a time, on a safe copy, kept only if it works.
Each turn pulls in the rest of the guide: a brief, your skills, and your baton.
Pick + spec it. One small thing, and write the brief for it. That brief is the same move as Art-Brief (section 2), pointed at whatever you're making.
Branch. A safe copy to work in.
Build it with the agent, using your skills (section 2).
Let it check itself. Ask for smoke tests, and have it run them and read its own errors. This is the accelerator.
Keep it (and note what changed in your baton, section 6), or revert. Your last good build is right there, untouched. Then repeat.
Match the brief to what you're making
A tool: a PRD or a short technical design doc.
3D art: an art brief.
A video: a shot list or treatment.
A dataset or report: a spec.
Two words worth knowing
Branch: a parallel copy of your project where you try something without touching the version that works.
Worktree: the same idea checked out as its own folder, so the experiment and the working version sit open side by side.
Keeping a change means committing it and jotting what changed in your baton (section 6). Small scope is the whole trick: one thing per loop means a revert only ever costs you that one thing.
8
Test them yourself
Models differ, and the differences matter for your work. You don't need to know how any of them work under the hood. Big, small, "mixture of experts," that's the vendor's org chart, and you don't hire on the org chart. You hire on the work that comes back. Judge a model the way you judge a vendor, by the output on a job you care about. Keep a few on hand, and aim each brief at the one that's best at it.
Don't take a leaderboard's word for it. Build your own tiny benchmark from a question only you can grade.
Whichever model gets your kind of question right is your model, no matter the leaderboard.
Pick one question from your job that's genuinely hard to answer well, one you already know a good answer to.
Ask a few different models the same question. Easiest path: OpenRouter, where you switch models against one prompt in one place.
Compare the answers side by side. The one that gets your kind of question right is your model, whatever the rankings say.
Save that question, and a few more, as a set you re-run whenever a new model drops. That's a benchmark, and it's yours.
Taken all the way, this becomes a real eval. My OSM-bench is that: a values-alignment benchmark for art outsource managers. You don't need to go that far to start.
9
A few things I built
None of this is fancy. These are small tools I made for myself, mostly to stop paying for something or to kill a chore. That's the point: the bar is low, and the payoff is real.
Nightly backups
A script that mirrors every project to my home server each night. Set once, forget it.
Text-to-speech
I wanted something better than Speechify, so I wrote my own. It reads anything on screen aloud.
A Lightroom stand-in
I didn't want to keep paying Adobe, so I built a photo editor that does the parts I actually use.
Each one started as a single annoyance and a loop or two. None of them took a career in software.
Glossary
Agent
an AI that can act on your files and run tools, not just chat back.
Model
the specific AI you're using (Claude, GPT, Gemini). Different models have different strengths.
Prompt
what you type to ask the model for something.
Skill
a reusable instruction file that teaches the agent to do a task your way.
Context
everything the model can see right now. It has a size limit.
Context rot
when a long session fills up and older context gets dropped or goes fuzzy.
Baton
a short state file the agent reads at the start of a session and updates at the end (often HANDOFF.md).
Branch
a parallel copy of your project to try something without touching what works.
Worktree
the same idea, checked out as its own folder so both are open at once.
PRD
product requirements document. A short brief for a tool: what it does and who it's for.
Smoke test
a quick automatic check that the basic thing still works.
API
the plug you call a model through when you build your own tool.
Further listening
Latent Space: the AI Engineer podcast. Builders talking about what actually ships.
ThursdAI: a weekly roundup of what happened in AI, so you don't have to track it all.