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:

The public Product-Manager-Skills repository itself
The Substack export at /Users/deanpeters/Code/15-days-of-aipm/substack/deanpeters.substack.com (also archived as research/deanpeters-substack-posts.zip)
Public market evidence only when needed for release notes or context
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)

---
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`)

---
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:

# /command-name

One-sentence summary of what this command does.

## Invocation

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

Workflow

Brief step 1 description using skill-name.
Brief step 2 description using skill-name.
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:

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:

The AI agent executing the work
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:

# 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):

Capture the idea in one sentence
Identify the user and situation
Clarify the user job, pain, or desired progress
Identify the behavior change the product must create
Identify why AI appears necessary
Remove the word "AI" and restate the value proposition
Identify the current workaround or alternative
Identify the riskiest assumption
Define what evidence would change the decision
Recommend: build, prototype, research, reframe, or reject

Output artifact (Application section):

# 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):

Restate the proposed feature
Identify the problem it claims to solve
Identify why AI is being proposed (whose idea, what was the trigger)
Evaluate input ambiguity (does input vary enough to require probabilistic handling?)
Evaluate output variability tolerance (can users accept non-deterministic output?)
Evaluate user trust and failure cost
Evaluate ground truth availability
Evaluate data/context readiness
Compare AI vs deterministic alternatives
Make the decision from the five-option model
Define next step and evidence needed

Output artifact:

# 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):

Identify the decision the prototype should inform
Identify the riskiest assumption
State the learning question (one question, not a list)
Choose the lightest prototype that can test that assumption
Explain why this fidelity is enough
Define the target reviewer/user
Define the test scenario
Define what evidence counts
Define what evidence does NOT count
Define kill/change/continue thresholds
Define timebox
Define capture/debrief plan

Output artifact:

# 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):

Ask what is being built
Classify the artifact (from the table above)
Identify data touched (real customer data? internal data? synthetic only?)
Identify systems touched (integrations, APIs, databases)
Identify user/customer exposure (who sees or uses this?)
Identify whether it can read/write/trigger actions
Define owner and lifespan
Define required review before sharing
Define what must not happen
Produce guardrail checklist and next action

Output artifact:

# 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):

Define what job the agent performs
Define who it serves (user/actor)
Define when it acts (trigger conditions)
Define what it may read
Define what it may write
Define what it may decide without human approval
Define what it may trigger in other systems
Define what it must never do (forbidden actions)
Define when a human must review before the agent continues
Define escalation paths if a human does not respond
Define what must be logged (observability requirements)
Define failure modes and rollback conditions

Output artifact (name it "Agent Delegation Contract"):

# 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):

Define the AI behavior being evaluated (what is the agent/feature doing?)
Define user-visible quality dimensions (from the user's perspective, what does "good" look like?)
Define unacceptable failures (what would cause a user to lose trust or the team to pull the feature?)
Define expected inputs and contexts (what situations will this face?)
Define output standards (what is an acceptable output? what is a great one?)
Create failure taxonomy (organize failure types by severity and frequency)
Create golden example plan (how will you collect and curate examples?)
Define human review rubric (how will reviewers score consistently?)
Define telemetry/monitoring plan
Define launch thresholds (what must be true before launch?)
Define "not ready" criteria explicitly
Define review cadence and ownership

Output artifact:

# 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):

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

Output artifact:

# 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):

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

Output artifact:

# 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.

## 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):

Sense — Run ai-product-sense to evaluate the idea before committing
Decide — Run ai-feature-or-not to confirm AI belongs
Learn — Use prototype-learning-plan to define what needs to be tested
Guardrail — Use vibe-coding-guardrails to classify the build and set boundaries
Specify — Use ai-agent-requirements if the feature is agentic
Evaluate — Use ai-evals-for-product-managers to define quality criteria before building
Red-team — Invoke product-sense-red-team to stress-test before investing further
Build brief — Generate a builder brief for the prototype tool or engineering partner
Handoff — Use prototype-to-production-handoff to close the loop

Builder Brief format (include in Application section):

# 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:

# 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:

---
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:

/sharpen-product-sense Add an AI assistant to our onboarding flow so users can ask questions

Workflow:

Evaluate the idea through ai-product-sense — separate AI novelty from user value
Confirm AI belongs with ai-feature-or-not — choose build/assistive/deterministic/fix-first/don't-build
Stress-test with product-sense-red-team — apply structured attack lenses
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:

---
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:

/build-with-judgment AI customer-discovery synthesis tool that turns interview notes into opportunity maps

Workflow:

Evaluate through ai-product-sense — confirm user, job, behavior change
Confirm AI necessity with ai-feature-or-not
Define the learning experiment with prototype-learning-plan
Classify the build and set boundaries with vibe-coding-guardrails
Run the full builder flow with ai-product-builder-playbook, including Builder Brief
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:

---
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:

/define-agentic-product Agent that monitors incoming support tickets and drafts suggested responses

Workflow:

Confirm agent is necessary with ai-feature-or-not — could this be a deterministic automation instead?
Define delegation boundaries, tools, data, checkpoints, and failure modes with ai-agent-requirements
Define quality criteria and "not ready" conditions with ai-evals-for-product-managers
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:

# 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):

# 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

It helps the PM think better, not just produce faster
The judgment behind the artifact is visible — not just "here are the steps"
Anti-patterns are specific and sharp (not polite reminders)
The output artifact is concrete and directly usable
No AI hype language
No customer-derived examples
It fits the release arc
Description is ≤200 chars and trigger-oriented
Folder name exactly matches the name frontmatter field
All referenced skills in the References section exist in skills/
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:

# 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:

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

Then:

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

Product sense beats build speed. Judgment is the moat.

FilesExpand file tree

15MAY26.md

Latest commit

History

15MAY26.md

File metadata and controls

TASK: v0.80 — AI Product Builder Track

Mission

Hard exclusions — read before writing a single line

Repo state at time of this handoff

Repo conventions — confirmed from live code inspection

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

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

Workflow

Checkpoints

Next Steps

Catalog behavior

dist/ behavior

No references/ directory

Decisions already made — do not re-litigate these

Release arc

Voice and style constraints

Pedagogic mandate — do not skip this section

Phase 0 — Setup

Phase 1 — Create 8 primitive skills

Skill 1: ai-product-sense

Skill 2: ai-feature-or-not

Skill 3: prototype-learning-plan

Skill 4: vibe-coding-guardrails

Skill 5: ai-agent-requirements

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

Skill 7: product-sense-red-team

Skill 8: prototype-to-production-handoff

Phase 2 — Create orchestration skill

Skill 9: ai-product-builder-playbook

Phase 3 — Create 3 commands

Command 1: sharpen-product-sense

Command 2: build-with-judgment

Command 3: define-agentic-product

Phase 4 — Validate

Phase 5 — Pack configuration check

Phase 6 — Documentation updates

Release note

README update

CLAUDE.md update

Phase 7 — Smoke tests

Cross-reference map

Quality bar — a skill passes only if

Do NOT do

Final file checklist

Source material location

How to run in Codex or another Claude Code instance

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

`dist/` behavior

No `references/` directory

Skill 1: `ai-product-sense`

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

Skill 3: `prototype-learning-plan`

Skill 4: `vibe-coding-guardrails`

Skill 5: `ai-agent-requirements`

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

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

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

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

Command 1: `sharpen-product-sense`

Command 2: `build-with-judgment`

Command 3: `define-agentic-product`