From Prompting to Process: How AI Is Improving My Workflow Methodology

In one session on ai-backend-factory, before writing any more implementation code, Codex stopped to add a definition of Generation Request to the project's CONTEXT.md. Then it continued with the task.

It is a small edit, but it is exactly the behavior I wanted: clarify a term, record it where the next session will find it, then write code. When I worked ad hoc with AI, that kind of trail was usually the first thing I lost.

This post is about the workflow I was running when that edit happened, and about what my own records do and do not show about it. It is a personal account built from my repositories and Codex session history around July 1–2, 2026, not an experiment with a control group.

Where it started: copying, deliberately

I first knew Matt Pocock from his TypeScript content. During a short recess in my master's in computer science, I watched four or five of his videos about AI workflows and skills, about structuring engineering work around agents instead of using AI as a bigger autocomplete. They changed my question from "how do I get a better answer from this prompt?" to "what workflow would make the answers more reliable?".

I did not start from a blank page. I copied one existing skill almost verbatim to understand the pattern from the inside: what a skill is responsible for, which phase it belongs to, which files it should produce and what it should refuse to do. Much of what I use now came from studying that pattern closely before adapting it.

The adapted version lives in my skills repository: an AGENTS.md, a WORKFLOW.md, and skills such as grill-with-docs, to-prd, task-planner, task-runner, tdd, technical-blog-writer and domain-modeling, plus project-generation helpers.

The workflow, in files

The core idea is that work starts from written context rather than from a request to write code:

• PROJECT.md describes what the project is and how to work in it;
• CONTEXT.md holds evolving decisions, risks and domain terms;
• docs/PRD.md states what must be true when the work is done;
• docs/TASKS.md breaks that into small, testable steps tied to files in the repository.

WORKFLOW.md fixes the order: PROJECT.md → CONTEXT.md → grill-with-docs → to-prd → task-planner → tdd. Implementation comes last, after the earlier layers exist.

The point of that sequence is to remove ambiguity before the model edits code. A model asked to improvise from a one-line request has to guess the requirements. A model dropped into a task with acceptance criteria and a validation command has much less to guess.

The proving ground

ai-backend-factory is where I tested this against a real project. At this stage it is a backend-only NestJS service that accepts structured generation requests and produces deterministic backend foundations in a fixed local workspace.

The repository has a PROJECT.md, a CONTEXT.md, a docs/PRD.md, a detailed docs/TASKS.md, several ADRs and per-task run notes under docs/task-runs/. Its first tasks covered bootstrap and health checks, domain modeling with Prisma persistence, shared core abstractions and authentication. Each task summary records the same things:

• what changed and which files moved;
• which tests were added or updated;
• which commands ran and which validations passed;
• which decisions were made;
• what the next task should be.

That last item is what I used to lose most. In a long chat, the next step lives in the chat. Here it lives in a file that the next session reads.

What the session history shows, and what it does not

Memory is flattering, so before writing this I checked my Codex session history. Around July 1–2, 2026, I logged:

• 9 sessions in ai-backend-factory;
• 11 sessions in skills/orchestration;
• 6 sessions in the root skills repository.

The counts show repetition across three layers: the skill system itself, a product repository using it, and an orchestration layer that tries to run more of the loop safely. That orchestration work became its own project, which I wrote about in From a Bash Loop to Guarded Orchestration for AI Agents.

The counts do not show productivity. I did not compare delivery time or defect rates with a period before the workflow. What I can point to is narrower: each task left a requirement, a change and a validation record that another session could pick up. My sense that continuity improved is a personal observation.

What changed for me

With that caveat, these are the practical differences I notice:

• I lose less context between sessions, because decisions live in files rather than in my memory or a model's context window.
• Handoffs are cleaner, because the PRD and task plan force work into explicit steps.
• I can revisit a decision by reading CONTEXT.md, an ADR or a task summary instead of an old chat transcript.
• Output fits the repository better, because the agent works from local rules instead of only general training.
• Validation has become part of each task instead of something I remember to do afterwards.

The deeper change is in how I use AI. It amplifies whatever process it is given: a loose workflow produces loose output faster, and an explicit one produces clearer output faster. That made me spend more effort on the workflow and less on the prompt.

What is still rough

Much of this is young, and part of it began as imitation. Some skills are probably too verbose and will need cutting.

Process also has a cost. Running a one-line fix through a PRD and a task plan is ceremony, and I do not want every change to go through the full sequence. Deciding when structure buys clarity and when it only adds ceremony is still a judgment I make case by case. Because the workflow is written down, I can at least change that judgment the same way I change code.

The open question is scale. Everything above comes from a few weeks on small repositories. The test that would tell me whether this holds is a larger, messier project: if a new session can pick up a half-finished task from the files alone, without me re-explaining it, the workflow is doing its job. If it cannot, the files are not carrying as much as I think they are.

Notes

This post is based on my own workflow artifacts: skills/AGENTS.md, skills/WORKFLOW.md, ai-backend-factory/PROJECT.md, ai-backend-factory/CONTEXT.md, ai-backend-factory/docs/PRD.md, ai-backend-factory/docs/TASKS.md, the task summaries under ai-backend-factory/docs/task-runs/, skills/orchestration/PROJECT.md, and my Codex session history from July 1–2, 2026.