██╗    ██╗██████╗ ██╗   ██╗███╗   ███╗
██║    ██║██╔══██╗╚██╗ ██╔╝████╗ ████║
██║ █╗ ██║██║  ██║ ╚████╔╝ ██╔████╔██║
██║███╗██║██║  ██║  ╚██╔╝  ██║╚██╔╝██║
╚███╔███╔╝██████╔╝   ██║   ██║ ╚═╝ ██║
 ╚══╝╚══╝ ╚═════╝    ╚═╝   ╚═╝     ╚═╝

Rewrites your prompts into something your LLM can actually use — automatically, before it answers.

Install · How it works · Flags · FAQ · llms.txt

_{AI agents / LLMs: read llms.txt.}

Note

🚀 New in v3.0.0 · flash-only, and it never changes your task

wdym now rewrites only when a rule clearly helps, runs the result at once, and leaves your prompt alone otherwise. The approval gate and run modes are gone, and 30 principles are down to 8. The first prompt of a session takes 2 tool calls instead of 4. Release notes

---

What it does

wdym catches every prompt you submit in Claude Code or Codex, works out what you're trying to do, and rewrites it into a clearer version before your LLM sees it. You write the way you'd talk; wdym hands the model something it can actually work with.

It runs as a one-time install and then stays out of your way:

• Fires on its own. A UserPromptSubmit hook intercepts each prompt — no command to remember.
• Knows when not to. Slash commands, prompts of five words or fewer, and "thanks" / "ok" / "continue" follow-ups pass straight through.
• Runs once per prompt. A reply that a Stop hook sends back, or a turn that Claude Code starts on its own (a background task reporting in), does not trigger a second rewrite.
• Detects the type. It classifies each prompt as code, question, or text-gen and pulls the principles that fit that type.
• Adds only what the session already knows. It names the file or function you meant, states what done looks like, and bounds the change. It never invents facts and never adds [fill-this-in] placeholders.
• Never changes your task. A rewrite keeps your request's intent and scope — no wider, no narrower, no extra questions.
• Leaves good prompts alone. If no rule clearly helps, your prompt runs exactly as typed.
• Stays out of the way. The rewrite runs at once. There is no approval gate.

Who is this for

Anyone who writes prompts faster than they polish them. If you use Claude Code or Codex all day and your prompts come out as half-formed thoughts, wdym does the polishing so you don't have to slow down. It's a single install per project or across every project, and after that it's automatic.

Installation

Three ways in. On Claude Code, the plugin is the simplest. The installer covers Codex and gives you the most control. The third option is for people already managing skills with the skills CLI.

Option 1 — the Claude Code plugin (recommended on Claude Code)

/plugin marketplace add ndisisnd/wdym
/plugin install wdym@wdym

The plugin brings its own UserPromptSubmit hook, so there is nothing to wire. It fires on every substantive prompt as soon as it is enabled. Then run /wdym --init once. It writes your pref.json and the trust contract into CLAUDE.md, which a plugin cannot do for itself. Updates arrive through /plugin like any other plugin.

Coming from a 1.x install? Remove the old skill first, then install the plugin. See Reinstalling, or moving to the plugin.

Option 2 — the installer (Codex, or full control)

curl -fsSL https://raw.githubusercontent.com/ndisisnd/wdym/main/install.sh | bash

That is the whole install. It detects which hosts you have — ~/.claude, ~/.codex, or both — lays down the skill files, wires the UserPromptSubmit hook, writes the trust contract into the host's instruction file, and creates your pref.json. Global is the default, so wdym fires in every project you touch. It pulls a tarball into a temp dir — no clone, nothing left behind.

Say so explicitly when the defaults aren't what you want. Piped into bash, flags go after -s --:

curl -fsSL .../install.sh | bash -s -- --both            # Claude Code and Codex
curl -fsSL .../install.sh | bash -s -- --claude --local  # this project only (Claude Code)
curl -fsSL .../install.sh | bash -s -- --on-demand       # install inert; runs only via /wdym

Or with the script on disk: ./install.sh --both.

Flag	What it does
--claude / --codex / --both	Pick the host. Default: whichever of ~/.claude and ~/.codex exists
--global, -g	Global install — the default
--local, -l	Local install into ./.claude for this project (Claude Code only)
--dir <path>	Local install into another project directory
--hook	Fire on every prompt — the default
--on-demand	Install inert; run only via /wdym, no hook wired
--copy	Copy the skill for Codex instead of symlinking it
--tarball <url|path>	Install from a specific tarball instead of main
--force	Skip the "you're inside the wdym repo" guard
--uninstall	Remove wdym at the chosen hosts and scope. Keeps pref.json and telemetry
--purge	With --uninstall, also delete pref.json and telemetry

Local always wins over global when both exist, so you can install globally and still override one repo. Re-run the installer any time — it is idempotent, keeps your pref.json and telemetry, and collapses a duplicated hook entry back to one if an earlier install left two behind. It needs python3, tar, and either curl or wget.

Already have the files on disk and just want to rewire? /wdym --init does the init half on its own.

Installing for Codex

Four things worth knowing, none of them blockers:

• Hooks are on by default in Codex, so there is nothing to enable first.
• Codex trusts hooks by file contents, so every install or update needs one manual step: run /hooks inside Codex and approve the wdym hook. Until you do, wdym stays silent and Codex will not warn you — prompts simply pass through unchanged. The installer prints this reminder last on every Codex run. To confirm it worked: submit any prompt, then run $wdym --status.
• The classification block is currently visible. Codex renders hook context as a visible developer message (openai/codex#16933, still open), so wdym's one-line signal shows up above the answer. Cosmetic only.
• Global scope only. --codex --local is refused on purpose: a repo-scoped Codex hook lives in a committed file, which would hand every teammate an approval prompt for a tool they never installed.

Codex users type $wdym where this README writes /wdym. Everything else is identical.

Option 3 — npx skills add

If you already manage skills with the skills CLI, wdym installs like any other package:

npx skills add ndisisnd/wdym          # this project
npx skills add ndisisnd/wdym -g       # every project (user-level)

Then finish the setup:

/wdym --init

That second step isn't optional. skills add delivers the skill files and stops there — it's a package manager, not wdym's installer. It doesn't know wdym has a hook to wire, a pref.json to write, or a trust contract to install. Without --init you get a skill that only answers to /wdym and never fires on its own.

/wdym --init asks you the same two questions the installers take as flags — scope (local or global) and activation (hook or on-demand) — then writes all three pieces.

Which one to use

	plugin	install.sh	npx skills add
Claude Code	✅	✅	files only
Codex	❌ use install.sh --codex	✅ global scope only	❌ use install.sh --codex
Skill files	✅	✅	✅
Hook	✅ ships with the plugin	✅	via /wdym --init
pref.json, trust contract	via /wdym --init	✅	via /wdym --init
Updates	/plugin	re-run it	npx skills update
Where it lives	~/.claude/plugins/	~/.claude/skills/wdym	.claude/skills/wdym or ~/.claude/skills/wdym

The installer and npx skills add land the skill in the same place — .claude/skills/wdym for project scope, ~/.claude/skills/wdym for global — so pick whichever fits your workflow. /wdym --init is idempotent across both.

Reinstalling, or moving to the plugin

Use these steps to replace a skill install (from install.sh or npx skills add) with the plugin. The order matters: remove the old skill before you run /wdym --init. While the old copy is on disk, /wdym can run the old 1.x code, which wires the old hook again.

1. Remove the old skill. Your pref.json and telemetry stay, so your settings carry over:

   curl -fsSL https://raw.githubusercontent.com/ndisisnd/wdym/main/install.sh | bash -s -- --uninstall

   For a local install, run it from that project with --claude --local --uninstall. If you installed with npx skills add, run npx skills remove wdym as well.

2. Add the marketplace and install the plugin:

   /plugin marketplace add ndisisnd/wdym
   /plugin install wdym@wdym
   

3. Restart the session, so the plugin's skill and hook load.

4. Run /wdym --init once. It writes the trust contract back into CLAUDE.md.

To reinstall the plugin itself, run /plugin uninstall wdym@wdym, then /plugin install wdym@wdym. You do not need /wdym --init again: the contract and your pref.json live outside the plugin and survive.

To reinstall a script install, just re-run the installer. It is idempotent.

Uninstalling

• Plugin: /plugin uninstall wdym@wdym. Then remove the contract block from ~/.claude/CLAUDE.md (between the wdym-auto-invoke markers), or run ./install.sh --claude --uninstall, which removes it for you.
• Installer or npx skills add: run the installer with --uninstall. It removes the skill files, the hook entry, and the trust contract on every detected host. Add --purge to delete pref.json and telemetry as well.

curl -fsSL .../install.sh | bash -s -- --uninstall           # every detected host, global
curl -fsSL .../install.sh | bash -s -- --uninstall --purge   # ...and your settings
curl -fsSL .../install.sh | bash -s -- --claude --local --uninstall  # this project only

A dev install that symlinks the skill dir loses only the link, never your checkout.

Confirming it works

To confirm it's wired up, submit any normal prompt, then run /wdym --status: the prompt shows up in the counts. /wdym --status reports the same thing from inside the session — scope, activation, and where the files came from. On Codex, run $wdym --status after approving the hook with /hooks; hook approval is the one thing only Codex itself can confirm.

How it works

Just write, and wdym translates it for you.

flowchart TD
    submit["You submit a prompt"]
    activation{"Activation"}
    hook["UserPromptSubmit hook<br/>scores the prompt deterministically"]
    manual["No hook fires —<br/>you invoke wdym yourself"]
    verdict{"Verdict"}
    skip["Passthrough — runs as-is, untouched"]
    block["Emits a prompt-detect block:<br/>a classified type, or ambiguous for the model to judge"]
    contract["Host reads its trust contract<br/>and invokes the skill"]
    skill["Pick the principles that clearly apply"]
    fits{"Any clear fit?"}
    rewrite["Rewrite — same task, no invented facts"]
    asis["Run as typed"]
    run["Your prompt runs"]
    telemetry["Appends one local telemetry line"]

    submit --> activation
    activation -->|"hook"| hook
    activation -->|"on-demand"| manual
    hook --> verdict
    verdict -->|"slash, 5 words or fewer, follow-up"| skip
    verdict -->|substantive| block
    block --> contract
    contract --> skill
    manual --> skill
    skill --> fits
    fits -->|yes| rewrite
    fits -->|no| asis
    rewrite --> run
    asis --> run
    skip --> run
    run --> telemetry

Loading

Two hosts, one flow. That path is the same on Claude Code and on Codex. Only four plumbing details differ, and the installer handles all four for you:

	Claude Code	Codex
Trust contract	~/.claude/CLAUDE.md	~/.codex/AGENTS.md
Skill path	~/.claude/skills/wdym	~/.agents/skills/wdym — a symlink to the Claude Code copy
Hook file	~/.claude/settings.json	~/.codex/hooks.json
Asking you	AskUserQuestion tool	plain-text question, then it stops and waits

The same path in words:

1. Catches it — a UserPromptSubmit hook intercepts the prompt. Slash commands, ≤5-word prompts, and "thanks" / "ok" / "continue" follow-ups wave straight through untouched — no ceremony for small talk.
2. Figures out what you meant — classifies the prompt as code, question, text-gen, or none. ~95% of real prompts resolve deterministically in the hook (zero tokens); only genuinely mixed signals go to the LLM to adjudicate.
3. Picks what clearly helps — eight principles in total: five for every prompt, one more for code, two more for text work. It applies up to three that clearly fit, and none when nothing does.
4. Rewrites it, carefully — it adds only what the prompt or the session already holds: the file you meant, what done looks like, how far the change may reach. It never invents facts, never adds placeholders, and never changes the task.
5. Ships it — the rewrite, or your prompt as typed, runs at once. There is no approval gate.

For the full flow, file map, and design notes, see ARCHITECTURE.md.

Flags

wdym has one behaviour: rewrite when a rule clearly helps, run at once, and leave the prompt alone otherwise. There are no run modes. Drop these into a prompt (or run them standalone):

Flag	What it does
--global	Forces the universal principle base and skips type detection for this run. Good for one-off, type-agnostic prompts.
--init	Bootstraps the skill — writes pref.json, wires the hook, and installs the trust contract, asking scope and activation.
--status (alias --stats)	Prints a styled usage report — prompts seen, transform rate, a ranked by-type breakdown. Telemetry stays 100% local.
--help	Lists all commands, modes, and prompt types with one-liners.

How to update

If you installed the plugin, update it from /plugin. Your pref.json and telemetry live outside the plugin, so an update keeps them.

Update wdym itself by re-running the installer. It is idempotent and never touches your pref.json or telemetry:

curl -fsSL https://raw.githubusercontent.com/ndisisnd/wdym/main/install.sh | bash

If you installed with npx skills add, update through the same CLI:

npx skills update wdym

On Codex, re-approve after every update. Codex trusts hooks by file contents, so an update invalidates the old approval — run /hooks in Codex and approve the wdym hook again, or it goes quiet without saying so.

Rewire an install you already have on disk — after editing settings by hand, if the hook came unwired, or after a skills update — with /wdym --init, which redoes the init half without reinstalling.

Check what's actually wired with /wdym --status ($wdym --status on Codex): it reports the resolved scope and activation from inside the session. Codex hook approval is the one thing it can't read — that lives inside Codex, so confirm it with /hooks there.

FAQ

Does it cost tokens on every prompt? Mostly no. The hook scores each prompt deterministically with keyword and regex matching, so ~95% of real prompts resolve to a type with zero model tokens. Only genuinely ambiguous prompts go to the LLM to adjudicate.

What if I like my original prompt? Then wdym most likely leaves it alone: a prompt that already names its target, its goal, and its scope runs exactly as typed. When it does rewrite, the rewrite keeps your task and adds only what the session already holds. To stop it firing on its own, run /wdym --init --on-demand.

Where did the approval gate go? v3.0.0 removed it, along with --set-mode, --flash, and --comprehensive. A gate made sense when rewrites could add new constraints. v3's rewrites cannot, so the gate only cost you a click.

Will it rewrite my slash commands and one-liners? No. Slash commands, prompts of five words or fewer, and short follow-ups like "thanks", "ok", and "continue" pass straight through untouched.

Where does my usage data go? Nowhere. Telemetry is an append-only local file (telemetry.jsonl) in the install directory, read only by /wdym --status. It never leaves your machine.

Global or local install? Global is the default and covers every project. Install --local when you want it scoped to one repo; a local install always wins over the global one, so you can do both. Codex is global-only — see the Codex notes under Installation.

Does it work with Codex? Yes, from v1.2.0. ./install.sh --codex (or --both) wires it: the skill is exposed at ~/.agents/skills/wdym, the hook goes into ~/.codex/hooks.json, and the trust contract into ~/.codex/AGENTS.md. One manual step remains — approve the hook with /hooks inside Codex after every install or update.

License

MIT

Acknowledgments

• mkpub for generating this README

---

Dedicated to JC 🍙, who runs 10x more prompts than I do.