Skip to content
Skills Library
Management & product · Analysis

shape

/shape

Interview the user in short rounds that settle every decision an idea, plan or design depends on, each question with a recommended answer, before anything is built. Use when the user wants to brainstorm, discuss, ideate, shape or stress-test an idea, plan or design, asks to be grilled or interviewed about it, or when requirements are unclear before building; it fires on these requests in any language the user writes.

Licence
MIT
Last repository change
13.11.2026

Assessment and security

90/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content25 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
1
Scripts
0
HTML comments
0
URLs in SKILL.md
1
Deprecation

No signals detected. Repository changed on 13.11.2026, without references to retired models or APIs.

Licence

MIT, open: use and modify while retaining author attribution.

What it does and when to use it

Interview the user in short rounds that settle every decision an idea, plan or design depends on, each question with a recommended answer, before anything is built. Use when the user wants to brainstorm, discuss, ideate, shape or stress-test an idea, plan or design, asks to be grilled or interviewed about it, or when requirements are unclear before building; it fires on these requests in any language the user writes.

Arguments

/shape <idea, plan or design to shape>
Original author description

Interview the user in short rounds that settle every decision an idea, plan or design depends on, each question with a recommended answer, before anything is built. Use when the user wants to brainstorm, discuss, ideate, shape or stress-test an idea, plan or design, asks to be grilled or interviewed about it, or when requirements are unclear before building; it fires on these requests in any language the user writes.

How it works

  1. Which interview runs
  2. Procedure
  3. Records
  4. Language
Original SKILL.md headings · 43 lines, 571 words
SKILL.md preview
---
name: shape
description: Interview the user in short rounds that settle every decision an idea, plan or design depends on, each question with a recommended answer, before anything is built. Use when the user wants to brainstorm, discuss, ideate, shape or stress-test an idea, plan or design, asks to be grilled or interviewed about it, or when requirements are unclear before building; it fires on these requests in any language the user writes.
argument-hint: "<idea, plan or design to shape>"
---

# Shape

Turns an open idea, plan or design into decisions the user has made, one round of questions at a time, and acts on none of it until the user confirms the result.

Learned from `grilling` by Matt Pocock ([mattpocock/skills](https://github.com/mattpocock/skills), MIT); no text is copied.

**Topic:** $ARGUMENTS

## Which interview runs

Advisory (agent judgment), owner's order (12/11/2026):

1. This skill runs first.
2. `grilling` (`/grill-me`, or `/grill-with-docs` when the user wants a glossary and decision records kept) runs when this skill is not installed or the user asks for it by name; put its questions through the host's native question tool too.
3. Superpowers `brainstorming` only when the user wants many divergent design ideas rather than decisions, and it is installed.

In a Spec Kit repository this skill works inside a phase like the other phase tools and yields to Spec Kit's own clarify step. At router depth MIN, skip it unless the user asked for it.

## Procedure

Advisory (agent judgment); no hook or script enforces these steps.

1. **Map the decisions.** List what must be decided and draw the dependencies as a tree: a decision is open to ask only when every decision it depends on is settled.
2. **Split facts from decisions.** A fact the agent can find (a file, a command's output, a read-only subagent's search) is the agent's to find; never ask the user for it. Choices, priorities and trade-offs are the user's.
3. **Ask one round, in the native form.** Ask every open decision whose prerequisites are settled, and nothing that depends on an answer still missing. Each decision is one question in the host's native question tool (`AskUserQuestion` on Claude Code, `request_user_input` on Codex, `ask_question` on Antigravity), never a numbered text list: two to four options, your recommended option first with its trade-off in the option's description, the alternatives after it. A round larger than one call allows (four questions on Claude Code) is split across calls, blocking questions first. Plain text only when the session has no such tool, the tool fails, or the answer is free text. A question that waits on a lookup still running waits; ask the rest now.
4. **Update the tree.** Record each answer, add the decisions it opens, drop the ones it closes, and ask the next round.
5. **Close.** When no open decision remains, summarize what was decided and ask the user to confirm it. Act on nothing (no code, no file, no dispatch) before that confirmation.

When the user only wants many raw ideas, the first round offers two or three distinct directions as options; later rounds go deeper on the one they pick.

## Records

Advisory (agent judgment):

- Write each settled decision with its date where the work keeps its decisions: the work record's goal and acceptance section when `coding-router` created a work record, otherwise the plan, the issue or the pull request body.
- A decision the user cannot make yet stays open in that record, with who owns it and what would unblock it.
- In a delegated or headless run nobody can answer: list the open decisions with your recommended answers in the report, mark them unanswered, and never present a recommendation as the user's decision.

## Language

**Advisory (agent judgment):** Talk to the user in the language they are using, including questions and option labels; keep command names, flags, file paths, skill names and other technical names unchanged.

Versions

RepositoryScoreLicence
This page · finolabs/finolabs-vibecode90MIT
biliboss/skills100MIT
gmdkaio/kstack100MIT
ebullient/qrspi-x100Apache-2.0
YnotnaUK/ai-skills100MPL-2.0
jamesm-dev/payday-dev100MIT
nyelonong/galdr100MIT
thecraighewitt/skills100MIT
tiago-peixoto/claude-shapeup95MIT

Database snapshot: 13.11.2026 · package version 1efd2e5a0901 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 100grill
    Interviews the user about an under-specified feature, project, or plan before any code is written, one decision at a time with a recommended answer for each. Use when the user asks to be grilled, interviewed, or questioned about requirements, a plan, or a design before building.
  • 100interview
    Interview the user in short rounds to turn a vague idea or plan into settled decisions, with a recommended answer for each question. Use before a spec, when requirements are fuzzy, or when the user says "grill me".
  • 90decision-interview
    Settle each open branch of a plan or decision, one question per turn with a recommended answer; record mode keeps only pinned terms and qualifying decisions. USE WHEN named. NOT FOR unnamed clarifying, design, plans or building.
  • 100grill-with-docs
    Interview the user relentlessly about a plan or design until reaching shared understanding — one question at a time, walking each branch of the decision tree, every question carrying a recommended answer, and every answer grounded in the project's own docs and examples rather…
  • 87grilling
    Use when the user wants a plan, decision, or idea stress-tested, asks to be grilled or interviewed about it, or uses any 'grill' trigger phrase.
  • 100grill-design
    Stress-test a design, idea, or approach by interviewing the user one question at a time. Each question comes with a recommended answer AND a one-line self-critique of that recommendation. After each user answer, briefly stress-test the answer against prior decisions before…

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.