grilling

Original：🇨🇳 Chinese

Translated

Ask and record decisions item by item regarding substantive unresolved user trade-offs in planning, product specifications, design, technical solutions, implementation, or release. Applicable to scope, priorities, trade-offs, risks, acceptance, dependencies, visual direction, or release authorization that cannot be closed from code, configurations, authoritative artifacts, or deterministic execution; it is not automatically triggered by new phases or new modules.

2installs

Sourceweberwang/phaser-skills

Added on2026-08-22

NPX Install

npx skill4agent add weberwang/phaser-skills grilling

SKILL.md Content (Chinese)

View Translation Comparison →

Grilling

Global Control Access

Control Plane Boundary: Proposals can be made, reviewed, and decisions recorded within the scope of Work Item task authorization or explicit approval, and must return to the

$phaser4-game-workflow-control

risk gate.

Grilling only generates

USER_DECISION

clarification records. Write user choices back to

taskAuthorization

, authoritative artifacts such as requirements/architecture/vision, or independent decision records, and clear the corresponding pending flags; do not write to the Approval Ledger, nor use terms like approval, review, pending, handoff, or approve to describe product choices.

Only let users decide matters that cannot be confirmed from the codebase, configurations, existing authoritative artifacts, or deterministic execution. Do not block pure factual queries, professionally determinable defects, or confirmed low-risk execution.

Entry Methods

Read the planning, design, technical solutions, acceptance, implementation, and confirmed decisions of the current phase, and distinguish between factual gaps, professional issues, and user trade-offs.
First close factual gaps through code, configurations, existing documents, and actual execution; leave professional quality to independent reviews. Enter grilling only when there are still user decisions that will substantially change scope, priorities, experience, architecture, risks, acceptance, dependencies, visual direction, cost, or release authorization.
For the first module or boundary change, first check code, configurations, contracts, and evidence; enter grilling only when substantive user trade-offs still exist. Records must be bound to Work Item, current gate, baseline, and failure conditions, and candidate identities cannot be fabricated.
When there is no product definition, start from target users, initial value, scope, business constraints, and risks; when there is an existing definition, only ask about gaps, conflicts, assumptions, or dependencies, and do not repeat existing conclusions.
New phases, new pages, first-time modules, or boundary changes themselves are not triggers.
Conduct open visual grilling only when trade-offs are still needed for visual direction, budget, signature strength, or implementation/asset costs. Do not re-confirm when a clear applicable baseline exists.
For V1/V2 with clear requirements or frozen baselines, and no visible deviations or substantive trade-offs among candidates, no questions are needed. During faithful restoration of specified renderings, only adaptations that do not change frozen visual facts and are within the project's predefined tolerance can be marked as
```
AUTO
```
; when professional quality fixes, engineering adaptations, or game feel improvements cause visible deviations, the impact and candidate solutions must be explained, and a precise confirmation must be requested while binding to approved exceptions. For new directions, equivalent solutions, visible structure/interaction changes, or trade-offs with high rework costs, only one confirmation request is needed; releases are still recorded according to A5/A6.
If there are no user decisions to be made, continue the original task directly without generating placeholder records.

Dialogue Rules

Ask only one question at a time; each question should explain the impact, recommended answer, and reasons.
Advance layer by layer from root decisions to dependent decisions, and only expand branches relevant to the current scope.
When answers expose conflicts or new dependencies, resolve the conflicts first, then return to the original branch.
Do not disguise recommendations as facts, nor treat unanswered questions or silence as consent.
Do not proceed with work directly affected by the grilling until the user explicitly confirms mutual understanding; independent work can continue.

Scope Branches

Product & Scope: Target users, initial value, success criteria, MVP, non-targets, priorities, and dependencies.
Experience & Trust: Key processes, failure recovery, permissions, privacy, payment, feedback, accessibility, and revocability.
Technology & Delivery: Irreversible architecture trade-offs, platforms, capability switches, API/data boundaries, acceptance, evidence, quality metrics, and risks.
Visual & Resources: Direction, information hierarchy, expression budget, authorization, cost, release eligibility, and verifiable quality standards.
Release: Candidate scope, remaining risks, rollback conditions, and external release authorization.

Completion & Documentation

After the user explicitly confirms mutual understanding, only summarize actual decisions, pending items, dependencies, rejected items, and next steps. Only explicit manual gate decisions are written to

.workflow-control/approvals/ledger.json

; regular task authorizations remain in Work Item. Domain owners then update authoritative artifacts, and must not record credentials, personal data, or full restricted contracts.

Prohibited Items

Do not ask facts that can be confirmed from code, configurations, documents, or execution evidence.
Do not leave implementation defects, lack of evidence, or professional aesthetic issues to users to bear risks.
Do not mechanically trigger or repeat questions due to phase advancement, module existence, or boundary changes.
Do not proceed with formal implementation or resource production directly affected when there are still unresolved scope, risk, or acceptance trade-offs.