/sdlc:product-new

Generated from solutions/ontological/skills/product-new/SKILL.md.

Description

Define a new Product — a thing this project builds and ships, usually a library — together with its Drivers, grounded in parallel domain research. Gathers the Product/Driver contracts and next ids, dispatches multiple research subagents (theory / prior-art / existing-libraries, each a configurable goal, run autonomously or with check-ins), synthesizes a Product entry + Driver entries + a research writeup, and validates. Invoke for “define a product”, “scope/define a new library”, “new product entry”, or when starting a library with a product-definition-and-research pass.

Allowed tools

• Bash
• Read
• Write
• Edit
• AskUserQuestion
• Agent

Source

Usage:

• /sdlc:product-new [idea] — define a new product/library. End state: a validated Product at docs/planning/products/PR-NNNN-<slug>.md, its Drivers at docs/planning/drivers/DR-NNNN.md, and a research writeup at docs/planning/<slug>-research.md — all under the project root.

Project context (read once; don’t re-derive every run):

• Contracts. Product: ${CLAUDE_PLUGIN_ROOT}lib/model/entities/product/definition.md + body-template.eta. Driver: ${CLAUDE_PLUGIN_ROOT}lib/model/entities/driver/definition.md + body-template.eta. These govern the frontmatter and body shape.
• No create op. Unlike /sdlc:task-new and /sdlc:standard-new, Product and Driver have no sdlc <noun> create verb — author the files by hand (Write) against the contracts above, then validate with sdlc entities validate. If a product create / driver create op ships later, switch to it.
• Instances live at docs/planning/products/ and docs/planning/drivers/ under the project root.

This skill is a fan-out orchestrator: it gathers context, dispatches one research subagent per goal, then synthesizes and validates. It does open-judgment research (general direction) and mechanical entity authoring (exact contract) — match your latitude to each step.

1. Resolve the idea and gather context

• Get the product idea from the invocation [idea]. If absent, ask one plain-text question: “What’s the product/library — a line or two on what it does?”
• Read the Product and Driver definition.md + body-template.eta (paths above) so the synthesized files match the contract exactly.
• Determine the next ids: list docs/planning/products/ for the highest PR-NNNN and docs/planning/drivers/ for the highest DR-NNNN. The new Product is that PR + 1; Drivers continue from that DR + 1 (these ids are sequential; no preview op exists for them).
• Pick a kebab-case <slug> for the Product — used in the Product filename and the research doc name.

2. Frame the research goals (one AskUserQuestion, or infer from the invocation)

Each selected goal becomes one subagent in Step 3. The default goals:

• theory — the formal/conceptual underpinnings; how the problem is modeled. Optional when the domain is well understood.
• prior-art — how existing tools/systems solve it; conventions worth honoring.
• existing-libraries — does this already exist? maturity, license, build-vs-wrap. The load-bearing goal for a new library.

Send one AskUserQuestion: which goals to run (multiSelect; default all three) and the mode — autonomous (each subagent researches to completion and returns a brief; the default) or directed/socratic (each subagent first returns 2-3 focusing questions and waits for your steer before researching). Skip this question entirely if the user already named goals and mode in the invocation.

3. Dispatch the research subagents (parallel fan-out)

• Spawn one subagent per selected goal in a single message (so they run in parallel) via the Agent tool. Give each subagent: the product idea, its single goal, and the instruction to use web search/fetch, cite source URLs, and return its findings as a markdown section plus a sources list. Have subagents return their section as text — do NOT have several subagents write the same file (write races); the skill assembles the doc in the next bullet.
• For directed/socratic mode, instruct each subagent to first return focusing questions and wait; relay them to the user, then re-dispatch with the answers folded in.
• Assemble the returned sections into one research writeup at docs/planning/<slug>-research.md (one H2 per goal + a short “Design takeaways” tail you synthesize: formal model, build-vs-wrap, hard cases, and a recommended minimal API). If a subagent returns nothing, note the gap and continue.

4. Synthesize the Product entry

Author docs/planning/products/PR-NNNN-<slug>.md (Write), following the product body-template.eta: Summary (first bullet tagged ^summary) / What it is / Boundary / free-form middle / Drivers & goals / Status / References. Frontmatter per the product schema: type: product, schema_version: '1', id: PR-NNNN, status: open/draft, title, created (today, date -u +%Y-%m-%d), related, tags, need_human_review: true.

• Draw Boundary and non-goals from the research’s build-vs-wrap and hard-cases findings.
• Product related may link narrative docs — add [[<slug>-research]] there.

5. Capture the Drivers

Author one docs/planning/drivers/DR-NNNN.md per motivating driver, following the driver body-template.eta: Statement (ends with ^summary) / Who-what it affects / Evidence / Toward resolution. Frontmatter: kind (use-case | pain-point | opportunity), product: '[[PR-NNNN-<slug>]]', status: open/proposed, plus the common fields.

• Driver related accepts entity-id wikilinks only ([[PR-NNNN-<slug>]], [[DR-NNNN]]). Do NOT put the narrative research doc in a driver’s related — it fails validation. Cite the research in the driver body prose instead.
• Update the Product’s “Drivers & goals” section to list every driver you created.

6. Validate

Run (no pipe — gate on the exit code):

${CLAUDE_PLUGIN_ROOT}cli/sdlc entities validate <product-path> <driver-path>...

Fix any failures and re-run until clean. The most common failure is a related wikilink that doesn’t match the entity-id pattern — see Step 5.

7. Report

Emit the terminal marker on its own line:

PRODUCT-NEW-DONE product=PR-NNNN drivers=<n> research=docs/planning/<slug>-research.md

Then tell the user: the Product path, the Driver ids, the research doc path, and a one-line next step (implement the package, or open a PR carrying the definition). On any unrecoverable failure, emit ERROR reason="..." instead.

Acceptance criteria

• Product at docs/planning/products/PR-NNNN-<slug>.md; one Driver per motivation at docs/planning/drivers/DR-NNNN.md; research writeup at docs/planning/<slug>-research.md.
• Every entity file passes sdlc entities validate with zero errors.
• The Product’s “Drivers & goals” lists every created Driver, and each Driver names the Product in product:.
• The terminal marker was emitted.

Notes

• No create op for Product/Driver. Author by hand against ${CLAUDE_PLUGIN_ROOT}lib/model/entities/{product,driver}/definition.md; validate rather than trusting a create op to shape frontmatter. This is the one place this skill diverges from the <noun>-new family.
• related scope differs by entity. Product related may link narrative docs ([[vision]], [[<slug>-research]]); Driver related is entity-ids only. The research-doc link goes in Product related and in Driver body prose.
• Research fan-out shape. One subagent per goal, returning text (not a shared file write); the skill assembles the single research doc. existing-libraries is the load-bearing goal for a build-vs-wrap decision; theory is skippable for a well-understood domain.
• Branch naming. To ship the definition as a PR, this is bulk planning-doc authoring — use a chore/<slug>-definition worktree+branch (not task/ or docs/<basename>). See ${CLAUDE_PLUGIN_ROOT}conventions/branch-naming.md.
• Keep it short. If the user packed the idea, goals, and mode into the invocation, skip the AskUserQuestion calls and go straight to the fan-out.