---
name: grill-me
description: >
  Interview the user relentlessly about a plan, architecture, or data model design until reaching shared understanding, resolving each branch of the decision tree. Use when the user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

**Triggers — use this skill when:**
- User says "grill me", "stress test this", "challenge my design"
- User asks to "poke holes", "find gaps", "review my thinking"
- User wants to validate a plan before implementing
- User says "interview me about this", "question my decisions"
- Used after `/architect` or `/plan` when the user wants to pressure-test the output
---

# Grill Me

Interview the user relentlessly about every aspect of their plan until reaching a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one by one.

## How It Works

Ask questions **one at a time**. For each question, provide your recommended answer based on what you know about the codebase and the Docyrus platform.

If a question can be answered by exploring the codebase or the discovery snapshot, explore it yourself instead of asking.

## Question Domains

Work through these domains systematically, but adapt the order based on what matters most for the specific plan:

### Data Model

- Why this data source and not an extension of an existing one?
- What is the expected record volume? Does the schema hold up at 10x scale?
- Are there fields that should be computed (formulas) instead of stored?
- Could any proposed data source be replaced by a custom query instead?
- Are slug and naming choices consistent with existing tenant conventions?

### Field Design

- Is this the right field type? (e.g., `field-select` vs `field-radioGroup`, `field-text` vs `field-richText`)
- Should this field be required, optional, or have a default value?
- Are validation rules sufficient? Too strict? Missing edge cases?
- For relation fields: is the cardinality correct? Should it be bidirectional?
- Are there fields that will rarely be used and could be deferred?

### Enumerations

- Are enum options exhaustive? What happens when a new option is needed later?
- Should this be an enum or a separate data source with its own lifecycle?
- Are enum values and labels clear and consistent?
- Is the ordering intentional?

### Relations and Dependencies

- What is the dependency graph between data sources? Are there cycles?
- What happens when a related record is deleted?
- Are there implicit relations that should be explicit?
- Does the creation order in the apply plan respect all dependencies?

### Access Control and Security

- Who should be able to read/write/delete these records?
- Are there tenant-level vs app-level permission considerations?
- Should any fields be hidden or read-only for certain roles?

### Edge Cases and Failure Modes

- What happens with empty states? First record ever created?
- What if the user enters unexpected data?
- Are there race conditions in concurrent record creation?
- What if a bulk import has partial failures?

### Implementation Feasibility

- Can this be built with existing Docyrus field types, or does it require platform changes?
- Are there known limitations in the current API that affect this design?
- Is the proposed migration path realistic?

## Interview Protocol

1. Start by reading the plan or architecture artifacts (PLAN.md, DATA_SOURCES.md, discovery snapshot, or whatever is available).
2. Identify the most critical or uncertain decision in the plan.
3. Ask one focused question about it, with your recommended answer.
4. Based on the user's response, either drill deeper into that branch or move to the next decision.
5. Track resolved decisions and open questions as you go.
6. When all major branches are resolved, summarize the final shared understanding.

## Output on Completion

When the interview is complete, produce a summary:

```markdown
## Resolved Decisions

- [Decision 1]: [Resolution]
- [Decision 2]: [Resolution]
...

## Changes to the Plan

- [Change 1]
- [Change 2]
...

## Remaining Open Questions

- [Question 1]
...
```

If the plan artifacts exist on disk (PLAN.md, data-sources.plan.json), offer to update them with the resolved decisions.
