Menu
Interview the user relentlessly about a plan or design until shared understanding is reached.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Reviews educational assessment interfaces for WCAG 2.2 Level AA compliance and assessment-specific accessibility needs. Use when implementing new interactions, reviewing UI changes, or conducting accessibility audits of test-taking interfaces.
Use when the user asks to turn a conversation, feature discussion, or implementation plan into a draft PIE Elements NG PRD under docs/prds/.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Reviews a PIE controller implementation for correctness, scoring accuracy, and contract compliance. Use when implementing or reviewing controller.ts files — especially outcome(), model(), and createCorrectResponseSession().
Implements a new PIE element (or non-trivial extension) end-to-end: PRD review → Model/Session/Controller → Svelte delivery component → authoring surface → tests. Use when adding a new @pie-element/* package or extending an existing element with a new mode or config surface.
Drafts or updates a PIE element PRD following the project conventions in docs/prds/README.md. Use when starting a new element that meets the PRD bar, or when a substantial change requires updating an existing PRD.
| name | source-command-grill-me |
| description | Interview the user relentlessly about a plan or design until shared understanding is reached. |
Use this skill when the user asks to run the migrated source command grill-me.
Interview the user relentlessly about every aspect of the plan until you reach shared understanding.
Walk down each branch of the decision tree and resolve dependencies between decisions one-by-one.
For each question:
If the question can be answered by exploring the codebase, explore the codebase first and then:
Keep a running internal map of:
Stop only when blocking decisions are resolved and both sides confirm shared understanding.
