跳到正文
FunCoding

搜索

搜索文档、Skill 和 MCP

grill-me

Interrogate the brief before a line is built — ask only the questions whose answers change the work, and put every unasked decision on the record as a stated assumption.

前端开发1.6k.claude/skills/grill-me/SKILL.md

安装

把这段话发给 Claude Code、Codex 或 Cursor。智能体会先检查安全性,你确认后才安装。

读取 https://funcoding.ai/skills/plugin87/ux-ui-agent-skills/grill-me/install.md ,按里面的步骤帮我安装这个 Skill。

SKILL.md

Step 0 — is the kit here? This skill reads files from the kit. Check once: ls ${CLAUDE_SKILL_DIR}/../../../tokens >/dev/null 2>&1 && echo KIT_OK || echo KIT_MISSING On KIT_MISSING only the skill folders were installed, which is what npx skills add does. Say so plainly, point the user at npx ux-ui-agent-skills init or the plugin install, and stop. Do not guess the contents of a file you could not open.

The gates catch a screen built wrongly. Nothing in this repo catches a screen built correctly from the wrong brief, and that is where the expensive rework comes from: four eval runs scored 14/14 on the gates and still came back from /critique as rework, every finding a decision no gate can see.

This command spends five minutes up front to remove that class of failure.

Target: $ARGUMENTS (the thing about to be built; if that is not clear, that is itself the first question).

1. Read before you ask

Asking for something the repo already answers is noise, and it teaches the user that answering you is a waste of time. Before writing a single question:

  • Look for an existing brief, CLAUDE.md, BRIEF.md, or a reference/ folder.
  • Look for an existing theme: ${CLAUDE_SKILL_DIR}/../../../tokens/*.json, design-tokens.json, theme.css. If one exists, the theme question is answered — do not ask it.
  • Look at the neighbouring screens and components. Framework, conventions, and the component inventory are usually visible, not unknown.

Every question you keep after this pass is one the code genuinely cannot answer.

2. The bank — grouped by what no gate can see

Pick from these. Do not ask all of them.

Purpose and lead

  • Who is this for, and what is the one task they came to finish?
  • What is the first thing their eye should land on? (Four equal cards means the answer is "nothing", and that is a composition bug before it is a design.)
  • What does success look like for them — what have they done when they leave?

Content reality

  • What does this look like with zero items? With one? With four hundred?
  • What is the longest string a real user will put in here — a 60-character project name, a nine-digit amount, an email with no spaces to break?
  • Which numbers are real and which are placeholder? Placeholder that ships as real is a lie the user catches immediately.

Irreversible actions

  • Which actions here destroy or cannot be undone, and what confirms them? (Destructive wears the danger variant in every place it appears — the trigger and the confirm dialog both. A blue Delete is an automatic fail.)
  • What happens when the action fails? What does the user read, and what can they do next?

Theme and platform

  • New theme or existing? If new: which direction, and does dark mode ship too?
  • What is the narrowest width this must survive? (The kit's floor is 280px.)
  • Which framework is the deliverable — and does it need RTL, AA or AAA?

Scope and done

  • How many screens or components exactly, and what is explicitly out of scope?
  • What has to be true before this is done: which gates, and is /critique part of the bar or not?

3. The rule on asking

  • Maximum seven questions, asked in one round. A drip of one question at a time is worse than a wrong assumption.
  • Every question must change the work. If both answers produce the same build, it is not a question, it is a default — take it and say so.
  • Never ask what you can choose well. Taste is the job. Ask about intent, content, and constraint; decide the rest.

4. Everything unasked becomes a written assumption

An assumption held silently is indistinguishable from a guess. Each one gets a line: what was assumed, the default taken, and what it costs if it is wrong.

Assumption: no dark mode requested -> shipping both anyway (the theme is already
dual, so the cost of including it is zero and the cost of retrofitting is not).

5. Output: a brief that can be checked later

Write BRIEF.md next to the work, in this shape:

# <what is being built>

Goal            one sentence, from the user's side
User and task   who, and the task they came to finish
Deliverables    exact list; N screens means N screens
Lead            the one thing the eye lands on first
Content reality empty / one / many, longest string, real vs placeholder
Irreversible    which actions, what confirms them, what failure reads like
Theme           source of truth, dark mode, brand direction
Platform floor  narrowest width, framework, RTL, AA or AAA
Out of scope    what this is deliberately not
Assumptions     each with its default and its cost if wrong
Done when       the gates that must pass, and whether /critique is part of the bar

This file is the thing /critique and a later reviewer argue against. A brief that lives only in the conversation cannot be checked, and so it will not be.

6. Then build, then prove it

/grill-me -> build -> /gate -> /critique. This command removes ambiguity. It does not produce quality, it does not score anything, and it is not a substitute for rendering the work and looking at it.

相似的 Skill

frontend-design
anthropics/skills180k

frontend-design

Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.

前端开发

web-artifacts-builder
anthropics/skills180k

web-artifacts-builder

Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Use for complex artifacts requiring state management, routing, or shadcn/ui components - not for simple single-file HTML/JSX artifacts.

前端开发

api-and-interface-design
addyosmani/agent-skills103k

api-and-interface-design

Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

前端开发

frontend-ui-engineering
addyosmani/agent-skills103k

frontend-ui-engineering

Builds production-quality, accessible, responsive user-facing UIs. Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requirements, managing state, or when the output needs to look and feel production-quality rather than AI-generated.

前端开发

performance-optimization
addyosmani/agent-skills103k

performance-optimization

Optimizes application performance across frontend, backend, queries, and databases. Use when performance requirements exist, when you suspect performance regressions, when Core Web Vitals or load times need improvement, when N+1 query patterns need fixing, or when profiling reveals bottlenecks.

前端开发

html-ppt-graphify-dark-graph
nexu-io/open-design100k

html-ppt-graphify-dark-graph

OpenDesign's feature business case for the plugin marketplace: the user pain, options, tradeoffs, and the measure of success. Built as a decision-grade product management deck for PM, eng, design, leadership.

前端开发