prd

prd — the strategic layer of a product

It interviews the operator and produces the strategic definition of a product: vision, problem, users, scope, competitors, opportunities, open questions and glossary. It is the entry door to the method — out of this layer come the specs.

It always writes into the context/ of the loaded product node of the brain, never into the body repo. The repo declared in repo: of the node's head is the body: specs, technical decisions, as-built. The strategic layer lives in the head, not in the body.

The interview applies pressure with the method of .claude/skills/grill/SKILL.md#method: it is cited by that heading, never copied. Any change to the method happens there, once.

The files it produces

They go into context/ of the loaded product node. If the node has no context/ yet, it is born with README.md first and the rest as the interview gets completed.

File	What it answers
README.md	Index: what the product is, in what order each file was filled, its state
vision.md	The finished system, where it gets to
problem.md	What problem it solves, for whom, why now, how you know whether it worked
users.md	Who it sells to, what they use instead today
scope.md	What it does NOT do, who it does NOT sell to, hard constraints, what goes into the first version
competitors.md	What it competes against and how it differs
opportunities.md	What might be worth it and has not been decided
open-questions.md	What is left to decide — live, it empties out as things close
glossary.md	The terms of the domain

No file in this list is written into the body repo. If completing a section forced touching the body repo or a resolver, the tool does not do it: it says so and stops — that is a stopping condition of the spec that brought it, not a decision of this session.

Without a product node, these eight generic filenames do not land loose in whatever folder the session started in, where they could overwrite files the user already had: they go into a product-context/ folder of the current folder instead — product-context/vision.md, product-context/problem.md, product-context/users.md, product-context/scope.md, product-context/competitors.md, product-context/opportunities.md, product-context/open-questions.md, product-context/glossary.md. With a product node loaded, the destination stays context/ exactly as above, unchanged.

The KPI tree does not go here: it belongs to another tool's metric brief; this skill references it if it already exists, it does not produce it.

Phase 1 — Read what the brain already knows before asking

Before the first question:

1. Identify the loaded product node and its context/ — if it does not exist, it is created with this interview.
2. Read in full the files that context/ already has. This is incremental: it is completed in stages and a filled section is never overwritten without saying so first.
3. Read the context of the owning organization and, if it exists, the dated research that applies — it lives in the research/ of the node, next to context/.
4. Tell the operator what you read and which sections you can already fill on your own with that. Only then does the interview start, and only over what is missing — you do not ask them what the system already has written.

Phase 2 — The interview

The questions come in rounds, as .claude/skills/grill/SKILL.md#method defines them, each with a line about why that section changes a decision. Without that line the question sounds like bureaucracy.

The six questions that force the truth

Opportunity and business stage, before touching the solution:

1. What is the strongest evidence that someone wants this? Not interest: behavior.
2. What do they solve it with today? If the answer is "with nothing", why do they live fine without this?
3. Name me a concrete person. Their job title, and what happens to them if they do not solve it.
4. What is the smallest version someone would pay for this week?
5. What surprised you watching someone use it or try to solve it?
6. In three years, does this become more necessary or less?

Research stage

Conclusions are not invented: if no research has been done, that is said and the matching discovery tool is offered. Questions cover the segment, the explicit non-target, and the alternatives the operator already uses today.

Solution stage

Before talking about what to build, the premise is challenged: is this the right problem? what happens if nothing is done? is there something already built that would do? Only then: vision, slicing, what it does NOT do with its reactivation condition, hard constraints, assumptions with their invalidation condition.

How to apply pressure

The method of .claude/skills/grill/SKILL.md#method decides when to counter-question, how many rounds, and what to do with the second resistance. It is not repeated here: it is applied.

Alternatives phase, mandatory

Before fixing the solution, 2 or 3 paths are presented, each with its effort, risk and what it reuses of what already exists:

• the smallest shippable one — the smallest version that can be launched this week,
• the one that ages best — the one that demands the least rework if the product grows,
• a lateral one that reframes the problem — a way out that is not "more of the same, smaller".

The operator picks one. Without this phase the document records the first idea, not the best one.

The explicit-gap rule

A gap is written only when the operator explicitly decides not to answer, and always with who closes it. A file full of gaps is not a deliverable: it is a failure dressed up as completeness. If a gap appears because the section was never asked about, it is not a gap: it is work not done, and the interview resumes.

Show before writing

Before touching any file, the operator is shown exactly what is going to be written —the content, not a summary— and their go-ahead is awaited. Only the files the interview touched get written; the ones that were already complete are not overwritten. A glossary term the operator accepted with "yes" in a round was already shown with its exact text: it is written then, as the method says, and is not shown again.

The closing verdict

At the end, one of three, always explicit:

• Complete — enough to write specs.
• Complete with reservations — it is possible to move forward, and these are the open questions that remain.
• Missing context — which file was left unclosed and what it takes to close it.

The minimums gate: if glossary.md, scope.md or the architecture of the body are left empty, no specs come out of there yet. It is said explicitly, never left to be discovered later.

Destination

The skill resolves the destination before producing the deliverable, never after. Three cases, two destinations:

• A product node is loaded: the deliverable goes to research/<YYYY-MM-DD>-<name>.md of that node.
• There is a brain, but no product node — no workspace yet, or a workspace without one: the deliverable is written to a file in the current folder.
• There is no brain at all: the deliverable is written to a file in the current folder.

With no product node, the file is written to the current folder anyway. The closing message names only the path it just wrote and stops there — that is the normal way this skill ends, not an anomaly to qualify.

This skill never asks which destination to use, and it never invents a third one.

The rest of the pack installs one skill at a time. Look at .claude/skills/ first and offer only the ones that are not there — once per session: the first time this skill closes in the session, never again on a later close of the same or another deliverable:

• grill — npx skills add pedroromeroluna/ai-first-product-skills --skill grill

The whole pack at once: npx skills add pedroromeroluna/ai-first-product-skills. That command installs what the pack offers; anything listed above it is installed by naming it.