PLAID in Practice - I Ran a Real Product Idea Through This Idea-to-Launch Skill

A couple of weeks ago I wrote about Addy Osmani’s agent-skills library and how Anthropic’s progressive-disclosure skill format is quietly reshaping how I do serious agentic work. Osmani’s skills are generic engineering discipline - the spec → plan → build → test → review → ship loop that every codebase needs. They assume you already know what you’re building.

PLAID (Product Led AI Development), from buildgreatproducts, attacks the other half of the problem. It is the skill that runs before you ever type /spec. It takes a founder from “I have a vague idea” to product vision + PRD + build roadmap + go-to-market plan, as a single orchestrated conversation. Where Osmani’s skills are a horizontal SDLC library, PLAID is a vertical pipeline aimed at one specific user: the solo or small-team founder who wants to ship.

I spent an evening running PLAID end-to-end on a throwaway pilot product idea. This is what it actually produced, what’s genuinely good about it, and where the cracks show.

What PLAID Is, Briefly

PLAID is a single Claude Code skill with three capabilities:

Capability	What it does	Output
Plan	Vision intake conversation + document generation	`vision.json`, `product-vision.md`, `prd.md`, `product-roadmap.md`
Launch	Go-to-market plan from the vision	`gtm.md`
Build	Executes the roadmap phase by phase, commits after each	Working code, phase-by-phase git history

The whole skill is around 2,800 lines of markdown across SKILL.md plus ten reference files (generation prompts, schema, intake guide, tech stack comparison). There is one Node.js validator with zero dependencies. That’s it. No agent framework, no state machine, no UI - it’s a set of well-written instructions the model follows.

Installation is a one-liner:

npx skills add BuildGreatProducts/plaid

Or manually, add the path to SKILL.md to your .claude/settings.json:

{
  "skills": ["/absolute/path/to/plaid/SKILL.md"]
}

Then in a Claude Code session, type PLAID or plan a product and the skill loads.

The Test Run

I needed a test idea realistic enough that I could judge the output quality. I picked something from my own backlog:

Currency Coach - a mobile app for IFR-rated pilots that ingests their existing ForeFlight or Garmin Pilot logbook, models the decay of each individual flying skill (ILS, LPV, circling, night, crosswind, hand-flown IMC), and delivers a pre-flight verdict for a specific planned trip. Not “are you legal?” but “are you sharp enough for this Saturday, and if not, what single 45-minute session would fix it?”

I am the target user, so I can tell the difference between a PRD that understands IFR flying and one that produces aviation cosplay. Good testbed.

I ran PLAID’s vision intake, filled out all eight sections (founder, purpose, product, audience, business, feeling, tech stack, tooling), saved the answers to vision.json, ran the validator (which passed on the first try, a small detail that mattered), and then generated the three documents.

The Output

Three files in docs/:

product-vision.md - 49 KB, ~8,000 words. Vision, mission, core values, strategic pillars, primary + secondary personas, JTBD, pain points, competitive landscape, MVP scope with explicit out-of-scope, brand voice with DO/DON’T examples, design tokens with hex values, typography specs, spacing scale.
prd.md - 72 KB, ~9,200 words. Stack table, Mermaid architecture diagram, full Convex schema with 12 tables, API specification, 24 functional requirements with acceptance criteria, screen-by-screen UI with empty/loading/error/populated states, Tailwind config with design tokens, auth implementation, subscription integration, edge cases, open questions.
product-roadmap.md - 38 KB, ~5,200 words. 72 tasks across 5 phases, every task with file paths, a phase prompt you can paste straight into Claude Code, and a “reference sections to load” block so the agent doesn’t have to load the whole PRD into context per phase.

This is not a stub. It is the shape of a real product spec, produced in under 20 minutes of model time from a vision.json.

What Genuinely Works

1. The Vision Intake Is The Product

The intake guide (references/INTAKE-GUIDE.md) is the best thing in the repo. Eight sections, around forty questions, each with:

The question text plus a one-sentence rationale for why it matters
A prompt for generating three substantively different suggestions based on what the founder has said so far
An explicit rule that the first two questions (name, expertise) get no suggestions (direct input only)
A rule that suggestions must get better over time, not just rephrase earlier content

The tech stack section is especially good. It uses a comparison table format that lays out Next.js vs Remix vs SvelteKit with honest pros/cons, and then makes a specific recommendation tied to the founder’s prior answers. The default recommendations (Next.js for web, Expo for mobile, Convex backend, Clerk or Convex Auth, Polar or RevenueCat) are opinionated but well-justified. You can override any of them, but the defaults are good enough that most solo founders should just take them.

This is where PLAID’s founder-specific scope pays off. A generic spec skill can’t ask “what’s your 90-day revenue target” or “who are you uniquely positioned to help” because those questions don’t fit every user. PLAID narrows hard on the founder archetype and earns the right to ask them.

2. The Three-Doc Cascade

PLAID is strict that the docs are generated in order - vision first, then PRD reading the vision, then roadmap reading both. This is obvious in hindsight but rare in practice. Most doc-generation tools treat each artifact as independent. PLAID’s cascade means that tokens set early (design tokens, skill names, magic moment) propagate consistently all the way through to task-level roadmap notes.

In my run, the color tokens chosen in the vision (#0A0C10 for ink, an amber warning, a muted sage for “sharp”) appeared verbatim in the PRD’s Tailwind config and then again in the roadmap’s Phase 0 tasks (“copy the full Tailwind config from PRD § 9”). I did zero reconciliation work. That’s the kind of compounding consistency you normally only get from a human who wrote all three documents in one sitting.

3. The Task Format

Every task in the roadmap uses this exact shape:

- [ ] **TASK-023** - Implement the decay-model unit tests.
  Files: `convex/decayModel.ts`, `convex/decayModel.test.ts`
  Notes: Test half-life curves for each skill type. Seed with 50 flights
  from fixtures/sample-logbook.json. Expected accuracy >= 90% vs labels.

Plus, every phase has a “Reference sections to read before starting” block pointing to specific sections of the vision and PRD. This matters because it means the build agent doesn’t have to load 72 KB of PRD into context for every task. It loads just the relevant sections. That’s progressive disclosure applied inside a single project - exactly the right move.

4. The Validator

node scripts/validate-vision.js --migrate is 340 lines of Node.js with zero external dependencies. It checks the JSON schema, applies migrations if you have an older vision.json from a prior PLAID version, and reports warnings without blocking. It is a minor touch and it completely changes the vibe. Most “AI skills” don’t ship a validator. Shipping one signals that the authors think about this as engineering, not prompting.

5. Resumability

PLAID’s capability files all check the project state on entry: does vision.json exist? Are the docs present? Is the roadmap partially done? Then it picks up from where things left off. You can close a session mid-intake and come back in a week, and the skill will tell you exactly where you paused. This pairs naturally with the skills framework’s “skills are workflows, not single-shot prompts” philosophy.

Where The Cracks Show

I want to be honest here because the reason I test these things is to know when to trust them.

1. Vision and PRD Overlap More Than They Should

The product-vision.md section on Product Strategy includes MVP scope and out-of-scope. The prd.md Overview and “Out of Scope” sections cover the same ground. The generation guides tell the model “don’t repeat information between sections” and then give section requirements that force repetition. I ended up with three slightly different framings of the same scope list in three different places. A cleaner structure would put scope once (in the vision) and have the PRD cross-reference it.

2. The PRD Template Biases Toward REST

The PRD generation guide includes REST endpoint examples (method, path, request body, response body). For a Convex app - which PLAID itself recommends as the default backend - there are no REST endpoints, just typed queries and mutations. The model correctly ignored the REST template and produced Convex RPC signatures, but it had to fight the template to do so. A stack-aware template (one for REST, one for Convex, one for tRPC) would eliminate that friction. Worth a PR.

3. Roadmap Task Granularity Is Aspirational

PLAID prescribes tasks sized for 15-45 minutes of agent work. Some tasks that came out of my test run are obviously multi-session - “TASK-021: Implement the decay-model classifier with >= 90% accuracy on a 50-flight labeled set.” That is a research problem, not a 30-minute task. The rule blocks the model from saying so. You end up with tasks that are nominally atomic but practically multi-day, which creates a false sense of scope. I’d rather the skill say “some tasks are classified as Research, here’s how to handle them” than force everything into the same granularity.

4. Opinionated Defaults Cut Both Ways

PLAID is strongly opinionated: Convex, Clerk or Convex Auth, Polar for web payments, RevenueCat for mobile. If you agree, you save hours - the PRD’s auth and payments sections come out implementation-ready with specific Convex + RevenueCat code patterns. If you disagree, the skill fights you. The tech stack comparison file honestly lists alternatives (Supabase, Firebase, Stripe, etc.) but the generation guides implicitly assume the defaults. Founders on a Stripe + Postgres + Supabase stack will get useful output but less polish.

This is the right trade for PLAID’s target audience (solo founders who want to ship) and wrong for mine on some projects. Know which side you’re on before you commit.

5. No Tests in the PRD or Roadmap

This is the one that will keep me from using PLAID as-is on anything serious. The PRD has a “Non-Functional Requirements” section that mentions quality thresholds, but the roadmap’s 72 tasks do not include a single task for writing unit tests or integration tests. Testing is absent from the phase-prompt scaffolding. This is exactly what Osmani’s test-driven-development skill exists to fix.

The honest solution is to layer: use PLAID to generate the vision + PRD + roadmap, then have Osmani’s skills (or equivalent) run on top for test-first implementation, code review, and shipping. That’s how I’ll use it going forward.

How PLAID Fits Next to Osmani’s Agent-Skills and Spec Kit

The three are complementary, not competing:

Dimension	PLAID	Agent-Skills (Osmani)	Spec Kit (GitHub)
Scope	Founder vertical: idea → launch	Generic SDLC horizontal library	Spec-Driven Development lifecycle
When to reach for it	New product, no docs yet	Any codebase, any phase	Starting a greenfield project
Primary unit	3-doc cascade (vision/PRD/roadmap)	20+ phase-specific skills	Slash-command scaffolding
Opinionated stack?	Yes - Convex/Clerk/Polar/RevenueCat defaults	No	No
Testing built in?	Missing	Core skill	Implicit in gated flow
Anti-rationalization	Implicit	Explicit section per skill	Implicit in phase gates

My emerging workflow for a greenfield product:

PLAID Plan to generate vision.json, product-vision.md, prd.md, product-roadmap.md. About an hour including the intake conversation. I edit the docs by hand for anything PLAID got wrong or missed.
Trim and annotate the roadmap tasks - flag the multi-session ones, add a handful of explicit test tasks, adjust granularity.
Osmani’s /spec, /plan, /build, /test, /review, /ship for execution. These skills live on top of PLAID’s artifacts, not underneath them.
PLAID Launch for the GTM plan when I’m ready to announce.
Use PLAID Build only on the truly trivial scaffold phases (Phase 0 setup, plumbing). For anything non-trivial I prefer Osmani’s skills because of the testing discipline.

The Takeaway

PLAID is the first skill I’ve seen that treats product definition as a first-class workflow, not a side effect of prompting. The intake guide alone is a cleaner, more opinionated version of what most founders try (and fail) to extract from ChatGPT over a dozen messy sessions. The three-doc cascade is a real innovation in enforced consistency. The validator is a quiet signal that the authors care about the engineering of the thing.

It is also narrower than Osmani’s library and missing the testing layer that turns a spec into a trustworthy product. Don’t use it as a complete agentic stack. Use it as the front end of one.

If you are a founder staring at an empty docs/ directory, run PLAID tonight. If you are an engineer with a codebase already in flight, stick with Osmani. If you are starting a greenfield product and want to do it properly, use both.

References

buildgreatproducts/plaid - The PLAID skill repository
My earlier piece on the skills framework - Agent-Skills, progressive disclosure, and why this all matters
addyosmani/agent-skills - The horizontal SDLC skill library
github/spec-kit - GitHub’s Spec-Driven Development toolkit
skills CLI - The npx skills add installer
Anthropic’s skill docs - The underlying format