# Promptmaster > Rewrite the user's raw request into an optimized prompt before answering it, audit it against the 35 credit-waste patterns in waste-patterns.json, and enforce every locked decision in decisions.md so nothing gets re-explained and nothing contradicts itself. Use whenever the user types /promptmaster, prefixes a request with it, or asks to optimize / tighten / fix a prompt. - Skill: `jakeschincariol/promptmaster` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds@latest add jakeschincariol/promptmaster` - Raw SKILL.md: https://api.skillmd.com/api/skills/jakeschincariol/promptmaster/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: Jakeschincariol (https://skillmd.com/u/jakeschincariol) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jakeschincariol/promptmaster --- # Promptmaster Get it right the first prompt. The user hands you a raw, messy, underspecified request. You turn it into a prompt that lands on the first try, then execute it. The goal is fewer turns: one optimized prompt instead of five rounds of re-explaining. ## The loop Run these five steps, in order, every time. ### 1. Load locked decisions Read `decisions.md` from the project root (create it from the template in this skill folder if the user locks something and it does not exist yet). In a chat without a filesystem, keep the decisions table in the conversation instead. Every locked decision is a standing order. Apply all of them to the rewrite without being asked. Never produce output that violates a locked decision. If the user's new request contradicts one, stop and say so: > This contradicts a locked decision (`length: under 200 words`, locked > 2026-08-14). Say `unlock length` to change it, or I'll keep the lock. Do not silently pick a side. Blocking the contradiction is the feature. ### 2. Rewrite the raw request Turn the vague ask into a specific one. Plain English, not a jargon template. A good rewrite answers, in one tight block: - **What exactly** gets produced (the deliverable, named: a table, a script, a file) - **For whom** (audience and what they already know) - **How big** (word cap, item count, duration) - **Hard constraints** (tools, stack, budget, deadline, do-not-touch list) - **Done when** (how the user will judge it finished) Example, the whole move in one line each: Raw: `write me something for instagram, idk` Rewritten: `Write a 30-day Instagram plan for a local coffee shop with 8k followers. One table: week, theme, 3 post ideas. Under 400 words.` Pull the specifics from three places, in this order: what the user already said in this conversation, the locked decisions, and only then sensible defaults. If one fact is genuinely missing and guessing wrong would waste a full turn (the audience, the quantity, the platform), ask for it in ONE batched question with a default offered for each item. One round of questions max. Never drip. ### 3. Audit against the 35 patterns Check the RAW request against every pattern in `waste-patterns.json`. Note each one it trips by id and name. The rewrite in step 2 must clear every flagged pattern. If your own rewrite still trips one, fix the rewrite. ### 4. Show the work, briefly Before the answer, print a compact header so the user sees what changed: ``` PROMPTMASTER rewrote: "write me something for instagram, idk" into: "30-day IG plan, local coffee shop, 8k followers, one table, <400 words" flagged: #1 no deliverable named, #2 no audience, #3 no length, #5 hedging applied: voice=casual (locked), emojis=never (locked) ``` Keep it to those four or five lines. The header is a receipt, not an essay. ### 5. Execute the rewritten prompt Answer the optimized prompt in full, in the same turn. The user should get the finished deliverable, not homework. Only skip execution when the user explicitly asks for the rewrite alone ("just optimize this, don't run it"). ## Locking and unlocking decisions When the user states a durable preference, or accepts one you proposed, lock it: - `lock: voice = casual, like I talk` appends a row to `decisions.md` - `unlock voice` removes it - `decisions` prints the current table Also lock decisions the user makes in passing ("never use emojis", "keep everything under 200 words") without requiring the `lock:` syntax. Confirm in one line: `locked: emojis = never`. When in doubt whether something is a one-off or a standing rule, ask in the same turn. ## Hard rules - Never make the user say the same thing twice. If it was said, it is context. If it is standing, it is locked. (Pattern #35: redundant context.) - Never contradict a locked decision. Surface the conflict instead. - One clarifying round maximum, batched, with defaults. Then commit. - The rewrite must be shorter or equal to the raw request plus its missing facts. Optimizing never means padding. - The receipt header is mandatory. It is how the user learns to write the tight version themselves.