Créer ou mettre à jour un document produit

VérifiéSûr

Crée ou met à jour le fichier product.md du blueprint, en élicitant le problème, les utilisateurs cibles, les métriques de succès et les priorités.

Spar Skills Guide Bot
DocumentationIntermédiaire
23/07/2026
Claude Code
#product-management#requirements#blueprint#elicitation#spec-driven-development

Recommandé pour

Synthèse automatique

Rédige ou met à jour docs/blueprint/product.md en faisant éliciter par l'utilisateur le problème, les utilisateurs cibles, les objectifs mesurables, la priorité des slices et les non-objectifs, sans jamais rien inventer.

Points forts

  • Conduit une élicitation structurée, une décision à la fois, avec des QCM et deux ou trois formulations proposées quand l'utilisateur hésite.
  • Refuse les objectifs non mesurables et exige pour chacun une métrique, une cible, un horizon et un point de mesure.
  • Détecte le mode création ou mise à jour et ne réinterroge que les vrais écarts en préservant le contenu déjà validé.
  • Impose une porte d'approbation explicite avant toute écriture et garde le document indépendant de toute stack technique.

Limites

  • Suppose l'écosystème de plugins VWF (worktree git, gabarits, mémoire) ; hors de ce contexte, plusieurs étapes sont inopérantes.
  • Dépend fortement des réponses de l'utilisateur : sans arbitrage humain, le document reste incomplet plutôt que deviné.
  • Le classement des slices et les métriques peuvent être fastidieux sur un produit déjà mature.
Quand l'utiliser

À utiliser au démarrage d'un blueprint ou lors d'un pivot, pour figer le problème, les utilisateurs et les métriques avant l'architecture et le plan.

Quand l'éviter

À éviter si vous cherchez un document technique, une spécification d'écran ou une architecture : ce skill exclut volontairement toute technologie.

Analyse de sécurité

Sûr
Score qualité92/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.

Aucun point d'attention détecté

Comment cette analyse est faite

Exemples

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

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/create-or-update-product-document-mrx3y0yi/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

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. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

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 doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/create-or-update-product-document-mrx3y0yi'

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

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/create-or-update-product-document-mrx3y0yi/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires