Skip to main content

grill-with-docs

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (.agent/plans/{feature}) inline as decisions crystallize. Use when user wants to stress-test a plan against their project's documented decisions.

Datos de origen

Repositorio
input-output-hk/daedalus
Última actividad en el origen
22 de agosto de 2026 a las 15:30
Idioma detectado de SKILL.md
inglés
Estrellas
1247
Forks
296

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
grill-with-docs
description
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (.agent/plans/{feature}) inline as decisions crystallize. Use when user wants to stress-test a plan against their project's documented decisions.
<what-to-do> Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask the questions one at a time, waiting for feedback on each question before continuing. If a question can be answered by exploring the codebase, explore the codebase instead. </what-to-do> <supporting-info> ## Domain awareness During codebase exploration, also look for existing documentation: ### File structure Use `.agent/readme.md` as a high-level overview of the domain model. Use `.agent/plans/{feature}/` for detailed documentation of specific features. Create files lazily — only when you have something to write. If no `.agent/plans/{feature}/` exists, create it when the first planning record is needed. ## During the session ### Sharpen fuzzy language When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things." ### Discuss concrete scenarios When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts. ### Cross-reference with code When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?" </supporting-info>
Ver en GitHub