Codebase-Grounded PRDs and Linear Handoffs
Turn rough feature requests into codebase-grounded PRDs with testable requirements and optional Linear projects and issues.
Before & after
Same prompt, same agent — the only difference is the skill.
I can definitely help you write a PRD from a feature request. That's a useful way to clarify scope and get alignment across your team. To make a good PRD, I'll need to understand the request in detail. What's the feature trying to solve? Who asked for it, and what's the business context? Are there any competitive products doing something similar? What does success look like — what metric or outcome should this drive? Also, do you know what the technical constraints are, or should I research the codebase to understand what's feasible? PRDs usually include things like user flows, wireframes, acceptance criteria, dependencies, and timelines. How much of that detail do you have already? Should I also create Linear tickets for the dev team, or just the PRD document? And what's your timeline — when would you want this to start building?
PRODUCT REQUIREMENTS DOCUMENT - API RATE LIMITING FEATURE OVERVIEW Title: Implement per-user API rate limiting Priority: P1 (blocks 3 enterprise deals) OwnedBy: Platform team DueDate: September 15, 2026 BACKGROUND Enterprise customers report API overages (4 per week avg). Current system has no per-user limits. Competitors Stripe and Twilio enforce rate limits at signup. Without this, we risk SLA breaches and support escalations. GOAL Enable fine-grained rate limiting: different tiers get different limits. Free: 100 req/min. Pro: 1000 req/min. Enterprise: custom. Block requests gracefully with 429 status code. USER STORY As an API consumer, I want to know my rate limit status (headers: X-RateLimit-Remaining) so I can build resilient applications. ACCEPTANCE CRITERIA 1. Rate limits enforced per API key (not IP) 2. Limits reset hourly 3. Responses include X-RateLimit-Limit, X-RateLimit-Remaining headers 4. Dashboard shows current usage + historical trend 5. Email alert when usage hits 80% threshold 6. 48h grace period before hard enforcement (soft warning first) TECHNICAL SCOPE Implementation: middleware in API layer (Redis counter). Database: track per-key limits + overages. Metrics: Prometheus gauge for usage by tier. DEPENDENCIES • Redis cluster ops (existing) • Dashboard UI team (2 days) • Billing team (true-up logic) NON-SCOPE • Burst allowance (future) • Cost reporting per endpoint RISK: Enterprise customers may hit limits unexpectedly. MITIGATION: 48h soft warning + email.
About this skill
Your feature request is buried in a transcript, and the first PRD reads as if the product will be built from scratch. Turn that request into a scoped specification that identifies existing systems, separates confirmed needs from proposed decisions, and gives engineering testable requirements.
What it does
- Extracts the user problem, requested behavior, constraints, and conflicting decisions from transcripts, threads, or plain-language descriptions.
- Traces the relevant code path through interfaces, handlers, services, persistence, permissions, and tests when repository access is available.
- Distinguishes observed implementation facts from assumptions and unresolved technical questions.
- Defines a bounded first release with explicit non-goals, acceptance criteria, failure behavior, and launch dependencies.
- Maps requirements into independently verifiable implementation slices with dependency ordering.
- Optionally creates the corresponding Linear project and issues when requested and connected, checking for existing work first.
What you get
A reviewable PRD with evidence-backed technical scope, numbered requirements, acceptance criteria, success measures, and decision blockers. When requested, you also get a Linear handoff with requirement mappings and verified links to created work.
Best for
Product managers, founders, and engineering leads turning rough feature requests into implementable changes to an existing product.
SKILL.md preview
---
name: codebase-grounded-prds-and-linear-handoffs
description: >-
Turn feature transcripts, threads, and descriptions into technically grounded PRDs by tracing relevant code paths, separating evidence from assumptions, and defining testable implementation boundaries. Optionally create matching Linear projects and issues. Use when the user says "turn this transcript into a PRD", "scope this feature against our codebase", "write requirements from this thread", "our PRDs keep missing existing behavior", "engineering says this spec is too vague", "what systems would this feature affect?", or "create Linear issues from this feature request".
---
# Codebase-Grounded PRDs and Linear Handoffs
… (sign up to view the full skill)More business & ops skills
View all Business & Ops skills →Product Practice Diagnostic
Trace a product-team symptom (unused features, roadmap churn, priority fights) to the broken stage of the loop and fix one thing first.
Feature Launch Go-to-Market Plan
Plan one feature launch: tier, plan access, audience messages, readiness gates for support, sales, billing, and docs, and success metrics.
Pricing Tier and Packaging Diagnosis
Finds why your pricing tiers underperform and redesigns value metric, fences, price gaps, and upgrade triggers with a migration plan.
Product Specs, Roadmaps, and Research Decisions
Turn customer evidence into testable PRDs, dependency-aware roadmaps, and stakeholder updates with clear decisions and tradeoffs.