The 7-stage skill workflow I use with coding agents

In my previous article, I described the seven Markdown files I use to manage projects with coding agents. Those files keep the current status of the project, but they are not what moves it from idea to implemented code.

For that, I use a sequence of skills I have set up in Codex:

1. init-project
2. grill-me or grill-with-docs
3. create-system-design
4. create-implementation-plan
5. create-implementation-tasks
6. implement
7. code-review

I approve the project brief, design, plan, tasks, and implementation scope before the next stage starts. After each approval, I invoke the next stage myself. During implementation, the agent calls supporting skills for test creation and code review.

Why I split the workflow into skills

A single long prompt can ask an agent to clarify requirements, design a system, plan the work, and implement it. The problem is that each step depends on the quality of the previous one. This means that a strong implementation will not make up for a weak design.

The skills also write their results to the project files I described in the previous article.

1. Start with init-project

I use init-project when I have an idea but no settled project brief. It asks about the problem, intended users, desired outcome, initial scope, and success criteria.

The skill proposes a brief and repository structure for approval, then writes a concise README.md and creates the confirmed directories. It suggests a starting layout, but leaves detailed system design and task planning for later.

At this point, I only want to decide whether the project should exist and what a useful first version means. Detailed architecture questions can wait until the purpose and boundaries are clear.

For a small experiment, I may stop here and start coding. A short script does not need the complete workflow.

2. Clarify project requirements with grill-me

I believe this step is the most important one and if you only take away one thing from this article, it should be to use this skill or a similar workflow. This skill has the agent ask clarifying questions about the design of the project and about the intended behavior. It will keep asking questions until you and the agent have ‘reached a common understanding’ of the project. What I find great about it is that it oftentimes surfaces questions that I have not thought about before, so it forces me to have a clear picture of what I actually want the final product to be. At the same time, what might be an obvious choice for me might not be an obvious choice for the agent, so aligning the agent on my vision is what using this skill will achieve.

I use grill-with-docs when the discussion also needs to settle project language and to create the GLOSSARY.md file described in the previous article. If the project is smaller and a glossary with the common project concepts would not have a lot of value, I run the normal grill-me skill instead.

I often answer 50+ questions during a grill-me session, as some of my answers and clarifications will trigger new questions to be asked by the agent.

This skill has been popularized by Matt Pocock. I highly recommend checking out his other skills as well.

3. Capture the result with create-system-design

After the grill-me interview is complete, I invoke create-system-design. It turns the resolved discussion into the authoritative DESIGN.md.

The design can cover user behavior, scope, domain rules, architecture, interfaces, failure behavior, edge cases, and testing boundaries. It records what the discussion established and identifies questions that still need my judgment. It does not contain any implementation details or concrete tasks yet.

I review and approve DESIGN.md before moving on. This is the main product and architecture checkpoint. If an open question blocks planning, I resolve it before moving on. Unresolved testing boundaries return to the interview before the design is finalized.

4. Turn the design into implementation slices

After approving the design, I invoke create-implementation-plan. It proposes vertical slices for review, then creates or updates PLAN.md after I approve their size, order, dependencies, and verification gates.

A vertical slice delivers observable behavior through every required layer. For example, “users can rename a project” is a slice. “Create the database table” is only one technical layer and does not produce a useful outcome on its own.

Each slice records its outcome, dependencies, scope, acceptance conditions, tradeoff, and status. The plan also shows which slices can start without waiting for another slice or a human decision.

The skill inspects the existing code before planning. This prevents stale documentation from generating work that the repository already contains.

PLAN.md stays strategic. It explains the order of the work and the verification gate for each slice. It does not contain the detailed actions needed to implement them.

5. Expand the plan into tasks

With the approved plan written, next comes create-implementation-tasks. It proposes the concrete checklist that will become TASKS.md.

The skill groups coordinated work into named task packages and small standalone actions under topics such as bugs, maintenance, or documentation. Each action should fit within one focused implementation step.

The distinction between the plan and tasks keeps both files useful:

File	Purpose
PLAN.md	Defines outcomes, order, dependencies, and verification gates.
TASKS.md	Defines the actions required to deliver those outcomes.

If task generation reveals a missing product decision, the workflow returns to system design. If it reveals a bad sequence, it returns to implementation planning. The task skill does not repair upstream problems by inventing new decisions.

I approve the proposed grouping, action size, order, human gates, and verification before the skill writes TASKS.md.

6. Execute one approved scope with implement

Finally, the implement skill executes one selected task group from TASKS.md.

Before editing code, the skill verifies the selected tasks against the repository. It then presents an execution contract with the scope, order, approach, tradeoffs, test plan, human gates, and commit boundaries. I approve that contract before code changes start.

For each production behavior, implement calls the supporting tdd skill. TDD stands for test-driven development and is a way to write source code. I won’t go into more detail on TDD in this article, but with how capable coding agents are nowadays, telling them to apply TDD during development is a freebie that pays off with higher-quality code (at least in my own experience).

The tdd skill runs a small red-green-refactor cycle:

1. Add one test for observable behavior and confirm the expected failure.
2. Add enough production code to make the test pass.
3. Improve the code without changing the behavior.

For behavior that cannot be checked at an honest automated boundary, the skill records the integration or manual verification still needed. For a refactor that preserves behavior, it uses existing tests or adds characterization tests to capture the current behavior.

The implementation skill updates TASKS.md after each completed action. It records decisions that need my input and commits related changes together so they are easier to review in version control.

Note: You can use a loop to instruct your agent to implement all task groups at once. However, as I am only on the $20/month ChatGPT Plus plan, I hit the five-hour usage limit very quickly. I often only get to implement one or two task groups before waiting until my allowance resets.

7. Review against standards and the specification

After implementation is green and committed, implement invokes code-review from the commit captured before work started.

The review separates two questions:

• Standards: Does the diff follow the repository instructions and coding rules?
• Specification: Does the diff implement the approved design and task scope?

The skill uses two parallel agents when available, or separate passes otherwise.

Keeping these reviews separate catches two different failures. Clean code can implement the wrong behavior. Correct behavior can still violate repository rules or omit required tests.

The review reports findings without editing code. Implementation fixes blocking findings within the approved scope and reruns affected checks. It repeats the review when those fixes conceptually change the implementation. Unavailable manual checks remain open as human verification gates.

The complete handoff

The workflow moves through a series of approved artifacts:

Idea
  -> README.md
  -> design interview and decision ledger
  -> DESIGN.md
  -> PLAN.md
  -> TASKS.md
  -> code and tests
  -> standards and specification review

Conclusion

In this article I explained the exact workflow I use when working on my projects. I want to highlight again that for smaller projects this whole workflow would be overkill, but for bigger projects that need more than a single session this workflow has proven to work very well for me. I should also note that this workflow and the creation and update of the Markdown files consume a lot more tokens than a simpler workflow. I have not measured the difference, but I suspect larger projects may save tokens overall. Clearer requirements could help the agent make fewer mistakes and reduce refactoring.

I am curious to know how other people designed their workflows and would love to take some inspiration in order to improve my workflow, so feel free to let me know your setup.