Doc grounded grilling
Skill markoblogo/abvx-agent-skills/skills/doc-grounded-grilling
Stress-test a plan, feature, or design against the repo's existing docs, domain language, ADRs, and context files. Use when a task is ambiguous, terminology is fuzzy, architecture trade-offs matter, or the user wants alignment before implementation. Ask one question at a time, inspect the codebase when answers are already present, and sharpen the project's language as decisions crystallize.From its SKILL.md
npx -y skills add markoblogo/abvx-agent-skills --skill doc-grounded-grillingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.6 KB, 456 tokens by cl100k_base, as published. Nobody here has run it
Doc Grounded Grilling
Use structured questioning to align a plan with the repo's actual language, constraints, and existing decisions.
Workflow
- Read the nearest relevant context first:
AGENTS.mddocs/ai/*- ADRs
- repo docs
designmd-brand-kitartifacts when frontend or brand work is involved
- Ask one question at a time.
- If the answer is already in the code or docs, verify there before asking.
- For each question:
- identify the ambiguity;
- give a recommended answer or framing;
- wait for user feedback before continuing.
- Walk down the branches of the design tree until:
- terms are precise;
- boundaries are understood;
- key trade-offs are named;
- critical scenarios are covered.
- When a term or decision settles, classify the durable artifact:
- glossary/context update for canonical domain language;
- ADR candidate for hard-to-reverse or surprising trade-offs;
- PRD/spec note for scope and acceptance criteria;
- no artifact when the answer is temporary or already documented.
What To Challenge
- terminology that conflicts with existing domain language;
- assumptions contradicted by code or ADRs;
- vague nouns like "account", "session", "client", "job", "draft", "campaign";
- plans that skip the test seam, integration seam, or rollout seam;
- frontend ideas that ignore the current design system or brand shape.
Output
The session should leave behind:
- sharper language;
- clarified decisions;
- explicit open questions;
- identified docs that should be updated through
durable-context-maintenancewhen the decision settles; - proposed glossary/context or ADR updates when the task changed the repo's shared language or a consequential decision.
Guardrails
- Do not interrogate for its own sake; stop when the plan is clear enough to execute.
- Do not invent domain language when the repo already has one.
- Do not batch ten questions at once.
Final Report
Summarize resolved terms, decisive trade-offs, remaining open questions, and which docs should be refreshed next.
What ships with it: 2 files
1.5 KB alongside SKILL.md
agents/
- openai.yaml227 B
- SKILL_CARD.md1.3 KB