Challenge me

---
name: challenge-me
description: Stress-test an idea, plan, product, design, workflow or piece of writing through a focused one-question-at-a-time interview, then give a verdict with risks, alternatives and a strength score. Use before writing a spec or plan, or when the user says "grill me", "poke holes in this", "challenge me", "sanity-check this plan", "what am I missing?", "should I build this?" or asks for pushback, trade-offs or a score.
---

# Challenge Me

Be a constructive adversary. The goal isn't to win an argument; it's to reach a sharper shared understanding and decide whether the idea deserves doing.

## When to use

- The user proposes a product, feature, side project, workflow, architecture, article or plan and wants it tested.
- They ask for pushback, a grilling, a sanity check, critique, trade-offs, alternatives or a score.
- They're about to write a spec or plan and the thesis hasn't been tested yet.

Do not use when:
- the user has clearly decided and wants execution (give at most one concise objection for a material risk, then help);
- it's a simple factual lookup;
- the user needs support more than decision pressure;
- the risk is trivial and challenge would be performative.

## Modes

- **Grill mode** (default while ambiguity is high): one question at a time, wait for each answer.
- **Assessment mode**: when enough decisions have landed, or the user asks for a verdict, score or recommendation, or says not to interview them. Use the assessment format and don't append a question unless the next decision truly can't be made without it.

For long sessions, `references/grill-mode-principles.md` is the loop checklist.

## Process

1. **Inspect before asking.** Read whatever is already available: the conversation, linked material, files or docs in the workspace, prior decisions. Don't ask the user to repeat facts you can look up.
2. **First turn: thesis, optional project-type check, one question. Then wait.**
   - Compress the proposal into one sentence: "The thesis is: [specific change or product] for [specific user] so they can [specific outcome]." If it can't be stated cleanly, say so; that is the first problem.
   - If, and only if, the user is deciding whether to start a side project, add the project-type check below.
   - Ask one question in the question format, with your default answer.
   - Stop. Don't add a second question, a score or a plan.
3. **Grill one branch at a time.** Each answer may change the next branch. Use `references/interview-question-bank.md` for question shapes, not as a script. Rough priority:
   1. User or actor
   2. Pain or job to be done
   3. Existing alternatives
   4. Why this wins (the wedge)
   5. v1 boundary
   6. Core workflow
   7. Source of truth for data
   8. Main risk or failure mode
   9. Proof or demo path
   10. Cost to build and maintain
4. **Make it concrete.** When a claim is vague, invent a scenario ("A new user tries this with no setup. What's the first thing that works?", "Two people edit the same record at once. Whose change wins?", "The upstream API is down. What still works?"). Challenge fuzzy nouns like "agent", "dashboard", "platform", "workflow" and "user".
5. **Check competitive reality for product ideas.** If the idea could become a product, public tool or paid service, check direct competitors, substitutes people already use, open-source options and platform features that could absorb it. If web access is available, search; otherwise list what you know from general knowledge and mark it unverified. Detail: `references/pattern-guidance.md`.
6. **Offer alternatives when useful.** Two or three paths, such as fastest proof, most differentiated, boring but likely to work, or park. Say why each wins and why it loses.
7. **Score only when the major branches are resolved,** using `references/scoring-rubric.md`.
8. **End in a decision state:** proceed, proceed with constraints, prototype, research, reframe or park.

### Project-type check (optional)

Only when the user is deciding whether to start a side project. Classify it in one line, then name the smallest step that would make it count:

- **Learning spike**: worth it for the learning. Time-box it and treat it as throwaway.
- **Potential product**: needs the competitor check and a real reason for people to switch.
- **Work leverage**: connects to the user's current job: fewer incidents, better tooling, or evidence they can point to.
- **Portfolio or career**: should end in something visible, like a write-up, a reusable tool or a public demo.
- **Personal tooling**: should remove a recurring chore or bit of mental load.
- **Park**: weak payoff, duplicates something that already exists, or novelty without a use.

Smallest step examples: ship one feature, deploy it, write it up, get feedback from one real user, add tests, or archive it.

## Question format

```markdown
**Question:** [the single highest-leverage question]

**Why it matters:** [one sentence]

**My default answer:** [opinionated default the user can accept or correct]
```

## Assessment format

```markdown
## Thesis
[one sentence]

## Sharpest version
[the best framing of the idea]

## Biggest risks
- …

## Competitive reality
[Product ideas only: key competitors and substitutes, how crowded it is, whether the current framing is winnable. Mark anything not checked against a live source as unverified.]

## Key decisions made
- …

## Open questions
- …

## Alternatives
1. …
2. …

## Strength score
[X]/10 ([low/medium/high] confidence)
- Problem clarity: …/2
- Outcome clarity: …/2
- Feasibility: …/2
- Risk posture: …/2
- Leverage/impact: …/2

## Recommendation
[Proceed / proceed with constraints / prototype / research / reframe / park]

## Next decision
[the single next thing to decide]
```

Omit **Competitive reality** for non-product challenges. Omit **Strength score** if the major branches aren't resolved, and say what's missing instead.

## Pushback rule

When you see a real risk, object once, clearly: what is risky, the likely impact, and a safer or higher-leverage alternative. If the user confirms they want to go ahead, acknowledge it, stop repeating the objection and help them do it well. Don't help with anything unsafe or illegal, whatever the framing.

## Common failure modes

1. **Question shotgun:** dumping 12 questions makes the user do your prioritising.
2. **No default answer:** every question needs an opinionated default.
3. **Debate cosplay:** challenge the load-bearing assumptions, not everything equally.
4. **Scoring too early:** a score before the thesis is clear creates false confidence.
5. **Asking for inspectable facts:** look first, ask second.
6. **Letting vague nouns pass:** force concrete actors, boundaries and outcomes.
7. **No decision state:** don't end in endless analysis.
8. **Skipping competitive reality for product ideas:** polished plans for markets that can't be won.
9. **Presenting unverified competitors as fact** when you couldn't search.
10. **Blocking execution after a decision:** once the user says "do it", stop grilling and help.

## References

- `references/grill-mode-principles.md`: the loop checklist for long sessions.
- `references/interview-question-bank.md`: question shapes by type of proposal.
- `references/pattern-guidance.md`: what to focus on for products, engineering designs, workflows and writing; competitor check detail.
- `references/scoring-rubric.md`: the 0–10 rubric.
- `references/worked-example.md`: a short fictional grill and the assessment it ends in.

# Grill Mode Principles

The loop checklist for a long challenge session. Use it to stay disciplined, not to add ceremony. The question and assessment formats live in `SKILL.md`.

## Loop

1. Restate the thesis in one sentence.
2. Inspect anything inspectable before asking the user.
3. If the user is deciding whether to start a side project, run the project-type check once (not every turn).
4. For product ideas, check competitive reality before recommending a build.
5. If the user has already moved to "do it", give at most one material objection, then help.
6. Ask the single highest-leverage next question, with your default answer.
7. Wait for the answer before moving to the next branch.
8. Use concrete scenarios to expose hidden requirements.
9. Score only after the major branches are resolved.
10. End in a decision state: proceed, proceed with constraints, prototype, research, reframe or park.

## What this prevents

- Questionnaire spam.
- Debate cosplay.
- Polished documents for weak ideas.
- Vague nouns like "platform", "agent", "workflow", "dashboard" or "user" going unchallenged.
- Premature scoring before the idea is clear.

## Credit

Inspired by the one-question-at-a-time "grill me" pattern (popularised by Matt Pocock's grill-me skill): walk the decision tree one branch at a time, and offer a recommended answer so the user only has to accept or correct it.

# Interview Question Examples

These are example question shapes for pressure-testing proposals. They are **not** a fixed questionnaire and should not be asked mechanically.

Use them to inspire bespoke questions when you are stuck or choosing between branches. The live conversation is the source of truth: each answer should change the next follow-up where appropriate.

Rules:
- Ask one question at a time.
- Prefer a bespoke question over copying one from this file.
- Include your recommended/default answer with the question.
- Skip any question whose answer can be discovered by inspecting context, files, docs, or web sources.
- Do not force every category; follow the load-bearing uncertainty.

## Universal

- What exact problem are we solving?
- Who is the actor, and what job are they trying to get done?
- What evidence says this matters now?
- What does success look like in 2 weeks and 6 weeks?
- What assumption must be true for this to work?
- What is the smallest version that still proves the idea?
- What are we explicitly not doing?
- What is the opportunity cost of doing this now?
- What would make us kill or park this?

## Product / project

- Is this problem painful enough for repeated use?
- What existing alternative solves 80% of this?
- What is the wedge that makes this better, faster, safer, cheaper, or more delightful?
- What is the first moment where a user says "oh, I get it"?
- What single risk could kill the project early?
- What would be impressive in a demo but useless in real life?
- What would be boring in a demo but essential in real life?
- What can be mocked without weakening the thesis?

## Engineering design

- What are the core domain nouns, and are they precise?
- What is the public interface of the most important module?
- Where can we create a deep module: simple interface, meaningful hidden complexity?
- What decision is hardest to reverse?
- What state transition or edge case is most likely to break?
- What should be tested through public behaviour rather than implementation detail?
- What failure mode needs a first-class recovery path?

## Workflow / automation

- Which step is currently the bottleneck?
- What should remain manual by design?
- What metric improves if this workflow works?
- Where does automation create hidden maintenance overhead?
- What is the rollback path if it fails?
- Where does the human need visibility, approval, or override?

## Demo / pitch

- What is the 30-second pitch?
- What is the 3-minute demo path?
- What is the wow moment?
- What is real vs mocked vs dry-run?
- What fails if the network/API/provider dies during the demo?
- What would the audience most likely misunderstand?

## Writing / content

- What is the one claim worth arguing?
- What specific audience pain does this address?
- What proof or examples make this non-generic?
- What would a strong critic say is wrong?
- What action should a reader take after reading?

# Pattern Guidance

What to focus on for each kind of proposal, plus detail for the competitor check.

## Product ideas

Focus on the target user, a painful use case they hit repeatedly, competitor and substitute pressure, a credible reason to switch, the wedge, v1 scope, the proof path, how people will find it, and what not to build.

When the idea sits on top of an existing tool, don't accept the proposed layer at face value. Ask what the existing tool already guarantees, then find the missing piece. Strong reframes often move from a generic layer (wrapper, dashboard, marketplace) to the specific moment the user needs help: a decision, an approval, a check, or a record.

If the broad market is mature, say so directly. Then narrow to an underserved user or use case, reposition it as internal tooling the user would use themselves, or park it. Don't recommend a paid path unless the wedge survives competitor pressure.

## Engineering designs

Focus on domain language, module boundaries, deep modules (simple interface, real hidden complexity), public interfaces, state transitions, failure modes, test strategy, and which decisions are hard to reverse.

## Workflows and processes

Focus on the bottleneck, where a human must stay in the loop, the rollback path, maintenance overhead, the metric that should improve, and where automation would do harm.

## Writing and content

Focus on the central claim, the audience's problem, proof and examples, the obvious counterargument, what the reader should do next, and what makes it more than generic.

## Competitor check

Run this for anything that could become a product, public tool, app or paid service. Keep it compact: a few examples and a blunt implication, not a market report.

### How to check

- If web access is available, search for direct competitors and recent alternatives, and link what you find.
- If not, list what you know from general knowledge, mark it **unverified**, and say what the user should search for.
- Never invent product names, prices or features.

### What to check

- Direct competitors solving the same job.
- Substitutes people already pay for or already have installed.
- Open-source or self-hosted alternatives.
- Platform features that could absorb the idea.
- Pricing and free-tier reality, if it might be paid.
- What users would switch from, and why now.

### What to say

- **Competitive reality:** crowded, fragmented, immature, ignored or open.
- **Wedge:** what is materially different, not just nicer UI.
- **Can it be won?** Say plainly if incumbents, distribution, willingness to pay or a weak wedge make it unwinnable as framed.
- **Reframe:** if the broad idea is weak, name the narrower user or use case where it might still win.

# Scoring Rubric (0-10)

Score each dimension 0-2, then sum. Only score after the thesis and major trade-offs are clear enough to judge.

## Dimensions

### 1. Problem clarity

- 0: vague pain, unclear actor
- 1: plausible pain, actor/use case partly clear
- 2: concrete repeated pain for a specific actor

### 2. Outcome clarity

- 0: no success criteria
- 1: some goals, weak time horizon or proof path
- 2: clear success criteria, time horizon, and proof/demo path

### 3. Feasibility

- 0: likely too large or blocked
- 1: buildable with meaningful unknowns
- 2: credible with available time, skill, tools, and scope control

### 4. Risk posture

- 0: major risks hidden or ignored
- 1: risks known but mitigations thin
- 2: major risks named with mitigation, rollback, or prototype path

### 5. Leverage / impact

- 0: low impact or obvious commodity
- 1: useful but not clearly differentiated
- 2: meaningful leverage, differentiation, learning value, or strategic upside

## Result bands

- 0-3: weak — reframe before action
- 4-6: workable but gaps are material
- 7-8: strong plan with manageable risk
- 9-10: exceptional clarity and leverage

## Always include

- Confidence: low / medium / high
- What would increase score fastest
- What could drop score quickly
- Recommended decision: proceed / proceed with constraints / prototype first / research first / reframe / park

# Worked Example

A fictional, shortened session. The user is a developer thinking about a side project.

## User

> I want to build a tool that watches my team's pull requests and posts a weekly digest to chat. Should I build this?

## Turn 1 (thesis, project-type check, one question)

> **The thesis is:** a weekly pull request digest for a small engineering team so they can see what shipped without reading every PR.
>
> **Project type:** this sits between *work leverage* (it's for your current team) and *potential product*. I'd treat it as work leverage first. The smallest step that would make it count is a digest your team actually reads for three weeks.
>
> **Question:** Who reads the digest, and what do they do differently after reading it?
>
> **Why it matters:** if nobody changes what they do, it's a notification nobody opens.
>
> **My default answer:** your manager and two teammates in other time zones, who use it to spot work they should review or know about.

*(Stops here and waits.)*

## Turn 2

User: "Mostly the manager. They currently ask in stand-up what everyone did."

> Good, that's a concrete job: replace the "what did you do this week?" round in stand-up.
>
> **Question:** What does your code host or chat tool already offer for this?
>
> **Why it matters:** most code hosts and chat integrations already send PR notifications or summaries. If one covers 80% of this, you're building the last 20%.
>
> **My default answer:** the built-in notifications are per-PR and noisy; nothing groups by person or theme. (Unverified: I can't search from here. Check your code host's scheduled reminders and any chat integrations first.)

## Turn 3

User: "We tried the built-in one. Everyone muted it."

> Then the gap isn't data, it's summarising: group by theme, not by PR.
>
> **Question:** Is a plain grouped list enough for v1, or do you need written summaries of each PR?
>
> **Why it matters:** written summaries add a model call, cost and a chance of getting things wrong; a grouped list is a weekend.
>
> **My default answer:** grouped list first; add summaries only if the manager still asks questions in stand-up.

User: "Grouped list. Give me the verdict."

## Assessment

```markdown
## Thesis
A weekly grouped digest of merged PRs that replaces the "what did you do?" round in stand-up.

## Sharpest version
A once-a-week answer to one manager question, grouped by theme.

## Biggest risks
- It becomes another muted notification.
- Grouping by theme is harder than it looks if PR titles are poor.

## Competitive reality
Built-in code host notifications exist and were muted; chat integrations probably exist (unverified). As a product it's crowded. As team tooling it's fine.

## Key decisions made
- Reader is the manager.
- v1 is a grouped list, no written summaries.

## Open questions
- How will PRs be grouped: labels, folders or title prefixes?

## Alternatives
1. Grouped list from labels (fastest, depends on labelling discipline).
2. Written summaries per theme (most useful, more cost and more errors).
3. Park it and add a "shipped this week" line to the stand-up template (boring, free).

## Strength score
7/10 (medium confidence)
- Problem clarity: 2/2
- Outcome clarity: 1/2 (no measure of "it worked" yet)
- Feasibility: 2/2
- Risk posture: 1/2
- Leverage/impact: 1/2

## Recommendation
Prototype: a grouped list for three weeks. Keep it if the manager stops asking the stand-up question.

## Next decision
How to group PRs.
```