product-boot

Overview

One of the five class boots surfaced by team-boot's Class Boots catalog. team-boot injects the always-relevant team context (constitution, CDR index, skills registry) at session start; this skill loads the product decision layer on demand — the Accepted PDR index from project memory — and pairs it with decision capture so new product choices are recorded (/product-specify) rather than evaporating.

Reading decisions and recording decisions are one loop: existing PDRs inform the work; decisions made during the work flow back into the same record system.

When to Use

Invoke when:

• Starting product work (PRD generation, feature definition, roadmap planning, GTM decisions).
• The session turns product-shaped mid-flight: feature scope, persona definition, monetization, pricing, or target-market choices emerge.
• Reviewing an existing product's decision backdrop (/product-analyze, /product-roadmap benefit from the loaded index).

Core Process

Step 1: Locate the PDR Index

From the current working directory (do NOT walk up parent directories):

1. Primary: .adlc/memory/pdr/pdr.md (generated by /product-implement; rows start with | PDR)
2. Fallback: .adlc/memory/pdr.md

If neither exists but .adlc/memory/pdr/PDR-*.md files do, synthesize a lean table from each file (ID from filename; Feature-Area/Status/Title from frontmatter or first heading). If the directory is empty or absent, report 0 PDRs — never fabricate rows.

Step 1b: Read the PDR Drafts Index

Check .adlc/drafts/pdr/ for PDR-*.md files with status: proposed in frontmatter. These are draft PDRs pending clarification. Collect ID / Title / Type / Status / Date from each file. If the directory is empty or absent, report 0 pending drafts.

Step 2: Inject PDR Context (Output Contract)

Emit before the task answer:

## PDR Context

| ID | Feature-Area | Status | Title |
|--|--|--|--|
| PDR-048 | triage | Accepted | AI triage scoring |

_Searched N PDRs, K matched._

## Drafts Pending Review

| ID | Title | Type | Status | Date |
|----|-------|------|--------|------|
| (from .adlc/drafts/pdr/) |

_N pending drafts — run /product-clarify to review._

• Render ID / Feature-Area / Status / Title from the index (the full index also carries Category, Date, Owner — read the individual PDR-*.md when a task matches a row).
• N = total index rows; K = rows relevant to the current task. K MUST equal the table rows shown — 0 matched → empty table, never inflate.

Step 3: Capture Product Decisions

Trigger	Action
Feature scope change, in/out decisions	PDR → direct write to .adlc/drafts/pdr/
Persona definition or revision	PDR → direct write to .adlc/drafts/pdr/
Monetization, pricing, target-market choice	PDR → direct write to .adlc/drafts/pdr/
PDR-class decision already in the ledger	verify capture happened; if not, re-surface

Add/refresh rows in the Session Decision Ledger (Decision | Type | Captured? | Skill) for every PDR-class decision detected this session — including ones from before this boot was invoked. At session end, prompt to run /product-clarify for any unrecorded PDR drafts in .adlc/drafts/pdr/.

Failure Handling

• Missing index + missing records → emit the empty table with _Searched 0 PDRs, 0 matched._ and continue the user's task; never block.
• Unparseable index rows → skip malformed rows, note the skip count.

Red Flags

• Fabricating PDR rows or inflating K beyond the table shown.
• Injecting the index but ignoring capture — the pairing is the point.
• Walking up parent directories to find .adlc/.

Verification

• PDR Context table emitted with _Searched N PDRs, K matched._ (K = table rows).
• Session Decision Ledger updated with detected PDR-class decisions.