# Prompt: Discover and Build an Ambitious Open-Source Develo...

Prompt

# Prompt: Discover and Build an Ambitious Open-Source Developer Tool ## Role You are acting as principal engineer, product strategist, open-source maintainer, UX designer, security engineer, and technical cofounder — combined. You have real research tools (web search, code search) available and should use them, not rely on memory alone. ## What "done" looks like for THIS response Do not attempt the entire project in one pass — that produces either fake breadth or silent scope-cutting, both of which defeat the point. Instead, this response should deliver, in order: 1. A **visible** shortlist of 15 candidate ideas with scores (not hidden reasoning) — table format. 2. A **single chosen idea**, with the elimination logic shown briefly (why the other 14 lost). 3. A full **Phase 1 spec** (problem, users, use cases, non-goals, core insight, architecture, threat model, competitive analysis). 4. **One deeply real vertical slice** of the hardest, most differentiating mechanism — actual working code, not scaffolding — plus a clear, explicit list of what is *not* built yet and why. 5. A **roadmap** for the remaining phases (foundation → core engine → UX → integrations → hardening → release), scoped as separate follow-up sessions, each with its own realistic deliverable. End with a short "what I'd build next, and what I need from you to do it" section. Do not silently drop requirements — if something below can't be done for real in this pass, say so explicitly rather than faking it. ## Objective Find and build one open-source product with a real shot at wide developer adoption in 2026. It must: - Solve a painful, frequent, expensive problem - Serve multiple use cases, for individuals and teams - Have a strong, organic reason developers share it with each other - Have genuine open-source network effects - Be hard enough that an average developer couldn't casually clone it - Have a spectacular demo and real UX quality - Have a credible path from "GitHub repo" to "widely used tool" - NOT be primarily an AI-API wrapper, chatbot, RAG app, coding assistant, agent framework, or CRUD SaaS — the anti-crap filter below is a hard filter, not a suggestion If a core mechanism is the reason the project is interesting, implement it yourself — don't hide it behind a third-party API and call the glue code "infrastructure." ## Research (do this first, with actual tool calls) Investigate current state, not remembered state, on: GitHub trending / fast-growing repos, AI coding-agent workflows and their failure modes, agent memory/context/skills problems, agent reliability and security, software supply-chain issues, observability, local-first software, CI/CD pain, debugging pain, codebase complexity at scale, dependency/security tooling gaps, problems specifically caused by AI-generated code, and recurring developer complaints (forums, issue trackers, "why doesn't X exist" threads). Look for a **gap between existing categories**, not a copy of a single trending repo. Note where you found convergence between two or more trends — that intersection is usually where the opportunity is. ## Idea scoring (show this table) For each of 15 candidates, score 1–5 on: pain severity, frequency, addressable user base, existing competition (lower = more crowded), differentiation potential, technical moat, open-source fit, shareability, demo appeal, UX potential, monetization potential, expansion potential, and difficulty. Then state a probability-of-actual-adoption estimate per idea, in plain language, with your reasoning — not just the number. Optimize for: **high pain × large user base × strong differentiation × technical moat × shareability.** Do not optimize for "easiest to build." The winning idea should have a "why doesn't this already exist" quality — and you should verify that via research, not assert it. ## Anti-crap filter (hard rejection criteria) Reject any idea whose entire value would disappear if you removed the AI model from it. Specifically reject: API wrappers, chatbot/RAG variants, another coding assistant, another generic agent framework, another project-management app, CRUD SaaS, a dashboard with no underlying mechanism, or a clone with nicer styling. AI may be *a* component; it cannot be *the* product. ## Design principle: infrastructure, not a feature Prefer a system that solves several related problems through one underlying mechanism, over a single-purpose tool. State plainly what that underlying mechanism is and why it's hard to replicate. ## Constraints and assumptions No stack, license, or deployment target is specified. Choose sensible defaults (language/runtime, storage, packaging, license) based on what best fits the chosen idea's technical requirements and target audience, and **state your assumptions explicitly** rather than asking — unless the choice is truly a coin flip with major downstream consequences, in which case ask one specific question. ## Technical bar (stated once — applies throughout, not repeated per phase) Clean, modular, typed architecture; correct concurrency; proper persistence; fault tolerance with retries and idempotency; caching where it earns its complexity; real observability; explicit security boundaries; and a test strategy spanning unit, integration, and (for the vertical slice you actually build) end-to-end tests. For anything not yet built, name the failure modes you'd design against, rather than building a hollow version of it. ## UX bar Every screen must map to a real user task — no marketing-dashboard filler. For whatever surface you actually build (CLI and/or UI), include real empty states, loading states, errors, and recovery flows. Don't design screens for features that don't exist yet. ## Open-source release readiness For the parts you build, include a README that answers within 30 seconds: what problem this solves, why it's better than existing options (named, specific), and how to try it in under a minute. Defer the rest of the release checklist (issue templates, CoC, full CI matrix, etc.) to the roadmap unless you're actually producing them now. ## Competitive analysis Identify the closest real competitors/projects (aim for 8–10), what each does well, what each does poorly, the specific gap your idea fills, and why that gap is real rather than assumed. Verify claims of uniqueness via research — don't assert them. ## Self-critique (after the vertical slice exists) Attack your own work from five angles: a senior backend engineer, a staff infrastructure engineer, a security researcher, a first-time user, and a competitor trying to kill the project. Surface the highest-impact weaknesses and fix the ones you can fix now; list the rest as known limitations in the roadmap. ## Final standard Useful, difficult, fast, honest about its own gaps, open, and shareable. Success is a strong engineer looking at what you *actually built* — not the plan — and thinking "I'd install this."

A system prompt was added to support web rendering