mirror of https://github.com/alirezarezvani/claude-skills.git synced 2026-08-28 04:24:58 +00:00

feat(agents,commands): trigger descriptions + gated workflow upgrades

- 17 root agents gained 'Use when...' trigger descriptions (<=1024 chars);
  cs-product-analyst placeholder body rewritten around real tools
- 21 commands had invalid YAML frontmatter fixed (unquoted inner colons);
  14 commands gained argument-hint; 6 duplicate commands marked with
  canonical-copy sync comments
- /prd: forcing questions + refuse-to-draft gate + required-sections checklist
- /sprint-plan: capacity math + carry-over check + definition-of-ready gate
- /tdd: rebuilt around the real tdd-guide assets with smoke-tested snippets
- cs-senior-engineer repointed from retired release-manager to
  changelog-generator

https://claude.ai/code/session_019AJddAL1NADWMXsy1qNPQF

2026-06-11 03:58:42 +00:00

2.9 KiB

Raw Permalink Blame History

name	description	argument-hint
prd	Gated PRD generation — interrogates problem, user, and metric before drafting; refuses to draft on unknowns. Usage: /prd <feature-or-problem>	<feature-or-problem>

/prd

Generate a concise, evidence-gated product requirements document for $ARGUMENTS.

Usage

/prd <feature-or-problem>

$ARGUMENTS is the feature, initiative, or problem statement. If empty, ask for it before doing anything else.

Phase 1 — Forcing Questions (before any drafting)

Walk these one at a time. Do not batch them. Each answer feeds a required PRD section.

Problem — What user problem does this solve, and how do you know it exists? (Evidence: support tickets, interview quotes, funnel data — "the CEO wants it" is not evidence.)
User — Who specifically has this problem? (Segment, role, frequency of pain. "Everyone" is a non-answer.)
Metric — What single number moves if this works, by how much, measured where?
Alternatives — What do these users do today instead? Why is that not good enough?
Non-goals — What adjacent asks are explicitly out of scope for v1?

Drafting Gate (hard refusal)

Refuse to draft the PRD if the answer to question 1 (problem), 2 (user), or 3 (metric) is unknown, circular, or "we'll figure it out later." Instead, output the open questions and the cheapest way to answer each (e.g., 5 customer interviews, a funnel query, a fake-door test). A PRD without a problem, a user, and a metric is a feature wish, not a requirements document.

Phase 2 — Draft (required-sections checklist)

Every PRD must contain all of these sections — emit the checklist at the end and mark each:

Problem statement (with the evidence from Q1)
Target user and segment (from Q2)
Goals and explicit non-goals (from Q5)
User stories with acceptance criteria
Success metric + threshold + measurement source (from Q3)
Alternatives considered / "do nothing" baseline (from Q4)
Scope, dependencies, and timeline assumptions
Open questions and risks

Keep it to ~2 pages. Use the repo template as the skeleton.

Phase 3 — Prioritization hook (optional)

If the user has multiple candidate features, offer to RICE-score them before committing the PRD:

python3 product-team/skills/product-manager-toolkit/scripts/rice_prioritizer.py features.csv --capacity 20

Repo Assets (verified paths)

Skill: product-team/skills/product-manager-toolkit/SKILL.md
PRD template: product-team/skills/product-manager-toolkit/assets/prd_template.md
PRD patterns reference: product-team/skills/product-manager-toolkit/references/prd_templates.md
RICE tool: product-team/skills/product-manager-toolkit/scripts/rice_prioritizer.py

/code-to-prd — reverse-engineer a PRD from an existing codebase
/rice — standalone RICE prioritization

2.9 KiB Raw Permalink Blame History