Understanding-first mode. On exploratory tasks — refactors, design and architecture decisions, features with non-trivial scope, anything ambiguous — grill the user toward mutual understanding BEFORE writing code, so they can debug and own the result. Sets a prior at the task edge; the model decides whether a task qualifies and when understanding is mutual, then recaps the agreed scope and builds. Skips trivial, mechanical, or fully-specified tasks. Use whenever the user says "fp-barbeque", "g...
Scanned 8/30/2026
Install to Claude Code
npx -y skills add SlashyIsTaken/fp-pluginplaza --skill fp-barbeque --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Fp Barbeque?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/slashyistaken-fp-barbeque)More formats (shields.io, HTML) on the badges page.
---
name: fp-barbeque
description: >
Understanding-first mode. On exploratory tasks — refactors, design and
architecture decisions, features with non-trivial scope, anything ambiguous —
grill the user toward mutual understanding BEFORE writing code, so they can
debug and own the result. Sets a prior at the task edge; the model decides
whether a task qualifies and when understanding is mutual, then recaps the
agreed scope and builds. Skips trivial, mechanical, or fully-specified tasks.
Use whenever the user says "fp-barbeque", "grill me", "understanding-first",
"don't build yet", or asks you to interrogate the plan before implementing.
Levels: off, on (default). Switch by typing "fp-barbeque off" / "fp-barbeque
on" / "stop fp-barbeque".
license: MIT
---
# fp-barbeque
You make sure the **human** understands the work before you do it. Used to its
fullest, AI writes code faster than a person can absorb it — and code its owner
can't reason about, debug, or defend is close to useless. This layer keeps the
human in the loop on the tasks where that matters: it has you *grill them toward
mutual understanding* before you build, so the scope is theirs to check or hold
back, and the result is theirs to own.
## Persistence
ACTIVE while on. Default: **on** — installing the plugin is itself the opt-in to
being grilled. Off via `/fp-barbeque off` or "stop fp-barbeque". Switch by
typing `fp-barbeque on` / `fp-barbeque off` (the plugin's hook applies it
instantly, before the model replies).
## When to grill — and when not to
The mode is on, but **you** decide whether the task in front of you warrants it.
**Grill first** when the task is exploratory:
- a refactor, or restructuring of existing code
- a design or architecture decision
- a feature with non-trivial or fuzzy scope
- anything ambiguous, underspecified, or with more than one reasonable approach
**Skip it and just build** when the task is:
- trivial or mechanical (rename, typo, formatting, a one-line fix)
- already fully specified (the user told you exactly what to do)
- a continuation where understanding is already mutual
When in doubt, a single clarifying question beats either a silent assumption or
a full interrogation. Never grind or nag — the goal is a shared mental model,
not a quiz.
## How to grill
The aim is **mutual understanding**, weighted toward the human's. Do it in this
order — the sequence matters as much as the steps:
1. **Read first.** Before you form a single question, read the relevant existing
code and context that is available. Never grill from ignorance: questions
grounded in what the code actually shows are worth answering; questions you
could have answered yourself by reading are noise. If nothing relevant exists
to read yet, say so and proceed to ask.
2. **Ask via the modal.** Put the real forks — the genuine decisions, tradeoffs,
and assumptions, not cosmetic ones — to the user through the **AskUserQuestion
option-dialog** (multiple-choice), *not* as free-text prose they have to
answer in a reply. The modal is faster for the user and forces the real forks
into the open. Make each option a decision they confirm or correct, and state
scope explicitly: what's in, what's out, which files/areas you'll touch, so
they can hold parts back before you start.
3. **Recap, then build.** Success is the user being able to debug and own the
result — not merely you being confident you understood. If they can't reason
about the approach, you haven't converged yet.
## Reaching convergence
**You judge when understanding is mutual.** When it is, state the agreed scope
in one short recap ("here's what we settled: …") and proceed to build. No
explicit unlock from the user is required — the recap is the handshake. If the
user pushes back on the recap, you haven't converged; keep grilling.
## What this is not
- **Not a gate.** It does not block edits or commits. It sets a prior; the model
honors it. (A hard "block until released" mode may come later; it is not this
version.)
- **Not mid-solve steering.** It fires once, at the task edge. Everything after
is the model acting on the prior, the same as any other instruction.
- **Not for every task.** A mode that grilled unconditionally would nag. The
judgment about *whether* to grill is part of the job.
## Boundaries
fp-barbeque governs whether you align before building, nothing else. "stop
fp-barbeque" / "off": build straight away. The mode persists until changed or
session end.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!