@slopus/beer 0.1.4 → 0.1.6

package/dist/_workflows/prompts/PROMPT_AGENTS_MD.md

@@ -0,0 +1,168 @@
+You are a senior software architect producing an AGENTS.md file — the definitive agent instruction manual for an AI coding assistant that will build a **new product from scratch**. There is no existing codebase to scan. Instead, you have research documents from studying an original project, and you must synthesize conventions, patterns, and rules for the new product based on what was learned.
+
+## Context
+
+- **Output File Path**: {outputPath}
+- **Original source repository:** {sourceFullName} (Use a `gh` tool to look into issues)
+- **Local checkout path:** {originalCheckoutPath} (the original project we studied — read for reference, not to copy)
+- **Product name:** {productName}
+
+The local checkout is the **original project we studied**. It is a reference, not our codebase. We are building a new product informed by what we learned from dissecting this one.
+
+Five documents have already been generated by analyzing the original project. Read them before starting:
+
+- **Research Summary**: {researchPath} — structured analysis of the original project's identity, architecture, dependencies, development lifecycle, conventions, and hidden knowledge.
+- **Unresolved Problems**: {unresolvedProblemsPath} — catalog of open questions, risks, contradictions, and gaps found in the original codebase.
+- **Key Decisions**: {decisionsPath} — comprehensive catalog of every significant decision visible in the original project, with analysis of what to keep and what to change.
+- **Product Pitch**: {productPitchPath} — description of the new product we are building, its features, philosophy, and goals.
+- **Technology Stack**: {technologyStackPath} — comprehensive stack recommendation with exact tools, versions, and conventions for the new product.
+
+## Core objective
+
+Produce an AGENTS.md that an AI agent reads before every task on the **new product**. It must be:
+- **Prescriptive**: tell the agent exactly how to write code for this new project
+- **Actionable**: every rule can be followed mechanically
+- **Minimal**: no filler, no aspirational statements, no repeating what tools already enforce
+- **Informed**: conventions are derived from lessons learned (what worked in the original, what didn't, what we're doing differently)
+
+This is NOT a description of the original project's conventions. This is the rulebook for the new one.
+
+================================================================
+SYNTHESIS PROCESS
+================================================================
+Follow this process in order. Do not skip phases. Do not guess when you can read.
+
+### Phase 1: Extract what to keep
+
+1. **Read the key decisions document.** For each decision marked as "keep" or with positive assessment:
+   - Extract the convention it implies
+   - Note the evidence that it worked well in the original
+
+2. **Read the research summary.** Extract conventions that are:
+   - Consistently applied across the original codebase
+   - Well-suited to the new product's goals (from the product pitch)
+   - Worth carrying forward as rules
+
+3. **Read the product pitch.** Extract:
+   - Stated design philosophy and values
+   - Technical architecture choices
+   - Features that imply specific coding patterns
+
+### Phase 2: Extract what to change
+
+4. **Read the unresolved problems document.** For each problem:
+   - Determine if it was caused by a convention (or lack of one)
+   - Design a rule that prevents the same problem in the new product
+
+5. **Read the key decisions document.** For decisions marked as problematic or with tensions:
+   - Determine the better alternative for the new product
+   - Write a concrete rule that enforces the better choice
+
+6. **Read the original codebase selectively** — only to verify or clarify specific patterns referenced in the research documents. Do not do a full codebase scan. Look at:
+   - Build/lint/format configs — to understand which settings worked and which to adjust
+   - Package manifests — to understand runtime and dependency baseline
+   - A few source files — to see patterns referenced in the research in their full context
+
+### Phase 3: Design new conventions
+
+7. **Fill gaps.** The original project may lack conventions in areas that the new product needs. For each gap:
+   - Check if the unresolved problems document flagged the absence
+   - Design a convention appropriate for the new product's goals
+   - Mark it as "new" (not inherited from the original)
+
+8. **Resolve contradictions.** Where the original had inconsistent patterns:
+   - Pick the better pattern based on the key decisions analysis
+   - Write a single clear rule
+
+### Phase 4: Write the AGENTS.md
+
+9. **Structure the output** following the format below. Every rule must be:
+   - Concrete enough that an agent can follow it without asking questions
+   - Justified by evidence from the research documents (even if briefly)
+   - Applicable to a greenfield codebase (no references to "existing code" — there is none yet)
+
+================================================================
+OUTPUT FORMAT
+================================================================
+
+Produce a single AGENTS.md file with the following structure. Every section is mandatory. If a section does not apply, omit it entirely (do not write "N/A"). Use the shortest phrasing that is unambiguous.
+
+```markdown
+# {productName} agent notes
+
+## Goals
+{3-5 bullet points: project philosophy and non-negotiable principles.
+ Derived from the product pitch and key decisions. These are the values that inform every convention below.}
+
+## Conventions
+{Bullet list of top-level structural conventions: package layout, language, output format, source locations, test patterns.
+ Each convention should state what to do, not what was done in the original.}
+
+## Build, Test, and Development Commands
+{Exact commands with one-line descriptions. Include prerequisites and command dependencies.
+ Derived from the original project's working setup, adjusted for any tooling changes.
+ Format: `- command: `exact invocation` (tool) — description`}
+
+## Coding Style & Naming Conventions
+{Concrete rules for the new product.
+ Include: language, strictness, naming patterns, file size guidelines, import patterns.
+ Carry forward conventions that worked in the original. Replace conventions that caused problems.
+ Every rule should be phrased as an instruction: "Use X", "Prefer Y over Z", "Never do W".}
+
+## {Pattern-specific sections}
+{One section per major architectural pattern for the new product.
+ Section name should be the pattern name (e.g., "Central Types", "Text Catalog", "Facade Classes").
+ Each section: brief explanation + usage example + rules for when/how to apply.
+ Include patterns carried forward from the original AND new patterns designed for the new product.
+ Only include code examples when the pattern is non-obvious.}
+
+## Agent-Specific Notes
+{Operational rules for AI agents working on this new codebase:
+ - Safety constraints (git, node_modules, versions, releases)
+ - Multi-agent coordination rules (if the new product will use multiple agents)
+ - Investigation methodology
+ - Commit and documentation workflow
+ - Things that require explicit user approval}
+```
+
+### Section writing rules
+
+- **Bullet points over paragraphs.** Each rule is one bullet. Use sub-bullets for examples only.
+- **Code examples only when essential.** If a pattern is clear from a sentence, skip the example. If it requires a code block to be unambiguous, include a minimal example (5-15 lines).
+- **Good/bad examples only for counter-intuitive rules.** If the convention matches common practice, don't waste lines showing it.
+- **No redundancy with tooling.** Don't document rules that the linter/formatter already enforces, unless agents need to know them before writing code.
+- **Forward-looking, not backward-looking.** Write "Use prefix notation for function names" not "The original project used prefix notation." The agent doesn't need to know the history — just the rule.
+- **Be specific.** "Keep files under ~500 LOC" not "Keep files small". "`bun run test`" not "run the tests". "`githubRepoCreate`" not "use prefix naming".
+
+================================================================
+RESEARCH RULES
+================================================================
+
+- **Read the documents, not the codebase.** The four research documents are your primary source. Read the original codebase only to verify specific claims or see patterns in full context.
+- **Distinguish keep from change.** For every convention, consciously decide: is this worth keeping, or did it cause problems? The unresolved problems and key decisions documents are your guide.
+- **Design for a blank slate.** The new product has no legacy code. Conventions should be ideal, not compromised by backward compatibility.
+- **Prioritize actionability.** Ask: "Could an agent follow this rule on the first file they create?" If not, rephrase until they can.
+- **Omit the obvious.** Don't document things universal to the language/framework. Only document project-specific choices.
+- **Note deliberate absences.** If the new product deliberately omits something (no barrel files, no cleanup methods, no inference fallbacks), state it as a rule.
+- **Quantify when possible.** "~500 LOC per file" is better than "keep files small".
+- **Fill the gaps the original left open.** If the original had no convention for something important, and the unresolved problems flagged it, create one.
+
+================================================================
+QUALITY GATES
+================================================================
+
+Before finalizing, verify:
+1. Every rule is phrased as an instruction for the new product (not a description of the original)
+2. No aspirational or opinion-based statements ("clean code", "well-structured", "best practices")
+3. No duplication between sections
+4. No rules that merely restate linter/formatter enforcement
+5. Code examples are minimal and realistic for the new product (not copied from the original unless the pattern is identical)
+6. An agent reading this file could create the first module of the new product without asking any questions about style, naming, file placement, testing, or commit workflow
+7. Conventions that differ from the original are justified by evidence from the research documents
+8. The file is under 500 lines (aim for 200-400 — dense and scannable)
+
+If any check fails, revise before returning.
+
+## Output
+
+Output only raw markdown. No preamble, no explanation, no commentary outside the document structure.

package/dist/_workflows/prompts/PROMPT_DECISIONS.md

@@ -0,0 +1,372 @@
+You are a Staff Engineer producing a comprehensive Key Decisions Document for a software project. Your goal is to extract, catalog, and explain every significant decision visible in the project — technology choices, architectural patterns, conventions, trade-offs, and constraints — so that a new contributor or downstream consumer can understand not just *what* the project does, but *why it is built the way it is*.
+
+## 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. Do not modify anything.
+
+Two research documents have already been generated for this project. Read them before starting:
+
+- **Research Summary**: {researchPath} — structured analysis of the project's identity, architecture, dependencies, development lifecycle, conventions, and hidden knowledge.
+- **Unresolved Problems**: {unresolvedProblemsPath} — catalog of open questions, risks, contradictions, and gaps found in the codebase.
+
+## Extraction methodology
+
+You have two rich input documents. Use them as your primary source. Supplement with targeted reads of the local checkout when you need to verify a claim, resolve ambiguity, or fill gaps the research documents left open. Do not re-do the full codebase scan — the research documents already did that.
+
+### Phase 1: Decision extraction from research
+
+1. **Mine the research summary** — read every section and extract every choice that represents a decision:
+   - Each dependency listed is a decision (why this library, not another?)
+   - Each config value documented is a decision (why this setting?)
+   - Each pattern described is a decision (why this pattern, not alternatives?)
+   - Each convention noted is a decision (why this naming, structure, or style?)
+   - Each absence noted is a decision (why NOT include this?)
+
+2. **Mine the unresolved problems** — read every question and extract the decisions that created those problems:
+   - Unresolved questions often point to decisions that were made implicitly or inconsistently
+   - Contradictions reveal competing decisions
+   - Gaps reveal decisions not yet made
+   - Risks reveal consequences of existing decisions
+
+3. **Targeted verification** — for high-impact decisions where the research documents lack specificity, read the relevant source files directly:
+   - Configuration files (tsconfig, lint configs, build configs) — each key is a micro-decision
+   - Package manifests — version constraints, engine fields, exports strategy
+   - Entry points — how the project is invoked and what it exposes
+   - Key source files referenced in the research — verify patterns and extract rationale from comments
+
+### Phase 2: Decision classification
+
+Classify every discovered decision into one of these categories:
+
+- **Language & Runtime** — programming language, runtime version, module system
+- **Framework & Libraries** — framework choice, key library selections, why-this-over-that
+- **Build & Tooling** — compiler, bundler, linter, formatter, test runner, package manager
+- **Architecture & Patterns** — architectural style, design patterns, module boundaries
+- **File Organization** — directory structure, naming conventions, file-per-function vs grouped
+- **Type System** — type strictness, shared types strategy, type definition patterns
+- **Error Handling** — error propagation strategy, custom error types, failure modes
+- **Testing Strategy** — framework, file placement, test types, coverage approach
+- **API Design** — public API surface, versioning, backwards compatibility
+- **Data & State** — data flow, state management, persistence, caching
+- **Async & Concurrency** — async patterns, concurrency primitives, parallelism approach
+- **Security & Secrets** — auth approach, input validation, secrets management
+- **CI/CD & Release** — pipeline structure, release process, versioning strategy
+- **Developer Experience** — local dev workflow, debugging, onboarding
+- **Coding Conventions** — naming rules, comment style, import ordering, code limits
+- **Operational** — logging, monitoring, deployment, configuration management
+
+### Phase 3: Decision analysis
+
+For each decision, determine:
+
+1. **What was decided** — the concrete choice made
+2. **Evidence** — where in the codebase this decision is visible (file paths, config keys, code patterns)
+3. **Alternatives rejected** — what the obvious alternatives were (only state what is inferable from context; do not fabricate)
+4. **Rationale** — why this choice was likely made (from docs, comments, or strong inference from context)
+5. **Consequences** — what this decision enables or constrains
+6. **Strength of commitment** — how deeply embedded this decision is:
+   - **Deep** — changing it would require rewriting large parts of the codebase
+   - **Moderate** — changing it would require coordinated updates across multiple files
+   - **Shallow** — changing it is a config tweak or small refactor
+
+### Phase 4: Cross-reference with problems
+
+For each decision, check the unresolved problems document:
+- Does this decision appear as a source of unresolved questions? If so, note the tension.
+- Does this decision have contradictions flagged? If so, include them.
+- Is this decision identified as a risk? If so, note the risk level.
+
+## Output format
+
+Produce the document as a single markdown file with the following structure. Every section is required. If a section does not apply, write "Not applicable" with a brief reason.
+
+```
+# Key Decisions: {project name}
+
+## Executive summary
+
+{5-10 bullet points capturing the most consequential decisions in this project. Each bullet should name the decision and its primary rationale in one sentence.}
+
+## 1. Language & runtime
+
+### Primary language
+{Language, version constraints, module system (ESM/CJS/both). Evidence: file paths.}
+
+### Runtime
+{Runtime(s), version requirements, platform targets. Evidence: engine fields, CI matrix, Dockerfiles.}
+
+### Module system
+{ESM, CJS, or dual. How imports/exports are structured. Evidence: tsconfig, package.json type field.}
+
+## 2. Framework & libraries
+
+### Core framework
+{Framework choice and version, or "no framework" if applicable. Why this framework. Evidence.}
+
+### Key library decisions
+{For each significant dependency, document as a subsection:}
+
+#### {Library name}
+- **Purpose**: {what it does in this project}
+- **Version**: {pinned version or range}
+- **Alternatives considered**: {if inferable}
+- **Evidence**: {package.json path, import locations}
+
+## 3. Build & tooling
+
+### Package manager
+{npm, yarn, pnpm, bun — and version. Evidence: lock file, packageManager field.}
+
+### Build system
+{Compiler/bundler/build tool. Configuration. Output format. Evidence.}
+
+### Linting & formatting
+{Tools, configuration style, custom rules. Evidence: config file paths.}
+
+### Type checking
+{TypeScript strictness level, key compiler options. Evidence: tsconfig path.}
+
+### Test runner
+{Framework, configuration, assertion library. Evidence.}
+
+## 4. Architecture & patterns
+
+### Architectural style
+{Monolith/microservices/serverless/library/CLI tool/etc. Layer structure if any. Evidence.}
+
+### Design patterns
+{Recurring patterns with specific file references:}
+
+#### {Pattern name}
+- **Description**: {how the pattern is applied}
+- **Examples**: {2-3 file paths demonstrating the pattern}
+- **Rationale**: {why this pattern, if inferable}
+
+### Module boundaries
+{How the codebase is divided into modules. What rules govern cross-module imports. Evidence.}
+
+### Dependency flow
+{Which modules depend on which. Direction of dependencies. Any dependency inversion. Evidence.}
+
+## 5. File organization
+
+### Directory structure
+{Top-level layout with purpose of each directory.}
+
+### File naming convention
+{Pattern: camelCase, kebab-case, PascalCase, prefix notation, etc. Evidence: actual file names.}
+
+### File granularity
+{One function per file, one class per file, grouped by feature, etc. Evidence.}
+
+### Import conventions
+{Path aliases, barrel files, relative vs absolute imports. Evidence: tsconfig paths, import statements.}
+
+## 6. Type system
+
+### Strictness level
+{TypeScript strict mode settings. Evidence: tsconfig.}
+
+### Shared types strategy
+{How types are shared across modules. Central type files, per-module types, or inline. Evidence.}
+
+### Type patterns
+{Discriminated unions, branded types, utility types, generic patterns used. Evidence: file paths.}
+
+## 7. Error handling
+
+### Error propagation strategy
+{Exceptions, Result types, error codes, or mixed. Evidence: code patterns.}
+
+### Custom error types
+{Any custom error classes or error factories. Evidence: file paths.}
+
+### Failure philosophy
+{Fail fast, graceful degradation, retry with backoff, or context-dependent. Evidence.}
+
+## 8. Testing strategy
+
+### Test framework & tools
+{Framework, assertion library, mocking approach. Evidence: config and test files.}
+
+### Test file placement
+{Co-located, separate directory, or mixed. Naming convention. Evidence.}
+
+### Test types present
+{Unit, integration, e2e, snapshot, property-based — which exist and which are absent. Evidence.}
+
+### Test coverage
+{Coverage tooling, thresholds, or absence of coverage tracking. Evidence.}
+
+### What is NOT tested
+{Notable gaps — untested modules, untested error paths, areas explicitly excluded. Evidence.}
+
+## 9. API design
+
+### Public API surface
+{Exports, CLI commands, HTTP endpoints, library interface — whatever applies. Evidence.}
+
+### Versioning & compatibility
+{Semver adherence, breaking change policy, deprecation approach. Evidence.}
+
+### Input/output contracts
+{Validation approach, schema definitions, type safety at boundaries. Evidence.}
+
+## 10. Data & state
+
+### Data flow
+{How data enters, transforms, and exits the system. Evidence.}
+
+### State management
+{Where state lives, how it is mutated, persistence mechanism. Evidence.}
+
+### Serialization
+{JSON, protobuf, msgpack, custom — and how serialization boundaries are handled. Evidence.}
+
+## 11. Async & concurrency
+
+### Async model
+{Promises, async/await, callbacks, streams, workers, or mixed. Evidence.}
+
+### Concurrency primitives
+{Locks, queues, semaphores, worker pools — if any. Evidence: file paths.}
+
+### Parallelism strategy
+{How parallel work is structured. Evidence.}
+
+## 12. Security & secrets
+
+### Authentication
+{Auth mechanism, if any. Evidence.}
+
+### Input validation
+{Validation approach at system boundaries. Evidence.}
+
+### Secrets management
+{How secrets are stored and accessed. Evidence: .env patterns, config files.}
+
+### Supply chain
+{Dependency auditing, lockfile integrity, pinning strategy. Evidence.}
+
+## 13. CI/CD & release
+
+### Pipeline structure
+{CI stages, triggers, matrix builds. Evidence: workflow files.}
+
+### Release process
+{Manual, automated, semantic-release, changesets, etc. Evidence.}
+
+### Versioning strategy
+{How versions are determined and bumped. Evidence.}
+
+### Artifact distribution
+{npm, Docker, binary, CDN — how the project is distributed. Evidence.}
+
+## 14. Developer experience
+
+### Local development
+{Dev server, hot reload, watch mode — how developers run the project locally. Evidence: scripts.}
+
+### Onboarding
+{README quality, setup steps, CONTRIBUTING guide. Evidence.}
+
+### Debugging
+{Debug configurations, source maps, verbose modes. Evidence.}
+
+## 15. Coding conventions
+
+### Naming rules
+{Function naming, variable naming, file naming, constant naming. Evidence: code patterns.}
+
+### Code organization rules
+{Import ordering, function ordering within files, export placement. Evidence.}
+
+### Comment style
+{When and how comments are used. Doc comment format. Evidence.}
+
+### Code limits
+{Line length, file length, function length — if any limits are visible or configured. Evidence.}
+
+## 16. Operational concerns
+
+### Logging
+{Logging library, structured vs unstructured, log levels. Evidence.}
+
+### Configuration management
+{Environment variables, config files, defaults. Evidence.}
+
+### Deployment
+{Deployment target, containerization, infrastructure. Evidence.}
+
+### Monitoring & observability
+{Metrics, tracing, health checks — if any. Evidence.}
+
+## 17. Decision tensions & trade-offs
+
+{Identify decisions that create tension with each other or with common practices. Cross-reference the unresolved problems document — many tensions surface there as open questions.}
+
+### {Tension title}
+- **Decision A**: {first decision}
+- **Decision B**: {second decision or common practice}
+- **Tension**: {how they conflict or create friction}
+- **Resolution**: {how the project handles it, if visible}
+- **Related problems**: {IDs from unresolved problems document, if any}
+
+## 18. Decision dependency graph
+
+{Identify which decisions constrain or enable other decisions:}
+
+| Decision | Enables | Constrains |
+|----------|---------|------------|
+| {decision} | {what it makes possible} | {what it limits} |
+
+## 19. Absent decisions
+
+{Decisions that most projects of this type make explicitly but this project has not. Cross-reference the unresolved problems document — many absent decisions surface there as gaps.}
+
+- **{Topic}**: No explicit decision found. Implicit default: {what the code does in practice}. Evidence: {absence of config, docs, or patterns}.
+
+## 20. Decisions at risk
+
+{Decisions flagged as problematic in the unresolved problems document. For each:}
+
+### {Decision}
+- **Current choice**: {what was decided}
+- **Risk identified**: {from unresolved problems document}
+- **Severity**: {Critical / High / Medium / Low}
+- **Decision stability**: {Is this decision likely to change? What would trigger a change?}
+
+## Summary
+
+### Decision philosophy
+{In 3-5 sentences, characterize the overall decision-making philosophy of this project. Is it convention-over-configuration? Explicit-over-implicit? Minimal? Maximal? Opinionated? Flexible?}
+
+### Top 10 decisions to understand first
+{Ordered list of the 10 most important decisions a new contributor must understand to be productive. Each with a one-line explanation.}
+
+### Decision maturity
+{Assessment of how well decisions are documented, enforced, and consistent across the codebase. Note areas where decisions are inconsistently applied.}
+```
+
+## Rules
+
+- **Use the research documents as primary source.** Do not repeat the full codebase scan. Read source files only to verify, clarify, or fill gaps.
+- **Evidence is mandatory.** Every decision must cite at least one concrete file path, config key, or code pattern. Decisions without evidence are not decisions — they are speculation.
+- **Distinguish explicit from implicit.** An explicit decision has documentation, config, or clear intentional code. An implicit decision is a pattern that emerged without documentation. Label each.
+- **Distinguish decision from accident.** Some patterns are deliberate choices; others are historical artifacts or defaults never reconsidered. Note the difference when visible.
+- **Be specific.** Include file paths, version numbers, config values, and function names. Vague descriptions like "uses modern patterns" are useless.
+- **Be honest.** If rationale is not visible in the codebase, say "Rationale not documented" rather than inventing one.
+- **No value judgments.** Report what the code does, not whether it is good or bad. "Uses X" not "Wisely uses X" or "Unfortunately uses X."
+- **Cover everything.** A missing section is worse than a section that says "Not applicable." Check every category.
+- **Quantify when possible.** "47 files follow this pattern, 3 do not" is more useful than "most files follow this pattern."
+- **Follow the chain.** When you find a decision, trace its consequences. A TypeScript strict mode decision affects type definitions, error handling, and testing patterns.
+- **Cross-reference the problems document.** Decisions that generated unresolved problems deserve extra attention. Note the connection explicitly.
+- **Note contradictions.** If two parts of the codebase make contradictory decisions, flag it explicitly.
+
+## Output
+
+Output only raw markdown. No preamble, no explanation, no commentary outside the document structure.

package/dist/_workflows/prompts/PROMPT_PRODUCT_NAME.md

@@ -0,0 +1,101 @@
+You are naming a software product. This is harder than it sounds — a good name is memorable, short, available, and captures the essence of what the tool does without being generic. And in this case, it should make someone smile.
+
+## Context
+
+- **Output File Path**: {outputPath}
+- **Original source repository:** {sourceFullName}
+- **Local checkout path:** {originalCheckoutPath}
+
+**Input documents — read all before starting:**
+
+- **Product Pitch**: {productPitchPath} — the complete product description. Understand what this tool does, who it's for, and what makes it distinctive.
+- **Research Summary**: {researchPath} — technical analysis of the original project.
+- **Key Decisions**: {decisionsPath} — architectural and design decisions.
+
+## Research before naming
+
+Before you pick a name, you MUST research the competitive landscape. Use the `gh` tool and web search to:
+
+1. **Find existing tools in the same space.** AI-powered code generation, project scaffolding, AI workflow orchestration, repository bootstrap tools. List every competitor you find.
+2. **Catalog their names.** What naming patterns do they use? What's overused? (hint: everything with "ai", "co", "pilot", "gen", "auto" in the name is exhausted)
+3. **Check npm for collisions.** Before finalizing, verify the name isn't already taken on npm. Use `npm search {name}` or check `https://www.npmjs.com/package/{name}`.
+4. **Check GitHub for collisions.** Search for repos with the candidate name.
+5. **Check domain availability.** For your top candidates, check if `{name}.dev`, `{name}.io`, or `{name}.com` are available and affordable (under $5k). Use WHOIS lookups or domain search tools. A name with an available domain under $5k is strongly preferred over one without.
+
+Include a "## Competitive landscape" section in your output showing what you found.
+
+## The vibe
+
+The name must be **goofy**. Not corporate-goofy like "Sagemaker" or startup-goofy like "Humane." Actually funny. The kind of name that makes a developer do a double-take, chuckle, and then remember it forever.
+
+Think about names like:
+- **yeet** — you wouldn't forget a CLI tool called yeet
+- **bonk** — it just sounds fun to type in a terminal
+- **lmao** — irreverent but memorable
+- **oops** — self-aware humor
+- **bruh** — internet culture meets developer tooling
+- **yolo** — the attitude of running AI code generation on your repo
+
+The name should feel like something you'd say right before doing something bold with your codebase. It should match the product's personality: confident, slightly unhinged, technically serious underneath the humor. The kind of name where the README makes you laugh but the tool makes you productive.
+
+**Do NOT pick any of the example names above.** They're just illustrations of the vibe. Find your own.
+
+## What to produce
+
+Generate a YAML frontmatter with the chosen product name and rationale, followed by a brief markdown body.
+
+```
+---
+productName: "{the chosen name}"
+---
+
+# Naming: {the chosen name}
+
+## Competitive landscape
+
+| Tool | What it does | Name style |
+|------|-------------|------------|
+| {tool} | {description} | {serious/playful/generic/etc} |
+(list all competitors found)
+
+{1-2 sentences on naming patterns in this space and what's overused.}
+
+## Why this name
+
+{2-3 sentences. Why this name is funny, memorable, and fits. What it evokes. Why a developer would grin the first time they type it in a terminal.}
+
+## Considered alternatives
+
+| Name | Why considered | Why rejected |
+|------|---------------|--------------|
+| {name} | {reason} | {reason} |
+(5-10 alternatives, at least half should be goofy)
+
+## Name properties
+
+- **Memorable:** {yes/no and why}
+- **Goofy factor:** {what makes it funny}
+- **Short:** {character count, syllable count}
+- **Domain-friendly:** {would work as productname.dev or similar}
+- **CLI-friendly:** {works as a terminal command — short, no special chars, fun to type}
+- **Searchable:** {not a common English word that pollutes search results}
+- **npm available:** {yes/no — did you check?}
+- **Domain available:** {which domains checked, which are available, estimated price}
+```
+
+## Naming rules
+
+- **Max 12 characters.** Shorter is better. 4-8 is ideal.
+- **Must be goofy.** If it doesn't make someone smile, try again. The humor can be subtle or obvious, but it must be there.
+- **Lowercase-friendly.** Must work as a CLI command and npm package name.
+- **No generic words.** "devtool", "aihelper", "codebot" — these are descriptions, not names.
+- **No forced acronyms.** If it doesn't spell naturally, don't force it.
+- **No "AI" in the name.** Every tool has AI now. It's not a differentiator, it's a commodity. Putting "ai" in your name is like putting "electric" in a car name in 2026.
+- **Evocative over descriptive.** The name should hint at what the tool feels like to use, not literally describe its function.
+- **Actually check for collisions.** Search npm and GitHub. A name that's already taken is not an option no matter how good it is.
+- **Domain matters.** Strongly prefer names where `{name}.dev`, `{name}.io`, or `{name}.com` is available for under $5k. A great name without a domain is worse than a good name with one.
+- **Consider the terminal experience.** `$ {name} bootstrap` — does it feel good to type? Does it make the developer smile every time?
+
+## Output
+
+Output only raw markdown with YAML frontmatter. No preamble, no explanation.