agentsclimarketplace
Sign in

Define product

Skill aryeko/agentic-workflow-kit/skills/define-product

Use when a user wants to define a product before technical planning — when they say "write a PRD", "spec the product", "define-product", "define the product requirements", "what are we building and why", or run /define-product. Writes a multi-file PRD under docs/prds/<slug>/ with ID acceptance criteria. Ingests rich context first, shows the flow, drafts from supplied material, asks only blocking questions, records safe assumptions, and recommends the next step: plan-delivery-track for simple features, design-technical-solution for complex technical work, UX/content pass for UI-heavy work, or validation/research for research-heavy work. Idempotent: never clobbers an existing PRD without confirmation.From its SKILL.md

Install
npx -y skills add aryeko/agentic-workflow-kit --skill define-product

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.4 KB, as published. Nobody here has run it

define-product

Author a product requirements document (PRD) before technical planning. The PRD defines the product: the what and why. It can start from notes, brainstorming output, existing docs, or session context; no upstream kit artifact is required. Technical how is decided downstream by design-technical-solution for complex technical work, or by plan-delivery-track directly for simple product work.

References (read before acting)

  • PRD contract (canonical format): ${CLAUDE_PLUGIN_ROOT}/references/prd-contract.md
  • Section templates: ${CLAUDE_PLUGIN_ROOT}/references/templates/prd/ (README.md + 01..10)
  • Worked example: ${CLAUDE_PLUGIN_ROOT}/examples/example-prd/
  • Technical solution contract: ${CLAUDE_PLUGIN_ROOT}/references/technical-solution-contract.md

Step 0 - Show the flow

Before drafting, show the assumed flow:

I will do: ingest context -> draft assumptions -> ask only blocking questions -> write PRD -> self-review -> suggest next step.

Then proceed unless a blocking decision is needed.

Step 1 — Resolve location and detect

  • Read .workflow/config.yaml if present and take paths.prdsDir (default docs/prds). define-product works even before /workflow-init — the default applies.
  • Agree a short kebab-case <slug> with the user.
  • If <prdsDir>/<slug>/ already exists, switch to resume/extend mode (see Idempotency).

Step 2 — Ingest existing material

If the user has notes, brainstorming output, existing docs, a brief, a partial PRD, design docs, session context, or relevant code, read them first. Summarize what was found and which PRD sections it pre-fills. Only interview on the gaps.

Step 3 — Draft with a context-rich fast path

When the user has provided rich context, use a context-rich fast path:

  • Draft all clearly supported PRD sections from the supplied material before asking questions.
  • Show the assumed flow and the assumptions you are carrying.
  • Ask only blocking questions: questions whose answer would materially change product scope, acceptance criteria, roles, phases, success metrics, or launch risk.
  • For safe defaults, record safe assumptions instead of interrupting.
  • Avoid section-by-section questioning unless the supplied context is thin or contradictory.
  • Add an Assumptions and blockers pass before writing: list assumptions the PRD will carry, then ask only questions that block a coherent PRD.
  • Add an Artifact boundaries pass: confirm the PRD owns what/why, while technical solution, tracker, story brief, detailed technical story spec, implementation plan, and runtime artifacts own their downstream responsibilities.

When context is thin, use the guided interview path: walk the contract's section order, asking focused questions one at a time. Confirm which optional sections apply (02-principles, 03-domain-model are skippable for small products; README, 01-context, 08-acceptance-criteria are always required). Draft each section, show it, get approval, then move on.

For 08-acceptance-criteria: group criteria by theme, give each group a short PREFIX, number criteria PREFIX-n, and tag every criterion [ship blocker] or [target]. These IDs are what plan-delivery-track maps stories to — keep each criterion observable and testable.

Step 4 — Write the PRD

Write <prdsDir>/<slug>/ from the bundled templates, filling placeholders. Conform to prd-contract.md: README index with a document map and the PRD-vs-technical-design boundary note, back-link headers and navigation footers per section, relative cross-links, and frontmatter status from the PRD vocabulary (draft | approved | shipped | archived). Do not use the story-level status vocabulary here. Record assumptions and blocking questions in 09-risks-and-open-questions.md.

Step 5 — Summarize and hand off

Print the files written and the slug, then recommend exactly one next step:

  • simple feature -> plan-delivery-track
  • technical feature -> design-technical-solution
  • UI-heavy feature -> UX/content pass or design-technical-solution, depending on scope
  • research-heavy feature -> validation/research first

Use design-technical-solution when the PRD implies new backend modules, data/query changes, AI prompts/triggers/tools, observability, migration/deploy surfaces, security boundaries, or multi-system integration. Otherwise, use plan-delivery-track to decompose the PRD into a tracker.

Do not auto-commit.

Idempotency

Re-running is safe: detect an existing PRD, report which contract sections are missing or thin, and offer to fill only those. Never overwrite an existing PRD or section without explicit user confirmation.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.