Works with the AI Agents you already use
Claude Code
Cursor
Codex CLI
Muse
Dots+22 moreClaude CodeCursorCodex CLIMuseDots
OpenClaw
Manus
Grok
Grok Bot+18 agentsWriting PRDs — Problem-First Specs, Metrics and Non-Goals
Writes PRDs, one-pagers and PR-FAQs that lead with an evidenced problem, explicit non-goals and testable criteria.
Free
Writing PRDs — Problem-First Specs, Metrics and Non-Goals
Example session with this skill installed
Write a PRD for "saved filters" on the invoice list.
Context
- We're a small-business invoicing app. The invoice list has filters (status, client, due date, amount) but they reset every visit.
- Support tagged 140 tickets "filters" last quarter, mostly "how do I keep my filters?".
- In 12 customer interviews, 9 said they rebuild the same view every morning (e.g. "overdue more than 30 days for client X").
- Analytics: 41% of invoice-list sessions apply 2 or more filters.
- Goal from leadership: cut "filters" tickets in half.
- One team (web + API), PM is Dana Ruiz, aiming for Q1 2027.
- Read your context and instructions
- Compiled the writing prds
Artifact choice: mini-PRD. This is a well-understood change for one team with low risk, so a full PRD or PR-FAQ would be more than it needs. Numbers below come only from your context; every target you didn't give is marked TBD and listed under open questions.
PRD: Saved filters on the invoice list
Owner: Dana Ruiz ·
Status: Draft ·
Target: Q1 2027 ·
Links: design: TBD · engineering design doc: TBD · support tag: "filters"
TL;DR
Let users save a named filter combination on the invoice list and return to it in one click. The goal is to halve "filters" support tickets, starting from 140 last quarter.
Problem
Users who triage invoices daily rebuild the same filter combination on every visit because filters reset.
Evidence:
- 140 support tickets tagged "filters" last quarter, mostly asking how to keep filters.
- 9 of 12 interviewed customers rebuild the same view every morning (e.g. "overdue > 30 days for client X").
- 41% of invoice-list sessions apply 2+ filters, so repeated multi-filter use is common.
Goals
- Users can get back to a recurring view without rebuilding it.
- Cut "filters" support tickets by half.
Non-goals
Sharing saved filters with teammates. Single-user first. Sharing raises permission questions this PRD does not answer.
- Filters on other lists (clients, payments). Invoice list only.
- New filter fields or operators. Only existing filters can be saved.
- Scheduled reports or alerts from a saved filter.
Remembering the last-used filter automatically. This PRD covers explicit saves only. Auto-restore is a separate decision.
Target users
Account owners and bookkeepers who open the invoice list at least daily to chase overdue invoices.
User stories
- As a bookkeeper, I want to save "overdue > 30 days, client X" under a name, so I can open it each morning in one click.
- As a user with several routines, I want to rename and delete saved filters, so my list stays relevant.
Requirements
Functional
- R1. Save the current filter combination with a user-given name.
- R2. List the user's saved filters on the invoice list; selecting one applies all of its filters.
- R3. Rename and delete a saved filter.
- R4. Saved filters are private to the user who created them.
Non-functional
- R5. Applying a saved filter returns the same results as applying the same filters manually.
- R6. Controls are keyboard-operable and labeled for screen readers.
- R7. Maximum saved filters per user:
TBD(see Q2).
Acceptance criteria
AC1 (R1): Given a user with status=Overdue and client=X applied, when they save it as "Morning chase", then "Morning chase" appears in their saved filters.
AC2 (R2, R5): Given a saved filter "Morning chase", when the user selects it on a fresh visit, then the list shows exactly the invoices matching status=Overdue and client=X.
AC3 (R1): Given a user saving a filter, when the name is empty, then the save is rejected with a message asking for a name.
AC4 (R1): Given a saved filter named "Morning chase", when the user saves another with the same name, then they are asked to rename or overwrite.
AC5 (R3): Given a saved filter, when the user deletes it, then it no longer appears and the current results are unchanged.
AC6 (R4): Given user A's saved filter, when user B in the same account opens the invoice list, then A's filter is not listed.
AC7 (R2): Given a saved filter that references a deleted client, when the user selects it, then the remaining filters apply and the user sees that the client filter was dropped.
AC8 (R7): Given a user at the saved-filter limit, when they try to save another, then they are told the limit and how to delete one.
Success metrics
| Metric | Type | Baseline | Target | Timeframe |
|---|---|---|---|---|
| "filters"-tagged support tickets per quarter | Lagging | 140 | ≤ 70 | First full quarter after GA |
| Share of daily invoice-list users with ≥ 1 saved filter | Leading | 0 (new) | TBD | 30 days after GA |
| Share of multi-filter sessions started from a saved filter | Leading | 0 (new) | TBD | 60 days after GA |
| Invoice-list load time (p95) | Guardrail | TBD (measure before build) | No regression vs. baseline | Ongoing from beta |
Scope
Now: R1–R7 on web. Deferred: saved filters in the mobile app; a default saved filter that opens automatically.
Dependencies and assumptions
- The API can store per-user preferences. Unvalidated. Confirm with engineering (Q3).
- Ticket tagging stays consistent before and after launch, so the ticket metric is comparable. Unvalidated. Confirm with Support.
- The 12 interviewees represent daily users. Partly validated: consistent with the 41% multi-filter sessions.
Risks
Low discovery: users don't notice the save option. Mitigation: show the save prompt after a user applies 2+ filters. Trigger: leading metric below target at 30 days.
- Stale filters after clients are deleted or renamed. Mitigation: AC7 behavior.
Open questions
| # | Question | Owner | Resolve by |
|---|---|---|---|
| Q1 | Targets for the two leading metrics | Dana Ruiz | 2026-10-22 |
| Q2 | Saved-filter limit per user | Dana Ruiz + eng lead | 2026-10-22 |
| Q3 | Where per-user preferences are stored (design doc) | Eng lead | 2026-10-29 |
| Q4 | Baseline p95 load time for the invoice list | Eng lead | 2026-10-29 |
Rollout
Feature-flagged beta for interviewed customers who opt in, then GA. "Launched" means GA to all web users with AC1–AC8 passing.
Anti-pattern lint: problem cited with evidence before any solution ✔ · non-goals specific ✔ · every metric has a target and timeframe, or a TBD with an owner and date ✔ · acceptance and success in separate sections ✔ · no architecture or schema in the PRD ✔.
Next steps
- Dana resolves Q1–Q2. Replace each
TBDwith a real number before review. - Engineering writes the design doc (storage, API) and links it in the header.
- Turn AC1–AC8 into test cases (
developing-features).
Connects securely to your tools. The creator never sees your data.
About this skill
Many PRDs fail in predictable ways. They describe a solution before anyone has shown the problem exists. Their metrics say "increase engagement" with no number or date. They have no non-goals, so scope grows during review. And they mix "we shipped it" with "it worked". This skill makes the agent write product requirements that avoid those failures.
Workflow:
- Decide whether and what to write. A quick opportunity check using Marty Cagan's 10 questions. For unproven strategic bets, it writes an Amazon PR-FAQ first.
- Pick the artifact weight. One-pager or mini-PRD for small, one-team changes; full PRD for new or cross-functional products; PR-FAQ when the value is unvalidated. The engineering design doc (the "how") stays separate.
- Problem before solution. Problem statement, evidence and target users come before any solution text.
- Metrics and acceptance criteria. North Star, leading and lagging metrics, each with a target and timeframe, plus guardrails. Acceptance criteria in Given/When/Then, kept in a separate section from success criteria.
- Lint against anti-patterns before sharing: solution-first writing, vanity metrics, missing non-goals, untestable requirements, smuggled implementation detail.
Reference files:
prd-structure.md: the 14-section PRD skeleton with one line of guidance per section, plus the artifact ladder.metrics-and-acceptance.md: North Star and guardrail metrics, acceptance vs. success criteria, and RICE, MoSCoW, Kano and Impact/Effort.pr-faq.md: the Working Backwards press release and internal/external FAQ template.shared/.../communication.md: answer-first structure (Minto Pyramid, SCQA), so the PRD opens with the recommendation.
It triggers on "write a PRD", "product spec", "one-pager", "PR-FAQ", "define requirements", "scope this feature", or a rough feature idea that needs a problem framed.
What sets it apart: it won't invent numbers. Missing targets are marked TBD and flagged with an owner. It also never commits anything.
Free and MIT-licensed, part of the claude-skills-czl collection.
Source on GitHub: this skill · full repository
How to use
Skills on Agensi run inside your AI agent. Copy the prompt, paste it into your agent, and it connects to Agensi and installs this skill for you. If a payment is needed, your agent shows it to you first.
Reviews
No reviews yet
Be one of the first to try it. Every listed skill passes our trust checks below.
Security scanned
Passed our 8-point scan before listing
Fresh listing
Recently published to Agensi
Free forever
No account required to browse
Trust & safety
Security scanned
Verified clean 11 days ago
- Free to download with an account