AI Product Skills Pack

Developers start building
before the plan exists.
This pack requires the plan first.

Drop one folder into your project. Claude Code now must define what success means before writing code, write down the scope before giving a time estimate, and plan what happens when the AI gives a wrong answer — or it cannot start the work.

Install in 30 seconds View on GitHub
2
Hard Gates
6
Skills
3
Agents
0
Unbounded Estimates
What gets skipped without this pack

Four ways product work fails before engineering starts

Not edge cases. The default outcome when no product quality enforcement exists.

No PRD Gate

"Build it and we'll figure out the metric later"

The feature shipped. Nobody agreed on what success looked like before it was built. Three months later, nobody can tell if it's working. The rollback argument has no data to stand on.

Blocked by prd-quality-gate — user problem, success metric with baseline, scope boundary, and anti-goals required before any estimate
No Scope

"It's probably a two-week job"

The estimate was given before the scope was written. The scope grew during the sprint. The two weeks became six. The estimate was the ceiling on expectations, not a ceiling on work.

Blocked by feature-scoping — written scope before estimate; estimate explicitly references the scope file
No Research Synthesis

"Users said they want X"

The research was done. Nobody synthesised it into decisions. The most vocal user's request made it into the roadmap. The pattern across 40 interviews didn't — because nobody extracted it.

Blocked by user-research-synthesis — every insight must chain to a decision; "users said X" requires "therefore we will Y"
No AI Validation

"The AI will just handle edge cases gracefully"

The AI feature shipped without a plan for hallucination UX, trust calibration, or what happens when it's confidently wrong. Users discovered the edge cases on day two and reported them as bugs.

Blocked by ai-feature-validation — hallucination UX, trust calibration, capability scope, and reversibility plan before approval
The 6 Rules

One rule per product quality failure

Two rules block work from starting until they're satisfied. Four rules enforce how every planning task is done.

prd-quality-gate The specific user problem, how you'll measure success with a real starting number, what's in and out of scope, and the time estimate — all five required before engineers start Hard Gate
ai-feature-validation What happens when the AI is wrong, how to show users what it can and can't do, what happens if it starts doing more than intended, and whether users can undo its actions — four checks required before any AI feature is approved Hard Gate
feature-scoping Written scope saved to a file before any time estimate. The estimate must reference that file. No 'we'll figure it out as we go.' Workflow
metric-definition The one number that measures success, two numbers that would mean something went wrong, a step-by-step view of the process, and a logging plan — all with real starting numbers before anything is built Workflow
user-research-synthesis Every finding from user research connects to a specific decision. Same number of findings and decisions. Every quote includes context. Every decision has an owner and a deadline. Workflow
ab-test-design What you're testing, how you'll measure it, how many users you need, how long it runs, when you can stop it early, and what you'll do in each of the four possible outcomes — all written before the test starts Workflow
How it works

Claude must produce real proof — not just say it's done

Each rule requires a specific output with real values. Claude cannot say a plan is ready without showing a real baseline number at a real file path.

prd-quality-gate — completion statement
PRD quality gate passed.
Feature: onboarding-flow-v2
PRD: product/prd/onboarding-flow-v2-2026-06-07.md ✓

User problem:
37% of new users drop before completing setup (Mixpanel, last 90 days)
Primary exit point: step 3 — workspace configuration (52% of drop-offs)

Success metric: 7-day activation rate
Baseline: 63% (Mixpanel cohort 2026-Q1)
Target: ≥ 75% within 60 days of launch

Scope boundary: steps 1–4 of onboarding only. Email verification not in scope.
Anti-goals: no changes to payment flow, no new integrations
Estimate: 14 days (references scope at product/scopes/onboarding-v2-2026-06-07.md)

Verdict: PASS — proceed to feature-scoping ✓

An agent that skips the metric definition cannot fill in Baseline: 63% (Mixpanel cohort 2026-Q1) with a real number.
That is the enforcement.

The 3 Specialists

Three AI roles Claude can take on

Each specialist has a narrow focus. All produce output at specific file paths — no chat-only results.

Sonnet

product-critic

Reviews plans and feature specs against all 6 rules. Verdict: pass, fix these things, or blocked. Writes the report to a real file. Never gives 'looks good.'

Sonnet

metric-designer

Sets up how a feature will be measured before it's built — the success number, the warning signs, how to track each step, what to log. Writes it to a real file.

Opus

research-synthesiser

Turns raw user research into a list of findings and decisions — one decision per finding, every quote with context. Writes the output to a real file.

Before and after

What changes when enforcement exists

The difference is work that was done before engineering started, not problems discovered after it finished.

✗ Without builder-product

✗ Feature scoped in a meeting. Estimate given without a written scope. Scope grew silently.
✗ No agreed success metric before build. Post-launch: "is it working?" answered by opinion.
✗ User research done, then filed. Most vocal user's request became the roadmap item.
✗ AI feature shipped. Hallucination UX undefined. Users discovered edge cases as bugs.
✗ A/B test run until "it feels significant." No stopping rule. No decision rule. No reproducibility.
✗ No anti-goals. "While we're there" scope additions accumulated throughout the sprint.

✓ With builder-product

✓ Written scope at product/scopes/ before estimate. Estimate references scope file path.
✓ 7-day activation rate, baseline 63%, target ≥ 75%. Logged from day one. Unambiguous at review.
✓ 40-interview synthesis: 8 insights → 8 decisions with owners and timelines.
✓ Hallucination UX designed. Low-confidence state defined. Irreversible actions confirmed.
✓ Calculated n=1,842 per arm. Fixed stopping rule: p < 0.001 at ≥ 80% sample for early stop.
✓ Explicit anti-goals block scope additions. Every deviation requires a new prd-quality-gate pass.
Installation

30 seconds to enforce product quality

Installs only skills/ and .claude/agents/. Non-destructive — won't overwrite existing files.

macOS / Linux
bash <(curl -fsSL https://raw.githubusercontent.com/
RBraga01/builder-product/master/install.sh)
Windows (PowerShell)
irm https://raw.githubusercontent.com/
RBraga01/builder-product/master/install.ps1 | iex
Start with prd-quality-gate before any feature enters planning. Run ai-feature-validation for every feature that calls an LLM. The product-critic agent reviews against all gates and writes a PASS / CONDITIONAL / BLOCK verdict to file.
The builder-* ecosystem

One pack per domain

All packs work standalone. All share the same enforcement model. Use one, some, or all.

Foundation

A Team

25 pre-configured engineering specialists, 18 workflow skills, a lead orchestrator, and a Pipeline Auditor. The base layer.
You are here

builder-product

Product quality gates. PRD, scoping, metrics, research synthesis, A/B test design, AI feature validation.
AI Engineering

builder-ai

Eval, prompt versioning, fallback design, RAG pipelines, safety review. Three hard gates that block ship.
Design

builder-design

AI UI design enforcement. States, streaming UI, prompt UX, accessibility, and design tokens.
Growth

builder-growth

Growth quality gates. Positioning, copy, funnel analysis, experiments, retention design, AI messaging review.