design-grill

Clarify ambiguous PRD, architecture, or UI decisions via a scoped decision tree.

133|9|Updated Mar 26, 2026
One-click install
npx skills add https://github.com/lync-cyber/CataForge --skill design-grill-lync-cyber
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design-grill
Source: https://github.com/lync-cyber/CataForge/tree/main/.cataforge/skills/design-grill
Command: npx skills add https://github.com/lync-cyber/CataForge --skill design-grill-lync-cyber

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps teams resolve ambiguous PRD, architecture, or UI decisions by systematically clarifying the underlying decision tree instead of guessing from incomplete information. It prevents premature choices, reduces rework, and keeps product, technical, and design decisions aligned with their proper owner and scope.

Core Features & Use Cases

  • Scoped deep clarification: Runs only when explicitly enabled or when project policy allows it, and it stays limited to PRD, architecture, or UI scope.
  • Decision-tree driven questioning: Follows dependent branches in order, asking only one question at a time while preserving facts, assumptions, and unresolved items.
  • Fact-first workflow: Uses local repository facts, current session context, docs, code, and references to avoid asking questions that can be answered by inspection.
  • Use Case: A team is unsure whether a feature belongs in PRD, architecture, or UI design, and this Skill walks them through the relevant decision path until the missing choices are explicitly confirmed.

Quick Start

Use the design-grill skill to deeply clarify the current PRD, architecture, or UI decision scope and continue only after the user explicitly confirms the next branch.

Frequently Asked Questions about design-grill

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I clarify ambiguous PRD decisions before starting development?

Clarifying ambiguous PRD decisions involves running a scoped decision tree that separates repository facts from unresolved choices, asking one question at a time until the missing product scope is explicitly confirmed.

What is a fact-first workflow for resolving UI specification gaps?

A fact-first workflow for UI specification gaps uses local repository facts, session context, and references to answer questions by inspection, avoiding unnecessary questions and ensuring only unresolved UI choices require user confirmation.

How do I systematically resolve architecture decision boundaries?

Systematically resolving architecture decision boundaries requires walking through dependent branches in order, validating facts first, and confirming each unresolved item explicitly to keep technical decisions aligned with their proper owner.

Does this decision tree questioning approach work for system design reviews?

Yes, the decision tree questioning approach works for system design reviews by enforcing one-question-at-a-time clarification, fact-first validation, and traceable summaries to resolve system boundaries and architectural scope.

Can I limit the clarification scope to only UI design and exclude PRD topics?

Yes, you can limit the clarification scope to only UI design, as the questioning stays strictly limited to PRD, architecture, or UI scope and runs only when explicitly enabled for the relevant context.

What's the best way to prevent premature design choices in a product review?

The best way to prevent premature design choices in a product review is to follow a scoped decision tree that separates facts from choices, enforcing explicit user confirmation before proceeding to the next branch.