· 5 min read
Day 5 | My AI workflow: from one request to site changes and article drafts
The earlier posts covered the site's architecture, backend and cost. This one is about how I work with AI: making a request, talking through the direction, doing the work, and finally saving the result.
The whole flow:
Make a request → brainstorm the requirements and options → agree on what "done" means → run and check it with goal → save the result → I take over and review it.
| Piece | Role in the workflow |
|---|---|
| AI model | Understands the request, analyzes data, writes content and decides the next step |
| Harness | The execution system around the model: manages conversation context, tool calls, permissions and the run itself |
| Superpowers brainstorming | Clarifies the requirements, discusses options and turns them into a design I can sign off on |
| Codex / Claude goal | Tracks the goal and checks after each run whether to keep going |
| Project docs and skills | Provide the working rules, formats and how things get delivered |
| CLI and other tools | Actually read, change or save data |
| Studio | Keeps article drafts in one place for me to read and edit |
The AI calls a tool, gets the result and decides what to do next; all of that runs on the harness. OpenAI on the harness
1. Making the request: the direction settles during the conversation
This post is an example. I first wanted to write about Supabase MCP, then added that I wanted to cover how AI looks up data and how I approve changes, then switched to the angle of editing an article. In the end I moved that topic to day ten and made day five about the workflow.
A request is rarely complete the first time. My part is saying what I want done this time, then adding constraints as I go: which angle, which day, save it as a draft first. The AI has to keep up with those changes, know which decisions have moved, and keep working on the same draft.
2. Brainstorming: get the problem clear first
For tasks that need talking through first, I use Superpowers' brainstorming. It first looks at the existing project and what I'm after, asks questions to pin down the requirements, then discusses options and trade-offs. For bigger tasks it writes the decisions up as a spec for me to approve before going further.
At this stage I confirm three things: what problem we're solving, what's in scope, and how far it has to go to count as done. For an article that means deciding whether it's a long post for the site or a social draft, where it gets saved, and whether publishing is part of it.
3. Rules live in docs, so I don't repeat them every time
My site's repo has AGENTS.md and CLAUDE.md for working rules, and the visual design lives in DESIGN.md. For example, the design spec has to be read before touching the UI, and the mobile layout has its own checks. When the AI changes a feature it has something to go on, and I can edit the docs directly to record decisions for next time.
Writing has its own Studio writing skill: how public content gets put together, each platform's format limits, and where drafts go. Articles also get a Chinese polishing pass that cuts repetition and filler while keeping what I meant.
The split is simple: project rules cover how the site gets built, writing rules cover how articles get delivered, and the conversation decides what to do this time.
4. Driving it with goal, and checking its own work
Once the direction and the done criteria are agreed, I use /goal for tasks that need to keep going.
Goal checks on its own whether the goal is met. If it isn't done and there's still a workable next step, it keeps going.
It can also stop when it hits a budget limit, the user interrupts, or it's blocked on something that needs outside help. So when setting a goal, spell out the expected result, how to verify it, and the scope. (Codex Goals docs)
For an article draft, the done criteria could read:
Turn the approved outline into a Traditional Chinese article, save it to the specified Studio draft, read it back and confirm the body matches. Keep it pending review and don't publish; if it can't be saved, explain where it got stuck and keep the draft.
Where the result goes, how to confirm it saved correctly, what's out of scope: all of it has to be written down, so the AI has something to judge "done" against. Site features work the same way: the done criteria can be a user flow, test results and what actually shows on screen.
While running, the AI reads files, edits code and runs commands through tools. Studio also has its own CLI that can look up articles, read versions and send finished text into the review queue.
5. Saving and checking: "it says it's written" isn't "it's saved"
When a tool reports it's done, the result still needs checking. Code changes run their tests, UI changes get looked at on screen, and articles get checked that the body actually saved, the platform is right, and it's still a draft pending review.
That's why I built Studio into my personal site. The conversation is for talking through direction, and drafts have a fixed place where I can keep working on them. One topic can have a site version and a social version, each with its own content and status.