Product
Run an interactive /product workflow to author or refresh PRODUCT.md so later pre-mortem and vibe reviews have explicit product context.
Overview
Product is an agent skill most often used in Validate (also Build pm, Ship review prep) that interactively generates or updates PRODUCT.md to unlock product-aware /pre-mortem and /vibe reviews.
Install
npx skills add https://github.com/boshu2/agentops --skill productWhat is this skill?
- Mandatory execution workflow—agent must run steps, not only describe /product.
- Pre-flight on existing PRODUCT.md with overwrite, update-with-defaults, or cancel via AskUserQuestion.
- Pre-populates suggestions from README.md and related project files before interactive questions.
- Output contract is PRODUCT.md; unlocks product-aware paths in /pre-mortem and /vibe including quick mode.
- Hexagonal domain tier with lean-startup, mythical-man-month, and DDD bounded-context practices baked in metadata.
- Produces PRODUCT.md per explicit output_contract
- Three-way pre-flight: overwrite, update with existing defaults, or cancel
Adoption & trust: 836 installs on skills.sh; 384 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are coding without a single source of truth for what the product is, so agent reviews cannot catch wrong-scope or wrong-audience decisions.
Who is it for?
Solo builders adopting AgentOps who want a guided PRODUCT.md before risk reviews or vibe checks on an existing or new repo.
Skip if: Repos that already have an approved PRODUCT.md you do not want to change, or teams skipping AgentOps slash-command workflows.
When should I use this skill?
User invokes /product [target-dir] to create or refine PRODUCT.md for AgentOps product-aware reviews.
What do I get? / Deliverables
You get a committed PRODUCT.md from an executed /product session—overwrite or merge chosen—so pre-mortem and vibe can run with product context.
- PRODUCT.md at repo root (or target-dir)
- result.json per produces metadata when the wider AgentOps pipeline runs
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Validate scope is canonical because PRODUCT.md captures what you are building and for whom before deep implementation and review gates. Scope subphase fits bounded product definition, overwrite/update decisions, and defaults that constrain later agent reviews.
Where it fits
New repo has only a README—you run /product to lock audience, problem, and boundaries before writing code.
Pivot mid-build—you update PRODUCT.md with merge defaults so vibe review questions reference the new positioning.
Before /pre-mortem you refresh PRODUCT.md so failure modes are judged against the actual product promise.
How it compares
Interactive PRODUCT.md generator in the AgentOps stack, not a generic markdown linter or a codebase-wide architecture doc skill.
Common Questions / FAQ
Who is product for?
Indie developers and small teams using boshu2/agentops who need PRODUCT.md as the shared kernel for standards-aligned reviews.
When should I use product?
Use it in Validate to scope the offering; in Build pm when repositioning; before Ship-style reviews when /pre-mortem or /vibe need product-aware defaults—especially if PRODUCT.md is missing or stale.
Is product safe to install?
It only writes PRODUCT.md after you choose overwrite or update; review the Security Audits panel on this page and back up an existing PRODUCT.md before accepting overwrite.
SKILL.md
READMESKILL.md - Product
# /product — Interactive PRODUCT.md Generation > **Purpose:** Guide the user through creating a `PRODUCT.md` that unlocks product-aware reviews in `/pre-mortem` and `/vibe`, including the default quick-mode inline paths. **YOU MUST EXECUTE THIS WORKFLOW. Do not just describe it.** **CLI dependencies:** None required. ## Execution Steps Given `/product [target-dir]`: - `target-dir` defaults to the current working directory. ### Step 1: Pre-flight Check if PRODUCT.md already exists: ```bash ls PRODUCT.md 2>/dev/null ``` **If it exists:** Use AskUserQuestion: - **Question:** "PRODUCT.md already exists. What would you like to do?" - **Options:** - "Overwrite — start fresh" → continue to Step 2 - "Update — keep existing content as defaults" → read existing file, use its values as pre-populated suggestions in Step 3 - "Cancel" → stop, report no changes **If it does not exist:** continue to Step 2. ### Step 2: Gather Context Read available project files to pre-populate suggestions: 1. **README.md** — extract project description, purpose, target audience 2. **package.json / pyproject.toml / go.mod / Cargo.toml** — extract project name 3. **Directory listing** — `ls` the project root for structural hints 4. **Existing product/release docs** — if present, read `PRODUCT.md`, `GOALS.md`, release notes, comparison docs, and recent `.agents/research/` or `.agents/plans/` artifacts for PMF, positioning, and evidence context Use what you find to draft initial suggestions for each section. If no files exist, proceed with blank suggestions. ### Step 3: Interview Ask the user about each section using AskUserQuestion. For each question, offer pre-populated suggestions from Step 2 where available. #### 3a: Mission Ask: "What is your product's mission? (One sentence: what does it do and for whom?)" Options based on README analysis: - Suggested mission derived from README (if available) - A shorter/punchier variant - "Let me type my own" #### 3b: Target Personas Ask: "Who are your primary users? Describe 2-3 personas." For each persona, gather: - **Role** (e.g., "Backend Developer", "DevOps Engineer") - **Goal** — what they're trying to accomplish - **Pain point** — what makes this hard today Use AskUserQuestion for the first persona's role, then follow up conversationally for details and additional personas. Stop when the user says they're done or after 3 personas. #### 3c: Core Value Propositions Ask: "What makes your product worth using? List 2-4 key value propositions." Options: - Suggestions derived from README/project context - "Let me type my own" #### 3d: Competitive Positioning Ask: "What alternatives exist, and how do you differentiate?" Gather for each competitor: - Alternative name - Their strengths (where they win) - Your differentiation (where you win) - Feature-level comparison (specific capabilities, not just vibes) Then ask: "What is the market trend you're betting on that competitors are ignoring?" This produces the Strategic Bet section — the contrarian thesis that justifies your product's existence. Examples: - "We bet that AI agents will need institutional memory, not just prompts" - "We bet that local-first tools will win over cloud-dependent ones" If the user says "none" or "skip" for competitors, write "No direct competitors identified" but still ask about the strategic bet. #### 3e: Evidence (Traction + Impact) Ask: "What evidence do you have that this product works?" Gather what's available: - **Usage data** — stars, downloads, clones, active