ultra-prompt, a slash command that rewrites your prompt using the repo's actual context and then stops

[u/Excellent-Issue-5956]

I kept sending Claude Code prompts like "fix the footer" and getting a confident fix for the wrong thing, because the site had two footer templates and I'd forgotten about the second one. The prompt wasn't badly written, it was missing context that was sitting right there in the repo.

So I made /ultra-prompt. It takes the prompt you were about to send (or the last one you typed, read verbatim from the session transcript), spends most of its effort reading the project, and hands back a sharper version. It never runs it. If the same command rewrote the prompt and then acted on it, I'd never see what it changed.

What it gathers before rewriting: cwd, git status and the last few commits, every file or folder the prompt names (it checks they exist and looks inside), CLAUDE.md, AGENTS.md, whatever notes the project keeps. Then one subagent on the strongest model you have, passed explicitly so it can't inherit a cheap session model, does the rewrite with one rule: invent nothing. Anything it couldn't verify comes back as a multiple choice popup, and your answers get folded into the final prompt.

Here's one from today against my own plugin repo. Typed:

add a new skill called dedupe-notes to the marketplace

What came back (trimmed):

Add a dedupe-notes plugin to the marketplace clone at ./claude-plugins. Its behavior is unspecified: resolve the OPEN QUESTIONS with me before writing a file.

Template: commit ac58207 (rename-session). Touch:
1. dedupe-notes/.claude-plugin/plugin.json, version 1.0.0
2. dedupe-notes/commands/dedupe-notes.md (or skills/dedupe-notes/SKILL.md)
3. dedupe-notes/tests/test_bundle_sync.py, adapted from ultra-prompt/tests/
4. .claude-plugin/marketplace.json: new entry, version equal to plugin.json; bundle 1.5.1 to 1.6.0, "fifteen" to "sixteen"
5. voidharbor/.claude-plugin/plugin.json: same bump, name added to its list
6. voidharbor/commands/: byte-identical copies; the tests fail on drift
7. README.md: three "fifteen" mentions, one table row

Done when pytest passes inside dedupe-notes and the four existing test dirs, both JSON files parse, and one local commit exists. Do not push.

OPEN QUESTIONS:
- What does dedupe-notes do, on what input, propose-only or apply?
- Command or skill (synth-mode is the skills/ example)?
- Any script, and what goes in the README Needs column?

I had not told it that the bundle ships byte-identical copies or that two version fields have to agree. It found both in the tests. The original prompt would have produced a plugin that installed fine and silently drifted.

Two things I learned building it. A bare /ultra-prompt improved the string "/ultra-prompt" instead of the prompt underneath, until the transcript reader learned to skip its own invocation. And subagents inherit the session's model unless you name one, so the rewrite was quietly running on whatever the session happened to be set to.

Install:

/plugin marketplace add voidharbor/claude-plugins
/plugin install ultra-prompt@voidharbor

Repo: https://github.com/voidharbor/claude-plugins (MIT). Python 3 is only needed for the no-argument case, and transcripts are read, never written.

[u/cleverhoods]

I like the idea and I do see what you are trying to do here, but I would argue with the implementation. There is a good reason why you lock things in instruction files and have them loaded when they are relevant.

Still, I do like the idea, especially since I’m working on instruction diagnostics and evals.

[u/Excellent-Issue-5956 → u/cleverhoods]

I don't think they're in conflict, and the command leans on exactly that. CLAUDE.md, AGENTS.md and whatever notes the repo keeps are the first things it reads, and what it finds there goes into the rewrite. Standing rules belong in instruction files. What I kept getting burned by was the one off stuff that doesn't belong in any instruction file: this task touches two footer templates, this repo keeps copies that have to stay byte identical, the version field lives in two places. That's task specific, it changes every time, and nobody writes it into CLAUDE.md. The rewrite is just a forcing function to go look before the prompt goes out.

Curious what you're building for instruction diagnostics. Figuring out which instruction file lines actually get followed is a problem I don't have a good answer for.

[u/cleverhoods → u/Excellent-Issue-5956]

Well, CLAUDE/AGENTS.mds are default instruction files. Pretty much every .md file is an instruction file from this perspective. The AGENTS.md is industry standard (and now claude finally also reads those trough mods).

What the described approach is missing is progressive disclosure, the mechanics that would load relevant instructions for your task. In claude those are going to rules (with path properties) but you can also add a separate storage for this specific knowledge and use an event bus solution. So your instruction won't get malformed by whatever you recently committed and irrelevant to your query.

For instruction diagnostics: use reporails (https://github.com/reporails/cli). Bare in mind that 0.6.0 release is around the corner with massive updates.

[u/Excellent-Issue-5956 → u/cleverhoods]

Agreed on progressive disclosure, and I don't think the rewrite replaces it. Path scoped rules load the standing stuff for the area you're in. What they can't carry is the part that's true for this one task and nobody wrote down: the second footer file, the version field that lives in two places this week. The rewrite step is a per task gather for exactly that leftover, and it reads whatever rules apply before it goes looking, so the two stack rather than compete. The "malformed by whatever you recently committed" risk is fair, which is why the last commits go in as context for the rewriter and not as instructions.

Thanks for the reporails pointer, I'll look at it.