Superpowers vs. Grill Me: Match AI Planning to the Cost of Being Wrong

A substantially expanded English analysis of a Chinese article by 大刘 (AI大刘), updated with current project documentation, official coding-agent guidance, and empirical research on clarification and planning.

AI coding is rarely limited by how fast a model can produce code. The expensive failure mode is building a plausible solution to the wrong problem, then discovering the mismatch after code, tests, and assumptions have accumulated. That is why planning skills have become popular. But “more planning” is not a universal answer, and “more questions” is not a quality metric.

This article responds to 大刘’s original WeChat article, which contrasts the comprehensive Superpowers workflow with Matt Pocock’s compact Grill Me skill. Its central intuition is useful: the tools allocate decision-making differently. Current documentation and newer research sharpen that claim. The practical question is not “Which tool wins?” It is “Which uncertainty are we reducing, and how costly would a wrong answer be?”

Clarification, planning, and verification do different jobs

Many discussions collapse three activities into “thinking before coding.” That hides their different purposes:

• Clarification reduces uncertainty about what should be built. It resolves intent, constraints, ownership, acceptable trade-offs, and observable success.
• Planning manages dependencies in how it will be built. It orders changes, identifies interfaces, assigns verification, and exposes coordination risks.
• Verification produces evidence that the result is acceptable. Tests, logs, type checks, screenshots, diffs, and human review answer a different question from either clarification or planning.

Claude Code’s official Plan mode illustrates the distinction. It is primarily a research-and-approval boundary: the agent can inspect the project and propose changes, but edits remain blocked until the plan is approved. That is valuable, yet it does not guarantee that the agent asked the product owner the one question that changes the feature’s meaning. A plan can be detailed and still encode the wrong requirement.

The reverse is also true. A thorough interview can establish intent without producing a safe migration sequence, a test strategy, or a reviewable implementation contract. The three layers complement one another; substituting one for all three is the mistake.

The 2026 comparison is stack versus primitive

The most important correction to a simple Superpowers-versus-Grill-Me framing is that these are not equivalent products at different sizes.

As checked on 14 July 2026, grill-me itself is a tiny user-invoked wrapper: it starts the underlying grilling skill. The current instructions say to walk a decision tree one question at a time, recommend an answer with each question, investigate facts available in the environment, leave decisions to the user, and wait for shared understanding before acting.

Matt Pocock’s broader repository now routes different situations to different skills. Its current ask-matt guidance directs greenfield, stateless discussion toward Grill Me; existing-codebase work that needs durable context toward grill-with-docs; and larger work through specification, ticketing, implementation, and review steps. Grill Me is therefore one entry point in a growing workflow stack, not a complete one-file replacement for design records, execution, testing, and review.

Superpowers is explicitly a full software-development methodology. Its latest formal release at the time of checking was v6.1.1, published 2 July 2026. The repository contained 14 top-level skills, and its documented chain runs from brainstorming through worktree isolation, detailed planning, subagent or sequential execution, test-driven development, review, verification, and branch completion.

This changes the comparison. The real alternatives are closer to these:

Layer	Matt Pocock workflow	Superpowers workflow	Primary output
Intent discovery	grill-me, grilling, or grill-with-docs	brainstorming	Agreed decisions and constraints
Durable design	Context and decision records, then spec when needed	Written design spec with review gates	Reviewable design artifact
Decomposition	Spec and tickets for larger work	writing-plans with small verified tasks	Ordered implementation contract
Execution	implement and related engineering skills	Subagent-driven or plan execution	Code changes in bounded steps
Quality control	TDD and final review in the broader stack	TDD, task review, branch review, completion verification	Evidence, review findings, release choice

The fair conclusion is not that Grill Me replaces Superpowers. It is that a compact clarification primitive can be useful before, inside, or instead of a larger methodology depending on the task’s risk and coordination needs.

Superpowers has also become more deliberate about user decisions

The current Superpowers brainstorming instructions do not simply let the agent decide everything. They tell the agent to inspect the project first, ask questions one at a time, propose two or three approaches with trade-offs, present the design in sections, obtain approval, write a design document, self-review it, and obtain review of the written specification before moving to planning.

That overlap matters. Both approaches separate facts the agent can discover from decisions the owner must make. Their main difference is what happens around and after the interview. Superpowers persists design artifacts and connects them to a mandatory engineering chain. Grilling can stop at shared understanding or hand off to other skills selected for the job.

Superpowers’ current writing-plans skill also reaches beyond a prose outline. It asks for exact files, interfaces, concrete code or commands, small actions, test-first RED/GREEN steps, and commits. That is expensive compared with a three-bullet plan, but it creates a portable execution artifact. The cost is justified when another agent or engineer must resume the work, when multiple components change in dependency order, or when reviewers need to detect divergence before merge.

The project is not static. Superpowers’ v6.0.0 release consolidated review steps, added branch-level review and plan checks, and revised interfaces and global constraints. Its v6.1 line reduced bootstrap overhead and improved Codex integration. It is therefore misleading to treat “Superpowers overhead” as a fixed property measured by one older run. Workflow cost depends on release, harness, model, codebase, and configuration.

Grill Me protects decision ownership—but should not ask everything

Grilling’s most useful rule is not “ask many questions.” It is “research facts; ask the user for decisions.” A repository can usually answer which framework is installed, how neighboring endpoints authorize requests, which commands run tests, and whether a migration helper already exists. Asking a user for those facts wastes attention and invites stale answers.

The user is needed for questions that the environment cannot settle: whether backward compatibility matters more than cleanup, which failure mode is acceptable, whether a data migration may be irreversible, who can view a new field, or what business event counts as success.

That division makes human attention a scarce engineering resource. Approval prompts can become theater when they appear at every minor action. The better control points are boundaries with real consequence: freezing the requirement, accepting the plan, crossing a sandbox or network boundary, applying an irreversible migration, merging, or publishing. Low-risk, local, reversible steps can proceed inside an agreed boundary and return evidence afterward.

Research supports targeted clarification, not maximum interrogation

The empirical literature gives stronger support to clarification than the original single-run comparison, but it also warns against overgeneralization.

The 2024 FSE paper ClarifyGPT detected ambiguous requirements, generated targeted questions, refined the request from the answers, and then generated code. In its small human study, GPT-4 Pass@1 on MBPP-sanitized rose from 70.96% to 80.80%. Across four automated benchmark evaluations, average GPT-4 performance rose from 68.02% to 75.75%, while ChatGPT rose from 58.55% to 67.22%. Those are meaningful results, but the human study had ten participants, the tasks were mainly function-level Python problems, and the larger evaluation relied on simulated user feedback. It supports the mechanism—not a claim that every large repository needs a long interview.

A newer 2026 study, Ask or Assume?, tested clarification on underspecified variants of SWE-bench Verified. Its uncertainty-aware multi-agent setup resolved 69.4% of tasks versus 61.2% for a standard single-agent setup. The agent also conserved questions on easier tasks. Again, the missing information and user interaction were experimentally constructed, so the result is evidence for uncertainty-aware clarification rather than a production guarantee.

Most directly relevant to Grill Me’s “37 questions” story, Asking What Matters found that increasing question count did not consistently improve task success; performance plateaued while the share of answerable questions declined. Its trained clarification module matched GPT-5’s resolution rate on the study’s underspecified issues with 41% fewer questions. The authors identify two useful criteria: task relevance—does the missing information predict success?—and user answerability—can the user realistically supply it?

That yields a better question test:

1. Can the agent find the answer in code, documentation, logs, tests, or a small experiment? If yes, investigate instead of asking.
2. Could different answers materially change the interface, data model, permission boundary, compatibility promise, or acceptance criteria? If no, defer or choose a reversible default.
3. Is the person being asked actually able and authorized to decide? If no, identify the owner or state the unresolved risk.
4. Will the answer be converted into a constraint or observable check? If no, the question may create conversation without reducing implementation risk.

The important unit is information gain per interruption, not questions per session.

Planning evidence is strongest when dependencies matter

Clarification is not the only intervention with empirical support. The 2024 TOSEM paper Self-Planning Code Generation reported relative Pass@1 improvements of up to 25.4% over direct generation by having models generate concise implementation steps first. The tasks were primarily algorithmic and function-level, so the exact gain should not be projected onto production repositories.

Repository-scale evidence is more relevant to Superpowers’ value proposition. Microsoft Research’s CodePlan used dependency-aware multi-step planning on repository migrations and temporal edits touching between 2 and 97 files. It passed build and correctness checks in five of seven repositories; a context-matched baseline without planning passed none. The sample was small and the task types were structured, but the result captures where planning earns its keep: later edits depend on earlier ones, and local correctness does not imply repository-level correctness.

Conversely, bounded work with a strong evaluator can benefit from a simpler loop. Agentless used a fixed localization–repair–validation pipeline rather than a highly autonomous workflow and solved 96 of 300 SWE-bench Lite issues in its reported evaluation. That historical benchmark does not settle today’s tool choice, but it illustrates a durable point: when the scope is narrow and the verifier is reliable, disciplined direct execution can outperform extra ceremony.

Treat the 0 / 6 / 37 comparison as a case study

The original article cites Alex Rusin’s comparison of three approaches on one API feature. In that reported run, Plan Mode asked no questions and produced a plan in roughly ten minutes; Superpowers asked six focused questions and took more than 31 minutes before stalling; Grill Me asked 37 questions.

Those figures are useful as a trace of how one configuration allocated decisions. They are not a benchmark. One feature, operator, model configuration, repository, and run cannot establish general speed or correctness. The projects have also changed since the test. Superpowers now has newer planning and review behavior; Grilling’s July 2026 releases added an explicit confirmation gate and a clearer facts-versus-decisions split.

A risk-weighted decision matrix

Choose the smallest workflow that covers the costly uncertainty—not the smallest workflow in absolute terms.

Situation	Useful default	What must be true before execution
Vague greenfield idea; domain owner available	Grill Me	High-impact choices are explicit and the user confirms shared understanding
Existing codebase; decisions need a durable record	Grill With Docs or equivalent	Context, terminology, and architectural decisions are written down
Multi-file or multi-component change with dependency order	Superpowers or another structured planning stack	Design is approved, interfaces are named, steps have verification and rollback boundaries
Small local change following a stable pattern	Lightweight plan and direct execution	Scope is reversible and a reliable test or observable check exists
Production write, security boundary, destructive migration, or external side effect	Structured workflow plus explicit approval	Blast radius, recovery path, owner, and final approval are unambiguous
Large, multi-session problem whose shape is still unclear	Discovery/decomposition workflow before implementation	The problem is split into independently reviewable scopes

A useful qualitative risk score is:

planning intensity ≈ probability of a wrong assumption × cost of reversal × coordination surface

This is not a numeric formula. It is a prompt to examine three independent reasons for more structure. High ambiguity raises the chance of choosing the wrong target. Irreversible or customer-visible effects raise the cost of being wrong. Many files, systems, sessions, or contributors raise the chance that a correct local change fails as a whole.

The strongest workflow is a sequence

For consequential work, the best combination is usually:

1. Inspect before asking. Read project instructions, neighboring code, tests, logs, schemas, and recent decisions. Separate facts from owner-only choices.
2. Grill only high-impact decisions. Ask one answerable question at a time, explain the recommended default, and record the decision as a constraint or acceptance criterion.
3. Freeze a decision brief. Capture goal, non-goals, external behavior, interfaces, compatibility, data and permission boundaries, acceptance criteria, and actions that require renewed approval.
4. Generate a dependency-aware plan. Map files and interfaces, sequence dependent changes, define RED/GREEN or equivalent checks, and place rollback or human gates at high-blast-radius steps.
5. Execute in verifiable increments. Keep changes small enough that failures have a clear cause. Use independent review where the cost warrants it.
6. Return evidence, not confidence. Show the diff, tests, logs, screenshots, citations, migration results, and unresolved risks before merge or publication.

This sequence matches broader official guidance. Anthropic describes an agent loop of gathering context, taking action, and verifying results, and recommends giving Claude something concrete to verify against. OpenAI’s original Codex description likewise emphasizes isolated environments and iterative tests. The tools differ, but the control principle is stable: approval governs authority; verification governs trust.

Stop grilling when

• every decision that would change scope, architecture, external behavior, data, or permissions has an owner-approved answer;
• goals, non-goals, and acceptance criteria are observable;
• discoverable facts have been investigated instead of delegated back to the user;
• remaining unknowns are local, reversible, or cheaply testable; and
• it is clear which later actions require renewed approval.

Start implementation when

• each plan step has a concrete artifact or observable result;
• verification commands and expected outcomes are present, not merely a list of files to edit;
• high-risk steps have rollback or approval boundaries;
• repository instructions contain current build, lint, test, and validation commands; and
• a reviewer can tell from the plan what “done” means.

What the evidence still cannot tell us

No cited study directly compares current Superpowers, Grill Me, Grill With Docs, Claude Plan mode, and a lightweight baseline across the same production repositories and human teams. Function-level benchmarks underrepresent coordination and maintenance. Simulated users may answer more consistently than real stakeholders. SWE-bench variants emphasize issue resolution rather than product discovery. Project release notes report maintainers’ intentions and internal evaluations, not independent universal outcomes.

That uncertainty should change how teams adopt these methods. Measure rework, elapsed time, human attention, escaped defects, review findings, and recovery cost on your own task mix. Do not use repository stars, plan length, token count, or question count as a substitute for outcome evidence.

The most defensible conclusion is narrower and more useful: clarification reduces uncertainty about what should be built; planning manages dependencies in how it will be built; verification determines whether the result is acceptable. Match the depth of each layer to the cost of being wrong.

Sources and attribution

• Original Chinese article: “2026年，Superpowers 可能不再是 Claude/Codex/Workbuddy 的最佳方案了（附实操建议）” by 大刘 / 爱AI的大刘. All 12 English-localized visual derivatives are mirrored to R2; the original Chinese images remain in the review inventory, and the first derivative is reserved as the featured image.
• Official project sources: Superpowers repository, v6.1.1 release, Superpowers brainstorming, Matt Pocock’s Grill Me, Grilling, and Grill With Docs, checked 14 July 2026.
• Official agent guidance: Claude Code permission and Plan modes, How Claude Code works, and Introducing Codex.
• Empirical research: ClarifyGPT (FSE 2024), Ask or Assume? (2026 preprint), Asking What Matters (2026 preprint), Self-Planning Code Generation (TOSEM 2024), CodePlan (FSE 2024), and Agentless (FSE 2025).
• Alex Rusin’s three-tool planning comparison, used only as a single case study.