Prd

Skill tmj-90/gaffer/runner/skills/prd

Self-hosted AI coding factory — sandboxed agents deliver tickets to merged code, gated by a human in a dashboard. Local-first, cost-transparent, human-in-the-loop.

Install

npx -y skills add tmj-90/gaffer --skill prd

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

0 stars0 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.

What its author says it does

Copied from the file, not written here

Use when writing a Product Requirements Document — to define what to build and why, with evidence-gated drafting. Refuses to draft without a real problem, user, and metric. Triggers on "write a PRD", "product requirements", "spec for this feature", "what should we build for X", or "requirements document".

SKILL.md

3.5 KB, as published. Nobody here has run it

Write evidence-gated product requirements

A PRD without a real problem, a specific user, and a measurable metric is a feature wish. Refuse to draft until those three are answered.

Forcing questions (walk one at a time — do not batch)

Problem — What user problem does this solve, and how do you know it exists? (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 not a user.)
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 enough?
Non-goals — What adjacent asks are explicitly out of scope for v1?

Drafting gate

Refuse to draft if Q1 (problem), Q2 (user), or Q3 (metric) is unknown, circular, or "we'll figure it out."

Instead: output the open questions and the cheapest way to answer each (5 customer interviews, a funnel query, a fake-door test, a 1-day prototype). A week of discovery is cheaper than shipping the wrong feature.

Required sections (every PRD must have all of these)

Problem statement — with the evidence from Q1.
Target user and segment — from Q2; who is explicitly NOT the target.
Goals and explicit non-goals — from Q5.
User stories with acceptance criteria — "As a [user], I want [action] so that [outcome]. Done when [testable condition]."
Success metric + threshold + measurement source — from Q3; how and when you'll measure.
Open questions — unresolved assumptions that need an answer before or during build.
Out of scope — explicit list; protects from scope creep in delivery.

Acceptance criteria format

Given [context / precondition]
When [action]
Then [observable outcome]

Every user story has at least one AC. ACs are testable — a QA engineer can verify them without asking questions.

Steps

Ask the forcing questions one at a time. Wait for answers. Don't proceed if answers to Q1–3 are vague.
Apply the drafting gate. If blocked, output the open questions + cheapest resolution path.
Draft the PRD in the required-sections format.
Emit the completion checklist at the end — mark each section done or flag what's missing.
Review with stakeholders before handing to engineering — especially the success metric.

Review checklist

Problem has evidence — not intuition or executive preference.
User is specific — a segment and role, not "users" or "everyone".
Metric is single and measurable — not "improve UX" or "users will like it".
Acceptance criteria are testable — a QA engineer can verify without asking the PM.
Non-goals are explicit — not implied.
Completion checklist emitted — all sections accounted for.

Rules

"The CEO wants it" is not a problem statement — push back and ask for user evidence.
One success metric per PRD. Multiple metrics split attention and make post-launch evaluation ambiguous.
Non-goals protect the team — be explicit and specific.