# TASK: v0.80 — AI Product Builder Track

You are working in the `Product-Manager-Skills` repository.

This document is the complete execution handoff for v0.80. Read it fully before touching any files.

---

## Mission

Create version 0.80 of `deanpeters/Product-Manager-Skills` as a coherent **AI Product Builder Track**.

Release thesis:

> AI compresses execution, but it does not improve judgment. v0.80 helps product managers build faster without outsourcing product sense.

This is not a vibe-coding prompt pack. It teaches PMs how to decide whether a problem deserves AI, prototype only what needs to be learned, define agent boundaries, evaluate AI quality, and hand off evidence without pretending a demo is a product.

---

## Hard exclusions — read before writing a single line

Do NOT use, mention, summarize, paraphrase, or derive examples from:

- Productside customer work
- Productside customer names
- Customer decks, workshops, or playbooks
- Consulting delivery artifacts
- Private business development material
- Any enterprise/customer case example that is not explicitly public and non-customer-derived

Allowed source material:

1. The public `Product-Manager-Skills` repository itself
2. The Substack export at `/Users/deanpeters/Code/15-days-of-aipm/substack/deanpeters.substack.com` (also archived as `research/deanpeters-substack-posts.zip`)
3. Public market evidence only when needed for release notes or context
4. Original synthesis from public/product-management concepts

When in doubt, exclude the material.

---

## Repo state at time of this handoff

**Branch:** main (clean)
**Current skill count:** 48 skills (verified in `catalog/skills-index.yaml`)
**Current command count:** 6 commands (verified in `catalog/commands-index.yaml`)
**After v0.80:** 57 skills, 9 commands

**Important:** `agent-orchestration-advisor` appears in CLAUDE.md as "complete" (Phase 6) but does NOT appear in `skills/` directory listing. Before creating any cross-references to it, run `ls skills/ | grep agent-orchestration` to confirm whether it exists. If it does not exist, remove references to it from new skills.

---

## Repo conventions — confirmed from live code inspection

### Skill frontmatter schema (exact — do not assume, use this)

```yaml
---
name: kebab-case-folder-name
description: Trigger-oriented description ≤200 chars. Explains what the skill does and when to use it.
intent: >-
  Richer multi-sentence explanation of what the skill does, who it serves, and why. Can be longer than description. Used in catalog and Streamlit.
type: component | interactive | workflow
theme: ai-product-builder
best_for:
  - "Short phrase describing a primary use case"
  - "Short phrase describing another use case"
  - "Short phrase describing a third use case"
scenarios:
  - "Complete sentence describing a realistic trigger scenario"
  - "Complete sentence describing another trigger scenario"
estimated_time: "X-Y min"
---
```

**Notes:**
- `name` must exactly match the folder name under `skills/`
- `description` ≤200 chars (Claude web upload limit)
- `intent` can be longer — this is the richer version
- `theme` for all 9 new skills: `ai-product-builder` (this is a new theme value — existing AI skills use `ai-agents`)
- `best_for` and `scenarios` are optional but should be included for discoverability in Streamlit
- `estimated_time` is optional but include it

### Command frontmatter schema (exact — from `commands/discover.md`)

```yaml
---
name: command-name
description: One-sentence description of what the command orchestrates.
argument-hint: "<what the user provides when invoking>"
uses:
  - skill-name-1
  - skill-name-2
  - skill-name-3
outputs:
  - Output 1
  - Output 2
  - Output 3
---
```

Followed immediately by a markdown body with these sections:

```markdown
# /command-name

One-sentence summary of what this command does.

## Invocation

```text
/command-name Example invocation text here
```

## Workflow

1. Brief step 1 description using `skill-name`.
2. Brief step 2 description using `skill-name`.
3. Continue through all skills in the uses list.

## Checkpoints

- Checkpoint 1 (decision gate or confirmation step)
- Checkpoint 2

## Next Steps

- What to do after this command completes
- What other command or skill to invoke next
```

### Skill section structure (confirmed from live skills)

```markdown
## Purpose
One paragraph. What this skill does and when to use it. Outcome-focused.

## Key Concepts
Core frameworks, definitions, mental models, anti-patterns, and tables.

## Application
Step-by-step guidance. Numbered when sequence matters. Decision points called out explicitly.
For interactive skills: question sequence and branching logic.
For component skills: template + quality criteria.
For workflow skills: process + orchestration, with references to child skills.

## Examples
Concrete real-world cases showing skill in action. Show the reasoning, not just the output.
For interactive skills: sample conversation flows.

## Common Pitfalls
Named failure modes with consequences and corrective actions. Not a polite list of reminders.

## References
- Links to related skills in this repo (use relative paths: `../../skills/skill-name/SKILL.md`)
- Source frameworks (JTBD, etc.)
- Source Substack posts if directly relevant (use public Substack URLs)
```

### Catalog behavior

The catalog is **fully auto-generated**. Never hand-edit:
- `catalog/skills-by-type.md`
- `catalog/skills-index.yaml`
- `catalog/commands-index.yaml`
- `catalog/commands.md`

After all skills and commands are written, regenerate with:

```bash
python3 scripts/generate-catalog.py
```

### `dist/` behavior

`dist/` is generated by build scripts. Never hand-edit anything in `dist/`.

### No `references/` directory

The repo has no `references/` directory. Do not create one. Instead, embed the AI Product Builder Principles directly in `ai-product-builder-playbook` (Key Concepts section) as a named section titled "AI Product Builder Principles." Reference them in 2-3 other skills with a one-line callout (`→ See AI Product Builder Principles in ai-product-builder-playbook`).

---

## Decisions already made — do not re-litigate these

| Decision | Choice | Rationale |
|---|---|---|
| `ai-evals-for-product-managers` type | **workflow** | 12-step process + plan artifact matches existing workflow skills like `discovery-process`. Supersedes the incomplete Phase 6 `ai-product-evals` placeholder. |
| Theme for all 9 new skills | **`ai-product-builder`** | Existing AI skills (`ai-shaped-readiness-advisor`, `context-engineering-advisor`) use `ai-agents`. New track is distinct enough to warrant its own Streamlit filter group and future pack config. |
| Shared principles location | **Embedded in `ai-product-builder-playbook`** | No `references/` dir. Embed 10 principles in orchestration skill's Key Concepts section. Brief inline callout in `ai-product-sense`, `vibe-coding-guardrails`, and `prototype-to-production-handoff`. |
| Phase 6 `ai-product-evals` | **Superseded by `ai-evals-for-product-managers`** | The new skill covers the same ground with better PM framing. Update CLAUDE.md Phase 6 status accordingly. |
| Implementation order | **8 primitives first, orchestration last** | Ensures `ai-product-builder-playbook` can reference already-written siblings accurately. |

---

## Release arc

Every skill should fit into this conceptual sequence:

```
Sense → Decide → Learn → Guardrail → Specify → Evaluate → Build → Red-team → Handoff
```

Map:
- **Sense**: `ai-product-sense`
- **Decide**: `ai-feature-or-not`
- **Learn**: `prototype-learning-plan`
- **Guardrail**: `vibe-coding-guardrails`
- **Specify**: `ai-agent-requirements`
- **Evaluate**: `ai-evals-for-product-managers`
- **Red-team**: `product-sense-red-team`
- **Handoff**: `prototype-to-production-handoff`
- **Orchestrates all**: `ai-product-builder-playbook`

---

## Voice and style constraints

Skills should sound like Product Manager Skills, not AI consultancy content.

**Use:**
- Sharp, practical product language
- Named failure modes
- Short memorable principles
- Anti-theater framing
- Concrete artifacts
- Coaching prompts
- Consequences of bad behavior
- Examples that make judgment visible

**Avoid:**
- Hype language
- "Transform your organization" language
- AI vendor boosterism
- Overclaiming
- Treating PMs as junior engineers
- Treating vibe coding as inherently good or inherently bad
- Enterprise case examples derived from customers

**Acceptable recurring phrases from the Substack archive (use sparingly — season, not dominate):**
- "Build faster without outsourcing judgment."
- "AI efficiency is rent. AI-augmented judgment is the moat."
- "A prototype is a learning instrument, not a baby product."
- "The prototype lied beautifully."
- "Your agents are running feral."
- "A lack of screaming is not confirmation of competence."
- "Context stuffing is not context engineering."
- "Stop solving the wrong problem."
- "AI doesn't speed you up. It speeds you off a cliff — faster, louder, and with better formatting."
- "Nothing triggers alarm when everything still compiles."

---

## Pedagogic mandate — do not skip this section

Every skill serves two audiences simultaneously:
1. The AI agent executing the work
2. The human PM learning the craft

ABC — Always Be Coaching. Explanation is load-bearing, not decorative. Anti-patterns are required, not filler. Examples show reasoning, not just output. Stripping learning scaffolding to tighten copy is a defect, not an improvement.

**Protected sections — never remove or abbreviate:**
- "Why This Works" explanations inside Application
- Anti-Patterns sections inside Key Concepts
- Consequence chains in Common Pitfalls ("X causes Y, which causes Z")
- Educational preambles in Purpose

---

## Phase 0 — Setup

Before writing any skill:

```bash
# 1. Create branch
git checkout -b v0.80-ai-product-builder-track

# 2. Confirm current state passes validation
./scripts/test-library.sh

# 3. Confirm skill count (expect 48)
ls skills/ | wc -l

# 4. Confirm agent-orchestration-advisor exists or not
ls skills/ | grep agent-orchestration

# 5. Confirm commands count (expect 6)
ls commands/*.md | grep -v README | wc -l
```

If `test-library.sh` fails before you touch anything, stop and investigate before proceeding.

---

## Phase 1 — Create 8 primitive skills

Create skills in this exact order. Each goes in `skills/<skill-name>/SKILL.md`.

---

### Skill 1: `ai-product-sense`

**Path:** `skills/ai-product-sense/SKILL.md`
**Type:** interactive
**Arc position:** Sense

**Purpose:** Help PMs evaluate an AI-shaped product idea, feature proposal, product-builder concept, or prototype opportunity before committing to build, discovery, roadmap, or stakeholder review. Diagnoses whether the idea reflects product sense or AI/tool enthusiasm.

**Core thesis:** Product sense is the ability to decide what deserves to exist before AI makes it cheap to build.

**Primary source posts:**
- `ai-first-is-cute-ai-shaped-is-survival-5-ai-pm-skills-2026.md`
- `why-starting-with-why-matters-for-ai.md`
- `how-might-we-ai.md`
- `day-03---stop-solving-the-wrong-problem.md`
- `the-vibe-code-deluge.md`
- `sam-altmans-missing-gpt-5-benchmark.md`

**Secondary source posts:**
- `day-02---the-ai-pm-skills-nobody-teaches.md`
- `organizing-on-ai.md`
- `even-the-worlds-best-ai-cant-fix-bad-product-management.md`

**Key concepts to cover:**
- Product sense before tool use
- AI-shaped, not AI-first
- Behavior change over feature excitement
- User value over AI novelty
- Evidence standards
- Assumption clarity
- The "remove AI from the sentence" test (restate value proposition without the word "AI")

**Workflow (Application section):**
1. Capture the idea in one sentence
2. Identify the user and situation
3. Clarify the user job, pain, or desired progress
4. Identify the behavior change the product must create
5. Identify why AI appears necessary
6. Remove the word "AI" and restate the value proposition
7. Identify the current workaround or alternative
8. Identify the riskiest assumption
9. Define what evidence would change the decision
10. Recommend: build, prototype, research, reframe, or reject

**Output artifact (Application section):**
```markdown
# AI Product Sense Assessment

## 1. Idea Summary
## 2. User and Situation
## 3. Real Problem / Job
## 4. Behavior Change Required
## 5. AI Necessity Check
## 6. Current Alternative / Workaround
## 7. Strongest Case For the Idea
## 8. Weakest Assumption
## 9. Evidence Needed
## 10. Product Sense Diagnosis
## 11. Recommended Next Move
- Build / Prototype / Research / Reframe / Reject
```

**Common pitfalls:**
- Starting with "we need an AI feature"
- Confusing stakeholder excitement with user demand
- Treating demo plausibility as market pull
- Solving a workflow problem with a chatbot
- Using AI to hide a weak value proposition
- Measuring novelty instead of behavior change

**Example scenario (show the coaching, not just the output):**
> User: "We want to add an AI assistant to our onboarding flow so users can ask questions."
>
> Skill should coach through: What onboarding behavior is failing? What questions are users actually asking? Would better IA, checklists, or progressive disclosure solve it? What evidence shows users would ask instead of abandon? What is the lowest-cost test?
>
> Diagnosis: "AI assistant" is currently a solution-shaped placeholder. The product-sense move is to isolate the onboarding decision or confusion that causes drop-off, then decide whether AI is needed to handle variability or whether deterministic guidance is enough.

**Interactive behavior:**
- Brief session heads-up (what the skill will do)
- Support "Best guess" mode (proceed with stated assumptions if context is partial)
- Support "Context dump" mode (if user pastes all context upfront, skip sequential questions)
- Ask only 3-5 questions before offering recommendations
- End with the output artifact

**Cross-references for References section:**
- `skills/ai-feature-or-not/SKILL.md` — decide if AI belongs
- `skills/pol-probe/SKILL.md` — define cheapest test (existing skill)
- `skills/product-sense-red-team/SKILL.md` — stress-test the idea
- Note: `→ See AI Product Builder Principles in skills/ai-product-builder-playbook/SKILL.md`

**Description (≤200 chars):**
```
Use when evaluating an AI product idea, feature proposal, or prototype opportunity before committing to build or discovery. Separates AI novelty from user value and recommends a next move.
```

---

### Skill 2: `ai-feature-or-not`

**Path:** `skills/ai-feature-or-not/SKILL.md`
**Type:** interactive
**Arc position:** Decide

**Purpose:** Help PMs decide whether a proposed product solution should use AI, use AI only assistively, use deterministic automation, fix product/design first, or not be built yet.

**Core thesis:** Most teams do not need "AI-first." They need to decide whether AI belongs in the product at all.

**Primary source posts:**
- `day-08---accidental-ai-vs-ai-first.md`
- `agentic-tool-tourism-is-not-a-strategy.md`
- `why-starting-with-why-matters-for-ai.md`
- `top-10-ai-pm-mistakes-of-2025.md`
- `ms-copilot-proves-you-can-ship-ai-perfectly--still-lose.md`
- `sauerkraut-is-not-a-strategy.md`

**Secondary source posts:**
- `how-might-we-ai.md`
- `day-07---youre-playing-the-wrong-ai-game.md`
- `organizing-on-ai.md`

**Key concepts to cover:**
- AI-shaped vs AI-bolted-on
- Accidental AI (AI added without a reason)
- Tool tourism (team adopts AI tools without strategic intent)
- Deterministic vs probabilistic solution fit
- Trust cost (how much users must trust AI for the feature to work)
- Review burden (who reviews AI output, at what cost)
- Data/context readiness

**Decision model (present as a table in Key Concepts):**

| Decision | When to use |
|---|---|
| Use AI | Problem requires synthesis, generation, NL interaction, prediction, pattern detection, or adaptive assistance. Input ambiguity is high and output variability is acceptable. |
| Use AI assistively | AI helps the team or internal workflow, but should not become the core product experience yet. |
| Use deterministic automation | Rules, workflow, integrations, or templates solve the problem more safely and cheaply. |
| Fix product/design first | The issue is clarity, UX, positioning, trust, workflow, incentives, or information architecture. |
| Do not build yet | Problem, evidence, ownership, data, or risk profile is too weak. |

**Workflow (Application section):**
1. Restate the proposed feature
2. Identify the problem it claims to solve
3. Identify why AI is being proposed (whose idea, what was the trigger)
4. Evaluate input ambiguity (does input vary enough to require probabilistic handling?)
5. Evaluate output variability tolerance (can users accept non-deterministic output?)
6. Evaluate user trust and failure cost
7. Evaluate ground truth availability
8. Evaluate data/context readiness
9. Compare AI vs deterministic alternatives
10. Make the decision from the five-option model
11. Define next step and evidence needed

**Output artifact:**
```markdown
# AI Feature Decision

## Proposed Feature
## Problem It Claims to Solve
## AI Necessity Signals
## AI Risk Signals
## Simpler Alternatives
## Decision
## Rationale
## Evidence Needed Before Build
## Recommended Next Step
```

**Common pitfalls:**
- Using AI to solve a positioning problem
- Automating a broken workflow
- Exposing AI to users before proving internal value
- Choosing nondeterminism where users need reliability
- Treating "competitors have AI" as a user need
- Creating review burden and calling it productivity

**Cross-references for References section:**
- `skills/ai-product-sense/SKILL.md` — product sense first
- `skills/ai-agent-requirements/SKILL.md` — if decision is "Use AI" for an agentic feature
- `skills/vibe-coding-guardrails/SKILL.md` — if decision is to build a prototype

**Description (≤200 chars):**
```
Use when deciding whether a proposed feature should use AI, deterministic automation, or a design fix. Prevents accidental AI and AI-bolted-on solutions through a five-option decision model.
```

---

### Skill 3: `prototype-learning-plan`

**Path:** `skills/prototype-learning-plan/SKILL.md`
**Type:** component
**Arc position:** Learn

**Purpose:** Turn a product or AI feature idea into a disciplined learning plan before any prototype is built. Defines the question the prototype must answer, the right fidelity, the evidence that counts, and the kill/change/continue criteria.

**Core thesis:** A prototype is not a baby product. It is a learning instrument. It exists to answer a decision-critical question.

**Primary source posts:**
- `vibe-first-validate-fast-verify-fit.md`
- `vibe-to-learn-not-to-earn.md`
- `if-you-give-a-manager-an-mvp.md`
- `timeboxes-are-not-evil.md`

**Secondary source posts:**
- `the-unspoken-state-of-pm-as-of-mid-2025.md`

**Key concepts to cover:**
- Proof-of-Life Probe (PoL Probe) — reference existing `pol-probe` skill
- Tiny bets over Titanic assumptions
- Learning before earning
- Prototype fidelity selection (matching fidelity to the risk being tested)
- Decision-driven validation (prototype answers a question, not validates a design)
- Kill/change/continue criteria (defined before, not after)
- What the prototype proves vs cannot prove (the honest list)

**Prototype fidelity options (include as a Key Concepts table):**

| Type | Best when testing |
|---|---|
| Storyboard | Whether the narrative is compelling |
| Landing page | Whether there is interest before building |
| Concierge test | Whether the workflow creates value manually |
| Wizard-of-Oz test | Whether users would use AI output if it were good |
| Clickable mockup | Whether the UX direction is right |
| Synthetic-data simulation | Whether the output quality is usable |
| Throwaway coded prototype | Whether technical feasibility is real |
| Proof-of-Life Probe | Whether a riskiest assumption has any signal of life |

**Workflow (Application section — this is a component skill so focus on the template and quality criteria):**
1. Identify the decision the prototype should inform
2. Identify the riskiest assumption
3. State the learning question (one question, not a list)
4. Choose the lightest prototype that can test that assumption
5. Explain why this fidelity is enough
6. Define the target reviewer/user
7. Define the test scenario
8. Define what evidence counts
9. Define what evidence does NOT count
10. Define kill/change/continue thresholds
11. Define timebox
12. Define capture/debrief plan

**Output artifact:**
```markdown
# Prototype Learning Plan

## 1. Decision to Inform
## 2. Riskiest Assumption
## 3. Learning Question
## 4. Prototype Type
## 5. Why This Fidelity Is Enough
## 6. Target Participant / Reviewer
## 7. Test Scenario
## 8. Evidence to Capture
## 9. What This Will Not Prove
## 10. Kill / Change / Continue Criteria
## 11. Timebox
## 12. Debrief Questions
```

**Common pitfalls:**
- Building the fanciest prototype instead of the smallest useful one
- Treating "users liked it" as validation (qualitative enthusiasm is not evidence)
- Calling a prototype an MVP
- Letting stakeholder demo value override customer learning
- Testing usability when the real risk is desirability
- Testing feasibility when the real risk is willingness to change behavior
- Skipping the "what this will not prove" section (false confidence)

**Cross-references for References section:**
- `skills/pol-probe/SKILL.md` — Proof-of-Life Probe template
- `skills/vibe-coding-guardrails/SKILL.md` — before building a coded prototype
- `skills/prototype-to-production-handoff/SKILL.md` — after the prototype

**Description (≤200 chars):**
```
Use before building any prototype to define the learning question, right fidelity, evidence standard, and kill/change/continue criteria. Prevents prototypes that teach nothing.
```

---

### Skill 4: `vibe-coding-guardrails`

**Path:** `skills/vibe-coding-guardrails/SKILL.md`
**Type:** interactive
**Arc position:** Guardrail

**Purpose:** Help PMs use AI coding/product-building tools safely and responsibly without creating shadow systems, brittle prototypes, hidden technical debt, or engineering-trust damage.

**Core thesis:** AI-assisted building without judgment produces plausible systems that compile, demo well, and quietly become expensive. Nothing triggers alarm when everything still compiles.

**Primary source posts:**
- `the-vibe-code-deluge.md`
- `the-coming-vibe-app-collapse.md`
- `wth-is-a-product-builder.md`
- `vibe-first-validate-fast-verify-fit.md`
- `weekend-at-lennys---part-1.md`

**Secondary source posts:**
- `vibe-to-learn-not-to-earn.md`

**Key concepts to cover:**
- Build classification (what kind of thing are you building?)
- Data boundaries (what data does it touch?)
- Authority boundaries (can it read/write/trigger/escalate?)
- Review boundaries (who reviews before use?)
- Lifespan boundaries (when does it get retired?)
- Ownership boundaries (who maintains it?)
- Engineering trust (the asset that gets damaged when PMs ship production code without disclosure)
- Disposable vs durable artifacts

**Build classification table (Key Concepts):**

| Classification | Meaning | Default guardrail |
|---|---|---|
| Learning artifact | Built to understand possibility or behavior | Disposable unless explicitly promoted |
| Demo artifact | Built to communicate a concept | Must not be treated as validated product |
| Internal workflow tool | Used by team members | Needs ownership, support, data review, cleanup path |
| Production candidate | May become real product/system | Requires engineering, security, design, and product review |
| Unsafe / blocked | Touches sensitive systems without ownership/review | Do not proceed |

**Workflow (Application section):**
1. Ask what is being built
2. Classify the artifact (from the table above)
3. Identify data touched (real customer data? internal data? synthetic only?)
4. Identify systems touched (integrations, APIs, databases)
5. Identify user/customer exposure (who sees or uses this?)
6. Identify whether it can read/write/trigger actions
7. Define owner and lifespan
8. Define required review before sharing
9. Define what must not happen
10. Produce guardrail checklist and next action

**Output artifact:**
```markdown
# Vibe-Coding Guardrail Assessment

## Artifact Classification
## Intended Use
## Not Intended For
## Data Boundaries
## System Boundaries
## Authority Boundaries
## Review Required
## Lifespan / Disposal Plan
## Owner
## Engineering Trust Risks
## Allowed Next Step
## Blockers
```

**Common pitfalls:**
- "It works on my laptop, so it is ready."
- Shipping prototype code because stakeholders liked the demo
- Creating a shadow system and calling it empowerment
- Forgetting cleanup and ownership
- Hiding AI-generated shortcuts from engineering
- Touching real customer data in a learning artifact
- Confusing technical plausibility with product validation

**Interactive behavior:**
- Start with a brief session heads-up
- Support "Best guess" mode and "Context dump" mode
- Ask only what is needed to classify and assess the build
- Be direct about blockers — do not soften

**Cross-references for References section:**
- `skills/prototype-learning-plan/SKILL.md` — define what you're building before building it
- `skills/prototype-to-production-handoff/SKILL.md` — after the build
- Note: `→ See AI Product Builder Principles in skills/ai-product-builder-playbook/SKILL.md`

**Description (≤200 chars):**
```
Use when about to build or share a PM-built AI tool, prototype, or workflow. Classifies the artifact, defines data and authority boundaries, and identifies what review is required before sharing.
```

---

### Skill 5: `ai-agent-requirements`

**Path:** `skills/ai-agent-requirements/SKILL.md`
**Type:** component
**Arc position:** Specify

**Purpose:** Help PMs define agentic product behavior before implementation by specifying delegation boundaries, tool/data access, human checkpoints, observability, evaluation needs, and failure handling.

**Core thesis:** An agent is not a smarter feature. It is delegated authority. If an agent can read, write, decide, trigger, or escalate, the PM must define its authority boundary before a single line of code is written.

**Primary source posts:**
- `day-10---your-agents-are-running-feral.md`
- `day-11---build-agents-that-dont-go-rogue.md`
- `agentic-orange-is-it-worth-the-squeeze.md`
- `agentic-tool-tourism-is-not-a-strategy.md`
- `2026--an-ai-accountability-odyssey.md`

**Secondary source posts:**
- `day-12---de-risk-your-ai-before-the-board-does.md`

**Key concepts to cover:**
- Delegated authority (agents have permission scope, not just capability)
- Agent job statement (what job is the agent doing, for whom)
- Trigger conditions (when does the agent act?)
- Read/write/decide/trigger/escalate permission taxonomy
- Human-in-the-loop checkpoints (when does a human review before the agent continues?)
- Tool access (what can the agent call?)
- Memory and context requirements
- Observability requirements (what must be logged/traced?)
- Failure taxonomy (what goes wrong and how does each failure mode manifest?)
- Escalation and rollback
- Cost boundaries (what spending or action volume triggers a stop?)
- "A lack of screaming is not confirmation of competence" — the silent failure risk

**Workflow (Application section):**
1. Define what job the agent performs
2. Define who it serves (user/actor)
3. Define when it acts (trigger conditions)
4. Define what it may read
5. Define what it may write
6. Define what it may decide without human approval
7. Define what it may trigger in other systems
8. Define what it must never do (forbidden actions)
9. Define when a human must review before the agent continues
10. Define escalation paths if a human does not respond
11. Define what must be logged (observability requirements)
12. Define failure modes and rollback conditions

**Output artifact (name it "Agent Delegation Contract"):**
```markdown
# Agent Delegation Contract

## 1. Agent Name / Working Label
## 2. User / Actor Served
## 3. Job to Be Delegated
## 4. Trigger Conditions
## 5. Allowed Actions
## 6. Forbidden Actions
## 7. Tool Access
## 8. Data Access
## 9. Context / Memory Requirements
## 10. Human Checkpoints
## 11. Escalation Paths
## 12. Observability Requirements
## 13. Evaluation Requirements
## 14. Failure Modes
## 15. Cost / Latency Boundaries
## 16. Rollback / Shutdown Conditions
## 17. Open Questions
```

**Common pitfalls:**
- Calling a chatbot an agent (chatbots respond; agents act)
- Giving tools to an agent before defining its authority
- Forgetting escalation paths
- Assuming silence means the agent is working correctly
- Treating observability as an engineering-only concern
- Letting agents accumulate scope without ownership
- Measuring task completion while ignoring failure cost

**Cross-references for References section:**
- `skills/ai-feature-or-not/SKILL.md` — confirm AI/agent is the right choice first
- `skills/ai-evals-for-product-managers/SKILL.md` — define quality criteria after requirements
- `skills/context-engineering-advisor/SKILL.md` (existing skill) — context and memory design
- Check if `skills/agent-orchestration-advisor/SKILL.md` exists before referencing it

**Description (≤200 chars):**
```
Use when specifying an AI agent before implementation. Defines delegation boundaries, tool access, human checkpoints, observability, and failure handling via an Agent Delegation Contract.
```

---

### Skill 6: `ai-evals-for-product-managers`

**Path:** `skills/ai-evals-for-product-managers/SKILL.md`
**Type:** workflow
**Arc position:** Evaluate

**Purpose:** Help PMs define product-quality evals for AI features, agents, copilots, or AI-assisted workflows without pretending PMs need to become ML engineers. Produces an AI Product Eval Plan that maps model behavior to user-visible quality, failure cost, business value, and operating constraints.

**Core thesis:** Evals without product context become expensive dashboards for impending disasters. Benchmarks are not product readiness. Model performance only matters when mapped to user-visible quality, failure cost, business value, and operating constraints.

**Primary source posts:**
- `eddie-the-eval-and-the-fools-gold-framework.md`
- `sam-altmans-missing-gpt-5-benchmark.md`
- `context-stuffing--context-engineering.md`
- `day-09---more-data-wont-save-you.md`
- `even-the-worlds-best-ai-cant-fix-bad-product-management.md`
- `day-12---de-risk-your-ai-before-the-board-does.md`

**Secondary source posts:**
- `day-05---context-engineering-is-a-team-sport.md`
- `day-06---the-customer-signals-ai-gets-wrong.md`

**Key concepts to cover:**
- User-visible quality (what the user actually experiences) vs model benchmark
- Product readiness criteria (what does "good enough to launch" mean for this product?)
- Failure taxonomy (classify failures by type, frequency, and cost)
- Golden examples (curated input/output pairs that define acceptable quality)
- Human review rubric (how do reviewers score outputs consistently?)
- Ground truth (where does correct output come from, and how do you know?)
- Context quality vs context volume (more data does not mean better signal)
- Drift (how do you detect when quality degrades after launch?)
- "Not ready" criteria (explicit definition of what blocks launch)

**Workflow (Application section — this is a workflow skill, so make it orchestrate the thinking):**
1. Define the AI behavior being evaluated (what is the agent/feature doing?)
2. Define user-visible quality dimensions (from the user's perspective, what does "good" look like?)
3. Define unacceptable failures (what would cause a user to lose trust or the team to pull the feature?)
4. Define expected inputs and contexts (what situations will this face?)
5. Define output standards (what is an acceptable output? what is a great one?)
6. Create failure taxonomy (organize failure types by severity and frequency)
7. Create golden example plan (how will you collect and curate examples?)
8. Define human review rubric (how will reviewers score consistently?)
9. Define telemetry/monitoring plan
10. Define launch thresholds (what must be true before launch?)
11. Define "not ready" criteria explicitly
12. Define review cadence and ownership

**Output artifact:**
```markdown
# AI Product Eval Plan

## 1. AI Behavior Under Evaluation
## 2. User-Visible Quality Dimensions
## 3. Product Readiness Criteria
## 4. Unacceptable Failures
## 5. Input / Context Requirements
## 6. Output Standards
## 7. Failure Taxonomy
## 8. Golden Examples Plan
## 9. Human Review Rubric
## 10. Telemetry / Monitoring
## 11. Launch Thresholds
## 12. "Not Ready" Criteria
## 13. Drift / Regression Checks
## 14. Review Cadence
## 15. Owner / Decision Rights
```

**Common pitfalls:**
- Treating benchmark performance as product readiness
- Measuring only hallucination (ignores latency, tone, context, relevance)
- Ignoring the cost of false confidence (AI that is wrong confidently is worse than AI that flags uncertainty)
- Failing to define "not ready" before launch (it gets defined by incidents instead)
- Collecting more data without improving signal quality
- Using evals as theater after launch instead of decision support before launch

**Cross-references for References section:**
- `skills/ai-agent-requirements/SKILL.md` — evaluation requirements belong in the agent contract
- `skills/context-engineering-advisor/SKILL.md` (existing) — context quality affects eval design
- `skills/prototype-to-production-handoff/SKILL.md` — eval plan informs handoff requirements

**Description (≤200 chars):**
```
Use when defining quality criteria for an AI feature, agent, or copilot. Produces an eval plan that maps AI behavior to user-visible quality, failure taxonomy, launch thresholds, and "not ready" criteria.
```

---

### Skill 7: `product-sense-red-team`

**Path:** `skills/product-sense-red-team/SKILL.md`
**Type:** interactive
**Arc position:** Red-team

**Purpose:** Stress-test a product idea, AI feature, prototype, or roadmap bet before it becomes politically expensive. Apply structured red-team lenses to find fatal assumptions, hidden costs, and weak evidence before the prototype builds momentum.

**Core thesis:** The cheapest time to find bad product logic is before the prototype becomes politically expensive.

**Primary source posts:**
- `feature-hostage-negotiations-just-a-small-fix.md`
- `why-your-ai-generated-user-stories-suck-and-what-to-do-about-it.md`
- `day-12---de-risk-your-ai-before-the-board-does.md`
- `day-07---youre-playing-the-wrong-ai-game.md`
- `day-03---stop-solving-the-wrong-problem.md`

**Secondary source posts:**
- `stakeholder-shuttle-diplomacy.md`
- `you-burn-50k-a-sprint--act-like-it.md`

**Key concepts to cover:**
- Red-team lenses (structured attack angles, not random skepticism)
- Fatal assumption candidates (the one assumption whose failure kills the whole idea)
- The difference between cynicism and red-teaming (cynicism kills without building; red-teaming kills AND builds something better)
- Alternative gravity (what behavior will users default to instead?)
- Incentive mapping (who benefits if this gets built? who pays the tax?)
- Hidden cost ("just a small fix" framing that disguises scope)

**Red-team lenses (Key Concepts table):**

| Lens | Question |
|---|---|
| Problem truth | Is the problem real, repeated, and costly to enough users? |
| User behavior | What behavior must actually change for this to succeed? |
| Evidence | What have we observed vs what are we assuming? |
| Alternative gravity | What will users keep doing instead? |
| AI necessity | Does AI create value or just theater? |
| Trust | What must users believe before relying on it? |
| Failure cost | What happens when the system is wrong? |
| Incentives | Who benefits if this gets built? Who pays the hidden tax? |
| Strategy | Why should this company do this now? |
| Hidden cost | What cost is being disguised as "just a small fix"? |

**Workflow (Application section):**
1. Capture the idea (one sentence — if the PM can't state it in one sentence, that is the first problem)
2. State the strongest case for it (steelman before attacking)
3. State the strongest case against it
4. Apply the red-team lenses systematically
5. Identify fatal assumption candidates
6. Identify what evidence is missing vs what was assumed
7. Recommend: build/prototype/research/reframe/kill
8. Provide a cleaner version of the idea if it survives red-teaming

**Output artifact:**
```markdown
# Product Sense Red-Team Review

## 1. Idea Under Review
## 2. Strongest Case For
## 3. Strongest Case Against
## 4. Red-Team Findings (by lens)
## 5. Hidden Costs / Externalities
## 6. Fatal Assumption Candidates
## 7. Evidence Needed
## 8. Reframe Options
## 9. Recommendation
- Build / Prototype / Research / Reframe / Kill
## 10. Cleaner Next-Step Brief
```

**Common pitfalls:**
- Softening critique until it becomes useless
- Confusing cynicism with red-teaming
- Treating stakeholder pressure as strategy
- Ignoring opportunity cost
- Focusing only on technical feasibility
- Failing to produce a better path after critique (red-teaming without a reframe is just veto)

**Interactive behavior:**
- Can be invoked standalone or as part of `sharpen-product-sense` command
- Start with idea capture before applying lenses
- Be honest — do not soften the findings to manage feelings
- Always end with a reframe or next-step recommendation, not just a verdict

**Cross-references for References section:**
- `skills/ai-product-sense/SKILL.md` — product sense assessment before red-teaming
- `skills/ai-feature-or-not/SKILL.md` — AI necessity check

**Description (≤200 chars):**
```
Use to stress-test a product idea, AI feature, or prototype before it gains political momentum. Applies red-team lenses to surface fatal assumptions, hidden costs, and missing evidence.
```

---

### Skill 8: `prototype-to-production-handoff`

**Path:** `skills/prototype-to-production-handoff/SKILL.md`
**Type:** workflow
**Arc position:** Handoff

**Purpose:** Convert a PM-built or AI-assisted prototype into an engineering-ready handoff that clearly separates learning, assumptions, shortcuts, validation, risks, and recommended next action.

**Core thesis:** A PM-built prototype earns the next conversation. It does not earn production status. Handoff requires humility: what was learned, what was not validated, what shortcuts were taken, and what engineering must inspect.

**Primary source posts:**
- `vibe-first-validate-fast-verify-fit.md`
- `the-coming-vibe-app-collapse.md`
- `the-vibe-code-deluge.md`
- `day-11---build-agents-that-dont-go-rogue.md`
- `eddie-the-eval-and-the-fools-gold-framework.md`

**Secondary source posts:**
- `vibe-to-learn-not-to-earn.md`
- `weekend-at-lennys---part-1.md`

**Key concepts to cover:**
- Prototype humility (the prototype proved something, not everything)
- Product validation vs technical validation (user enthusiasm ≠ engineering soundness)
- The "what was not proven" list (explicitly required — this is where most handoffs fail)
- AI-generated code risk (specific risks: duplication, hallucinated dependencies, security gaps, maintenance debt, no tests)
- Rebuild/refactor/discard/continue decision (explicit recommendation required)
- Engineering trust (handoff that hides shortcuts damages the relationship)

**Workflow (Application section):**
1. Identify prototype purpose (what was it built to learn?)
2. Summarize what was built (honest description of what exists)
3. State what was learned (actual evidence gathered)
4. State what was not validated (explicit list — do not skip this)
5. List assumptions that remain untested
6. List shortcuts taken during prototype build
7. Identify AI-generated or unknown code risks
8. Identify data/security/privacy/compliance concerns
9. Identify technical unknowns
10. Identify user evidence (what did users actually say/do?)
11. Recommend: rebuild/refactor/discard/continue learning/productize after review
12. Write the engineering handoff brief

**Output artifact:**
```markdown
# Prototype-to-Production Handoff

## 1. Prototype Summary
## 2. Original Learning Goal
## 3. What the Prototype Proved
## 4. What the Prototype Did Not Prove
## 5. User / Stakeholder Evidence
## 6. Assumptions Still Untested
## 7. Shortcuts Taken
## 8. AI-Generated or Unknown Code Risks
## 9. Data / Security / Privacy / Compliance Notes
## 10. Technical Unknowns
## 11. Product Questions Remaining
## 12. Engineering Review Needed
## 13. Recommended Path
- Rebuild / Refactor / Discard / Continue learning / Productize after review
## 14. Handoff Brief
```

**Common pitfalls:**
- "Just clean this up." (handing engineering a vibe-coded artifact without context)
- Shipping prototype code because it demos well
- Forgetting to document what the prototype did not prove
- Hiding generated-code uncertainty from engineering
- Confusing validation evidence with implementation readiness
- Omitting the "what was not proven" section under time pressure

**Cross-references for References section:**
- `skills/prototype-learning-plan/SKILL.md` — the learning plan that preceded this
- `skills/vibe-coding-guardrails/SKILL.md` — guardrails assessed during the build
- `skills/ai-evals-for-product-managers/SKILL.md` — eval plan informs what engineering must build
- Note: `→ See AI Product Builder Principles in skills/ai-product-builder-playbook/SKILL.md`

**Description (≤200 chars):**
```
Use after a PM-built or AI-assisted prototype to create an engineering handoff that separates learning from assumptions, names shortcuts taken, and recommends rebuild, refactor, or discard.
```

---

## Phase 2 — Create orchestration skill

### Skill 9: `ai-product-builder-playbook`

**Path:** `skills/ai-product-builder-playbook/SKILL.md`
**Type:** workflow
**Arc position:** Orchestrates all

**Purpose:** Guide PMs from AI-shaped product idea to disciplined prototype path, guardrails, eval thinking, and handoff plan. The full release arc in one skill: Sense → Decide → Learn → Guardrail → Specify → Evaluate → Red-team → Handoff.

**Core thesis:** The AI-era PM builder is not defined by coding ability. They are defined by the ability to turn judgment into evidence quickly.

**Primary source posts:**
- `wth-is-a-product-builder.md`
- `ai-first-is-cute-ai-shaped-is-survival-5-ai-pm-skills-2026.md`
- `vibe-first-validate-fast-verify-fit.md`
- `the-vibe-code-deluge.md`
- `no-ai-wont-replace-your-job.md`

**Secondary source posts:**
- `vibe-to-learn-not-to-earn.md`
- `weekend-at-lennys---part-1.md`
- `the-coming-vibe-app-collapse.md`

**IMPORTANT — Key Concepts section must include the AI Product Builder Principles:**

Include a section titled "AI Product Builder Principles" with all 10 principles from the execution brief. This is the canonical home of these principles in the repo. Other skills reference this section.

```markdown
## AI Product Builder Principles

These 10 principles unify the AI Product Builder Track. Use them to keep product-builder work grounded in judgment, evidence, safety, and learning.

1. **AI efficiency is rent. AI-augmented judgment is the moat.**
   AI can make product work faster, but speed without judgment just ships bad assumptions with better formatting.

2. **Product sense comes before tool use.**
   Start with the user, the job, the behavior change, the business reason, and the evidence standard before selecting AI tools.

3. **A prototype is a learning instrument, not a baby product.**
   A prototype exists to answer a decision-critical question. It does not earn production status because it demos well.

4. **AI is not always the right answer.**
   Sometimes the right solution is deterministic automation, workflow redesign, better information architecture, clearer positioning, or no build at all.

5. **Agents are delegated authority, not smarter features.**
   If an agent can read, write, decide, trigger, or escalate, requirements must define its authority boundary.

6. **Benchmarks are not product readiness.**
   Model performance only matters when mapped to user-visible quality, failure cost, business value, and operating constraints.

7. **Context quality beats context volume.**
   Stuffing more context into an AI system is not the same as designing the right context, memory, retrieval, constraints, and review loops.

8. **If everything still compiles, the risk may be harder to see.**
   AI-generated systems can look functional while hiding fragility, duplication, security gaps, and maintenance debt.

9. **A PM-built prototype earns the next conversation, not production status.**
   Handoff requires humility: what was learned, what was not validated, what shortcuts were taken, and what engineering must inspect.

10. **Build faster without outsourcing judgment.**
    The goal is not to make PMs reckless builders. The goal is to help PMs turn judgment into evidence faster.
```

**Workflow (Application section — orchestrates child skills, do not duplicate their content):**
1. **Sense** — Run `ai-product-sense` to evaluate the idea before committing
2. **Decide** — Run `ai-feature-or-not` to confirm AI belongs
3. **Learn** — Use `prototype-learning-plan` to define what needs to be tested
4. **Guardrail** — Use `vibe-coding-guardrails` to classify the build and set boundaries
5. **Specify** — Use `ai-agent-requirements` if the feature is agentic
6. **Evaluate** — Use `ai-evals-for-product-managers` to define quality criteria before building
7. **Red-team** — Invoke `product-sense-red-team` to stress-test before investing further
8. **Build brief** — Generate a builder brief for the prototype tool or engineering partner
9. **Handoff** — Use `prototype-to-production-handoff` to close the loop

**Builder Brief format (include in Application section):**
```markdown
# Builder Brief

## Goal
## User / Situation
## Problem to Demonstrate
## What to Build
## What Not to Build
## Required Inputs
## Required Outputs
## Constraints
## Data Rules
## UX Notes
## Evaluation Criteria
## Timebox
## Disposal / Handoff Plan
```

**Output artifact:**
```markdown
# AI Product Builder Playbook

## 1. Product Sense Summary
## 2. AI Feature Decision
## 3. Prototype Learning Plan
## 4. Guardrails
## 5. Builder Brief
## 6. Eval / Quality Plan
## 7. Red-Team Findings
## 8. Handoff Path
## 9. Recommended Next Move
```

**Common pitfalls:**
- Building before product sense
- Treating code output as learning
- Skipping the AI necessity decision
- Generating a fancy demo with no evidence plan
- Letting the prototype become the roadmap
- Failing to define what happens after the build

**Cross-references for References section (list all child skills):**
- `skills/ai-product-sense/SKILL.md`
- `skills/ai-feature-or-not/SKILL.md`
- `skills/prototype-learning-plan/SKILL.md`
- `skills/vibe-coding-guardrails/SKILL.md`
- `skills/ai-agent-requirements/SKILL.md`
- `skills/ai-evals-for-product-managers/SKILL.md`
- `skills/product-sense-red-team/SKILL.md`
- `skills/prototype-to-production-handoff/SKILL.md`

**Description (≤200 chars):**
```
Use to guide a full AI product build cycle from idea through prototype to handoff. Orchestrates product sense, AI decision, learning plan, guardrails, evals, red-team, and handoff skills.
```

---

## Phase 3 — Create 3 commands

Each command goes in `commands/<name>.md`. Follow the exact schema confirmed from live commands.

---

### Command 1: `sharpen-product-sense`

**Path:** `commands/sharpen-product-sense.md`

**Frontmatter:**
```yaml
---
name: sharpen-product-sense
description: Stress-test whether an AI or product idea deserves more investment before build momentum takes over.
argument-hint: "<product idea, AI feature proposal, or opportunity hypothesis>"
uses:
  - ai-product-sense
  - ai-feature-or-not
  - product-sense-red-team
  - prototype-learning-plan
outputs:
  - Product judgment assessment
  - AI necessity decision
  - Red-team findings
  - Evidence plan
  - Recommended next action
---
```

**Body sections:** Invocation, Workflow, Checkpoints, Next Steps

**Invocation example:**
```text
/sharpen-product-sense Add an AI assistant to our onboarding flow so users can ask questions
```

**Workflow:**
1. Evaluate the idea through `ai-product-sense` — separate AI novelty from user value
2. Confirm AI belongs with `ai-feature-or-not` — choose build/assistive/deterministic/fix-first/don't-build
3. Stress-test with `product-sense-red-team` — apply structured attack lenses
4. Define the learning path with `prototype-learning-plan` if the idea survives

**Checkpoints:**
- Confirm user, job, and behavior change before proceeding past Sense
- Confirm AI necessity decision is explicit before proceeding past Decide
- Confirm at least one fatal assumption is named before proceeding past Red-team

**Next Steps:**
- Run `/build-with-judgment` if the idea survived and you're ready to prototype
- Run `/define-agentic-product` if the idea involves an agent

---

### Command 2: `build-with-judgment`

**Path:** `commands/build-with-judgment.md`

**Frontmatter:**
```yaml
---
name: build-with-judgment
description: Move from product idea to AI-assisted prototype without confusing velocity with evidence.
argument-hint: "<product idea or validated opportunity>"
uses:
  - ai-product-sense
  - ai-feature-or-not
  - prototype-learning-plan
  - vibe-coding-guardrails
  - ai-product-builder-playbook
  - prototype-to-production-handoff
outputs:
  - Product sense summary
  - AI decision
  - Prototype learning plan
  - Guardrail assessment
  - Builder brief
  - Handoff path
---
```

**Invocation example:**
```text
/build-with-judgment AI customer-discovery synthesis tool that turns interview notes into opportunity maps
```

**Workflow:**
1. Evaluate through `ai-product-sense` — confirm user, job, behavior change
2. Confirm AI necessity with `ai-feature-or-not`
3. Define the learning experiment with `prototype-learning-plan`
4. Classify the build and set boundaries with `vibe-coding-guardrails`
5. Run the full builder flow with `ai-product-builder-playbook`, including Builder Brief
6. Define the handoff path with `prototype-to-production-handoff`

**Checkpoints:**
- Do not proceed to prototype-learning-plan without confirmed AI decision
- Do not proceed to vibe-coding-guardrails without a learning question defined
- Do not complete without a handoff path — even disposable artifacts need a disposal plan

**Next Steps:**
- Optionally invoke `product-sense-red-team` before building if the idea feels uncertain
- Use `ai-evals-for-product-managers` to define quality criteria before engineering takes the prototype

---

### Command 3: `define-agentic-product`

**Path:** `commands/define-agentic-product.md`

**Frontmatter:**
```yaml
---
name: define-agentic-product
description: Define agent behavior, boundaries, quality standards, and handoff requirements before implementation.
argument-hint: "<agent concept or agentic feature description>"
uses:
  - ai-feature-or-not
  - ai-agent-requirements
  - ai-evals-for-product-managers
  - prototype-to-production-handoff
outputs:
  - AI/agent necessity decision
  - Agent Delegation Contract
  - Eval plan
  - Failure modes
  - Human checkpoints
  - Observability requirements
  - Handoff requirements
---
```

**Invocation example:**
```text
/define-agentic-product Agent that monitors incoming support tickets and drafts suggested responses
```

**Workflow:**
1. Confirm agent is necessary with `ai-feature-or-not` — could this be a deterministic automation instead?
2. Define delegation boundaries, tools, data, checkpoints, and failure modes with `ai-agent-requirements`
3. Define quality criteria and "not ready" conditions with `ai-evals-for-product-managers`
4. Define handoff requirements with `prototype-to-production-handoff`

**Checkpoints:**
- Confirm the agent is not a chatbot or deterministic automation in disguise before proceeding
- Confirm forbidden actions are explicitly listed in the Agent Delegation Contract
- Confirm human checkpoints are named — no agent should run without at least one review gate

**Next Steps:**
- Use `context-engineering-advisor` to design the agent's context and memory architecture
- Use `product-sense-red-team` to stress-test the agent concept before engineering commits

---

## Phase 4 — Validate

Run these in order after all skills and commands are written:

```bash
# 1. Check metadata on all skills
python3 scripts/check-skill-metadata.py

# 2. Check trigger readiness
python3 scripts/check-skill-triggers.py --show-cases

# 3. Check command metadata
python3 scripts/check-command-metadata.py

# 4. Run full library test
./scripts/test-library.sh

# 5. Regenerate catalog (DO THIS LAST — after all validation passes)
python3 scripts/generate-catalog.py
```

Do not hand-edit any files in `catalog/` — always regenerate.

If any validation fails, fix the skill before regenerating the catalog.

---

## Phase 5 — Pack configuration check

Inspect `scripts/build-claude-desktop-packs.sh` to understand how packs are defined. If packs are configured as named lists of skills, add an `ai-product-builder` pack containing:

```
ai-product-sense
ai-feature-or-not
prototype-learning-plan
vibe-coding-guardrails
ai-agent-requirements
ai-evals-for-product-managers
product-sense-red-team
prototype-to-production-handoff
ai-product-builder-playbook
```

Do not guess the pack config format — inspect the script first. If pack definitions don't exist in the script, skip this step.

Also check `scripts/build-codex-skills.sh` for similar pack configuration patterns.

---

## Phase 6 — Documentation updates

### Release note

**Path:** `docs/announcements/2026-05-15-v0-80-ai-product-builder-track.md`

Use this structure (expand into full prose):

```markdown
# v0.80 — AI Product Builder Track

## Build faster without outsourcing judgment.

AI has made it easier for product managers to create prototypes, workflows, demos, and agentic product concepts. That does not mean every PM should build more things faster. It means product judgment matters more because bad assumptions now become plausible artifacts almost instantly.

v0.80 adds a coherent AI Product Builder Track for PMs who need to evaluate AI ideas, decide whether AI belongs, prototype to learn, define agent boundaries, evaluate AI quality, and hand off evidence without pretending a demo is a product.

## What shipped

**9 new skills:**
- `ai-product-sense` (Interactive) — Evaluate AI ideas before committing to build
- `ai-feature-or-not` (Interactive) — Decide whether AI belongs in the product
- `prototype-learning-plan` (Component) — Define what a prototype must prove
- `vibe-coding-guardrails` (Interactive) — Build AI tools without creating shadow systems
- `ai-agent-requirements` (Component) — Define agent delegation boundaries
- `ai-evals-for-product-managers` (Workflow) — Define AI quality criteria for product managers
- `product-sense-red-team` (Interactive) — Stress-test ideas before they gain momentum
- `prototype-to-production-handoff` (Workflow) — Honest handoff from PM prototype to engineering
- `ai-product-builder-playbook` (Workflow) — Full arc from idea to evidence

**3 new commands:**
- `/sharpen-product-sense` — Stress-test an idea before build momentum
- `/build-with-judgment` — Move from idea to prototype without confusing velocity with evidence
- `/define-agentic-product` — Define agent behavior, boundaries, and quality before implementation

## Why it matters

When everyone can build, product sense becomes the differentiator. These skills help PMs build faster, think harder, and ship less nonsense.
```

### README update

Add v0.80 to the Recent Updates section following the v0.79 pattern in `CLAUDE.md`.

Update skill count: 48 → 57
Update command count: 6 → 9

### CLAUDE.md update

Update the `## Project Status` section:
- Change current state header to reflect v0.80 released
- Add v0.80 to Recent Updates list
- Update Phase 6 status: mark `ai-product-evals` as superseded by `ai-evals-for-product-managers` in v0.80
- Update skill counts in all relevant sections

---

## Phase 7 — Smoke tests

Run one smoke test per skill to confirm behavior before closing the release:

| Skill | Test prompt |
|---|---|
| `ai-product-sense` | "We want to add an AI assistant to our onboarding flow so users can ask questions. Help me decide if this is a good product idea." |
| `ai-feature-or-not` | "Our CEO wants every dashboard to include an AI summary. Should this be an AI feature or something else?" |
| `prototype-learning-plan` | "We think users would trust an AI-generated weekly planning recommendation. Create a prototype learning plan." |
| `vibe-coding-guardrails` | "I built a small internal tool with Cursor that summarizes customer notes and writes next-step recommendations. What guardrails do I need before sharing it with the team?" |
| `ai-agent-requirements` | "Define requirements for an agent that monitors incoming support tickets and drafts suggested responses." |
| `ai-evals-for-product-managers` | "Create an eval plan for an AI feature that summarizes user interviews into product insights." |
| `product-sense-red-team` | "Red-team this idea: an AI copilot that tells PMs what features to build next based on Jira, Slack, and customer calls." |
| `prototype-to-production-handoff` | "I built a prototype that classifies feedback themes from interview notes. Create an engineering handoff." |
| `ai-product-builder-playbook` | "I want to test whether PMs would use an AI tool that turns messy stakeholder input into an opportunity map. Guide me through the builder playbook." |
| `/sharpen-product-sense` | "Sharpen this idea: AI feature prioritization based on customer call transcripts, support tickets, and revenue impact." |
| `/build-with-judgment` | "Help me move from idea to prototype for an AI customer-discovery synthesis tool." |
| `/define-agentic-product` | "Define an agentic product that watches onboarding analytics, identifies stuck users, and suggests interventions." |

---

## Cross-reference map

Use this when writing References sections. Verify each path before writing it.

```
ai-product-sense
  → ai-feature-or-not
  → pol-probe (existing)
  → product-sense-red-team

ai-feature-or-not
  → ai-product-sense
  → ai-agent-requirements (if agentic)
  → vibe-coding-guardrails (if prototyping)

prototype-learning-plan
  → pol-probe (existing)
  → vibe-coding-guardrails
  → prototype-to-production-handoff

vibe-coding-guardrails
  → prototype-learning-plan
  → prototype-to-production-handoff
  → ai-product-builder-playbook (for principles)

ai-agent-requirements
  → ai-feature-or-not
  → ai-evals-for-product-managers
  → context-engineering-advisor (existing)
  → agent-orchestration-advisor (VERIFY EXISTS before referencing)

ai-evals-for-product-managers
  → ai-agent-requirements
  → context-engineering-advisor (existing)
  → prototype-to-production-handoff

product-sense-red-team
  → ai-product-sense
  → ai-feature-or-not

prototype-to-production-handoff
  → prototype-learning-plan
  → vibe-coding-guardrails
  → ai-evals-for-product-managers
  → ai-product-builder-playbook (for principles)

ai-product-builder-playbook
  → all 8 primitives above
```

---

## Quality bar — a skill passes only if

1. It helps the PM think better, not just produce faster
2. The judgment behind the artifact is visible — not just "here are the steps"
3. Anti-patterns are specific and sharp (not polite reminders)
4. The output artifact is concrete and directly usable
5. No AI hype language
6. No customer-derived examples
7. It fits the release arc
8. Description is ≤200 chars and trigger-oriented
9. Folder name exactly matches the `name` frontmatter field
10. All referenced skills in the References section exist in `skills/`
11. Validation passes: `./scripts/test-library.sh`

---

## Do NOT do

- Do not hand-edit `catalog/` files
- Do not hand-edit `dist/` files
- Do not create a `references/` directory
- Do not reference `agent-orchestration-advisor` without confirming it exists in `skills/`
- Do not write descriptions over 200 characters
- Do not let folder name differ from `name` frontmatter
- Do not commit without running `./scripts/test-library.sh` first
- Do not strip educational preambles, "Why This Works" explanations, or Anti-Patterns sections to tighten prose
- Do not use Productside customer examples, even paraphrased
- Do not use hype language ("transform," "unlock innovation," "revolutionize")
- Do not write the orchestration skill (`ai-product-builder-playbook`) before all 8 primitive skills are complete

---

## Final file checklist

When done, these files should exist and pass validation:

```
skills/ai-product-sense/SKILL.md
skills/ai-feature-or-not/SKILL.md
skills/prototype-learning-plan/SKILL.md
skills/vibe-coding-guardrails/SKILL.md
skills/ai-agent-requirements/SKILL.md
skills/ai-evals-for-product-managers/SKILL.md
skills/product-sense-red-team/SKILL.md
skills/prototype-to-production-handoff/SKILL.md
skills/ai-product-builder-playbook/SKILL.md

commands/sharpen-product-sense.md
commands/build-with-judgment.md
commands/define-agentic-product.md

docs/announcements/2026-05-15-v0-80-ai-product-builder-track.md

catalog/skills-by-type.md     (regenerated — 57 skills)
catalog/skills-index.yaml     (regenerated — 57 skills)
catalog/commands-index.yaml   (regenerated — 9 commands)
catalog/commands.md           (regenerated — 9 commands)
```

And these existing files should be updated:

```
README.md          (v0.80 section, updated counts)
CLAUDE.md          (Project Status, Phase 6 notes, skill counts)
```

---

## Source material location

Substack posts are in either:
- `/Users/deanpeters/Code/15-days-of-aipm/substack/deanpeters.substack.com/`
- `research/deanpeters-substack-posts.zip` (extract if needed)

Read posts individually as you write each skill. Do not batch-read all 35. Use them for style, themes, and principles — prefer synthesized insights over direct quotes.

---

## How to run in Codex or another Claude Code instance

From the repo root:

```bash
# Confirm you are on the right branch
git checkout v0.80-ai-product-builder-track

# Read this file fully before starting
cat 15MAY26.md

# Then follow Phase 0 through Phase 7 in order
```

If using Codex, paste this document as the task, then run:

```text
Review your own changes against this task. Identify anything incomplete, risky, or likely to fail validation.
```

Then:

```text
Run the validation scripts and fix any errors until ./scripts/test-library.sh passes cleanly.
```

---

Product sense beats build speed. Judgment is the moat.
