This one dropped quietly on r/PromptEngineering this week and it’s worth a closer look.
A developer built seed.show, essentially npm for hardened prompts. Fifty prompt bundles covering domains where AI hallucination risk is highest: tax law, hiring compliance, SEO strategy, git workflows. Each one is called a “seed.” The word choice is intentional. A seed is not a full system prompt you copy-paste and forget. It’s a starting structure that grows with the task, pre-loaded with constraints most people figure out the hard way after their agent confidently cites a tax code that hasn’t existed since 2019. The bundles are already opinionated about where the sharp edges are in each domain, and they’re built around those edges specifically.
The install is one line for any agent with shell access:
Fetch & Install seed.show/marketing.seo.strategy
Claude Code, Cursor, Cowork, OpenClaw. The agent curls the URL, unpacks the bundle, runs the prompt. That part is clean. What makes it different from just keeping a prompts folder in your repo is that the bundle doesn’t assume you remember to update it. That’s the whole problem with most prompt libraries: they’re great when they’re written, increasingly wrong six months later, and nobody has a system to know when they’ve gone stale. The git commit history says the prompt was last touched in October. Whether it’s still accurate is a different question entirely.
Each seed bundles a sources.md with live URLs.
The agent fetches those URLs when it runs the task. Not when the seed was written. Not when you installed it. When it runs the task. So the “never cite a number from this file; fetch sources for current-year figures” constraint baked into the tax seed is not just a reminder. It’s structurally enforced by what the bundle actually contains.
Think about what that means concretely. The SEO strategy seed doesn’t just tell the agent “use current ranking signals.” It hands the agent a list of URLs to hit right now: Google’s Search Central blog, recent algorithm update documentation, current keyword research references. The agent’s working context includes today’s information, not last year’s. The prompt instructs the behavior, the sources.md provides the live data, and both ship together as one installable unit. You install once and the freshness problem mostly handles itself going forward.
That’s a different solution to prompt rot. Most people fix stale prompts by rewriting them. This makes the prompt reach out for fresh data at execution time instead. It’s a subtle shift but the second-order effect is meaningful: the maintenance burden moves from “who updates the shared prompt library” to “do the source URLs still serve authoritative content.” The second question is much easier to audit on a regular schedule.
How to try it:
- 🔎 Browse the seed catalog at seed.show and find your domain
- 📦 Copy the install line and run it inside your agent session
- The bundle unpacks into a README (mental model + common failure modes) and a sources.md (live authoritative links). Read the README first. It tells you what failure modes the seed was built to prevent, which tells you whether it actually fits your use case or just covers an adjacent one
- Run your task. Sources get fetched live at execution time, not install time
- 🎯 For high-stakes work like tax, legal, or hiring, audit those source URLs before trusting outputs blindly. Open each one manually, check who runs the site, when it was last updated, and whether it covers your jurisdiction. A seed for US employment compliance won’t handle Canadian labor law by default, even if both domains share similar hallucination risks
Pro tip: The URL is dual-mode. Hit it in a browser, you get a human-readable share page. Hit it from an agent (UA-sniffed), you get the bash installer. Same URL, two different renderers. That’s a pattern worth stealing for your own tools. If you’re building anything that agents and humans both need to consume, serving different responses based on the User-Agent string means you don’t have to maintain two separate endpoints or two separate docs. One canonical URL does both jobs, and sharing it with a teammate works the same as sharing it with an agent session.
One fair warning the community raised: prompt injection risk. If you’re running seeds in a production agent, check what those source URLs actually serve before you hand them authority. A seed’s sources.md is a list of URLs your agent will fetch and use as context. If any of those URLs has been compromised, redirected, or now serves adversarial content, your agent processes it without knowing anything changed. This is the same trust model as any third-party dependency and deserves the same due diligence: review sources periodically, and don’t install seeds from unofficial bundles you can’t trace back to a known author.
🚀 Worth bookmarking if you’re building agents that touch compliance, legal, or anything where hallucinating a specific number has real consequences.
Frequently Asked Questions
Q: Why is “prompt + live sources” better than a giant static prompt everyone copies?
Static prompts go stale not because the wording ages, but because the world around them changes: new documentation, API updates, policy shifts. With live sources, your prompt stays authoritative without rewrites. As one commenter put it, most agent failures aren’t about lack of capability anymore. They’re caused by bad assumptions, overconfidence, and stale context.
Q: Do I need different prompts for Claude vs. GPT vs. other models?
Yes. Different models respond better to different prompting styles. Check the model-specific guidelines (OpenAI’s latest docs and Claude’s prompt guides are both solid). The seed bundle pattern works across any model, but you may need to adjust the actual wording based on what your specific model responds to best.
Q: How do hardened constraints actually prevent agent failures?
Constraints like “always fetch current sources instead of relying on memory” or “AI cannot make the final decision alone” prevent overconfident hallucinations. They codify what not to do, which turns out to matter more than what to do. That’s where most real agent failures actually happen.
Q: Is downloading and running scripts from seed.show safe?
It’s a fair security question. Any script installation from a URL carries some risk. Only use seeds from sources you trust, and always review the README and sources.md first to understand exactly what you’re installing and what permissions it needs.
Q: What other seed categories would be most useful?
Commenters suggested incident response/oncall triage, RAG and eval pipelines, cloud cost optimization, startup due diligence, and compliance/security review workflows. These are complex operational areas where stale guidance leads to cascading failures.
I packaged 50 hardened-prompt bundles your agent can install with one line
by u/mm_cm_m_km in PromptEngineering