用途：把模糊的产品想法转化为精确、可验证的产品定义。流程位置为 /aep-envision → /aep-map → /aep-scaffold → [设计/发布/构建/收尾] → /aep-reflect。输入为产品想法（可粗可细），输出为 product/index.yaml（机会、角色、能力、产品分节）与 product-context.yaml（calibration、changelog）；V1 回退模式下全部写入 product-context.yaml。字段结构见 templates/product-context-schema.yaml。
主要能力分两阶段。Phase 0 机会框定：追问想法触发点、现有痛点、世界变化、独特优势与失败理由，综合成 Opportunity Brief；再用三个是/否问题做 Kill Point，结果记为 proceed、kill 或 defer，早期终止是高回报决策。Phase 1 产品框定：散开收集问题陈述、角色与 JTBD、MVP 边界、用户活动主干、技术约束、需要人类判断的质量维度、分层 MVP 契约（Layer 0 为可走通骨架）；随后结构化为 Context Document；再由未参与对话的独立智能体从产品可行性、技术可行性、范围控制三角度冷审查，逐条由用户处理或记为 open_question 与默认假设。多旅程产品需为每个能力建立 product/maps/<capability-id>/frame.yaml。
使用方式：开始前先运行探针判断 SPLIT 或 V1 模式，如 ls product/index.yaml 2>/dev/null && echo "SPLIT MODE" || echo "V1 MODE"；更新模式下先读现有文件并确认修订或重写，保留未更新分节。提交前需校验 YAML，例如 npx js-yaml product-context.yaml > /dev/null && echo "YAML OK"。随后按 /aep-git-ref 解析 $BASE 并提交，如 git add product-context.yaml product/ docs/ 与 git commit -m "feat: add product context (opportunity brief + context document)"。迭代时读取现有定义、更新变更分节、仅对改动分节重跑压测、追加 changelog 并提交。
适用场景：启动或重新审视一个想法，或回答“该做什么”。限制：与 /aep-reflect 的分工是前者处理新机会或骨干变更，后者处理已发布工作的反馈重切；资料未提供具体平台支持、收费或效果数据。