grill-hard

name	grill-hard
description	Grilling session that challenges your requirements against the existing codebase. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".
disable-model-invocation	true

Brainstorm

Start by understanding the current project context. Then, relentlessly interview the user about every aspect of the plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

The output is a brainstorm session document, not an implementation plan. However, details must be concrete enough to avoid ambiguity. Weak assumptions and underestimated risks are unacceptable—call them out or resolve them.

What belongs in problem description vs. implementation plan

Problem Description (this skill)	Implementation plan (separate step)
What the system must do and why	How to build it (file changes, task order)
References to existing types, interfaces, method signatures	Actual code diffs and new file scaffolds
Pseudo-code or data-flow sketches clarifying behavior	Step-by-step implementation instructions
Constraints, invariants, edge cases	Detailed test plans with exact assertions
High-level acceptance criteria	CI commands, deployment steps

Workflow

1 Parse the user intent

Extract:

• Primary user goal (what "success" looks like)
• Inputs/outputs
• Ambiguous terms and implied constraints
• Hidden subproblems or coupled concerns

2 Decide whether this is one task or multiple tasks

Assess if the request mixes multiple high-level concepts. If yes, split into units:

• Independent units: can be implemented and verified separately (prefer this split)
• Sequential units: require an earlier prerequisite slice

Outcome of this step MUST be:

• A named list of units
• A recommended ordering

Rules:

• Prefer the smallest slice that provides user-visible or measurable value.
• Do not "boil the ocean".

3 Challenge and validate ideas or proposals

• Does the potential solution solve the right problem, for the right user?
• Are terms unambiguous (add glossary if needed)?
• Are there contradictions or missing states (edge cases, error states)?
• Is the request actually a prerequisite problem (e.g., missing abstraction, missing data model)?
• Are constraints real or assumed? Flag weak assumptions explicitly.
• Are the proposed features or requirements justified by user value, or are they "nice to have" features that should be deferred?
• Sharpen fuzzy language. When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."

4 Ground in codebase reality

• Identify the existing types, interfaces, and modules that the feature touches.
• Reference concrete method signatures and data structures—not vague module names.
• Note architectural constraints (layer boundaries, dependency direction) that shape what is achievable.
• Surface risks: missing abstractions, type gaps, invariants that may break.
• When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"

5 Ask targeted questions

• Use AskUserQuestion tool to ask the smallest set of questions that materially affects behavior, scope boundaries, acceptance criteria, or feasibility
• Prefer multiple choice questions when possible, but open-ended is fine too
• Present options conversationally with your recommendation and rationale
• When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.

6 Synthesize artifact

Produce docs/process/brainstorm/{Y-m-d-session-name}.md — containing the result of the brainstorming session. This document serves as the input for a future precise requirements or implementation plan.

Principles

• Be blunt: explicitly state what is unclear or inconsistent.
• Assume nothing: if a term has multiple interpretations, define it or ask.
• No weak assumptions: if something "should probably work", verify it or flag it as a risk. Underestimated risks poison downstream plans.
• YAGNI ruthlessly: Remove unnecessary features from all designs. No gold plating or bike-shedding,
• Watch for architectural antipatterns: leaky abstractions, cargo cult refactoring, lava layering or premature optimization.
• Focus: Keep the conversation and artifacts anchored to the chosen initial theme. Do not expand scope or switch to adjacent concepts unless they are required to clarify, make feasible, or verify the proposed ideas.
• No empty sections. Include only sections with content. Omit a heading, list, or subsection entirely when it would contain zero items — do not include empty lists, placeholder subsections, or negative statements like "none", "N/A", or "no open questions".

Output Template (you might change or expand this as needed)

{Y-m-d-session-name}.md

# [Feature Name]

## Session Summary

### Problem Statement

- ...

### Glossary

- ...

### Expected Behavior

Describe behavior as observable outcomes.

- Primary flow:
- Alternate flows:
- Error/invalid states:

### Scope

...

#### Includes

- ...

### Open Questions

- Q1: ...
- Q2: ...

IMPORTANT ensure that the artifact you produced is present in the correct directory. No need to display it in the output.