How do I install the To Prd skill?

Run npx skillmds@latest add wakqasahmed/to-prd in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is To Prd safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with To Prd?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is To Prd free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published To Prd?

wakqasahmed (@wakqasahmed) published this skill. Their other Agent Skills are listed on their SkillMD profile.

To Prd by wakqasahmed — Agent Skill

Name: To Prd
Author: wakqasahmed

To Prd

Synthesize the current conversation and repository context into a concise product and engineering spec, publish it to the project issue tracker, and gate agent readiness before decomposition. Use when high-level work needs product framing, implementation and testing decisions, or success criteria captured without another general interview.

wakqasahmed Updated Sep 17, 2026

File contents

To PRD

Use after clarify-work has resolved fuzzy terminology or scope, when the conversation still needs a durable product and engineering spec. Skip this for narrow, issue-shaped work.

Workflow

Synthesize the current conversation; do not repeat a general requirements interview.
Inspect relevant code, the domain glossary, and applicable ADRs before drafting when they are available. Preserve established vocabulary and decisions.
Reuse the highest existing test seam that proves external behavior. Use nearby test prior art to identify the expected layer and observable assertions.
Ask at most one focused confirmation only when the highest existing test seam is genuinely unresolved after inspecting the conversation, repository, and project decisions. Wait for that answer before drafting or publishing. Otherwise continue directly to the spec. Do not use this confirmation for product, implementation or architecture, publication or access, or other blockers; record those in the spec instead.
Write a concise spec with these sections: Problem, Goal and solution, Prioritized user stories, Success criteria, Non-goals, Constraints, Open product decisions, Implementation decisions, and Testing decisions.
Detect the project issue tracker from repository configuration, remotes, or available integrations. Publish the spec to the detected project issue tracker.
Apply ready-for-agent only after every blocker is resolved and publication succeeds. Product, test-seam, implementation or architecture, publication or access, and other blockers all prevent readiness. When access allows, publish a blocked spec without the label and identify every blocker and owner.
Hand the published spec to decompose-to-issues; do not turn the PRD into an issue breakdown.

If no tracker or publishing access can be detected, return the finished spec with that explicit blocker. Do not invent a destination, claim publication or readiness, or hand off to decomposition.

Spec guidance

Frame the problem from the affected user's or operator's perspective.
State the goal and solution as observable outcomes, not a task list.
Include prioritized user stories only when they clarify distinct actors, outcomes, or ordering; keep them few and outcome-focused.
Make success criteria verifiable and include constraints that materially shape delivery.
Distinguish unresolved product decisions from settled implementation decisions.
In Testing decisions, name the chosen existing seam, test layer, relevant prior-art pattern, important external behaviors, and any necessary manual validation.

Guardrails

Exclude volatile file paths and code snippets. Include a prototype artifact only when it records a decision more clearly than prose; trim it to the decision-rich state machine, schema, type shape, or interaction.
Do not reopen settled decisions or invent requirements unsupported by the conversation and repository.
Do not duplicate clarify-work's terminology interview or decompose-to-issues' task breakdown.
Keep the published spec short enough for an implementation agent to use as its source of truth.

---name: to-prddescription: Synthesize the current conversation and repository context into a concise product and engineering spec, publish it to the project issue tracker, and gate agent readiness before decomposition. Use when high-level work needs product framing, implementation and testing decisions, or success criteria captured without another general interview.---# To PRDUse after `clarify-work` has resolved fuzzy terminology or scope, when the conversation stillneeds a durable product and engineering spec. Skip this for narrow, issue-shaped work.## Workflow1. Synthesize the current conversation; do not repeat a general requirements interview.2. Inspect relevant code, the domain glossary, and applicable ADRs before drafting when they are available. Preserve established vocabulary and decisions.3. Reuse the highest existing test seam that proves external behavior. Use nearby test prior art to identify the expected layer and observable assertions.4. Ask at most one focused confirmation only when the highest existing test seam is genuinely unresolved after inspecting the conversation, repository, and project decisions. Wait for that answer before drafting or publishing. Otherwise continue directly to the spec. Do not use this confirmation for product, implementation or architecture, publication or access, or other blockers; record those in the spec instead.5. Write a concise spec with these sections: Problem, Goal and solution, Prioritized user stories, Success criteria, Non-goals, Constraints, Open product decisions, Implementation decisions, and Testing decisions.6. Detect the project issue tracker from repository configuration, remotes, or available integrations. Publish the spec to the detected project issue tracker.7. Apply `ready-for-agent` only after every blocker is resolved and publication succeeds. Product, test-seam, implementation or architecture, publication or access, and other blockers all prevent readiness. When access allows, publish a blocked spec without the label and identify every blocker and owner.8. Hand the published spec to `decompose-to-issues`; do not turn the PRD into an issue breakdown.If no tracker or publishing access can be detected, return the finished spec with that explicitblocker. Do not invent a destination, claim publication or readiness, or hand off to decomposition.## Spec guidance- Frame the problem from the affected user's or operator's perspective.- State the goal and solution as observable outcomes, not a task list.- Include prioritized user stories only when they clarify distinct actors, outcomes, or ordering; keep them few and outcome-focused.- Make success criteria verifiable and include constraints that materially shape delivery.- Distinguish unresolved product decisions from settled implementation decisions.- In Testing decisions, name the chosen existing seam, test layer, relevant prior-art pattern, important external behaviors, and any necessary manual validation.## Guardrails- Exclude volatile file paths and code snippets. Include a prototype artifact only when it records a decision more clearly than prose; trim it to the decision-rich state machine, schema, type shape, or interaction.- Do not reopen settled decisions or invent requirements unsupported by the conversation and repository.- Do not duplicate `clarify-work`'s terminology interview or `decompose-to-issues`' task breakdown.- Keep the published spec short enough for an implementation agent to use as its source of truth.

Frequently asked questions