Tag: Agent Skills

Imagine asking a coding agent to “make failed payments more reliable.” It finds the background-job system, adds three automatic retries, writes passing tests, and produces a clean pull request. The implementation is technically competent. It may also violate customer-support policy, create duplicate-payment risk, and change the product experience without anyone authorising those choices.

This is not primarily a hallucination problem. The agent may understand the code perfectly. The failure is authority leakage: a system designed to execute work silently becomes the owner of a decision that belongs to a product, security, legal, or operations role.

A recent update to Matt Pocock’s open-source grilling workflow, reached through the small grill-me wrapper, makes two useful ideas explicit. The agent should investigate facts that already exist, and it should wait when the answer depends on a human choice. A confirmation gate then checks shared understanding before execution.

Those rules are a good starting point. Production agent systems need a broader operating model: one that connects conversational confirmation to tool permissions, sandbox boundaries, network policy, audit records, rollback, and measurable reliability. In other words, an agent needs an authority control plane, not just a polite prompt.

Authority is different from capability

Models are increasingly capable of proposing product rules, migration strategies, security controls, and operational responses. Capability answers, “Can the system produce a plausible solution?” Authority answers, “Who is entitled to choose this outcome, and under which constraints?”

The distinction matters because a repository contains several different kinds of information:

Information class	Typical source	Correct agent response
Retrievable fact	Code, tests, configuration, logs, documentation, authorised tools	Investigate and cite the evidence
Non-negotiable constraint	Regulation, contract, compatibility guarantee, budget, explicit project rule	Preserve it and flag conflicts
Owned preference	Product intent, risk tolerance, policy, design direction, new trade-off	Present options and wait for the responsible owner
Testable hypothesis	Prediction about users, performance, adoption, or an uncertain technical approach	Design a prototype, measurement, or reversible experiment

The fourth category prevents a subtle mistake. If no internal caller uses an API, that does not prove an external customer is not using it. Repository search cannot settle the question, but neither can a manager’s preference. The answer may require telemetry, a deprecation window, or a controlled experiment.

This expanded classification produces a better division of labour:

• Agents retrieve evidence.
• Systems enforce constraints.
• Accountable people make choices.
• Experiments resolve hypotheses.

NIST’s AI Risk Management Framework supports this organisational view. Its core asks organisations to define human and AI roles, document system knowledge limits, specify how outputs are overseen, and assign responsibility for AI risk. Oversight is therefore a designed operating process, not a generic “human in the loop” label.

Replace binary approval with four action modes

Not every tool call deserves the same interruption. A useful control plane assigns each proposed action to one of four modes.

1. Observe

Read-only inspection of code, documentation, logs, schemas, or authorised dashboards. These actions should usually proceed automatically when access is already in scope. The agent records what it inspected and does not mutate state.

2. Prepare

The agent creates a draft, diff, plan, migration preview, query, or message without applying it to the live target. Preparation is valuable because it converts an abstract request into something a reviewer can inspect. A prepared database migration is not the same as running it; a drafted email is not the same as sending it.

3. Execute with guardrails

The agent performs a bounded, reversible mutation inside a defined environment. Examples include editing files in a worktree, running tests in a sandbox, or changing a feature flag for a small canary. The control plane limits tools, credentials, network destinations, scope, and runtime.

4. Explicit approval

The action affects an external system, uses privileged credentials, creates a material commitment, changes customer-visible policy, destroys data, or is difficult to reverse. The agent pauses and presents an approval packet tied to the exact action.

This model is stricter than “ask before every write” and more useful than “let the agent decide.” It allows low-risk work to move quickly while concentrating attention on authority transitions.

English redraw of an illustration from the original Chinese report. The translated headline announces a major grill-me workflow update.

Use an authority budget, not a vague risk label

“High risk” is too imprecise to drive tooling. A more actionable approach evaluates five dimensions:

1. Impact: what happens if the action is wrong?
2. Irreversibility: can the previous state be restored completely and quickly?
3. Scope: how many users, records, services, or repositories are affected?
4. Uncertainty: how strong is the evidence that the proposed action is correct?
5. Novelty: is this a familiar, tested pattern or a new path with weak operational history?

This is an editorial synthesis of NIST risk management, OWASP least-agency guidance, and release-engineering practice—not a published standard. Its value is operational: increasing any dimension should reduce the agent’s autonomy or increase the strength of the control.

The same idea can be expressed as an authority budget:

• Which tools may the agent invoke?
• Which data and resources may those tools reach?
• How large a side effect may one action create?
• How long may the agent continue before a checkpoint?

A local formatting change may have a generous budget. A production schema deletion should have almost none.

OWASP’s guidance on excessive agency identifies excessive functionality, permissions, and autonomy as distinct root causes. That separation is important. Even a well-instructed model remains dangerous if its tool can execute arbitrary shell commands with a production administrator credential. Conversely, a narrowly scoped tool operating under the current user’s identity can make a model error much less damaging.

A confirmation packet should be parameter-bound

The least useful approval prompt is “Continue?” It hides the information the reviewer needs and encourages reflexive acceptance.

A serious approval packet should contain:

• Outcome: the user-visible or operational result.
• Exact action: tool, target, parameters, command, request, or proposed diff.
• Affected resources: files, services, records, users, and external systems.
• Effective identity: whose credential and which scopes will be used.
• Evidence: tests, repository facts, policies, and primary documentation.
• Decisions: choices already made and their accountable owner.
• Residual uncertainty: assumptions and unverified inferences.
• Blast radius: plausible worst-case impact.
• Recovery: rollback, restore, cancellation, or containment path.
• Reason for escalation: the boundary that requires approval.

The OpenAI Agents SDK human-approval flow illustrates several implementation details. Approval can be attached to specific tools, execution can pause with the tool name and arguments visible, state can be serialised, and the original run can resume after approval or rejection. Decisions can be scoped to one call instead of becoming vague permission for everything that follows.

That last point is critical. “Yes, send this email” should not become “Yes, send any future email.” Sticky approval can be convenient within a bounded run, but it should be explicit, time-limited, and tied to a known tool and scope.

Separate the decision plane from the execution plane

The same model that proposes an action should not be the only mechanism deciding whether the action is permitted. Prompts express policy intent; enforcement belongs in the surrounding system.

A bounded-autonomy architecture uses at least six control surfaces:

Tool surface

Expose only necessary operations. Prefer read_invoice and schedule_retry over a general shell or unrestricted HTTP client. Validate structured arguments before execution.

Identity surface

Run actions in the requesting user’s context where possible. Use short-lived credentials, narrow OAuth scopes, least-privilege database roles, and separate read from write identities.

Filesystem and process surface

Place code execution in an isolated workspace. Anthropic’s Claude Code sandboxing report describes filesystem and network isolation as complementary boundaries and reports that sandboxing reduced internal permission prompts by 84%. A filesystem boundary alone does not stop exfiltration; a network boundary alone does not stop local secret access.

Network surface

Default-deny outbound access for sensitive workflows, then allowlist required destinations. Log allowed and denied requests. Do not treat a URL fetched from untrusted content as implicitly authorised.

Approval surface

Pause before boundary-crossing actions and show the parameter-bound packet. Keep the approval mechanism outside the agent’s natural-language reasoning loop.

Trace surface

Record model and policy version, user goal, selected tool, exact arguments or diff, target, effective identity and scope, approval identity and time, result, and rollback pointer. NIST SP 800-53 provides implementation-grade least-privilege and audit principles: processes should receive only the privileges required, privileged functions should be audited, and audit records should capture who did what, where, when, and with what result.

OpenAI’s description of running Codex safely follows the same layered logic: sandbox policy constrains writes and network access, approvals govern boundary crossings, and telemetry captures security-relevant activity. The design lesson is more important than any vendor implementation: safety emerges from layers that fail independently.

Approval fatigue is a safety defect

Requiring confirmation for every action sounds conservative. In practice it can train reviewers to click through.

A controlled USENIX SOUPS study on warning habituation found that repeated non-security notifications reduced attention and adherence even for a new security warning, especially when the interfaces looked similar. The study was not about coding agents, so applying it here is an informed analogy. The implication is still useful: uniform approval dialogs can make exceptional risk look routine.

Approval design should therefore be tiered:

• Do not interrupt for authorised read-only investigation.
• Batch related low-risk prepared changes into one reviewable diff.
• Use distinct visual treatment for privileged, destructive, or externally visible actions.
• Explain why the action escalated.
• Show the exact side effect, not only the agent’s rationale.
• Measure approval volume, rejection rate, and time-to-decision.
• Remove approval prompts that never affect the outcome.

The goal is not zero friction. It is high-information friction at the moment responsibility changes hands.

Checkpoint, validate, and promote

Conversation-level approval is only one checkpoint. A stronger workflow separates preparation from promotion:

1. Snapshot: create a commit, worktree, database snapshot, or versioned configuration before mutation.
2. Act in isolation: let the agent modify a sandbox or staging target.
3. Validate: run deterministic tests, static analysis, policy checks, security scans, and task-specific graders.
4. Review evidence: present the diff, results, residual risk, and rollback pointer.
5. Promote atomically: merge, deploy, publish, or switch traffic only after the required approval.
6. Observe: monitor defined success and failure signals.
7. Rollback or expand: restore the previous state when thresholds fail, or progressively increase scope when evidence remains healthy.

This pattern imports proven release-engineering ideas into agent workflows. Google SRE’s canarying guidance recommends small, self-contained changes because they are easier and cheaper to reverse. A canary exposes only a limited population while the system compares outcomes and decides whether to continue.

For coding agents, the equivalent may be a local worktree, draft pull request, shadow query, dry run, feature flag, or limited rollout. Autonomy can increase as reversibility increases.

Worked example: redesigning payment retries

Return to the failed-payment request.

Observe

The agent inspects the queue, payment-provider integration, idempotency-key handling, error taxonomy, customer notifications, dashboards, and existing tests. It records factual findings and links them to files or documentation.

Map constraints

The agent identifies provider limits, contractual commitments, compliance requirements, and existing support procedures. If those sources conflict, it flags the conflict instead of selecting the most convenient interpretation.

Isolate owned choices

The team must decide which errors qualify for retry, maximum delay, customer-visible state, notification timing, and ownership of a final failure. The agent presents options and consequences.

Identify hypotheses

Whether retries improve recovery without increasing duplicates is an empirical question. The plan may require a small canary, a shadow calculation, or historical replay before changing live behaviour.

Produce the approval packet

The packet might propose one retry for a narrow transient-error class, preserve the existing idempotency key, exclude declined cards, add an operator metric, limit rollout to 5%, and automatically disable the flag when duplicate-attempt or error thresholds are exceeded.

Execute and observe

The agent implements the bounded change in a worktree, runs tests, opens a reviewable diff, and waits before production promotion. After approval, the system deploys gradually and records overrides, failures, and rollback decisions.

Most work remains agent-owned. Human attention is reserved for customer policy, financial risk, and production authority.

Evaluate both outcomes and trajectories

An agent saying “done” is not evidence. The final environment state must prove the claim.

Anthropic’s guide to agent evaluations distinguishes the outcome from the trajectory. The outcome is what changed in the environment; the trajectory is the sequence of model turns, tool calls, and intermediate actions. Both matter:

• A correct patch produced through an unauthorised production action is not a safe success.
• A perfectly compliant trajectory that fails to solve the task is not a useful success.

Use deterministic graders where possible: tests, schema validation, file assertions, permission checks, and state comparison. Use model-based grading for qualities that resist exact rules, then calibrate those graders periodically against human experts.

Evaluation should also separate:

• Capability suites: difficult tasks that reveal what the agent may be able to do.
• Regression suites: established behaviours expected to pass consistently.
• First-try usefulness: often expressed as pass@1.
• Consistency: the probability of succeeding across repeated trials, often expressed as pass^k.

Benchmarks such as SWE-bench are valuable because they apply generated patches to real repositories and run tests in controlled environments. They do not replace organisation-specific evaluation. Production authority failures may never appear in a repository issue benchmark.

Infrastructure can distort results too. Anthropic reported in its analysis of evaluation infrastructure noise that resource configuration alone moved Terminal-Bench 2.0 scores by six percentage points in one study. Small leaderboard differences should not drive autonomy policy unless the environments are comparable.

For long-running work, task duration matters. METR’s task-completion time horizon asks how long a task would take a human expert at a specified agent success probability. An operational inference follows: as the expected task horizon grows, checkpoints, state persistence, evidence review, and recovery mechanisms should become stronger.

Metrics for the authority control plane

Track technical performance and oversight quality together:

• Task success rate after environment verification.
• First-try success and repeated-trial consistency.
• Approval requests per completed task.
• Approval acceptance, rejection, and override rates.
• False-positive escalations: the agent asked for a decision that evidence could answer.
• False-negative escalations: the agent acted where approval was required.
• Time to escalation and time waiting for a decision.
• Post-approval failure rate.
• Rollback frequency and mean time to recovery.
• Tool errors, retry loops, and policy violations.
• Blast radius of failed actions.
• Human overrides by action class.
• Cost and token use per verified outcome.

The target is not fewer approvals at any cost. It is better allocation: fewer interruptions for facts, more reliable escalation for real authority changes, and stronger evidence before irreversible actions.

Confirmation belongs inside a lifecycle

NIST’s Generative AI Profile places governance, testing, monitoring, incident response, recovery, and deactivation in one lifecycle. Relevant practices include sending pre-deployment test evidence to release authorities, recording human overrides, defining escalation routes, maintaining fallback procedures, and establishing criteria for deactivation.

That suggests a continuous control loop:

Test → authorise → observe → override → learn → rollback or deactivate

A confirmation gate handles the authorise step. It cannot compensate for missing monitoring, an unusable rollback path, or a system that never learns from rejected approvals.

A practical rollout sequence

Teams do not need to build the entire control plane at once.

First: inventory side effects

List every tool and classify whether it reads, prepares, mutates locally, affects an external system, uses privileged identity, or performs an irreversible action.

Second: narrow the execution surface

Remove unused tools, split broad functions, reduce credential scopes, and run code in isolated workspaces. Enforce limits outside the prompt.

Third: define escalation policy

Assign action modes, authority owners, and the evidence required for promotion. Make rules parameter-bound and test them on both positive and negative examples.

Fourth: make recovery real

Add snapshots, dry runs, feature flags, limited rollouts, cancellation, and rollback. Test recovery rather than documenting an unverified command.

Fifth: trace and evaluate

Record trajectories and final state. Seed an evaluation suite with actual failures, including cases where the agent should proceed and cases where it must stop.

Sixth: tune the human experience

Measure approval burden and remove low-value interruptions. Preserve prominent, information-rich prompts for high-impact actions.

What this model cannot guarantee

An authority control plane does not make an agent correct. A reviewer can approve a harmful action. A sandbox can be misconfigured. A tool can hide side effects. A rollback can fail after data has propagated. A model can produce a persuasive but false rationale.

The design therefore assumes failure and limits its consequences. Prompts express intent; permissions bound capability. Tests provide evidence; traces support investigation. Human approval allocates responsibility; staged execution and rollback preserve operator control.

The most mature agent is not the one given unlimited freedom. It is the one embedded in a system that knows the difference between evidence, experimentation, and authority—and can prove what happened after the decision.

References

• Original Chinese report and image source — AI海森 / AI沐
• Matt Pocock’s skills repository and v1.1.0 release
• NIST AI Risk Management Framework Core and Generative AI Profile
• OWASP LLM06: Excessive Agency and Top 10 for Agentic Applications
• OpenAI Agents SDK: human-in-the-loop, sandboxing, and tracing
• Anthropic: Claude Code sandboxing and agent evaluations
• Google SRE Workbook: Canarying Releases
• USENIX SOUPS: The Fog of Warnings
• SWE-bench evaluation guide and METR time horizons

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.