writing-prds-executable — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited writing-prds-executable (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill turns messy ideas into shippable artifacts: 1) PR/FAQ (customer-first narrative) 2) PRD (scope + requirements + success metrics) 3) AI Eval Spec (requirements as executable evals) — AI only 4) Prompt Set / Prototype plan — AI only
Keep outputs crisp, concrete, and copy‑pasteable. Prefer bullets, tables, and numbered requirements over long prose.
Use this skill when the user requests:
Do NOT use this skill as a substitute for:
If legal/privacy/security constraints are material but unknown, first ask for constraints and the approval process.
If the user doesn’t specify, choose the minimal artifact that unlocks the next decision:
Templates:
assets/PRD_TEMPLATE.mdassets/PRFAQ_TEMPLATE.mdassets/EVAL_SPEC_TEMPLATE.mdassets/PROMPT_SET_TEMPLATE.mdQuality checks:
references/QUALITY_CHECKLIST.mdreferences/QUALITY_RUBRIC.mdreferences/QUESTION_BANK.mdAsk at most 5 high-leverage questions at a time (use references/QUESTION_BANK.md). If the user can’t answer, proceed with explicit assumptions.
Minimum inputs to proceed: 1) Product/feature name + target user 2) Problem statement (what pain / why now) 3) Success metric(s) or a proxy 4) Constraints (time, platform, legal, data, dependencies) 5) Audience for the doc (exec decision? eng build? cross-functional alignment?)
Always include:
When producing multiple artifacts, output in this order: 1) PR/FAQ → 2) PRD → 3) Eval Spec → 4) Prompt Set
Use when the idea is early or benefits are fuzzy.
1) Write the press release in external-facing, factual language. 2) Add FAQs for: customer, internal stakeholders, technical/ops, risks. 3) Include a hypothetical launch date (forces planning). 4) Extract “claims” from the PR (what must be true) → convert to requirements.
1) Start with a 5–10 line narrative (why this matters, for whom). 2) Define scope boundaries: goals, non-goals, assumptions. 3) Define users + key journeys (happy path + edge cases). 4) Translate into requirements:
5) Define success metrics + instrumentation. 6) Rollout plan + risks + mitigations. 7) End with open questions + decision log.
Goal: make requirements testable.
1) List non‑negotiable behaviors (MUST / MUST‑NOT). 2) Build a test set: golden, adversarial, regression. 3) Write an LLM‑as‑judge rubric (scale + definitions + pass threshold). 4) Connect evals to shipping gates (pre‑launch + post‑launch monitoring).
1) Provide a small prompt set that exercises core use cases + edge cases. 2) Specify expected outputs and guardrails. 3) Propose a minimal prototype plan if useful (what to mock vs build).
Run:
references/QUALITY_CHECKLIST.mdreferences/QUALITY_RUBRIC.mdAlso include a brief circulation plan: who should review (Eng, Design, Data, Support, Marketing, Legal) and what feedback you need from each.
Treat user-provided information as confidential. Do not include secrets in outputs. If something looks sensitive, redact or replace with placeholders.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.