<!-- Generated by mstack from Misbah's Build Like This workflow. Regenerate instead of editing. -->

design-grilling

This skill is part of Misbah Khursheed's Build Like This workflow. Thinking, evidence, and explicit trade-offs come before generated output.

Project identity and sources of truth

The repository where this skill is installed is the host project being built. Build Like This is the method used to build it; mstack only installs and reconciles method resources. Do not assume mstack or Build Like This is the product unless project-owned sources explicitly identify this repository as mstack itself.

Use project-owned docs/, decisions, executable code, and tests as sources of truth. .mstack/templates/ are reference scaffolds to copy and adapt into project-owned documents, not product requirements and not a replacement for docs/.

Purpose

Surface the decision frontier that must be settled before docs/product.md or docs/architecture.md can honestly constrain delivery. This prepares those phases; it does not replace product-definition or architecture-design.

Required inputs

• The idea, feature, or change under consideration, plus any existing research, product, or architecture evidence.
• Known constraints, non-goals, and which decisions the user already considers settled.
• Whether glossary or ADR updates are deferred to grill-with-docs.

If a missing input would materially change the result, state the gap and obtain or discover it before proceeding. Otherwise label the assumption and continue.

Process

1. Restate the outcome, evidence versus assumptions, and the earliest lifecycle phase that is still incomplete.
2. Build a decision tree: each node is a consequential choice with dependencies; work only the frontier whose prerequisites are settled.
3. For each frontier decision, recommend a default grounded in repository evidence, word the question so accepting the recommendation is easy, and record the user's confirmed answer.
4. Route facts to inspection or specialist lanes; never invent user evidence, market size, or shipped behavior.
5. Stop when the frontier is empty or the remaining nodes require research-idea, identify-target-users, or another earlier phase.
6. Hand off a confirmed decision ledger to write-product-definition, design-architecture, or grill-with-docs—do not write those docs until the user confirms.

Output contract

• A frontier decision ledger with confirmed answers, rejected alternatives, and open research gaps.
• Explicit readiness signal for product-definition and/or architecture-design, or the earlier phase still blocking them.
• Pointers to evidence inspected; no fabricated citations.

Guardrails

• Do not write or overwrite docs/product.md or docs/architecture.md in this skill.
• Do not treat a plausible recommendation as confirmed without the user.
• Do not expand into implementation, tickets, or refactors while decisions remain open.

Delegation and parallel safety

• Material lifecycle work must delegate at least one bounded specialist lane when subagents are available. Prefer two or more concurrent lanes only for independent evidence gathering, analysis, or non-overlapping file ownership.
• The active lead owns integration and acceptance. Supporting agents do not recursively delegate unless explicitly promoted to lead a named lane.
• Assign distinct outputs and ownership. Serialize shared docs, contracts, schemas, migrations, deployments, external writes, and overlapping file edits.
• When subagents are unavailable, perform the same named specialist passes sequentially and state that constraint instead of implying parallel verification.
• Delegation never grants permission for outreach, consequential external actions, destructive changes, paid resources, or production operations.

End with the evidence gathered, verification performed, and any residual risk or unresolved decision.