One prompt set up my AI coding workflow: PROGRESS.md, skills, and review loops

A while back I wrote about my AI coding workflow. That post was about IDE assistants: plan before you code, review every line, break tasks down until the model stops struggling. The bones of that advice still hold, but my day to day looks nothing like it anymore.

I don't sit next to an autocomplete anymore. I run coding agents, usually several at once, working in parallel on different features for hours at a stretch. Some of those sessions stay alive for weeks. And most of the infrastructure holding this together is markdown files.

Here's the part I actually want to tell you about though. I didn't sit down and design this system. Most of it got built in a single session, by the agent itself, and it started with me reading a blog post.

The prompt that started it

Anthropic's Claude team published a piece called Loop engineering: Getting started with loops. It's about the different shapes of agentic loops: turn-based, goal-based, time-based, proactive. Good article. But reading a workflow article and nodding along changes nothing, I've nodded along to a hundred of them.

So instead of nodding, I opened a session and sent this:

Read this article, review my current workflow, and tell me 5 things I can do to be more productive https://claude.com/blog/getting-started-with-loops

That's the whole prompt. The reason it works is the middle part: review my current workflow. The agent wasn't reasoning in the abstract. It had my context: my instruction files, my progress notes, weeks of accumulated session history on that machine. It knew what my workflow actually was, including the janky parts I'd stopped noticing.

It came back with five concrete suggestions. Turn my hand-rolled PR review ritual into a proper loop. Script the deterministic steps instead of re-reasoning them from scratch every session. Encode my verification habits as skills. Add scheduled proactive loops that watch production health. Run a morning digest of things blocked on me.

Useful list. But the real unlock was the follow-up. I said: can you set up the right skills and workflows, be thorough. The agent came back with a plan, and I replied with the four words that did most of the work:

just figure it out and set it up

By the end of that session it had built the whole thing, live-tested against real data: two scheduled review pipelines, four development-lifecycle skills, a git hook that hard-blocks dangerous commands, and email delivery so the reports land in my inbox. I approved decisions and vetoed a couple of ideas. It did the rest.

If you take one thing from this post: don't just read workflow articles. Hand the article to an AI that knows your workflow, and ask it to apply the ideas to you. Then let it build the result.

The rest of this post is what that system looks like now, and where the pieces that predate that session came from, because a couple of them were earned the hard way.

PROGRESS.md

This one came before the big session, out of pure pain.

When you're running four or five parallel agent sessions, and one of them has been going for two weeks, jumping back in is brutal. I'd open a session I hadn't touched in days and spend twenty minutes scrolling, trying to reconstruct where we were, what was blocked, what I'd promised to test. I kept losing the thread, and losing the thread is expensive. The agent has the same problem in reverse: every new session starts blank, with no idea what we decided yesterday or which approaches we already rejected.

Both problems turned out to have the same fix. I added a standing rule to my global agent instructions: every session maintains a PROGRESS.md file in the working directory, and keeps it current turn by turn, not just at the end.

After each meaningful chunk of work, the agent appends an entry covering:

• What was actually done, concretely: files, commits, commands, outcomes
• Decisions taken and why, including the options we rejected
• Current state, open questions, and the next steps
• Anything I'd need to resume cold

The part that makes it work is a pinned "Current state / Next up" section at the top of the file, updated every turn. When I come back to a session after four days, I read that block and I'm oriented in about thirty seconds.

The other half of the rule: when a session starts, the agent reads PROGRESS.md first, before doing anything else. So the file isn't just for me. A fresh session inherits the context of every session before it. This is also, not coincidentally, why the "review my current workflow" prompt worked at all. The agent had these files to read.

Here's the shape of a typical entry (details invented, structure real):

## Current state / Next up
- PR #142 open, review round 2 in progress
- BLOCKED: rate limit fix needs a decision on retry strategy (options below)
- Next: address review findings, then run the deploy smoke checks

## Turn 14 (evening)
- Fixed pagination bug in export service (commit a1b2c3d).
  Root cause: the row cap silently truncated large exports.
- Decided AGAINST caching the results. Rejected because exports
  are rare and the cache invalidation wasn't worth it.
- Open question: should retries back off exponentially or fail fast?

One more thing I ask for: every few turns, the agent proactively resurfaces the big picture. A short recap of the overall goal, where we are against it, and what's left. When you're twelve review comments deep into a PR, it's shockingly easy to forget why the feature exists.

The file stays untracked, by the way. It's my session context, not codebase documentation. It never goes into a PR.

Skills: write the lesson down once

Skills are what the agent built the most of in that session. A skill is just a markdown file with a description of when it applies and a procedure to follow. The agent loads it when the situation matches. No code, no framework, just a written playbook.

My rule of thumb since then: anything I've explained to an agent twice becomes a skill.

A few from the collection:

A verify skill. Before the agent claims a change works, it has to actually drive the affected flow end to end and observe the behavior. Not "the tests pass". Not "it compiles". Open the thing, click the thing, watch it work. Agents are eager to declare victory, and this skill exists because I got burned by "done!" one too many times.

A deploy smoke skill. After a merge to main, the agent watches the deploy finish, hits a set of canary URLs on production, and checks the error tracker for any new issues in the deploy window. It sounds obvious. It also would have caught, much earlier, several problems I instead found out about from users.

A PR description skill. This one was born from a specific failure: the agent once wrote a changelog based on what it assumed the commits did. Plausible, confident, wrong. The skill now says: read every commit's actual diff before describing the work, and if the diff contradicts the commit message, the diff wins.

Each of these encodes a lesson I learned the annoying way. The difference from human teams is what happens next. A human team spreads lessons through onboarding and osmosis, slowly, with loss. My setup spreads them by editing a file. Every future session, on every machine, inherits the scar tissue without the scar.

The Codex review loop

This is my favorite part of the whole setup: two AIs reviewing each other's work. The habit predates the skill by over a month, and it started with a production bug report, so this one I did earn manually.

Claude writes the code and opens the PR. Codex, a different model from a different company, reviews it. The loop goes like this:

1. Open the PR on a clean branch and wait for the review
2. Fix every finding properly. Fix the underlying issue, not a workaround
3. Push, then reply to each review comment with the fix commit and a one-line summary, so every thread has a paper trail
4. Each push triggers a fresh review. Loop until approval

Two to four rounds is normal. And the findings are real more often than you'd hope: pagination that broke past a database row cap, a race between stale async work and fresh state, a migration that could have dropped the only good index under a specific failure mode. Different models miss different things, which is exactly why the pairing works. The reviewer has no attachment to the code and no memory of the author's intentions. It just reads what's there.

Now the gotcha, because this one cost me. Codex signals "no further suggestions" with a thumbs-up reaction on the PR. Not a comment. Not a review. A clean pass produces no new event on any endpoint you'd think to poll. My agent sat there for 45 minutes waiting for a verdict that had already been delivered as an emoji.

That incident is why the loop is now a written skill instead of a habit, complete with the rule that came out of that afternoon: never wait on a single proxy signal. Bound the wait, and when time runs out, go inspect the actual state instead of assuming the notification is still coming. Which is decent advice for distributed systems generally, learned here via emoji.

Sessions that run while I sleep

This was suggestion four from the article session, and the agent built it the same day. The OS scheduler kicks off headless agent sessions on a timer: twice a week, one reads through recent support conversations and emails me a digest of bug reports, friction points, and feature ideas worth stealing. Another triages new production errors daily and emails only if something actually needs me.

I read the reports over coffee. The agents wrote them at 6am. It's a strange feeling the first few times, and then you stop wanting to live without it.

The rules file

Underneath all of this sits a global rules file with the non-negotiables. Never run anything against the production database. Never stage all files blindly. Don't commit until I've confirmed the change actually works. A few of the rules are enforced by hooks that hard-block the action, because an instruction the agent can't violate beats one it merely shouldn't. The hook was another thing the agent built in that session, and the first thing it blocked was a real command, the same week.

Every rule in that file exists because of a specific incident. It reads like aviation regulation, and for the same reason.

All of this is just memory

Step back and there's one idea underneath everything here. PROGRESS.md is memory for a session. Skills are memory for process. The rules file is memory for judgment. None of it makes the model any smarter. It just stops the model from starting over, which in practice matters more.

It's also the reason the origin story works. The agent could redesign my workflow because my workflow was written down where it could read it. Context in, leverage out.

That's the same gap that got me building MemoryPlugin in the first place. The models are genuinely good now. What's missing, every single time, is that they know nothing about you when the conversation starts: your projects, your preferences, the decisions you already made, the approaches you already rejected. The files above solve that for one repo. MemoryPlugin solves it for your life, across every AI tool you use.

Same trick either way. Write it down once, and never re-explain it again.

Key takeaways

• Don't just read workflow articles, feed them to your agent - "Read this article, review my current workflow, and tell me 5 things I can do to be more productive" turned a blog post into a working system. Then say "set it up" and mean it
• Most agent failures are context failures - The model was capable of doing it right. It just didn't know what you knew
• Keep a PROGRESS.md per session - Updated every turn, with a pinned "Current state / Next up" block. It rescues future-you, bootstraps every future session, and gives the agent the self-knowledge tricks like the one above depend on
• Turn repeated explanations into skills - If you've told an agent something twice, write it into a playbook file it loads automatically. Each skill is a lesson you never have to teach again
• Make AIs review each other - A second model with no attachment to the code catches real bugs. Make the agent fix findings properly, reply to every thread with the fix commit, and loop until approval
• Never wait on a single proxy signal - Bound every wait, then go inspect actual state. My agent once idled 45 minutes for an approval that had arrived as an emoji reaction
• Write rules after incidents, and enforce the critical ones with hard blocks - An instruction the agent can't violate beats one it shouldn't

If you're running agents day to day, I'd genuinely love to hear what your setup looks like. Mine is still evolving, and as of this post, the best improvements to it were the agent's idea, not mine.