dot-claude/skills/grill-me-with-docs/SKILL.md
Grilling session that challenges your plan against the existing domain model, sharpens terminology. Use when user wants to stress-test a plan against their project's language and documented decisions.
npx skillsauth add n1kben/dotfiles grill-with-docsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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>During codebase exploration, also look for existing documentation.
When the user uses a term that conflicts with the existing language in docs, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
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."
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.
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?"
Don't couple to language to implementation details. Only include terms that are meaningful to domain experts.
</supporting-info>development
Open Plannotator's browser-based code review UI for the current worktree or a pull request URL, then act on the feedback that comes back.
testing
Open Plannotator on the latest rendered assistant message and use the returned annotations to revise that message or continue.
development
Open Plannotator's annotation UI for a markdown file, converted HTML file, URL, or folder and then respond to the returned annotations.
development
Author and manage the ubiquitous language of a codebase — one precise, opinionated definition per domain term in CONTEXT.md, and a map of the bounded contexts and how they relate once a system has more than one. Trigger whenever the user wants to record, sharpen, or settle domain vocabulary — define a term, pick the word for a concept, document a bounded context or context map, or reconcile language that has drifted — however loosely phrased.