I’m building a meal planner for tired parents — I’m one of them, and I use it every week to figure out what we’re eating. One human. No budget. Limited evening time. Every task — defining what to build, planning how to build it, building it, telling people it exists — is mine. Everything is serial, and there’s no one to hand a ticket to or give me a review.
In my day job I’m an engineer on a team with product managers and other engineers. Getting from idea to implementation involves a lot of human conversation — product reviews, engineering handovers, spec clarifications — and those conversations are genuinely valuable. They catch gaps. They surface assumptions. They make the spec something you can actually build from.
I don’t have those people on this project. I wanted to see if I could have the conversations anyway.
Everything lives in the repo
Some context on how the project is organised.
There’s no Linear. No JIRA. No Notion. No project management tool of any kind. There’s a
ROADMAP.md in the root of the repository. It’s a markdown file that says what we’re
going to build, roughly when, and why. Epics link to more detailed files that carry the
full context: background, acceptance criteria, copy drafts, success criteria, and —
once they’re ready — a complete implementation plan.
When an agent picks up a task, the repository is the brief. Everything it needs is there. When the work is done, everything it produced is there too. Git is the audit trail.
This only works if the documentation is genuinely good. A thin ticket with a vague acceptance criterion doesn’t help me and it doesn’t help an agent. The investment in writing clearly pays twice.
Ideas arrive before specs do
An epic doesn’t start as a spec. It starts as a hunch — something that feels like the right next thing to build, for reasons I can half-articulate. Getting from that to something buildable takes iterations. Conversations where I pressure-test the idea, ask why it matters, define the edges. What counts as done? What would tell me it worked? What am I deliberately not building?
Those conversations happen with Claude in a product role. Over several sessions — not usually in one sitting — a vague idea gets enough definition to write down. Then that draft gets refined. Then refined again. Each session adds a layer. But each session also takes time, and time is the constraint.
The epic-ready skill is the final structured pass before I hand it off to be built. By that point the shape is there, but it still needs the kind of scrutiny that only comes from someone reading it cold for the first time.
The skill
I built a slash command that takes an epic file and prepares it for implementation. It runs three phases, each with a different cast of agents, and produces two outputs: a fully specced epic file and any new entries in the roadmap that the process surfaced along the way.
The whole thing runs as a structured facilitation. I’m the chair. The agents are the specialists. My job is to answer questions that only I can answer and to make final calls. The agents handle everything else.
Phase 1 — Product finalisation
The first agent is a Head of Product. It reads the epic cold — no prior context, just the file — and audits it for product gaps. Vague acceptance criteria. Missing success metrics. Decisions that were left to “figure out later.” Assumptions that we haven’t validated yet. Any spec where an agent — or I — could build the wrong thing and still claim the brief was met.
It returns a structured list of concerns, not edits. The concerns come to me. I work through them. Some I answer directly. For some I’m uncertain, so I re-engage the HoP with the specific question and let them offer a recommendation before I decide.
Once everything is resolved, the HoP edits the epic directly. It drafts copy, it rewrites weak acceptance criteria, adds success criteria where they were absent, and sharpens anything that was drift-prone.
Phase 2 — Engineering handover
The second agent is a Head of Engineering. It reads the now-tightened epic and audits it for a different class of problem: not whether we’re building the right thing, but whether we’ve said enough to build it unambiguously.
It’s looking for assumptions that would force a mid-build decision. Places where the acceptance criteria could be met in more than one technically valid way and the intent isn’t clear. Unstated dependencies between tickets. Anything that would become a conversation during the build rather than a decision before it.
Here’s the part I find most interesting: the HoE’s questions are directed. Each one is addressed either to the Head of Product (product intent questions) or to me (technical and architectural questions). The HoP-directed questions go to the HoP silently — I don’t see that conversation happen. I just see the answers when they come back, alongside my own questions.
A significant number of concerns in this phase get resolved between the two agents without me being involved at all. The HoP answers an engineering question. The HoE accepts the answer. I find out in the summary. This is not a small thing — in a real team, this is the back-and-forth that fills a week of Slack threads and a couple of meetings. Here it happens in a single turn.
When everything is resolved, the HoE does a final sign-off. If there are remaining blockers, we keep going. If it’s ready to plan, we move on.
Phase 3 — Engineering planning
The HoE comes back with the full context of both prior phases and writes the implementation plan directly into the epic file. Not a summary — the actual plan. Specific files. Specific patterns. The build order with explicit dependencies. Data model changes with migration notes. Key decisions documented so a future agent doesn’t relitigate them. Known risks and how to mitigate them.
The plan has to stand alone. When I pick up a ticket — or hand it to an agent — the file is the entire brief. Nobody to ask. The conversations that produced it are gone. The decisions have to be there.
Roadmap items surface naturally
One thing that consistently happens in this kind of thorough handover — in teams with real humans, too — is that you discover things that are out of scope for this epic but clearly worth capturing for later. A mechanism you deliberately don’t build because the data to justify it doesn’t exist yet. A decision you park because the user base isn’t there yet.
The skill tracks these as they come up and writes them into the roadmap at the end. They get added in the style of the existing roadmap entries: what the idea is, why it’s deferred, and what signal would justify building it. This session surfaced one — a re-engagement strategy for users who churn even after a targeted email. Not the right problem to solve now. Very much the right thing to remember.
And when the time comes — when there’s data, when the signal is there — that roadmap item becomes a hunch. The hunch becomes a conversation. The conversation becomes a draft. And eventually the draft goes through this same process.
What I get out of it
At work, the best spec reviews I’ve had came from people who were smart and read it cold — a product manager who hadn’t been in the room when the idea formed, an engineer who hadn’t heard any of the background assumptions. They catch the things I can’t catch because I know too much. I don’t have those people on this project.
Before this skill existed, I was reviewing my own specs. They had gaps I couldn’t see. Now I get the cold read. The HoP reads the epic like someone who wasn’t in the room when I wrote it, because they weren’t.
The silent resolution of engineering questions is the thing that still catches me off guard. The HoE asks the HoP something about product intent. The HoP answers. I find out in the summary. In a team, that exchange takes a Slack thread, maybe a meeting, definitely some calendar time. Here it happens while I’m answering my own questions in the same turn.
What I end up with is the benefit of a team process — cold reads, directed questions, agent-resolved clarifications — while every actual decision still goes through me. The engineering calls, because I’m the one building it. The product calls, because I’m the founder. The judgement calls about what a tired parent actually needs on a Tuesday evening, because I’m that too. The agents do the scrutiny. I do the deciding. Everything lands in the repository, and that’s where it stays.