# Product Orchestrator > Use when work is still at the idea-to-plan stage and needs bounded product-definition artifacts before implementation. - Skill: `munlucky/product-orchestrator` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add munlucky/product-orchestrator` - Raw SKILL.md: https://api.skillmd.com/api/skills/munlucky/product-orchestrator/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: munlucky (https://skillmd.com/u/munlucky) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/munlucky/product-orchestrator --- # Product Orchestrator ## Use When Use while an idea still needs bounded product definition before architecture or implementation. ## Route Away Use `moonshot-architecture` after product approval and `moonshot-orchestrator` only for bounded implementation-ready work. ## Role Run the product-definition workflow before code-oriented Moonshot execution. This is the default public entrypoint for the Intake stage when the request is still shaping product scope. This skill is explicitly for: - idea to product intent - product intent to PRD - PRD to product behavior model - behavior model to architecture - architecture to execution slices This skill is not for: - market validation - user interview automation - MVP experiment pipelines - shipping code directly It may prepare a `demo_first` MVP execution pack. That pack is a planning and execution contract, not a market experiment runner. ## Output Contract Write artifacts under: - `{tasksRoot}/{feature-name}/product/` Required outputs: - `PRODUCT_INTENT.md` - `PRD.md` - `SOLUTION.md` - `SPEC.md` - `ADR/*.md` - `PLAN.md` - `tasks/*.md` - `ASSUMPTIONS.md` - `BLOCKERS.md` - `execution/REQUIREMENTS_TRACEABILITY.md` when document-trace completion is required - `execution/SCENARIO_MATRIX.md` when user-visible flows matter - `execution/UAT_CHECKLIST.md` when the target is UAT-ready handoff Conditional demo-first MVP outputs: - `MVP_SCOPE.md` - `MINI_ARCHITECTURE.md` - `UI_DEMO_PLAN.md` - `UI_FLOW_MAP.md` - `UI_STATE_MATRIX.md` - `MOCK_SCENARIOS.md` - `MOCK_API_CONTRACT.md` - `USER_DEMO_TEST.md` - `DEMO_EVIDENCE.md` - `USER_DEMO_APPROVAL.md` - `POST_DEMO_IMPLEMENTATION_PLAN.md` - `UI_CHANGE_REQUEST.md` Planning artifacts should also record: - explicit non-goals - scope reduction or scope hold notes when requests are too large - a short cost/benefit rationale at `PRODUCT_INTENT`, `PRD`, and `PLAN` - canonical domain terms or glossary gaps when language is ambiguous - testing decisions focused on user-visible behavior, not implementation details ## Procedure 1. Build compact intake/plan knowledge context and classify facts, decisions, assumptions, and blockers. 1.1. classify unresolved input as fact, decision, assumption, or blocker; do not self-resolve decisions affecting scope, security, data, package/runtime surface, or user-visible behavior. 2. Draft `PRODUCT_INTENT.md`, `PRD.md`, `SOLUTION.md`, `SPEC.md`, and `PLAN.md` in order. 3. Run the product gate at every stage; add CEO review for intent, PRD, and plan, plus engineering review for spec and plan. 4. Use Discovery Map and current-fact references only when needed; they remain advisory and never authorize execution. 4.1. Record task-relevant consultation through `docs/public/guidelines/skill-readiness-policy.md`. 5. Slice accepted planning into tasks, retry a weak draft at most twice, and reduce scope when value is unclear. 6. Hand the approved package and compact context to the appropriate execution entrypoint. 6.1. Route architecture-heavy PRDs through `moonshot-architecture`, then preserve `REQUIREMENT_INVENTORY.md`, `TRACEABILITY_MATRIX.md`, and `ARCHITECTURE_REVIEW.md` for `moonshot-orchestrator` or `moonshot-phase-runner` handoff. ## Hard Stops Every stage ends with one of: - `pass`: ready for the next stage - `conditional_pass`: acceptable with explicit assumptions or follow-up notes - `fail`: rewrite the current stage Escalation rules: - Same issue repeated twice -> `conditional_pass` - Missing but non-critical detail -> add to `ASSUMPTIONS.md` - Hard dependency missing -> add to `BLOCKERS.md` - Weak value or poor cost/benefit -> reduce scope, hold scope, or fail the stage Stage-specific detail, value tests, and demo-first sequencing are conditional references in `docs/public/guidelines/product-definition-workflow.md` and `docs/public/guidelines/demo-first-mvp-gate.md`. ## Approval Boundary - Human approval may be used to accept the planning package before execution begins. - After execution begins, implementation -> review -> verify -> retry loops should continue without additional human checkpoints unless a true blocker or external dependency appears. - Exception: `demo_first` MVP work must hard-stop after Mock Functional Demo evidence until `USER_DEMO_APPROVAL.md` is approved with non-empty approved scope. ## Handoff Contract When the plan passes: - provide document paths, not full inline content - summarize assumptions and blockers - include architecture package paths when `moonshot-architecture` was used: `REQUIREMENT_INVENTORY.md`, `ASR_CATALOG.md`, `TRACEABILITY_MATRIX.md`, selected `ADR/*.md`, and `ARCHITECTURE_REVIEW.md` - hand `tasks/*.md` to the implementation-oriented workflow - route bounded implementation to `moonshot-orchestrator`; route multi-phase, staged adoption, or long-running packages to `moonshot-phase-runner` Recommended next step: - `/moonshot-orchestrator` with the generated product package ## References - `docs/public/guidelines/product-definition-workflow.md` - `docs/public/guidelines/demo-first-mvp-gate.md` - `docs/public/guidelines/retrieval-and-recency-policy.md` - `templates/product-definition/DISCOVERY_MAP.template.md` - `templates/product-definition/DISCOVERY_TICKET.template.md` - `schemas/discovery-map.schema.json` - `docs/public/guidelines/skill-readiness-policy.md` - `/templates/product-definition/` - `skills/product-gate-reviewer/SKILL.md` - `skills/plan-ceo-review/SKILL.md` - `skills/plan-eng-review/SKILL.md` - `skills/task-slicer/SKILL.md` - `skills/assumption-ledger/SKILL.md` - `skills/moonshot-orchestrator/SKILL.md` ## Project Knowledge Context Contract Product-definition work uses advisory `projectKnowledgeContext` with `stage=intake` or `stage=plan` before plan-package prompt assembly. The context is a compact recall source, not an enforcement source. If the helper is unavailable, continue with degraded advisory metadata unless the user explicitly requested a strict memory task. Do not inline raw MemoryGraph/KG/ontology records, logs, transcripts, or secrets into product prompts or plan artifacts.