{"slug": "i-shipped-5-products-using-these-11-ai-prompts-open-sourced-with-outputs", "title": "I Shipped 5 Products Using These 11 AI Prompts (Open-Sourced, With Outputs)", "summary": "A developer open-sourced 11 AI prompts used to ship five digital products in two months, covering launch tweets, Show HN posts, changelog entries, cold outreach DMs, README intros, and PR description templates. Each prompt follows a four-part structure—role, context, constraints, output—to avoid vague results, with actual outputs and explanations included.", "body_md": "I've launched five digital products in the last two months. Every launch artifact — the launch tweet, the Show HN post, the changelog entry, the cold outreach DM, the README intro, the PR description template — was drafted by an AI prompt I'd written, tested, and refined.\n\nThis post is those prompts. Not a teaser. The actual prompts, with the actual outputs they produced, and a short note on why each one works. If they're useful, steal them. If you want the full set of 30+ tested prompts covering the entire product lifecycle, I link to it at the bottom.\n\nEvery AI prompt list I've read has the same problem: the prompts are vague. \"Write a launch tweet\" produces generic SaaS-speak. \"Write a cold email\" produces a wall of buzzwords. The model isn't broken — you've given it nothing specific to optimize for, so it optimizes for the average of every mediocre launch tweet it's ever seen.\n\nEvery prompt below follows the same four-part structure. If you remember nothing else, remember this:\n\n```\n1. ROLE       — Who the model is pretending to be.\n2. CONTEXT    — The specific product, audience, and goal.\n3. CONSTRAINTS— Tone, length, format, what to avoid.\n4. OUTPUT     — The exact shape of what you want back.\n```\n\nVague prompts fail because they skip 2 and 3. Every prompt below has all four.\n\nThe launch tweet is the single highest-leverage piece of copy you'll write. It has to do five things in 280 characters: hook, name the problem, imply the solution, show proof, and link.\n\n```\nROLE: You are a developer who just launched a side project.\nCONTEXT: I'm launching [PRODUCT], which [ONE-SENTENCE WHAT IT DOES].\nThe target reader is a developer who has experienced [SPECIFIC PAIN].\nThey've tried [COMMON ALTERNATIVE] and found it [SPECIFIC FAILURE].\nCONSTRAINTS: Maximum 270 characters. No emoji in the first 12 words.\nNo \"we're excited to announce\". No hashtag spam. End with a link\nplaceholder. The hook must be a specific observation, not a question.\nOUTPUT: Three different tweet drafts. Label them A, B, C.\n```\n\n**Why it works:** The \"no emoji in the first 12 words\" constraint kills the 🚀-openers that make every launch tweet look identical. The \"specific observation, not a question\" constraint kills the \"Tired of slow builds?\" template. Forcing three drafts lets you pick the strongest.\n\n**Example output (for a fictional config-file generator):**\n\nA — I've generated the same tsconfig.json by hand 40 times this year. So I built a generator that outputs a valid one in 6 seconds. Free, no signup: [link]\n\nB — Every new TypeScript project starts with the same 15-minute tsconfig ritual. Mine now starts with a button. [link]\n\nC — tsconfig.json has 60+ options. Most devs copy-paste and hope. There's a better way: [link]\n\nA is the strongest — it leads with a specific number (\"40 times\"), names the pain, and implies the solution without announcing it.\n\nShow HN is the highest-signal launch channel on the internet. A bad title kills the post before anyone reads it. Hacker News titles have to be factual, understated, and specific — no marketing language.\n\n```\nROLE: You are a developer writing a Show HN submission.\nCONTEXT: I built [PRODUCT], a [ONE-LINE DESCRIPTION].\nIt's built with [TECH STACK]. The core technical idea is\n[SPECIFIC TECHNICAL DECISION]. It's different from [EXISTING TOOL]\nbecause [SPECIFIC DIFFERENCE].\nCONSTRAINTS: Title must be under 80 characters. No adjectives like\n\"amazing\", \"powerful\", \"revolutionary\". No exclamation marks.\nStart with \"Show HN:\" exactly. The title must describe what the\nthing IS, not what it does for the user.\nOUTPUT: The title only. Then a 3-sentence first paragraph for the\npost body that explains the technical decision and why you built it.\n```\n\n**Why it works:** Show HN downvotes anything that smells like marketing. Forcing the title to describe \"what the thing IS\" kills \"supercharge your workflow\" titles. The 80-character limit forces specificity. Banned adjectives kill hype language.\n\n**Example output:**\n\nTitle:Show HN: A static-site generator for config files (tsconfig, eslint, prettier)\n\nBody:I built a collection of static HTML tools that generate valid config files for JavaScript tooling — tsconfig.json, eslint config, prettier config, and about 35 others. Each tool runs entirely client-side, no backend. The interesting technical decision was generating the output as a downloadable file via Blob URLs instead of a textarea, because it means the output preserves exact formatting and can be committed directly.\n\nChangelogs are read by your most engaged users — the ones who already installed your thing and care enough to check what changed. A good changelog entry is specific, dated, and grouped by impact.\n\n```\nROLE: You are a maintainer writing a changelog entry.\nCONTEXT: This release ([VERSION]) of [PRODUCT] includes these changes:\n- [CHANGE 1: what it is and why it matters]\n- [CHANGE 2: what it is and why it matters]\n- [CHANGE 3: what it is and why it matters]\nCONSTRAINTS: Use Keep a Changelog format. Group as Added, Changed,\nFixed, Removed, Deprecated, Security — only include groups that\nhave entries. Each entry is one sentence, present tense, imperative\nmood (\"Add X\", not \"Added X\" or \"Adds X\"). Link to the issue/PR\nnumber if known.\nOUTPUT: The full changelog section for this version, ready to paste.\n```\n\n**Why it works:** Imperative mood is the Keep a Changelog convention but most LLMs default to past tense (\"Added a new setting\") — the constraint catches it. Forcing one-sentence entries kills the wall-of-text changelog nobody reads. Grouping by impact lets users skim.\n\n**Example output:**\n\n```\n## [1.4.0] - 2026-07-21\n\n### Added\n- Support for generating `.npmrc` files with scoped registry auth ([#42](https://example.com/issues/42))\n- A \"Copy as CJS\" toggle to the lint-staged generator\n\n### Fixed\n- Quotes in YAML values are now escaped correctly in the docker-compose output\n- The tailwind generator no longer crashes on empty `theme.extend`\n```\n\nCold DMs have a ~2% response rate. The ones that work don't pitch — they offer something specific and useful, then ask one question.\n\n```\nROLE: You are a developer reaching out to another developer.\nCONTEXT: I'm [YOUR NAME], I built [PRODUCT]. I'm messaging\n[RECIPIENT NAME] because they [SPECIFIC THING THEY DID OR WROTE\n— a blog post, a tweet, an OSS project]. Their work on [SPECIFIC\nDETAIL] is relevant because [SPECIFIC REASON]. I am NOT asking\nthem to buy anything.\nCONSTRAINTS: Maximum 120 words. No \"I hope this finds you well\".\nNo \"I'd love to pick your brain\". No attachment in the first\nmessage. The message must contain exactly one specific compliment\nabout their work, one specific question, and one concrete thing\nthey can say no to. End with a low-friction exit.\nOUTPUT: The DM only, ready to send.\n```\n\n**Why it works:** The \"one concrete thing they can say no to\" forces you to make an actual ask instead of a vague \"let's connect\". The \"low-friction exit\" makes replying optional, which paradoxically increases reply rate. The specific-compliment requirement kills the \"I love your content!\" template that gets ignored.\n\n**Example output:**\n\nHi [Name] — your post on dependency injection in TypeScript was the clearest explanation I've read. The bit about constructor vs property injection finally clicked for me.\n\nI'm building a set of free config-file generators and I'm curious: when you set up a new TS project, do you start from a template or write tsconfig from scratch? No pitch — just genuinely interested in the workflow. Happy to ignore if busy.\n\nThe first 3 lines of your README decide whether someone stars, clones, or bounces. Most README intros bury the lede.\n\n```\nROLE: You are an open-source maintainer writing a README.\nCONTEXT: [PRODUCT] is a [ONE-LINE DESCRIPTION]. The ideal reader\nis [WHO]. The single most important thing they need to know in\nthe first 5 seconds is [THE KEY VALUE]. It's built with [TECH].\nIt's different from [ALTERNATIVES] because [SPECIFIC DIFFERENCE].\nCONSTRAINTS: The intro must be exactly 4 lines. Line 1 is the\nproject name as an H1. Line 2 is a one-sentence description with\nno buzzwords. Line 3 is a \"why\" sentence starting with \"Because\"\nor \"For\". Line 4 is a one-line install command in a code block.\nNo badges in the first 4 lines.\nOUTPUT: The README intro only.\n```\n\n**Why it works:** Badges-first READMEs push the actual description below the fold on GitHub. The \"Because/For\" opener on line 3 forces you to articulate the why, not just the what. The install command on line 4 lets impatient users skip the rest.\n\n**Example output:**\n\n```\n# dev-launch-pack\n\nA collection of 38 free, static-site config-file generators for JavaScript and Python tooling.\n\nFor developers who generate the same tsconfig/eslint/prettier/docker-compose files by hand every new project.\n```\n\nbash\n\nnpx dev-launch-pack\n\nyaml\n\nBug reports that get fixed fast have a specific shape. This prompt generates the template, not a specific bug — you fill it in.\n\n```\nROLE: You are a maintainer creating a bug report template.\nCONTEXT: [PROJECT] is a [TYPE]. The most common bug categories\nare [LIST 3-5]. Contributors often forget to include [WHAT THEY\nFORGET]. The maintainers need [WHAT THEY NEED TO DEBUG].\nCONSTRAINTS: Use GitHub issue template YAML frontmatter with\nname, about, title, labels. Use Markdown checkboxes for steps.\nInclude a \"Steps to reproduce\" section with 3 numbered steps.\nInclude an \"Expected vs Actual\" two-column table. Include a\n\"Environment\" section with version fields. No free-text-only\nsections — everything is either a checkbox, a dropdown, or a\nspecifically-prompted text field.\nOUTPUT: The full .github/ISSUE_TEMPLATE/bug_report.yml file content.\n```\n\n**Why it works:** Free-text-only sections produce bug reports like \"it doesn't work, please fix\". Structured fields force contributors to give you what you need. The YAML frontmatter means it shows up in GitHub's \"New issue\" picker.\n\nPR descriptions are read by reviewers who are deciding whether to read your code. A good description makes the review faster; a bad one makes the reviewer close the tab.\n\n```\nROLE: You are a developer opening a pull request.\nCONTEXT: This PR [WHAT IT DOES]. It's motivated by [ISSUE OR REASON].\nThe implementation approach is [APPROACH]. I chose this over\n[ALTERNATIVE APPROACH] because [REASON]. Testing done: [WHAT YOU\nDID TO TEST IT]. Risk areas: [WHERE A REVIEWER SHOULD LOOK HARD].\nCONSTRAINTS: Use this structure: ## Summary (2 sentences max),\n## Motivation (1 short paragraph), ## Changes (bullet list, each\nbullet a logical change), ## Testing (bullet list of what was run),\n## Risk (bullet list of areas needing review). No \"This PR fixes\n#123\" as the only description.\nOUTPUT: The full PR description, ready to paste.\n```\n\n**Why it works:** The \"Risk\" section is the one most PRs omit and the one reviewers need most. The \"alternative approach\" line forces you to justify your design, which catches bad decisions before review. Banning \"fixes #123\" as the only description kills the worst PR template on earth.\n\nLaunch day is chaos. A checklist generated for *your specific product* is worth 10x a generic one.\n\n```\nROLE: You are a product launch manager.\nCONTEXT: I'm launching [PRODUCT] on [DATE] on these channels:\n[LIST CHANNELS — Show HN, Product Hunt, Twitter, Reddit, etc.].\nThe product is [TYPE]. I have [N] hours of prep time.\nCONSTRAINTS: Output a chronological checklist. Group by \"T-7 days\",\n\"T-3 days\", \"T-1 day\", \"Launch day\", \"T+1 day\". Each item must be\na specific, checkable action, not a vibe (\"Draft the launch tweet\"\nnot \"Prepare social\"). Include a \"what can go wrong\" section with\n3 specific failure modes and one-line mitigations.\nOUTPUT: The full checklist as a Markdown task list.\n```\n\nAngry users become loyal users if you reply well. They become public critics if you don't.\n\n```\nROLE: You are a founder replying to a frustrated customer.\nCONTEXT: The customer [NAME] wrote: \"[PASTE THEIR MESSAGE]\".\nThey are frustrated because [THE SPECIFIC PAIN]. Our product\n[WHAT HAPPENED — a bug, a delay, a misunderstanding]. We have\n[WHAT WE CAN DO ABOUT IT — a fix, a refund, a workaround].\nCONSTRAINTS: Maximum 150 words. Acknowledge their specific pain\nin the first sentence (not \"I'm sorry you're frustrated\" — name\nthe actual thing). Do not use the word \"unfortunately\". Do not\nblame the customer, the system, or a third party. Offer one\nconcrete next step. Sign off as a human, not \"The Team\".\nOUTPUT: The reply only, ready to send.\n```\n\n**Why it works:** \"I'm sorry you're frustrated\" is the most enraging phrase in customer support — it centers the company's feelings, not the customer's problem. Naming the specific pain (\"You lost two hours of work because our autosave failed\") is the difference between a defused user and a charged-back one. Banning \"unfortunately\" kills the passive-voice non-apology.\n\nThe highest-signal feature requests come from a one-question survey sent to users who just used your product.\n\n```\nROLE: You are a product manager writing a follow-up survey.\nCONTEXT: [PRODUCT] is a [TYPE]. The user just completed [ACTION].\nI want to know [WHAT I WANT TO LEARN — a feature gap, a friction\npoint, a willingness to pay]. The survey will be sent via\n[EMAIL / IN-APP / DM].\nCONSTRAINTS: Maximum 2 questions. Question 1 must be open-ended\n(not multiple choice) and start with \"What\". Question 2, if present,\nmust be a single multiple-choice with an \"Other\" option. No\ndemographic questions. No \"How likely are you to recommend\" (NPS)\n— it's noise for early-stage products.\nOUTPUT: The survey text only, ready to send.\n```\n\n**Why it works:** NPS at early stage is vanity. The open-ended \"What\" question surfaces feature gaps you'd never think to ask about. Capping at 2 questions respects the user's time and increases completion rate.\n\nPricing pages fail when they describe tiers instead of outcomes. Nobody buys \"5 seats and 10GB\" — they buy \"for my team of 4 that ships daily\".\n\n```\nROLE: You are a copywriter writing pricing-tier descriptions.\nCONTEXT: [PRODUCT] has [N] tiers: [LIST TIERS WITH PRICES]. The\nideal customer for tier 1 is [PERSONA 1]. For tier 2 is [PERSONA 2].\nFor tier 3 is [PERSONA 3]. The core differentiator between tiers\nis [DIFFERENTIATOR — usage, features, support].\nCONSTRAINTS: Each tier description is exactly 2 lines. Line 1\nnames who it's for (\"For solo developers\", \"For small teams\", \"For\nscaling startups\"). Line 2 names the single most important thing\nthat tier unlocks. Do NOT list every feature — list only the one\nthat justifies the price jump from the tier below. No \"Most\npopular\" badge unless I specify it.\nOUTPUT: The tier descriptions only, formatted for a pricing table.\n```\n\nA prompt is code. You wouldn't ship code without running it. Prompts are nondeterministic, so **one good generation proves nothing** — you need to see how the prompt behaves across runs and edge cases.\n\nMy testing process, for every prompt before it ships into a workflow:\n\nThe 11 prompts above are the ones I use most. The full pack I sell covers 30+ prompts across the entire product lifecycle — launch, growth, support, ops — each tested with the rubric process above.\n\nOr ** browse the full storefront**. Every pack is tested and refundable via Gumroad. The $9 launch pack is the cheapest way to see if the approach works for you.\n\nNo hard sell. If the 11 prompts in this post were enough, great — use them. If you want the rest of the set, tested and ready, the link is there.\n\n**TL;DR:** 11 tested prompts for shipping products — launch tweet, Show HN title, changelog, cold DM, README intro, bug report template, PR description, launch checklist, support reply, feature survey, pricing copy. Each follows Role → Context → Constraints → Output format. Test prompts like code: 5 runs, 3 edge cases, rubric scoring. Free to use; full 30+ pack linked at the bottom.", "url": "https://wpnews.pro/news/i-shipped-5-products-using-these-11-ai-prompts-open-sourced-with-outputs", "canonical_source": "https://dev.to/draftkit/i-shipped-5-products-using-these-11-ai-prompts-open-sourced-with-outputs-3k3c", "published_at": "2026-07-21 10:04:54+00:00", "updated_at": "2026-07-21 10:35:28.488919+00:00", "lang": "en", "topics": ["artificial-intelligence", "generative-ai", "developer-tools"], "entities": ["Hacker News"], "alternates": {"html": "https://wpnews.pro/news/i-shipped-5-products-using-these-11-ai-prompts-open-sourced-with-outputs", "markdown": "https://wpnews.pro/news/i-shipped-5-products-using-these-11-ai-prompts-open-sourced-with-outputs.md", "text": "https://wpnews.pro/news/i-shipped-5-products-using-these-11-ai-prompts-open-sourced-with-outputs.txt", "jsonld": "https://wpnews.pro/news/i-shipped-5-products-using-these-11-ai-prompts-open-sourced-with-outputs.jsonld"}}