# 32 Claude Skills for Product Builders, From an Idea to a Prototype Users Can Try 32 Claude skills to frame one idea, spec it, prototype it, check it is safe to show, test it with real users, hand it to engineering and get a decision. - Page: https://lantern.meet-polar-bear.com/skills/product-builders-pack - Download: https://lantern.meet-polar-bear.com/skills/product-builders-pack.zip - Source: https://github.com/polar-bear-org/claude-skills/tree/main/packs/product-builders-pack - Price: free ## Install in Claude Code ``` /plugin marketplace add polar-bear-org/claude-skills /plugin install product-builders-pack@polar-bear-skills ``` ## The 32 skills you get The set follows one idea in eight stages: frame it, spec it, prototype it, make it work, check it is safe to show, test it with real users, hand it over, and decide. ### 1 · Frame it - **Problem Frame** — use when: You have the idea and the screens in your head, and nobody has said what question it answers. Output: One testable question, the decision it feeds and its owner by role, scope in three lists, a "how might we" line, one alternative framing. - **Idea One-Pager** — use when: You want a go-ahead for a week of prototyping and all you have is a chat thread. Output: The ask at the top (prototype time and five real users), problem with its evidence source, the bet, one success measure, what you will not build, open questions. - **Prototype Test Card** — use when: The prototype is about to be built and nobody can say what result would make you stop. Output: Beliefs sorted by what rides on them and how little evidence they have, one belief per card, the task, one observable measure, a dated pass line. ### 2 · Spec it - **Prototype Brief** — use when: You are about to type "build me an app" and have not decided how much of it has to work. Output: How real it must be (sketch, clickable, working), what is real and what is faked by hand, the Claude surface that fits, visual direction, what is out, a time box. - **Screen-by-Screen User Flow** — use when: The idea falls apart the moment you list what happens after the first click. Output: One journey from entry to done, each screen with its purpose, action and destination, dead ends, empty, error and loading states, one large-data case. - **Prototype Spec** — use when: The prototype will be judged against "what we agreed" and nothing was agreed in writing. Output: Answer-first summary, problem and evidence, non-goals, numbered requirements each with a pass or fail check, open questions with owners, a dated export. ### 3 · Prototype it - **Product Context File** — use when: You re-explain your product in every chat and the screens still use the wrong words. Output: One short file about your product (users by need, terms, what exists, constraints, tone), what never goes in it, where it lives, a review date. - **Design System Brief** — use when: Every prototype comes out in the same generic style. Output: What to import and from where, the components and tokens to use, what the system does not cover, a three-screen spot check, gaps for the owner. - **Clickable Prototype** — use when: You have a week, a spec and no engineer, and need something a user can click through. Output: The flow built screen by screen with requirement ids, two or three structurally different layouts, every state, sample content, a visible "prototype" label, decisions logged. - **Prototype Heuristic Review** — use when: Claude says it looks great and you are the only person who has seen it. Output: A walk against the 10 usability heuristics, problems with proposed severity, an over-design check, a short accessibility pass, ranked fixes. ### 4 · Make it work - **Claude Code Setup** — use when: The clickable version is not enough and you have never opened Claude Code. Output: A separate prototype folder, the permission mode that asks first, a short rules file, what you will and will not approve, the engineer's written yes. - **First Working Version** — use when: You asked for the whole app at once, got forty files, and cannot tell what works. Output: The one flow that must really work, what stays faked and labelled, small steps each with a check on screen, save points, a stop rule. - **Error Fix Log** — use when: It broke, the message means nothing to you, and each fix broke something else. Output: The error in plain words, the smallest steps that reproduce it, one change per attempt, when to rewind, when to stop and ask an engineer. - **Sample Data Plan** — use when: You are about to paste a customer export "just to make the demo look real". Output: Each field the prototype needs, invented data for every one, the cases to cover, where real data is tempting and why it stays out, who approves an exception. - **Connector Plan** — use when: Real tickets or analytics would be more convincing and you do not know what Claude could change. Output: Whether live tool data is needed at all, each connector page checked, reads allowed and writes off, personal data flagged, who turns it on, a first-run check. - **AI Prototype Input Check** — use when: The AI part worked beautifully on the three examples you chose. Output: Hand-picked inputs listed, a random share of real cases masked, runs per input, picked and random results reported apart, what one good run cannot show. ### 5 · Check it is safe to show - **Secrets and Keys Check** — use when: The prototype calls a real service and the key may be sitting in the page. Output: Where every key, password and token lives, the "could this be public" test, a search of files and history, revoke and replace steps, questions for an engineer. - **Personal Data Check** — use when: A real name, email or account number is on a screen you are about to send. Output: Every place data is shown, stored or sent, each item marked invented, masked or real, real items removed or approved by name, what shared storage and recordings hold. - **Access and Sharing Check** — use when: You pasted the link in a channel and do not know who can now open it. Output: Who can open the link today, what travels with it, the narrowest setting that lets testers in, a "prototype, not the product" label, the date access ends. - **Pre-Share Sign-Off** — use when: The checks are done in your head and nobody has said "yes, send it". Output: One page: what is shared and with whom, the three checks as run, anything real that remains, what could go wrong, the named person who says yes. ### 6 · Test it with real users - **Tester Recruitment and Consent Note** — use when: The easiest five people to ask are the ones sitting next to you. Output: Who counts as a real target user and who does not, where to find five, the invitation, a plain consent note. - **Five-User Usability Test Plan** — use when: Your script says "click here and tell me if you like it". Output: Test goals tied to the belief, task scenarios with the path unstated, success criteria set first, a moderator script, an observer grid, a pilot. - **Usability Test Findings** — use when: The sessions "went well" and four people could not finish the main task. Output: Per task: completed, with help, not completed; what people did beside what they said; problems with proposed severity; the moments to show. - **Prototype Iteration Plan** — use when: You want to fix everything after session two and have lost track of which version anyone saw. Output: What to fix before the next round and what to leave, one change per problem, what the next round must show, what cannot be compared, when to stop. ### 7 · Hand it over - **Prototype Demo Script** — use when: You are about to demo to leaders and the first question will be a date. Output: The moment to show first, the path, what users did (counts as run), the limits said out loud, the decision asked, answers for "when can we have it". - **Prototype vs Production Note** — use when: It looks finished, so someone has started calling it "version one". Output: What it proved against its pass line, what it does not prove, what is faked, the gap as work items with an owning role and no dates. - **Engineering Handover Note** — use when: You sent engineers a link and they have forty questions before they can start. Output: How to open and run it, a screen and requirement map, decisions and reasons, everything faked, known problems, keep, rebuild or throw away as a recommendation. - **Engineering Review Request** — use when: Your prototype has sat in a review queue for two weeks. Output: The one question for an engineer, what you are not asking, a thirty-minute walk-through plan, the three places you suspect, what you will do with the answer. ### 8 · Decide - **Prototype Learning Card** — use when: The story of what happened changes each time someone tells it. Output: What we believed, what we observed against the pass line, what we learned, what we still do not know, what we do next. - **Build, Change or Stop Decision** — use when: The prototype has been praised by everyone and decided on by no one. Output: One page: the decision asked, the evidence, the gap to production, three options with their cost as engineering states it, who decides, the date. - **Experiment Design Plan** — use when: The decision was "build" and the argument is whether it will move the number. Output: For the version engineers build: hypothesis, variants, one primary metric, guardrails, a sample and duration check, a decision rule set before launch. - **Build Routine Skill** — use when: The second idea arrives and you start again from a blank chat. Output: Your own repeat steps turned into a skill: real trigger phrases, fixed steps, a quality bar with the pre-share checks, a test on three past inputs. ## Workflows - **Frame the idea** (An idea, the screens in your head and no agreed question.) Problem Frame → Idea One-Pager → Prototype Test Card - **Spec before you build** (You are about to ask Claude for an app and nothing is agreed in writing.) Prototype Brief → Screen-by-Screen User Flow → Prototype Spec - **Build a clickable prototype** (A spec, a week and no engineer.) Product Context File → Design System Brief → Clickable Prototype → Prototype Heuristic Review - **Make one flow work** (The test needs a working version, not a clickable one.) Claude Code Setup → First Working Version → Error Fix Log → Sample Data Plan → Connector Plan → AI Prototype Input Check - **Check before you share** (The link is about to go out.) Secrets and Keys Check → Personal Data Check → Access and Sharing Check → Pre-Share Sign-Off - **Test with five users** (Five real target users to find, run and read.) Tester Recruitment and Consent Note → Five-User Usability Test Plan → Usability Test Findings → Prototype Iteration Plan - **Hand over and decide** (The prototype is tested and people have started calling it version one.) Prototype Demo Script → Prototype vs Production Note → Engineering Handover Note → Engineering Review Request → Prototype Learning Card → Build, Change or Stop Decision ## The quality bar - The pass line comes first: what counts as success is written and dated before anything is built or tested, and it is never moved after the results are in - Real target users, real sessions: colleagues, the leaders who asked and simulated users are not testers. Only what people did in a session becomes a finding - Nothing invented: no made-up numbers, quotes, results or user reactions. What is unknown stays in [brackets] until you fill it in - Faked is labelled as faked: every share carries a visible “prototype” label, and every handover lists what is hardcoded or done by hand - Checks are run by a person: security points end with “check with your engineering or security lead”; legal, privacy and consent points end with “check with a qualified adviser”. No skill declares a prototype secure - Problems are rated, people are not: severity belongs to a usability problem. Participants are codes, and nothing grades a tester or a teammate - The red line: Claude builds the prototype, real users test it and engineers own what ships: a prototype is never called production, and nothing holding real customer data or a live key is shared until a named person has checked it ## Questions people ask ### What is in the Claude for Product Builders pack? 32 Claude skills that follow one idea in eight stages: frame it, spec it, prototype it, make it work, check it is safe to show, test it with real users, hand it over, and decide. Each skill produces one artifact and names the skill to run next. ### How do I install these Claude skills? In Claude Code, two lines install all 32 at once. In Claude.ai or Claude Desktop, download the zip, open Settings, Skills, Add, and upload the skills you want. Either way it takes about five minutes. ### Do I need Claude Code to use them? No. The skills work in Claude.ai, Claude Desktop and Claude Code. In the app you upload them yourself; in Claude Code one command installs the whole pack. ### Do the skills work with ChatGPT or other assistants? They are built as Claude Skills, and installing them is a Claude feature. Each one is a plain Markdown file, so you can read it and reuse the method elsewhere, but it will not load and trigger by itself outside Claude. ### Can I ship the prototype as the product? No. Claude builds the prototype, real users test it and engineers own what ships. A prototype is never called production, and nothing holding real customer data or a live key is shared until a named person has checked it. ### Is the pack free? Yes. It is free to use inside your company and in client work, and not for resale. There is no signup: the download and the install command are on this page. ## About Written by Polar Bear (https://meet-polar-bear.com/). Published on Lantern (https://lantern.meet-polar-bear.com/), which turns your notes, documents and call transcripts into social post drafts you review and publish.