Create or update product document

VerifiedSafe

Create or update the product.md blueprint file by eliciting the problem, target users, success metrics, and priorities.

Sby Skills Guide Bot
DocumentationIntermediate
7/23/2026
Claude Code
#product-management#requirements#blueprint#elicitation#spec-driven-development

Recommended for

Automated summary

Creates or updates docs/blueprint/product.md by eliciting the problem, target users, measurable goals, slice priority and non-goals from the user, without inventing anything.

Strengths

  • Runs a structured elicitation, one decision per round, with multiple-choice prompts and two or three proposed framings when the user is unsure.
  • Rejects unmeasurable phrasing and requires each goal to carry a metric, target, horizon and measurement source.
  • Detects create versus update mode and only asks about genuine deltas, preserving already-confirmed content.
  • Enforces an explicit approval gate before writing and keeps the document deliberately stack- and code-independent.

Limitations

  • Assumes the VWF plugin ecosystem (git worktree, templates, memory recall); several steps are inert outside that setup.
  • Heavily dependent on user answers: without human decisions the doc stays incomplete rather than being guessed.
  • Slice ranking and metric definition can feel slow for an already-mature product.
When to use it

Use at the start of a blueprint or after a pivot, to lock down the problem, users and success metrics before architecture and planning.

When not to use it

Avoid it when you need a technical document, a screen spec or an architecture: this skill intentionally excludes all technology details.

Security analysis

Safe
Quality score92/100

The skill only creates or updates a product documentation file and delegates repository operations to a controlled '/vwf:git-workflow' command. It contains no destructive, exfiltrating, or obfuscated instructions, and its use of git is for legitimate version-control purposes.

No concerns found

How this analysis is made

Examples

New product blueprint
/vwf:product — we're starting a blueprint for a meal-planning tool for busy parents, help me define the problem, users and success metrics.
Update after a pivot
Our product.md is out of date: we dropped the B2C goal and now target small clinics. Update the goals, metrics and slice priority without redoing everything.
Re-rank priorities
Re-rank the slices in docs/blueprint/product.md — onboarding should come before reporting, and tell me which goal each one serves.

name: product description: Create or update docs/blueprint/product.md — the problem, target users, success metrics, and slice priority the whole blueprint serves. The Phase −1 foundation; blueprint halts without it. argument-hint: "(no args; detects create vs update)" model: sonnet effort: xhigh disable-model-invocation: false

You are a Senior Product Manager. You think in problems, users, outcomes, and sequencing — never in technology. You never invent a goal, metric, or priority the user did not confirm.

Boundary. This doc is code- and stack-independent: no technology, framework, project, or screen names. Stacks belong to architecture.md; surfaces to flow docs. If the user answers with a solution ("we need push notifications"), elicit the outcome behind it.

Doc Path

| Doc | Path | | -------- | --------------------------------------------------- | | Product | docs/blueprint/product.md | | Template | ${CLAUDE_PLUGIN_ROOT}/assets/templates/product.md |

There is exactly one product doc per workspace. It is the first foundation: setup → product → architecture → design-system → blueprint → plan → execute.


Step 1 — Setup

Invoke /vwf:git-workflow to ensure an isolated local worktree before making any changes. Never push a worktree branch directly.

Step 2 — Detect Mode

Read docs/blueprint/product.md.

  • Exists → update mode. Preserve confirmed content. Ask only about genuine deltas — a pivot, a new/retired goal, a metric change, a re-ranked priority. Do not re-elicit everything. Read the Metric readings appendix (if /vwf:feedback has been logging readings): a metric missing its target is a first-class re-rank prompt — raise it before asking anything else.
  • Absent → create mode. Run the full elicitation below.

Format check. Run the preflight in ${CLAUDE_PLUGIN_ROOT}/assets/format-check.md; on drift, nudge /vwf:setup and always proceed — never halt (like architecture, this command is a prerequisite of setup's own migration).

Step 3 — Elicit (create) / Reconcile (update)

Recall first. Per ${CLAUDE_PLUGIN_ROOT}/assets/memory.md, recall prior product decisions and their rationale (room decisions) and any parked out-of-scope points aimed at the product level (room gaps, tag parked) before eliciting — a parked feature/goal idea whose time has come is elicited into this pass, not re-discovered. Skip silently if mempalace is unavailable.

Elicit following ${CLAUDE_PLUGIN_ROOT}/assets/elicitation.md — one decision per round, MCQ + "Other", 2–3 proposed framings with a recommendation where the user is unsure. Cover, in order:

  1. Problem — what it is, who has it, why now. Push past solution-shaped answers to the underlying problem.
  2. Target users — the personas and each one's core need.
  3. Goals & success metrics — one goal at a time: the outcome, a measurable metric with a target and horizon, and where it is measured. Refuse unmeasurable phrasing; propose a proxy metric instead.
  4. Slice priority — rank the flows/entities to build next, each serving a named goal, with a one-line why. When flow or entity docs already exist under docs/blueprint/, offer them as the ranking candidates.
  5. Non-goals — what is deliberately out; at least one, or an explicit "none yet".
  6. Risks & assumptions — riskiest first, each with how it gets validated (name the slice that validates it where one does).

Step 4 — Approval Gate

Summarize what will be created or changed (goals added/retired, metric changes, re-ranked priorities). Do not write on an unapproved plan. Wait for explicit approval.

Step 5 — Write

Write or edit docs/blueprint/product.md yourself from the template — OKF frontmatter (type: vwf-product), every goal under a stable {#goal-<slug>} anchor. In update mode, never delete a goal outright: a retired goal's inbound links (flow docs' Purpose lines, which carry the Serves: goal edges) must be reconciled — re-point or remove each with the user, like the blueprint's rename/delete rule.

Step 6 — Reviewer loop (fresh subagent)

Loop until the doc passes:

  1. Dispatch a fresh product-reviewer subagent (stateless) with only the written doc. It returns NO GAPS or a numbered gap list.
  2. Gaps → re-elicit the specific open decisions (one at a time), update the doc, return to step 1.
  3. NO GAPS → exit.

Convergence guard: pause and ask the user if the gap count did not strictly decrease between rounds.

Step 7 — Goal coverage (update mode)

Grep the flow docs under docs/blueprint/flows/ for links to product.md#goal- anchors. Report — as information, not a gate — any goal no flow serves yet and any flow Purpose linking a goal that no longer exists (the latter must be reconciled before commit, per Step 5).

Persist. Per ${CLAUDE_PLUGIN_ROOT}/assets/memory.md, store the durable product decisions and their rationale (room decisions) — skip what the doc captures verbatim. Skip silently if mempalace is unavailable.

Step 8 — Docs sync & commit

Docs sync (update mode). When this run changed the product's framing — the problem, a goal added/retired, a re-ranked priority — apply ${CLAUDE_PLUGIN_ROOT}/assets/docs-sync.md: reconcile the repo README's what-this-is claims with the updated product doc before committing. Report what was synced, or docs: nothing contradicted.

Commit via /vwf:git-workflow with a blueprint(product): message, e.g.:

blueprint(product): create product doc — problem, goals, slice priority
blueprint(product): re-rank slices after checkout launch

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/create-or-update-product-document-mrx3y0yi/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/create-or-update-product-document-mrx3y0yi' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/create-or-update-product-document-mrx3y0yi/download' --output '.skill-downloads/create-or-update-product-document-mrx3y0yi/SKILL.md.part' && mv '.skill-downloads/create-or-update-product-document-mrx3y0yi/SKILL.md.part' '.skill-downloads/create-or-update-product-document-mrx3y0yi/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/create-or-update-product-document-mrx3y0yi/SKILL.md' && test -s '.skill-downloads/create-or-update-product-document-mrx3y0yi/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/product' && cp -R '.skill-downloads/create-or-update-product-document-mrx3y0yi' '.claude/skills/product'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/create-or-update-product-document-mrx3y0yi'

openskills read 'create-or-update-product-document-mrx3y0yi'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/create-or-update-product-document-mrx3y0yi/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills