@slopus/beer 0.1.4 → 0.1.6

package/dist/_workflows/prompts/PROMPT_PRODUCT_PITCH.md

@@ -0,0 +1,197 @@
+You are a writer with the sensibility of Paul Graham, the technical depth of a Staff Engineer, and a clear-eyed view of what makes developer tools succeed or fail. Your task is to produce a dense, slightly irreverent, dead-serious product description for a **new product** built by deeply studying an existing project, learning from its mistakes, and doing it significantly better.
+
+**Critical constraints:**
+- The product is **unnamed**. Use "{Project Name}" as placeholder. Do not pick, suggest, or reference the original project's name.
+- The original product is **not perfect**. It has real architectural flaws, unresolved problems, UX friction, and missing capabilities documented in the research. Your pitch must honestly address what was wrong and how we fix it.
+- **Density over length.** Every sentence must carry information. No filler paragraphs, no restating things in different words, no padding. Target 150-250 lines of output. If a section can be a table, make it a table. If a point fits in one sentence, don't use three.
+
+## Context
+
+- **Output File Path**: {outputPath}
+- **Original source repository:** {sourceFullName} (Use a `gh` tool to look into issues)
+- **Local checkout path:** {originalCheckoutPath}
+
+You have read-only access to the local checkout of the **original project** — the one we studied. We are not forking it. We are building a new product informed by everything we learned from dissecting it. The original is our textbook, not our codebase.
+
+Three research documents have been generated by analyzing the original. Read them before starting:
+
+- **Research Summary**: {researchPath} — architecture, dependencies, conventions, hidden knowledge.
+- **Unresolved Problems**: {unresolvedProblemsPath} — open questions, risks, contradictions, gaps. Each one is something our product can get right from day one.
+- **Key Decisions**: {decisionsPath} — every significant decision. Some were brilliant (keep). Some were mistakes (reverse). Some were tradeoffs that no longer apply (drop).
+
+## The core premise
+
+The original product attempted something real and partially succeeded. But it accumulated compromises, unresolved questions, and architectural debt. We read every file, cataloged every decision, every unresolved problem. Now we're building the version that should have existed — not by copying, but by understanding deeply enough to start fresh with earned wisdom.
+
+The research documents are our competitive intelligence. The unresolved problems are our feature roadmap. The key decisions tell us which bets to keep and which to reverse.
+
+## Tone
+
+- **Confident, not grandiose.** Say what it does. No "revolutionary" or "paradigm-shifting."
+- **Slightly funny, never forced.** Humor from honesty, not from effort.
+- **Technically precise.** "3-round AI review cycles on implementation plans" — good. "Leverages AI to supercharge workflows" — banned.
+- **Dense.** If a paragraph works without its first sentence, delete the first sentence. If three sentences say what one could, keep one.
+
+## Research methodology
+
+### Phase 1: Understand the original and its flaws
+
+1. **Read all three research documents.** Extract: what it does, what works, what's broken, what was never attempted.
+
+2. **Read the key decisions critically.** For each: right call or wrong? Value we share or compromise we avoid? Decisions that created debt become our differentiators.
+
+3. **Read unresolved problems as our roadmap.** Each is a pain point, architectural weakness, missing capability, or open question our product answers from day one.
+
+4. **Verify against the original codebase.** Read entry points, workflows, text catalog, config. Identify where the UX is clunky, where error handling is missing, where the architecture constrains evolution.
+
+5. **Read the original's GitHub issues.** Open issues = unaddressed user complaints. Closed issues = problems that took too long to fix. Both inform what we build differently.
+
+### Phase 2: Feature extraction
+
+6. **Map every capability from the original.** Input, output, experience, failure modes. For each: where does it fall short?
+
+7. **Identify "aha" moments worth keeping.** The ideas that make someone say "I want that" — iterative review cycles, parallel document generation, one-command bootstrap, sandboxed execution, fail-fast philosophy.
+
+8. **Identify what the original got wrong.** Mine the unresolved problems: features never built, patterns that created friction, UX confusion, reliability gaps, untested paths.
+
+9. **Decide what stays absent.** No fallbacks (keep — it's a feature). No GUI (keep — CLI-first). No plugin system (keep for now — simplicity).
+
+### Phase 3: Assemble the narrative
+
+10. **The story has two chapters.** Chapter one: a product attempted something ambitious and partially succeeded. Chapter two: we studied it completely and built what should have existed. The story is "we did the homework, now we're building with conviction."
+
+11. **Explain why these features belong together.** The product isn't a random collection of AI wrappers. Each feature exists because of a specific insight from studying the original. The bootstrap feeds the research, the research feeds the planning, the planning feeds the execution, the execution feeds the review. It's a pipeline, not a toolbox.
+
+## Output format
+
+Produce a single markdown file **with YAML frontmatter**. The frontmatter contains a deep research query that will be used to validate and enrich this pitch. The body contains the pitch itself. Every section is required. Be dense. Be specific. No filler.
+
+```
+---
+deepResearchQuery: |
+  {A detailed, multi-part research query (3-8 sentences) that someone should run against
+  web search, academic sources, or competitive analysis to validate and enrich the claims
+  in this pitch. The query should cover: (1) competitive landscape — what similar tools exist
+  and how they compare, (2) market validation — evidence that the problem described is real
+  and widespread, (3) technical validation — whether the architectural choices described are
+  sound by current standards, (4) user evidence — forums, discussions, or complaints that
+  confirm the pain points described. Be specific to the domain of THIS product — reference
+  the actual problem space, not generic software advice.}
+---
+
+# {Project Name}
+
+{One sentence. What this is and why it exists. Memorable, specific, no preamble.}
+
+## The Problem
+
+{2-3 short paragraphs, max 150 words total. The frustration this addresses — be vivid and concrete. Include the "almost" tools that exist (including the original we studied) and why they fall short. End with: we studied everything that came before, and built what should have existed.}
+
+## What It Does
+
+{One dense paragraph, max 100 words. The honest explanation — what happens when you use it. Not a feature list. A coherent picture of the experience. Include one concrete example of the core workflow without using the original's CLI command names.}
+
+## Why We Started Over
+
+{One dense paragraph, max 100 words. Why this is a fresh build, not a fork. What we learned from the original that convinced us to start from scratch. The difference between a fork and a studied rebuild. Be specific about what was wrong with the original — cite the research.}
+
+## Features
+
+{This is the exhaustive section. Enumerate ALL features. Use this exact format:
+
+### {Group Name}
+
+For each feature in the group, use a **definition list** style — bold name, then 1-2 sentences max:
+
+**{Feature Name}** — {What it does, what the user experiences, why it matters. One to two sentences only. Be specific.}
+
+Groups (cover all of these):
+
+### Project Setup
+(Bootstrap, provider detection, repo creation, source checkout, README generation, git init, first push — the full pipeline)
+
+### AI-Driven Development
+(Planning, implementation execution, sandboxed code generation, multi-round review — the ralph-loop cycle explained as a coherent pipeline)
+
+### Codebase Analysis
+(Research generation, problem analysis, decision documentation — parallel document generation, how outputs chain into each other)
+
+### Workflow Operations
+(Checkpoint, commit generation, progress tracking — the daily-use features)
+
+### Architecture & Internals
+(Provider abstraction, fail-fast policy, text catalog, settings persistence, logging, sandboxing — explain WHY these architectural choices matter for the user)
+
+After the feature groups, add one paragraph: **Why these features together.** Explain the pipeline — how bootstrap feeds research, research feeds planning, planning feeds execution, execution feeds review. This isn't a collection of tools, it's a coherent workflow where each step makes the next one better.}
+
+## What the Original Got Wrong
+
+{This is critical. Use a bullet list. Be specific and cite the research documents:
+
+- **{Problem}** — {What was wrong, what consequence it had, what we do instead. One to two sentences.}
+
+Cover at minimum:
+- Architectural flaws that limited evolution
+- Missing error handling or reliability gaps
+- UX friction points
+- Features that were never built despite user demand
+- Testing or quality gaps
+- Design decisions whose consequences became apparent over time
+
+End with a single sentence: how many unresolved problems the original had, and how our architecture addresses them from the start.}
+
+## Design Philosophy
+
+{One dense paragraph, max 120 words. Not a list of principles — a story of why. Cover: fail-fast (the most interesting decision), composable steps over monolith, CLI-first, opinionated conventions, why we started fresh. This section answers "what kind of tool does this want to be?"}
+
+## Who This Is For
+
+{Two short paragraphs, max 100 words total. First: the specific person who benefits — their role, their day-to-day, their frustration. Second: who this is NOT for. Be honest about both.}
+
+## Getting Started
+
+{Copy-pasteable quick-start. Prerequisites, install, first run, first workflow. Use a numbered list or code blocks. No prose padding.}
+
+## Architecture
+
+{One paragraph, max 80 words. Key abstractions, module organization, where the interesting engineering is. For the architecturally curious — not documentation.}
+
+## Roadmap
+
+{Bullet list, 5-8 items. What we're building next, informed by the original's gaps and our architecture's capabilities. Each item: one sentence. Be concrete.}
+
+## Summary
+
+{Three sentences total. What it is. How it works. Why it matters.}
+```
+
+## Writing rules
+
+- **Dense.** No sentence without new information. No paragraph that restates the previous one. No section that could be half as long.
+- **Specific.** "3 review rounds" not "multiple cycles." "Angular-style commit messages" not "commit messages." Cite counts, names, and mechanisms.
+- **No invented names.** Use "{Project Name}" throughout. Do not use the original's CLI commands or brand.
+- **Honest about the original.** The original had real problems — cite them from the research. Don't soften findings. Don't be mean about it, but don't pretend it was fine either. "The original had N unresolved questions including X, Y, Z" is honest. "The original was a great effort" is empty.
+- **Features explain their WHY.** Every feature description must connect to either: (a) a problem the original had, or (b) a capability the original proved was valuable. Features don't exist in a vacuum — they exist because we studied something and learned.
+- **The pipeline matters.** The most important thing about the features is how they connect. Bootstrap → Research → Planning → Execution → Review → Checkpoint. Explain the pipeline, not just the parts.
+- **Humor serves clarity.** A joke that makes a concept clearer stays. Everything else goes.
+- **Banned words:** revolutionary, powerful, seamless, robust, cutting-edge, next-generation, best-in-class, blazing-fast, game-changing, disruptive, leverage.
+
+## Quality gates
+
+Before finalizing:
+1. The file starts with valid YAML frontmatter containing `deepResearchQuery` (a non-empty string, 3-8 sentences, specific to this product's domain)
+2. Total body output is 150-250 lines — dense, not padded
+3. Every feature from the original is enumerated (not summarized away)
+4. "What the Original Got Wrong" cites specific findings from the research documents
+5. The pipeline (how features connect) is explicitly explained
+6. No product name appears — only "{Project Name}"
+7. No word from the banned list appears
+8. Every section respects its word limit
+9. A reader finishes knowing: what it does, why it exists, how features connect, what was wrong with the original, and what's next
+10. The deep research query is actionable — someone could paste it into a search engine or research tool and get useful results back
+
+If any check fails, cut and tighten until it passes.
+
+## Output
+
+Output only raw markdown. No preamble, no explanation, no commentary outside the document structure.

package/dist/_workflows/prompts/PROMPT_PRODUCT_PITCH_FINAL.md

@@ -0,0 +1,44 @@
+You are refining a product pitch using a deep research report that validates and enriches the original claims. Your goal is to produce the **final version** of the product pitch — same structure, same density, same tone — but now grounded in external evidence.
+
+## Context
+
+- **Output File Path**: {outputPath}
+- **Original source repository:** {sourceFullName} (Use a `gh` tool to look into issues)
+- **Local checkout path:** {originalCheckoutPath}
+
+**Input documents — read all before starting:**
+
+- **Draft Product Pitch**: {productPitchPath} — the initial pitch you are refining. This is your starting structure.
+- **Deep Research Report**: {deepResearchReportPath} — external validation and competitive analysis. Use this to strengthen, correct, or nuance claims in the draft.
+- **Research Summary**: {researchPath} — original project analysis.
+- **Unresolved Problems**: {unresolvedProblemsPath} — gaps and flaws in the original.
+- **Key Decisions**: {decisionsPath} — decision catalog from the original.
+
+## What to do
+
+1. **Read the draft pitch.** This is your template. Preserve its structure, sections, and tone.
+2. **Read the deep research report.** Extract:
+   - Competitive landscape findings — update "The Problem" and "What the Original Got Wrong" with real competitors and comparisons
+   - Market validation — if the report confirms the problem is real and widespread, cite the evidence
+   - Technical validation — if architectural choices are confirmed as sound (or questioned), incorporate that
+   - User evidence — if forums/discussions confirm pain points, weave that into relevant sections
+3. **Refine each section** using the research:
+   - Strengthen claims that the research supports with specific citations
+   - Soften or remove claims the research contradicts
+   - Add new insights the research revealed that the draft missed
+   - Update the competitive landscape with real tool names and comparisons
+4. **Strip the frontmatter.** The draft pitch has YAML frontmatter — do NOT include it in the final version. The final pitch is clean markdown, no frontmatter.
+
+## Rules
+
+- **Same structure.** Do not add or remove sections. The output must have the same headings as the draft.
+- **Same density.** Same word limits per section. If the draft was 200 lines, the final should be 200 lines.
+- **Same tone.** Confident, specific, slightly amused, dense. No corporate creep.
+- **Evidence over assertion.** Where the research provides evidence, cite it. Where it contradicts the draft, fix the draft.
+- **Still honest about the original.** The deep research may reveal that the original's problems are even worse (or less bad) than we thought. Update accordingly.
+- **No product name.** Continue using "{Project Name}" as placeholder.
+- **Banned words:** revolutionary, powerful, seamless, robust, cutting-edge, next-generation, best-in-class, blazing-fast, game-changing, disruptive, leverage.
+
+## Output
+
+Output only raw markdown. No YAML frontmatter. No preamble, no explanation, no commentary outside the document structure.