OpenFlow adds grill-me: Let AI question before executing

OpenFlow v0.4.0 introduces grill-me: not an extra step, but a way for AI to scrutinize requirements before writing the spec.

Last week, while modifying OpenFlow, I kept having this annoying question in my head.

Does AI programming really need a stronger model?

No.

At least, that’s not my experience over the past few months. Tools like Claude, Codex, and Cursor are already powerful enough. How powerful? Give them a clear plan, and they can really run through testing, implementation, fixing, and verification all the way.

But the problem lies right at the beginning.

Many projects don’t die during coding. They die before coding, in that pile of unclear requirements.

You think you’re asking AI to write code, but you’re actually asking AI to guess riddles.

That’s ridiculous.

So OpenFlow 0.4.0 adds a new phase: /openflow grill.

The name sounds a bit unorthodox, but what it does is very serious: Before entering the spec, it drags out the proposal and interrogates it.

The scariest thing about AI programming isn't slowness, it's smoothness

Many people, when first using an AI programming pipeline, get addicted to that smooth feeling.

Write a requirement, AI nods.

Generate a spec, AI nods.

Start coding, AI keeps nodding.

Looks great.

But sometimes, being too smooth is frightening. Like an airport without security, everyone running to board, only to find something that shouldn’t be there in the cargo hold after takeoff.

I’ve seen too many scenarios like this:

• The requirement says “support user configuration”, but doesn’t mention how to handle default values;
• The plan says “reuse existing module”, but doesn’t confirm whether the existing module has side effects;
• The spec says “show an error on failure”, but doesn’t define which errors are retryable and which should abort;
• Halfway through the build, you realize this requirement will change the public API.

Then AI starts patching holes.

It patches diligently.

And it’s also quite frightening.

Because every hole it patches might dig a new hole.

OpenFlow already connected OpenSpec and Superpowers: OpenSpec manages requirement specifications, Superpowers handles engineering execution, and OpenFlow serves as the translation layer in between.

This approach hasn’t changed.

But 0.4.0 fills in a more “quality-check” segment.

Not to make the process longer.

To keep the process from being too sloppy.

What exactly does grill-me grill?

/openflow grill does a simple thing: after a proposal or brainstorming session produces proposal.md, before entering the spec, AI starts asking reverse questions.

Not vague questions like “Are you sure?”

That’s useless.

It targets four types of issues.

First, hidden assumptions.

For example, you write “enable new workflow by default”. Grill will ask: do existing users also get it by default? What if there’s a configuration conflict? If the user previously disabled it manually, should we respect the old setting?

These questions are the most annoying.

And also the most valuable.

Because they specifically poke the areas you don’t want to face. To be blunt, a lot of rework starts rotting from here.

Second, edge cases.

For example, “generate plan-ready.md”. What if the OpenSpec CLI doesn’t exist? What if Superpowers isn’t installed? What if there’s already a plan-ready.md but it’s outdated?

Don’t laugh.

In real projects, many bugs grow from “that shouldn’t happen”.

Third, design trade-offs.

A is safer but slower. B is faster but may have hidden risks. Grill doesn’t pretend there’s only one correct answer; it forces you to choose.

This step is uncomfortable. But that’s right. A comfortable design review is usually just polite mutual deception.

Fourth, conflicts with existing systems.

This one is most like an old engineer frowning beside you: doesn’t this change conflict with the behavior of that previous module?

Yeah.

I’m very familiar with that sentence.

The most crucial change in 0.4.0: not a new command, but a new “brake”

OpenFlow 0.4.0’s changelog has three core updates:

• Added an optional grill-me gate;
• Bare /openflow and direct /openflow spec can no longer stealthily enter the spec; they must first handle the grill selection;
• Added regression tests for generated skill instructions to ensure this logic is not lost across multi-tool targets.

Sounds like engineering details.

Actually, it’s a product judgment.

In the past, many tools designed “skip review” as the default path and “pause to think” as an extra operation.

Of course people skip it.

Humans are lazy. Developers are even lazier. A developer at 2 a.m. — well, that’s not laziness, that’s survival.

OpenFlow 0.4.0 reverses this path:

You can skip grill.

But you have to explicitly skip it.

This difference is subtle, but powerful.

Like a checklist before submitting a PR. You can of course skip testing, but when the system puts “Has it been verified?” in front of you, your heart skips a beat.

/openflow grill is that skip.

One question at a time, and AI must first give a recommendation

I dislike AI that dumps questions on users.

“Please confirm A, B, C, D, E, F, G meet expectations?”

Annoying to look at.

Are you an assistant or a survey?

So grill-me has two hard rules.

First, ask only one question at a time.

It doesn’t bombard you with 12 risk points at once. Like a serious but slightly annoying reviewer, it blocks one key point at a time.

Second, each question must include an AI-recommended answer and rationale.

Not just:

Do we need rollback on failure?

But:

Do we need rollback on failure? My recommendation: roll back user-visible state, but keep debug logs. Reason: user state cannot be half-failed, and logs are the entry point for troubleshooting.

This is completely different.

The former throws the cognitive burden onto you.

The latter helps you make a decision.

Of course you can argue against it. You can simply say: “No, we don’t need rollback in this scenario.” No problem. Grill writes your answer into the grill-me decision log in proposal.md.

This is not a chat record.

It’s the basis for the subsequent spec and build.

If AI can check the code itself, don’t ask me

Grill-me has another rule I like a lot:

If a question can be answered by looking at the code, AI checks the code first before asking.

This sounds ordinary, but I think it’s very important.

Because many AI tools appear to be collaborating, but are actually being lazy.

It asks: “Does the current project already have a similar module?”

Buddy, can’t you search for it yourself?

It asks: “Will this feature affect existing configuration?”

Can’t you read the configuration parsing logic yourself?

It asks: “What is the test command?”

Can’t you check package.json yourself?

When these questions pile up, users get annoyed. Eventually, users start answering randomly. After random answers, AI writes specs based on those random answers.

Broken.

The whole process gets dirty from here.

OpenFlow’s grill phase shifts some responsibility toward AI: check what can be checked, bring evidence to ask; if it can’t be checked, let the user decide.

That’s what an assistant should be.

Not a question generator in assistant’s clothing.

Now OpenFlow has 7 phases

After 0.4.0, the full OpenFlow pipeline is:

proposal → brainstorming → grill(optional) → spec → translation → build → amend → close

You can think of it as an AI programming pipeline.

proposal handles lightweight requirement capture, usually 3–5 key questions, compressing fuzzy ideas into proposal.md.

brainstorming handles deep design exploration, suitable for requirements that have multiple paths from the start.

grill is the new optional stress test. It doesn’t write code, only challenges the proposal.

spec calls OpenSpec to turn the proposal into structured specifications, tasks, and scenarios.

translation is OpenFlow’s core glue layer, translating the requirement perspective into an engineering perspective, producing plan-ready.md. This is not a summary; it’s an executable handoff for Superpowers: Source Coverage, File Responsibility Map, Implementation Slices, TDD expectations, Validation commands.

build is handed over to Superpowers, executed following TDD and checkpoints.

amend handles requirement changes discovered during build or before close.

close performs consistency verification and archiving.

The most interesting thing about this pipeline is that OpenFlow doesn’t replace OpenSpec or Superpowers.

It doesn’t take over their jobs.

It orchestrates.

OpenSpec is good at formalizing requirements. Superpowers is good at standardizing engineering execution. OpenFlow connects the two, with a grill quality gate in between.

Like a quality inspector on an assembly line.

Doesn’t produce parts, but can stop bad parts.

When should I use grill?

If you’re just fixing a typo in a README, don’t use it.

Seriously, don’t.

A tool isn’t better just because it’s heavier. Using a scalpel to peel an apple is showy but stupid.

But for these scenarios, I strongly recommend grilling:

First, when the requirement affects public behavior.

For example, routing rules, configuration defaults, permission checks, state machines, data migrations. As long as others will depend on it after the change, don’t rush to spec.

Second, when you use words like “default”, “automatic”, “compatible”, “reuse” in the proposal.

These words are dangerous.

Default for whom? Automatic to what degree? Compatible with old data or old behavior? Reuse the module or the concept?

These words seem to save space, but actually hide mines.

Third, when the plan involves multiple trade-offs.

For example, security vs. speed, simple implementation vs. long-term extensibility, user experience vs. maintenance cost. Let grill help you articulate the trade-offs explicitly, and the rework probability later will be much lower.

Fourth, when you’re about to let AI execute many steps continuously.

Once AI starts running, it’s very fast. Speed is good, but if the direction is wrong, it’s a disaster.

Spending 5 minutes grilling now might save 50 minutes of patching later.

Installation and usage

If you’re already using OpenFlow, upgrade to 0.4.0 and regenerate skills:

npm install -g @lininn/openflow
openflow update

Initialize a new project:

cd your-project
openflow init --tools claude

Supported tools include Claude, Codex, Cursor, OpenCode.

In Claude Code, you can do:

/openflow proposal
/openflow grill
/openflow spec
/openflow build
/openflow close

If you use OpenCode, the corresponding command is:

/openflow/grill

Grill is optional.

But before the spec, it will explicitly ask if you want to grill. You can skip it, but you won’t “accidentally” skip it anymore.

I think that’s the key of 0.4.0.

Not a new command.

But OpenFlow learning to say, before AI starts working: Wait, can this plan withstand questioning?

Conclusion: Don’t treat AI as a typist, nor as a wishing well

I increasingly believe the next phase of AI programming is not “letting AI write more code”.

It’s “letting AI participate in decisions earlier”.

Not to make decisions for you.

But to find holes, force you to be clear, and nail down ambiguities in documents.

OpenFlow v0.4.0’s grill-me is a small button in this direction.

Very small.

But it stands right in front of the spec.

That position is quite important.

If you’re already using OpenSpec, Superpowers, Claude Code, or if you’ve been tortured by the “requirements unclear, code written first” situation in AI programming, give OpenFlow 0.4.0 a try.

Project address:

https://github.com/lininn/openflow

Installation:

npm install -g @lininn/openflow

Next time before letting AI start working, grill it first.

Maybe the first question it asks can save you one rework.

That’s it.