Nostr notes by

Grow Your “Agentic Prompt” One Section at a Time This series ...

2026-10-28T03:16:21Z

Grow Your “Agentic Prompt” One Section at a Time

This series covers prompt patterns for agents that run in a loop: the agent builds something, measures it, improves it, and repeats the cycle the next day without a person supervising. Across this series I cover:
How to grow a long prompt without it contradicting itself
How to keep an agent from damaging the machine it runs on
How to hand an agent a loop it can run without approvals
How to let real usage tune an interface
How to get creative output you don’t have to babysit
How to make the loop improve its own prompts
These patterns are for builders whose agent work looks like mine. I write prompts for Claude Code and hand them to an agent that works on its own for hours. My agents run across many sessions, so the prompt has to carry everything the next session needs to pick up the work. I patch my prompts constantly, and before I used these patterns each patch made the prompt longer and less coherent. These patterns pay off on the second and later cycles of a loop, so one-shot prompts get little from these patterns.
My daughter is old enough to have a phone so she can keep up with her friends. I’ve come to the conclusion that notifications, infinite scroll, and algorithms tuned for engagement are producing adults with limited reasoning and focus. So I gave her a Light Phone. She can text, take photos, and listen to music, and she skips the cognitive denial of service attack that comes with a modern smartphone.
She also needs to start learning how to make things with AI, so I built her an Omarchy workstation. Then I realized a workstation for learning AI was a bit like putting her on a vegan diet. Veggies are nice and all, but learning needs some fun in it. Quake had an outsized influence on my origin story. Quake is the reason I learned TCP/IP networking, and Quake pulled me into hacking and security. Maybe Quake would do the same for her.
So I set out to build a Quake server she could play on with her friends. The project vends a game server, multiplayer clients that run on Mac, Linux, or a mobile browser, and a nightly SportsCenter-style recap of the night’s games, complete with breakfast awards we review the next morning. I wanted the server to make it worth practicing a few Linux commands every day. I wanted an agent to build, run, and keep improving the whole system, on a home server that already runs a bunch of services my family relies on.
Each pattern in this series is a small trick, usually a paragraph or two of prompt text. The value comes from how the patterns stack on each other. I’ve found these patterns produce productivity acceleration similar to compound interest. A savings account that earns interest grows slowly at first and then quickly. Each year’s gain becomes part of the base for the next year. These patterns work the same way for agentic development. A build plan that absorbs every successful experiment makes the next rebuild better. A log of every confusing instruction makes next week’s prompts clearer. Each cycle of the agent’s loop starts from a higher base than the cycle before.
This first post covers how to grow the prompt itself. I couldn’t write my agent’s prompt in one pass, and rewriting the prompt every time a gap showed up kept breaking rules I’d already gotten right. My build loop went through eight rounds. Each round surfaced a requirement I hadn’t planned for, like sudo commands on a shared box, iPads, and an LLM that talks to the kids during play. Each new requirement became a new section added to the prompt instead of a rewrite.
I found these practices produced large amounts of time savings while the prompt grew:
Wire every new section into the plan contents list, the acceptance criteria, and the directory layout. The agent decides what to build from the plan contents list, what to test from the acceptance criteria, and where to put files from the directory layout. A requirement missing from the plan contents list, the acceptance criteria, and the directory layout gets skipped. Inserting new sections into the plan’s shared planning section ensures each new requirement built, tested, and stored in accordance with standards for the whole project.
Rank your goals in a numbered priority list at the top of the prompt. When two goals conflict, the agent follows the higher-ranked goal instead of guessing. Every rule section must cite a priority number, so each goal keeps a single wording as the prompt grows.
Write one interpretation of each ambiguous requirement into the prompt, and tell the person who gave the requirement which interpretation you chose before the agent runs. The person can correct a wrong interpretation with one message, before the agent spends a week acting on the wrong interpretation.
My build objectives
I wrote the priorities first, in rank order, so the agent knows which goal to give up when two goals collide.
1. Protect existing services. Every service on this host keeps running exactly as it runs today. A Quake feature that risks an existing service gets dropped or redesigned.
2. Working LAN Quake. Quake clients on the LAN connect and play fun sessions.
3. Game modes. Deathmatch and Quake Team Fortress work.
4. Web app. A local web app serves players and the operator.
5. Creativity. The experience produces stories the family retells later.
Every rule section in my prompt opens by naming the priority the rule section protects. The standing rules section starts with “Each rule exists to keep priority 1 intact while you work.” When I added a privilege model section three rounds later, the privilege model section cited priority 1 instead of explaining again why the other services matter.
Problem: an agent hits conflicts between goals all the time, and a prompt that states its goals in several places gives the agent several different answers about which goal wins. Say the agent finds that QuakeWorld’s default port, 27500, is already taken by another service on the box. The networking section says players must be able to connect. The safety section says existing services keep running. If each section describes its own goal in its own words, with no ranking between the goals, the agent has no tiebreaker, and the agent could free the port by catastrophically stopping the other service. The wording of goals also drifts apart as the prompt grows, because each new section restates the goals a little differently, and after a few rounds two sections disagree about which goal wins.
Solution: I wrote the goals once, ranked, at the top of the prompt. Each rule section opens by naming the priority number the rule section serves. When two rules conflict, the agent compares the priority numbers of the two rules and follows the rule with the lower number. In the port example, priority 1 protects existing services and priority 2 is working Quake, so the agent picks a different free port and leaves the other service running. Later sections cite a priority number instead of restating the goal, so each goal has exactly one wording in the whole prompt and the sections stay in agreement as the prompt grows.
The pattern that carries over to any prompt: rank your goals once, in one place, and make every rule point to a rank. The ranking gives the agent a tiebreaker the orchestration agent can apply without asking you, and the single wording of each goal keeps new sections from redefining old goals.
Adding a section for each problem
When a new requirement showed up, I added a new headed section to the prompt for that requirement and left the existing sections as they were. My prompt is one markdown file with a heading per topic: priorities, standing rules, and one heading per build phase. Each requirement the file didn’t cover got its own heading. The new requirements showed up in this order:
RoundProblem that came upSection I added2Some steps need sudo and could hurt other servicesPrivilege Model and Change Control3Claude Code on the host can generate content during playPhase 4B: LLM-Powered Live Experiences4Players on iPads and iPhones need a way inResearch topic 10, iPad and iPhone play5Touch controls will need dozens of small tweaksPhase 5B: Apple Device UI Fast Loop6I want a daily page that recaps the last sessionPhase 4C: The Chronicler Agent7I want cheaper models doing most of the workOrchestration and Model Tiers
Problem: rewriting the prompt to absorb the iPad requirement would have meant touching the server, client, and testing sections at once. This would result in the loss of prompt instructions that I’d worked hard to tune and that produced high quality results.
Solution: I wrote the iPad requirement as its own research topic and left the server, client, and testing sections untouched. A new section can only refer to things the prompt already names, so each new section forced me to name the things the new section needed to point at. The privilege model needed to tell “commands that touch only my project” apart from “commands that touch the whole server,” so I defined privilege tiers. The feature toggles needed a list of features, so I created a feature manifest file. Resuming after an interruption needed a place to read progress from, so I created the STATE/ directory. Every later section points at the privilege tiers, the feature manifest, and the STATE/ directory by name instead of describing them again.
The pattern that carries over to any prompt: when a new section needs to refer to something that only exists as scattered descriptions, give that thing a name and a file. Named things become stable reference points that later sections can cite without redefining them.
Wiring each new section into the build, test, and file lists
After writing a new section, I edit three other places in the prompt: the plan contents list, the acceptance criteria, and the directory layout. The agent reads the plan contents list to decide what to build, the acceptance criteria to decide what to test, and the directory layout to decide where files go.
flowchart LR
P[Unanticipated problem] --> S[New prompt section]
S --> A1[Build plan contents]
S --> A2[Acceptance criteria]
S --> A3[Directory layout]
A1 --> B[Agent decides what to build]
A2 --> T[Agent decides what to test]
A3 --> F[Agent decides where files go]
Here’s the wiring for iPad support. The iPad research section was the new section. The edits below to the plan contents list, the acceptance criteria, and the directory layout made the agent build, test, and store iPad support.
Plan contents:
- Client bundle contents and install flow for Linux, plus the chosen iPad and iPhone path: browser client hosting and transport bridge, or native app build and install procedure, including any local TLS setup and the per-device onboarding steps.
Acceptance criteria:
- An iPad and an iPhone each complete the documented onboarding and join the same match as a Linux client, with playable frame rate and working touch or controller input.
Directory layout:
ios-ui/ # Apple device UI configs, envelope, tests, telemetry, fast-loop log
The agent builds and tests iPad support only when the plan contents list and the acceptance criteria both list iPads. The agent builds the items in the plan contents list and tests the items in the acceptance criteria. A prompt with the iPad research section alone would get an agent that researches iPad options, writes a recommendation, and then builds and tests a Linux-only server.
Problem: a requirement described only in its own section stays out of the lists the agent builds and tests from, so the agent researches the requirement and never ships the requirement.
Solution: after adding a section, add a line for the new requirement to the plan contents list, the acceptance criteria, and the directory layout. I use the plan contents edit, the acceptance criteria edit, and the directory layout edit as a checklist every time the prompt grows.
Naming the files each phase produces
Every phase in my prompt ends with an Artifact line listing the files the phase must produce. The agent marks the discovery phase complete when these files exist:
Artifact: STATE/discovery.md, STATE/storage-decision.md, STATE/blog-howto.md,
STATE/healthcheck.sh, STATE/baseline-health.md
The listed files are the documentation for the phase, so the record of the phase is the work the agent already produced. The same files are also where a fresh agent session picks up the work after an interruption.
Stating which interpretation of an ambiguous requirement got encoded
When a requirement could mean two things, the prompt author writes one interpretation into the prompt and tells the person who gave the requirement which interpretation was chosen. I asked for a daily recap page that becomes “viewable the day after the last visit.” The phrase could mean the day after anyone’s visit or the day after a specific kid’s visit. Claude, drafting the prompt with me, chose the day after anyone’s visit, wrote that interpretation into the publication rules, and told me the choice in the same reply. Correcting the interpretation at that point would have taken one message from me. Correcting the interpretation after a week of the agent publishing on the wrong schedule would have meant reading logs to figure out why the page appeared on the wrong days.
What I’d do differently
I worked these practices out while the prompt was already growing. Starting the next project with these improvements in place from the first draft would make each round of growth cheaper.
I’d put empty headings for the plan contents list, the acceptance criteria, and the directory layout into the very first draft.
Why: without the headings in place, wiring each new requirement into the build, test, and file lists depends on my remembering to do it. A section that misses the wiring describes work the agent researches and never builds.
How: start the first draft with a “Plan contents” heading, an “Acceptance criteria” heading, and a “Directory layout” heading, each empty. Every time I add a section, I add one line under each heading in the same edit, so each new requirement reaches the build, the tests, and the file layout in the round I write the requirement.
I’d write the priority list before anything else and add only rules that name the priority they serve.
Why: a rule with no priority behind it gives the agent instructions without a reason, so the agent can’t tell how much the rule matters when the rule conflicts with another rule. Unranked rules also make the prompt longer without making it clearer.
How: write the ranked goals as the first section of the prompt. Before adding a rule, write the priority number the rule protects as the rule section’s first sentence. If no priority fits, either the rule is unnecessary or the priority list is missing a goal, and I fix the priority list first.
I’d keep a dated log of every interpretation chosen for an ambiguous requirement, in the prompt repo.
Why: interpretations get decided in conversation and then disappear from memory. When the agent does something odd months later, I need to know whether the agent is following an interpretation I approved and forgot, or whether the agent is making a mistake.
How: create an INTERPRETATIONS.md file next to the prompt. Each entry records the date, the original requirement wording, the interpretation chosen, the alternative that was rejected, and the prompt section that encodes the interpretation. Check that file first whenever the agent’s behavior surprises me.
Summary
A prompt for a long-running agent grows one requirement at a time, and these practices kept my prompt coherent through eight rounds of growth:
Rank your goals in a numbered priority list at the top of the prompt, and open every rule section with the priority number the rule serves. The agent uses the ranking as a tiebreaker when goals conflict.
Add a new headed section for each new requirement and leave the existing, tuned sections as they are. Give a name and a file to anything a new section needs to point at.
Wire each new section into the plan contents list, the acceptance criteria, and the directory layout, so the agent builds, tests, and stores the new requirement.
End every phase with an Artifact line naming the files the phase must produce. Those files serve as the phase’s documentation and as the restart point after an

https://patrickmccanna.net/grow-your-agentic-prompt-one-section-at-a-time/

#prompt #quake #claudecode #linux

#rss #feeds #linksharing #qwibbit

Automation: Taxes and expense tracking for your utility bills: ...

2026-10-16T04:35:37Z

Automation: Taxes and expense tracking for your utility bills:

Ten minutes now saves you a weekend in April
Picture next April. You sit down to do your taxes, and the form asks what you spent last year on electricity, trash, water, and gas. Four companies sent you roughly twelve bills each, and all 48 sit scattered through a year of email.
Digging them out by hand costs an afternoon, and a missed bill puts a wrong number on your return. Today your bills land in your inbox with everything else. After the work below, each bill files itself into a single tax folder, and year-end reporting means opening that folder and adding up four totals.
Build four email rules so every utility bill files itself into one tax folder
This takes about ten minutes, once.
Find one recent bill email from each company: electricity, trash, water, gas.
Create a label (Gmail) or folder (Outlook) named “Taxes 2026.”
Build one rule per sender:
Gmail: open the bill, click the three dots, choose “Filter messages like these,” then “Create filter,” and check “Apply the label.”
Outlook: right-click the bill, choose “Rules,” then “Create rule,” and set it to move messages from that sender into your folder.
Apply each rule to existing mail so this year’s earlier bills move over too.
Check the folder when a bill arrives, total it once a year
When a bill arrives: glance at the tax folder and confirm the bill landed there. Five seconds.
Every January 1: create the new year’s folder and point the four rules at it. Five minutes.
At tax time: open the folder, total each utility, and enter the four numbers.
I learned this one the slow way, searching my inbox bill by bill.
Some additional gmail automation notes:
Gmail calls tags “labels,” and filters apply them automatically.
Create a filter that applies a label
In Gmail on the web, click the slider icon at the right edge of the search bar (Show search options).
Fill in the properties to match: From, To, Subject, Has the words, Doesn’t have, Size, Has attachment.
Click Create filter (bottom of that panel).
Check Apply the label, then pick an existing label or choose New label.
Optional: check Also apply filter to matching conversations to label existing mail too.
Click Create filter.
Shortcut from an existing email: open the message, click the three-dot menu, choose Filter messages like these. Gmail pre-fills the sender.
Matching more precise properties
The “Has the words” field accepts any Gmail search operator, so you can match on far more than the form fields offer:
{term1 term2} is shorthand for OR, and a space between terms means AND
from:(alice@example.com OR bob@example.com) matches either sender
list:announce@example.com matches a mailing list
filename:pdf or filename:invoice matches attachment type or name
subject:(invoice OR receipt) matches either subject word
to:me+shopping@gmail.com matches a plus-address you gave out
larger:5M matches by size
-from:boss@example.com excludes a sender

https://patrickmccanna.net/automation-taxes-and-expense-tracking-for-your-utility-bills/

Working with AI, one folder per project: every session creates ...

2026-10-16T03:40:19Z

Working with AI, one folder per project: every session creates compounding value

Many students now study with AI chat apps such as Claude or ChatGPT. A common approach works like this: you open the app, upload your study guide, and ask the AI to write practice questions from it. The AI reads the guide and quizzes you on your own material. For a single study session, this works well.
The approach feels good in the short term- but it fails to support you in the long term. Three weeks after the midterm, the final arrives. Your earlier conversations are buried in the app’s history, the study guide needs uploading again. You retype a request you only half remember. Each chat answer gets used once.
Keeping your prompt files on your computer is a more sustainable way to work. Each project gets a folder holding your source material, the requests you wrote, and the documents the AI produced. Save copies of your prompts in the prompt folder. Invoke the coding agent to read the prompt file directly. Every new session then starts with all the information and solutions you already built. Your results improve each time you enhance the files.
Create one project folder with resources, prompts, and outputs so the AI works from your files and saves its work beside them
This takes about ten minutes per project.
In your Documents directory, create a folder named for the project, such as “bio-final.” Inside the project folder, create three subfolders: resources, prompts, outputs.
Copy your source material into resources: a study guide, a research document, a CSV of transactions.
Write your request as a text file and save it in prompts, such as “practice-exam.md.”
Open a coding agent in the project folder. A coding agent, such as Claude Code, is an AI program that reads and writes files on your computer at your direction. Tell the agent to read your prompt, process the files in resources, and write its results to outputs.
Debate the draft, then fix the prompt that produced it
When the agent produces a document: read the document and argue with the agent about it. Push back until the document matches what you want.
When you settle on a version: ask the agent to compare your original prompt with the result you ended up with, and to rewrite the prompt so it produces that result on the first try. Save the new prompt.
When you start any new AI task: create its folder first.
Each cycle results in a sharper prompt. Each run gets you closer to the output you want. Over a semester, your Documents directory becomes a record of every AI project you have run, each one reusable.
Build the folder first and the answers will keep paying you back.

https://patrickmccanna.net/working-with-ai-one-folder-per-project-every-session-builds-on-the-last-one/