Grilling Before You Build

Most planning problems are not about not having enough information. They are about not asking the right questions before starting. You think you understand the feature, you open an editor, and two days later you hit an assumption that was wrong from the start.

grill-me is a skill that tries to prevent this. It interviews you about your plan, one question at a time, and walks down the decision tree until the design is actually resolved rather than vaguely understood. I have been using it for a while now as part of a longer planning sequence, and the combination with to-spec and to-tickets has changed how I start any work that is more than a small change.

This is not a tutorial. It is an account of what works, what does not, and how I shaped these tools to fit the way I actually work.

What the grilling session does

The grilling skill is a structured interview. It asks about your plan one branch at a time, waits for your answer, and proposes a recommendation for each question so you are reacting rather than generating from scratch. That last part matters: being asked “should this be stored on the user or the account?” and having a suggested answer in front of you is much faster than being asked the same question with a blank page.

The value is strongest in business logic. If a feature has multiple parts with non-obvious connections, the session forces you to articulate those connections out loud. You end up with a clear picture of the decision tree, resolved, before anything gets built. Dependencies that would have surprised you mid-implementation become visible early.

I also use grill-with-docs when working in a codebase with an existing domain model. That variant checks your language against the project’s glossary and updates documentation as decisions are made. When a term gets resolved during the interview, it gets added to CONTEXT.md in the same session. This keeps the model and the documentation consistent rather than diverging.

Where it falls short

grill-with-docs handles business logic well. UI and interactions are a different story.

The session works through decisions that have a defensible answer: data dependencies, sequencing, ownership rules, edge cases. What it does not ask about is the other layer: whether a confirmation belongs in a modal or inline, whether the interaction flow makes sense in practice, whether the overall experience feels right once someone is using it. Those decisions simply do not come up.

The gap shows up after you build. The implementation can be correct by everything the session decided and still feel wrong when you use it. A dialog is missing where the user expects one. The flow works but feels off. Nothing in the grilling session would have flagged this, because the session never went there.

Visual and interaction decisions need building, looking at, and adjusting. There is no version of reasoning your way to the right interaction pattern.

This is not a criticism of the skill. The problem is expecting it to cover ground it was never designed for. The tool works well where it works. The mistake is assuming the grilling session has resolved the full picture when it has only resolved the logic.

Knowing where the tool is useful is part of using it well.

The sequence

After the grilling session, I run to-spec in the same session, without starting a new conversation. The skill reads what was discussed, explores the codebase, and writes a Markdown spec file. No further interview. It synthesises, writes, and stops.

The spec covers the problem statement, user stories, implementation decisions, testing decisions, and anything flagged as out of scope or unresolved. Having all of that in one reviewable document is considerably easier than scrolling back through a long grilling session looking for what was actually decided.

The stop is the important part.

When you are inside a grilling session, it is easy to feel like everything has been resolved. The conversation has momentum. Reading the resulting spec is a different experience. The document makes vague resolutions visible: things that were gestured at rather than actually decided tend to show up as incomplete or contradictory sentences in the spec. Reviewing it takes fifteen minutes, and those fifteen minutes regularly catch something worth fixing.

Only after reviewing the spec do I run to-tickets. That skill takes the approved spec and breaks it into work items, each with its blocking edges declared: which other tickets must finish before this one can start.

The review boundary is not ceremony. It is the point at which you decide whether the plan is good enough to decompose. Fixing a sentence in a Markdown file is fast. Fixing a wrong assumption that has been spread across eight tickets and assigned to an agent is not.

Linked dependencies in OpenForge

When to-tickets publishes tickets to OpenForge, the blocking edges become real links rather than notes in a description. Each ticket lists what it depends on, and OpenForge creates structural blocking relationships between them.

This matters in practice. When an agent picks up work from the queue, only tickets with no unresolved blockers are available. The execution sequence that was reasoned through during grilling is preserved in the tracker. Nothing gets picked up out of order because the order is enforced, not just suggested.

If ticket three depends on a schema migration in ticket one, that is a link, not a comment. The agent working on ticket three will not start until ticket one is done. The dependency is captured in the place where it can actually do something.

Dependencies are one of the harder things to communicate across a planning session. Writing them down in a spec is useful but passive. Having them as structural links in the tracker is something an agent can act on.

Customising the skills

The skills I use are not exactly the originals. There are three changes I made.

The first is making them work with OpenForge. to-tickets in its general form handles multiple trackers and output formats. That flexibility adds branching logic that is noise in my setup. I trimmed the skill to target OpenForge specifically and removed the parts that do not apply.

The second is adjusting the output templates. The ticket format that made sense for the original skill is not the same as what OpenForge expects, and the spec template needed adjustments to fit the projects I work on. These were small changes: a few structural edits to the format blocks in the skill files.

The third is making the two-skill sequence explicit. grill-me and to-spec run in the same session. The to-spec skill now knows it is synthesising an existing conversation rather than starting fresh. It does not re-interview.

None of this required understanding how the skills work at a deep level. They are text files with instructions. You read them, find what does not fit, and change it.

How to modify skills without breaking them

One change at a time. Use the modified version for a day. Then decide whether the output is better or worse.

This sounds too simple, but the alternative is making five changes at once and not knowing which one produced the new behaviour. Skill files are short and easy to read, which makes it tempting to see ten improvements when you open one and make them all at the same moment.

The one-change rule gives you a clean comparison. You ran the previous version yesterday. You run this version today. The difference is one variable. If the output improved, keep the change. If it got worse, revert it and try something different.

Skills change how a model approaches a task. Some changes that look like improvements produce subtly worse output in ways that only show up after a few uses. The only way to catch that is to actually use the thing before moving on to the next change.

The actual value

Two things make this sequence worth using.

The first is dependency capture. The grilling session surfaces how parts of the plan connect and what blocks what. Those dependencies end up in the spec and then as structural links in the tickets. The execution order is not an afterthought added during planning: it is the thing planning produces.

The second is shared understanding. Before any code is written, there is a document that describes what is being built and why. The decisions from the grilling session are recorded rather than existing only in a session that will be lost. If you are picking the work up after a break, or someone else is picking it up at all, the spec is there.

Neither of these is guaranteed. A careless grilling session produces a weak spec and weak tickets. But the structure makes it easier to produce something useful, which is the most a planning tool can offer. The rest is still your job.

If you have not tried this sequence before, start with one real feature. Run grill-me, read the resulting spec, and see whether the dependency graph it surfaces matches what you had in your head. The gap, if there is one, is the thing the session was for.