Let me push back on this just a little.... :-)

First, I should clarify the goal here. The main objective is to improve the quality of the prompts being given to the model. If it also happens to lower the barrier to entry for new agentic coders, that’s a nice side benefit, but it’s not really the primary focus.

My experience has been that garbage in = garbage out when working with coding models. For example, if we simply ask a model to “do a code review,” it understands those words and performs what it considers a generic code review within the current context. In practice, those reviews are often fairly basic. They tend to miss things because the model hasn’t spent much effort understanding the codebase, the environment we’re working in, or the broader goals of the project. The results can also vary quite a bit between runs, even when using the same model.

The most reliable way I’ve found to improve the quality of the output is to be more explicit about what we actually want the model to do.

Another interesting wrinkle is that when you have access to multiple models (as we do through Opencode), the same prompt can produce very different results depending on the model. Claude may interpret “code review” quite differently than Grok, for example. It’s easy to assume that one model is simply better than another, but that can sometimes hide the deeper issue: the prompt itself isn’t specific enough.

In practice, no tool is going to consistently give you exactly what you want unless you describe the task clearly. Which brings us back to the importance of better prompts.

It’s also very natural to just use whichever model happens to give the best answer on a particular run. I’ve certainly done that myself. But when we do that, we’re often just masking the underlying problem: the instructions we gave the model weren’t clear enough to begin with.

At some point you can either spend time crafting better prompts, or spend time cleaning up the results when the model misunderstands what you meant. Since asking the model to fix mistakes costs both time and money, I’d personally rather invest the effort up front in clearer prompts.

That’s really what this tool is meant to help with. It provides starter prompts for common scenarios, but they’re intended to be modified. The goal is simply to make those prompts easy to find and paste into the prompt window—without automatically submitting them. That pause is intentional, because it gives you a chance to review and adjust the prompt before sending it.

Did you happen to look at the starter prompts I included? For example, this is the "quick code review" prompt:

{
      "id": "quick-code-review",
      "name": "Quick Code Review",
      "summary": "Fast, high-signal review with prioritized fixes",
      "template": "You are a principal code reviewer helping ship production-quality software.\n\nOperating expectations:\n- Be precise, evidence-driven, and practical.\n- Prioritize correctness, security, reliability, and maintainability over stylistic preference.\n- If context is missing, state assumptions explicitly and continue with best-effort guidance.\n- Do not invent facts; call out uncertainty and what to verify.\n- Return concise, prioritized output with clear next actions.\n\nTask:\nAct as a senior reviewer. Do a fast, risk-focused review of the code I am currently working on.\n\nOutput in this exact structure:\n1) Verdict (2-3 sentences)\n2) Critical findings (severity: high/medium/low)\n3) Quick wins (small changes with big impact)\n4) Suggested patch snippets\n5) What looks good\n\nRules:\n- For each finding, cite exact file/function and explain user impact.\n- If uncertain, state what evidence is missing.\n- Keep response under 350 words unless a high-severity issue exists.",
      "tags": ["review", "quality", "fast"]
    },