---
name: aipatterns-grill
description: Grill a product from idea to production, or grill a design-pattern application before code. Use when the user starts a new project, presents a product idea, or asks to build an app. Use for the full product lifecycle - discovery, research, requirements, architecture, design, implementation, testing, deployment, and cost planning. Use when the user wants to apply or implement a pattern such as factory, saga, circuit breaker, or rate limiting in real code. Asks questions in small rounds with recommended answers. Writes planning documents. Builds to a deployed, tested application. Not for explaining, researching, comparing, or reviewing a pattern in the abstract. Not for stress-testing a plan the user does not intend to build.
license: MIT
metadata:
  source: https://aipatterns.dev/skills
  version: "2.1.0"
---

# Grill: from product idea to production

This skill runs a grill: a guided workflow of questions, research, and decisions that ends in working software. Two paths share one method.

- **Build a product.** The user has an idea, a partial plan, or an empty repository. Run the lifecycle in "Phases". This is the primary path.
- **Apply a pattern.** The user is about to add a design pattern to a real codebase. Run "The pattern grill". The product lifecycle also runs it inside Phase 4.

Both paths end at working, tested software, or at an explicit stop from the user. A plan alone is not done.

## Choose the path

Pick the path from the request:

- New product, new app, new feature area, "build me", an idea, or a startup plan - build a product.
- A named pattern (strategy, factory, cache-aside, circuit breaker, rate limiting, ...) plus an existing codebase - apply a pattern.
- A product build that reaches architecture with a pattern candidate - build a product, and run the pattern grill inside Phase 4.
- Explaining, comparing, or researching a pattern in the abstract - stop. This skill does not apply.
- Stress-testing a plan or decision the user does not intend to build - stop. That is a different interview.

## Tell the user this first

Before the first question, show the user this message. Adjust the wording. Keep the meaning:

> This workflow turns your idea into a working application. It takes time. We will cover product discovery, research, design, architecture, implementation, testing, and deployment. The goal is a production-ready application, not a plan or a prototype. I will ask questions in small rounds. Each question comes with options to pick from, and you can always type your own answer instead. I will recommend one option per question. You decide.

IMPORTANT: Do not skip this message. Do not write product code before the user approves the implementation plan.

## How the grill works

Run discovery in rounds. Treat the project as a tree of decisions. Each decision has questions that depend on it.

A **frontier** is the set of questions you can ask now, because the user answered their prerequisites. Ask the whole frontier in one round. Keep each round to six questions or fewer. Split a larger frontier into two rounds. Number each question. Give every question two to four concrete options and mark your recommended one. Always add a free-text escape so the user can type their own answer. Then stop and wait for the user's answers.

Format a round like this:

```markdown
❓ **Q1** - **<question title>**: <question body>

A. <option>
B. <option>
C. <option>
✍️ Or type your own answer

➡️ Recommended: B - <reason>

---

❓ **Q2** - **<question title>**: <question body>

A. <option>
B. <option>
✍️ Or type your own answer

➡️ Recommended: A - <reason>
```

Rules for the options:

- Make each option a real, distinct answer for this project. Fill closed questions ("yes or no") with just two options; open questions get two to four. Never pad with options that all mean the same thing.
- The free-text escape stays on every question, even closed ones. The user is never forced into a choice that fits nothing.
- When the host has a native question picker (a structured multiple-choice prompt with a free-text escape), use it instead of the markdown format. It renders the options as clickable choices. Respect its per-call limits; send the remaining questions in another call.

Each round of answers settles decisions and opens the next frontier. Compute the frontier again and ask the next round.

Two rules split the work:

- **Facts are your job.** When a question needs a fact from the repository, the tools, or the web, dispatch a sub-agent to find it. Do not ask the user for a fact you can look up. Do not block the round on a running search. Only the questions downstream of that fact wait.
- **Decisions are the user's.** Put each decision to the user. Wait for the answer.

End every phase with a short summary: the decisions made, the open questions, and the documents written. Ask the user to approve the summary before the next phase. Do not make an architectural commitment before the user approves it.

If the user asks to skip the questions, record your assumptions in the business plan. Mark each assumption as an assumption.

Copy this checklist into your working notes and mark each phase as you complete it:

```text
- [ ] 0 Orient
- [ ] 1 Product discovery
- [ ] 2 Research
- [ ] 3 Requirements validation
- [ ] 4 Architecture and technology (approval gate)
- [ ] 5 Design direction
- [ ] 6 Implementation plan (approval gate)
- [ ] 7 Implementation
- [ ] 8 Testing
- [ ] 9 Security review
- [ ] 10 Deployment
- [ ] 11 Production readiness
- [ ] 12 Maintenance
```

If a check fails in any phase, fix the failure and repeat the check before you continue.

## Stage specs

Close every phase by writing its spec. The spec is the source of truth for the phase. Create the spec file when the phase starts, from the stage spec template in [references/artifacts.md](references/artifacts.md). Fill it as the decisions land. Write it to `specs/<NN>-<phase-name>.md` in the planning directory. NN is the two-digit phase number.

The spec records the questions you asked with the user's answers, the decisions, the assumptions, the outputs, and the open questions. When you resume a project, read the specs first. Rebuild the frontier from them.

## Phases

| Phase | Name | Main outputs |
|-------|------|--------------|
| 0 | Orient | Environment notes |
| 1 | Product discovery | Business plan draft |
| 2 | Research | Research report, reference collection |
| 3 | Requirements validation | Business plan, requirements specification |
| 4 | Architecture and technology | Architecture, technology choices, cost estimate |
| 5 | Design direction | Design direction document |
| 6 | Implementation plan | Implementation plan, testing strategy, deployment plan |
| 7 | Implementation | Working, tested software |
| 8 | Testing | Full test pass results |
| 9 | Security review | Security findings and fixes |
| 10 | Deployment | Deployed application |
| 11 | Production readiness | Production checklist, monitoring, backups, rollback plan |
| 12 | Maintenance | Handoff notes |

Write each document with the template in [references/artifacts.md](references/artifacts.md). Create the document from its template when its phase starts. Update it as decisions land. Ask the question sets in [references/questions.md](references/questions.md).

### Phase 0: Orient

Inspect what exists before you ask anything.

- Repository: structure, README, contribution rules, existing planning notes.
- Skills: the available skills listing. Record which skills exist.
- Tools: MCP servers, project scripts, package manager, test runner.
- Conventions: naming, formatting, document locations.

Record the findings as environment notes in the planning directory. Reuse what exists before you propose anything new.

### Phase 1: Product discovery

Use the product discovery questions in [references/questions.md](references/questions.md). Cover vision, target users, problems, features, requirements, constraints, success criteria, technology preferences, budget, and operating costs. Keep asking rounds until the frontier is empty.

When the vision, the users, and the version 1 features are clear, start Phase 2 in the background. Do not wait for the remaining discovery answers.

### Phase 2: Research

Research is mandatory. Run the three research tasks in [references/research.md](references/research.md) as parallel sub-agents: product research, design research, and technical research.

When the agents report, consolidate the findings into the research report and the reference collection. Label every finding as verified, recommended, or inspiration. Keep every credible link. Record which finding shaped each major choice. If sub-agent tooling is unavailable, do the research yourself and record that limitation in the report.

### Phase 3: Requirements validation

Test the requirement set. Use the requirements validation questions in [references/questions.md](references/questions.md) to find gaps. Name every contradiction between answers and ask the user to resolve it. Check the research findings against the requirements. Flag where research shows a requirement is unrealistic, already solved better, or missing.

Write the business plan and the requirements specification.

### Phase 4: Architecture and technology

Use the architecture and technology questions in [references/questions.md](references/questions.md). Recommend one option per topic. Explain the trade-offs. Reject complexity that no requirement needs.

- Check each candidate technology against its current official documentation before you recommend it. Use a documentation tool such as Context7 when one is available.
- When a design pattern becomes a candidate, run the pattern grill (below) before you commit.
- Research the cost of every service before you recommend it: hosting, database, cache, queues, storage, third-party APIs, and AI usage. Use the current official pricing pages.
- Run the cost review in [references/questions.md](references/questions.md) before the approval gate. Compare the estimate with the budget numbers. Present cheaper options when the estimate exceeds the budget.

End this phase with a formal approval gate. Show the architecture, the technology choices, and the cost estimate. Do not continue before the user approves.

### Phase 5: Design direction

The design research from Phase 2 is mandatory input here. Ask the user about pages, layouts, aesthetics, responsive behavior, accessibility, onboarding, and authentication screens before you commit to a direction.

Produce the design direction document: visual direction, key screens and flows, accessibility target, and the design system choice. Use the research references as inspiration. Build an original direction that fits this user's requirements. Do not copy a reference product.

Invoke the installed design skills for this phase. Check them in the skills listing first. See "Skills: check, install, invoke".

### Phase 6: Implementation plan

Write the implementation plan, the testing strategy, and the deployment plan. Build them after the frontier is empty and the user answered the requirements questions.

- Order milestones so each one ends in working, tested software.
- Cover unit, integration, end-to-end, performance, security, and accessibility tests in the testing strategy. Add multi-tenant isolation tests when the product isolates tenants.
- Write realistic acceptance criteria for each feature. Name the test environments and the CI checks.
- Name every environment variable and secret in the deployment plan.
- End the plan with the task checklist. Give each task one `- [ ]` line with its files, its acceptance criteria, and its check command.

Ask the user to approve the plan before Phase 7.

### Phase 7: Implementation

Build the software. Do not stop at the plan.

- Dispatch the tasks with the coordination prompt in [references/coordination.md](references/coordination.md). One task per agent. Mark a checklist line done only after the check command passes on your side.
- Read the official documentation of the selected framework before you write code. Use an installed framework skill when the listing has one.
- Invoke the design skills for interface work.
- Complete each milestone. Run its tests. Check that the software runs. Then start the next milestone.
- Preserve existing functionality. Reuse established implementations. Never remove working logic without a tested replacement and tests that cover the change.

### Phase 8: Testing

Run the full test pass from the testing strategy: unit, integration, end-to-end, performance, security, and accessibility. Use an end-to-end tool such as Playwright unless the repository already runs one. Use AI-assisted testing where it helps: generated test cases, generated test data, or an agent that drives the application end to end. Fix what fails. Run the failing tests again until they pass.

### Phase 9: Security review

Invoke a security review skill when the listing has one. Otherwise run a structured review: input validation, authentication, authorization, secrets, dependency vulnerabilities, rate limiting, and data exposure. Check multi-tenant isolation when the product isolates tenants. Fix every finding at the source. Re-test after each fix.

### Phase 10: Deployment

Deploy with the deployment plan. Check the deployment: the application loads, the main flows work, and the logs are clean. When the user runs deployments personally, prepare everything, check the plan, and give the deployment to the user.

### Phase 11: Production readiness

Fill the production checklist in [references/artifacts.md](references/artifacts.md) before you call the project done:

- Error tracking, logging, and alerts work.
- Backups run on a schedule. A restore succeeded in a test.
- The rollback plan works.
- The accessibility and performance targets from the requirements hold.
- The monthly cost matches the estimate in the cost review.

### Phase 12: Maintenance

Write the handoff notes: how to run, test, deploy, and extend the application. Record the known risks and the cost risks. Update every planning document to match the shipped application.

## The pattern grill

Run this grill when the user is about to apply a pattern to a codebase, or when Phase 4 makes a pattern a candidate. You are about to add a pattern to a real codebase. Interrogate the code and the user first. Write the pattern's code only when both answers are in hand. If the pattern does not fit at all, first establish a concrete, current pain in this codebase. No proven pain, no grill, no pattern.

1. **Check the intent is application.** Explaining, comparing, or reviewing a pattern needs no grill. Stop there. Applying it to this codebase needs the grill.
2. **Inspect the code where the pattern would land.** Find the callers, the layer boundaries, the tests, and the idioms in use. A middleware chain, a DI container, or a fetch wrapper is often the pattern, already running under another name.
3. **Detect existing infrastructure before you assume it is absent.** Search package manifests and config first. Look for caches (`redis`, `memcached`, `lru-cache`), queues (`bullmq`, `pg-boss`, `sqs`, `celery`), schedulers, cron, event buses, rate limiters, and feature flags. Note the deploy target and the instance count. They decide whether a per-process answer is enough.
4. **Read the pattern's grill card** in [references/apply-grills.md](references/apply-grills.md), or call the MCP tool `grill_pattern` at https://aipatterns.dev/mcp. Every card has three fields. **Inspect first**: the signals to find in this codebase. **Missing pieces**: the infrastructure or libraries the pattern needs, with options and their trade-offs, costs, and operational burden. **Ask before you build**: the questions whose answers change the design.
5. **Ask the user only what the inspection did not answer.** Group the questions as scale, performance, reliability, budget, and implementation. Give every question its options and the free-text escape, in the round format above. Never ask what the code already answered. Never skip a question whose answer would change the design.
6. **Recommend the smallest option that fits.** State its trade-offs, costs, and operational requirements. When the existing setup already covers the need, recommend no new infrastructure. Do not start budget-changing work before the user answers.
7. **Then implement** the pattern here in small behavior-preserving steps. One step at a time. Tests stay green between steps.

Report before you build. Name each infrastructure gap you found present or absent. Name each question with the user's answer. Name the recommended option with its cost. If an answer changes whether the pattern fits, re-read the pattern's "Do not use it when" rules before you implement anything.

## Skills: check, install, invoke

Never assume a skill exists. Never assume an installation succeeded.

1. **Check.** Read the available skills listing in your context. Look for a skill whose name or description matches the need. Names differ between environments.
2. **Install.** When the need exists and no skill covers it, offer to install one. Use the ecosystem installer: `npx skills find <topic>` to search, `npx skills add <owner/repo@skill>` to install. Propose a source only when it is official or widely installed.
3. **Re-check.** After an install, run the check again: the skill directory now exists with a SKILL.md file, or the skill appears in the listing. State the result.
4. **Invoke.** Call the skill at the phase that needs it.
5. **Report.** When installation is not possible, say so. Continue without the skill. Record the limitation in the phase summary.

Match these needs to skills at these phases:

| Need | Known examples | Phase |
|------|----------------|-------|
| Visual design direction | `frontend-design` | 5, 7 |
| UI and UX design, audit, polish | `impeccable` | 5, 7, 8 |
| Framework conventions | a framework skill for the chosen stack | 7 |
| Test strategy and automation | a testing skill such as TDD or end-to-end testing | 6, 7, 8 |
| Security review | a security audit skill | 9 |
| Plain-language rewrite of user-facing text | `asd-ste100` or an equivalent plain-language skill | every phase |

The example names come from one installation. Check the listing in the current environment. A missing name can mean a different name or a missing skill.

Reuse existing tools, MCP servers, and project conventions before you add a dependency or write a custom implementation.

## Standing rules

- IMPORTANT: never stop at a plan. The workflow ends at a deployed, tested application, or when the user stops it. A plan, a prototype, or a partial build is not done.
- **Keep documents consistent.** When an answer changes a decision, update every document that records it before you continue.
- **Write plainly.** Write all questions, summaries, and documents in plain technical English: active voice, short sentences, one idea per sentence, no hedging. Use a plain-language skill when the listing has one.
- **Reuse before rebuild.** Check the repository, the installed skills, the MCP servers, and the standard library before you add a dependency.
- **Report honestly.** State limitations. Never claim research, a test pass, or a check that did not run.
- **Protect existing work.** Never remove working logic without a tested replacement and test coverage.
- **Costs before commitments.** Attach a monthly cost estimate to every infrastructure and service recommendation. Justify each recommendation against the requirements and the budget. Prefer the option that meets the requirements at the lowest cost.

## Examples

**Scenario: a vague idea.** The user says: "Build me a chat application." Run the full lifecycle. Phase 0 finds an empty repository. Phase 1 asks the first frontier: target users, chat modes, platforms, expected users in year one, build budget, monthly cost ceiling. Phase 2 starts the three research sub-agents once the vision and the version 1 features are clear. Phase 4 recommends the smallest stack that fits. Example: one managed database, one hosted authentication service, one managed platform with WebSocket support. The cost review compares the estimate with the budget before the approval gate. Phases 7 and 8 build and test the application. Phases 10 and 11 deploy it and fill the production checklist. The workflow ends at a deployed application, not at a plan.

**Scenario: a pattern application.** The user says: "Add rate limiting to this API." Run the pattern grill. Inspect the routes and the middleware. Find an existing rate limiter in the package manifest. Read the rate-limiting grill card. Ask only what the inspection did not answer: the limit window, the store, the behavior at the limit. Recommend the smallest option that fits. Implement it in small steps with tests green between steps.

**Scenario: a continuation.** The user says: "We finished discovery last week. Continue." Read the stage specs in the planning directory. Rebuild the frontier from them. Resume at the first phase with an unchecked box in the checklist.

## Scope and routing

- This skill runs its own procedure end to end. Do not hand discovery, questioning, research, planning, or decisions to another skill.
- Invoke another skill only for a phase need that this skill names. Use the check, install, re-check, invoke, report steps above. Continue without the skill when it is missing.
- MCP tools are tools, not skills. Use the aipatterns MCP server tools (`grill_pattern`, `check_pattern_fit`) inside this workflow.
- The pattern path inlines everything it needs. It does not point to other aipatterns skills, because an installing agent may not have them.
- This skill does not apply to abstract pattern questions or to plan stress-tests without a build. Answer those directly, or let another skill take them. Do not start this workflow for them.

## References

- [references/questions.md](references/questions.md) - question sets for each grill phase
- [references/research.md](references/research.md) - research delegation prompts and consolidation rules
- [references/artifacts.md](references/artifacts.md) - document templates and the planning directory convention
- [references/coordination.md](references/coordination.md) - the task dispatch prompt and the merge rules
- [references/apply-grills.md](references/apply-grills.md) - the per-pattern grill cards, generated from the site content