prompt-upgrade

SKILL.md

---
name: prompt-upgrade
description: Used to help me create more creative prompts. When I am frustrated about not being able to describe something beautiful, interesting, creative, or whatever, this is the skill to use.
---

name: prompt-upgrade\
description: Rewrite a thin or vague prompt into a fully-constrained, high-yield brief before it goes to an AI model, for any harness or task type — code, design, writing, research, 3D, anything. Use when the user says "upgrade this prompt", "make this prompt better", "flesh out this prompt", "turn this into a proper brief", "what would a great prompt for X look like", or "prompt-upgrade"; when the user pastes a short task description and asks how to get better results from an AI; or proactively when handed a one-line task and asked to write the prompt first rather than do the task. ---

# Prompt Upgrade

Rebuilds a thin prompt into a constrained, high-yield brief on a fixed\
seven-slot skeleton, and shows its work so the user can strike or edit\
anything before sending it.

## The skeleton

Every upgraded prompt is built on these seven parts, in this order:

1. **Goal + register** — one sentence stating what, plus a deliberately\
   chosen style/lane (e.g. "cinematic and stylized, not photorealistic").\
   The register is a design decision that tells the model which tradeoffs\
   to make, not a decorative adjective.
2. **Component inventory** — an explicit noun list of every part the output\
   must contain. Each noun becomes something the result can be visibly\
   missing, which stops the model silently dropping parts.
3. **Failure modes as prohibitions** — name what the lazy/average version of\
   this output looks like and forbid each item ("no placeholder text", "no\
   sluggish motion"). Highest-leverage slot: naming the model's average\
   behavior and forbidding it removes it.
4. **Pre-decided forks** — resolve the decisions the model would otherwise\
   stall on or guess wrong: scope (blank slate vs. build on X), deliverable\
   format, allowed inputs/assets/libraries, who picks tools.
5. **The central tradeoff, with a stated lean** — e.g. "quality vs.\
   real-time performance — keep it smooth without an obvious quality\
   sacrifice."
6. **Verification loop** — how to actually test the result (run it, open\
   it, screenshot it, read console/logs/tests), a concrete defect list to\
   check for, fix everything found, then re-verify against a final\
   acceptance list.
7. **Response shape** — what the final reply should look like ("finish with\
   only a brief response").

Standing rule: the upgraded prompt describes OUTCOME and ACCEPTANCE at high\
resolution and leaves METHOD open. Never prescribe libraries, algorithms, or\
implementation steps unless the user's original prompt already did.

## Modes

ModeUse whenHow`infer-and-mark` (default)No flag given.Draft every slot, mark inferred lines.`--ask`User passes `--ask` or says "ask me first".Delegate to `grilling`'s interview mode.

### infer-and-mark (default)

Draft every slot from what is known about the task domain. Mark every line\
that was inferred rather than stated or clearly implied by the user with\
`[inferred]` at the end of the line; say once, before the prompt, that\
unmarked lines come from the user's own prompt. After the upgraded prompt,\
append "Assumptions to confirm" — at most 5 bullets, the inferences that\
most change the result if wrong. Keep the upgraded prompt itself clean\
enough to copy-paste once the marks are stripped: stripping is one\
find-and-replace of `[inferred]`.

### --ask

Do not infer. Invoke the `grilling` skill's `interview` mode for\
one-question-at-a-time extraction, scoped to slots 3–6 (failure modes,\
pre-decided forks, the central tradeoff, verification). Keep it to the 3–5\
questions that matter most: what does the bad version look like, how will\
you know it's done, what's the deliverable, what's already decided. Do not\
reimplement an interview inside this skill — assemble the answers into the\
same seven-slot shape once `grilling` concludes.

## If the prompt is already well-constrained

Say so, and propose at most 2–3 additions instead of rewriting it.

## Output format

Produce exactly these four parts, nothing else — no lecture on prompting\
theory:

1. One line: the register chosen, and why.
2. The upgraded prompt, sectioned by the seven slots (short headers or\
   clear paragraph breaks), inferred lines marked.
3. "Assumptions to confirm" (max \~5 bullets).
4. One line: how to strip the marks.

## Guardrails

- Never invent domain facts as if the user stated them — that is what marks\
  are for.
- Don't pad. A good upgraded prompt is typically 150–400 words.
- Never add a requirement that contradicts something the user stated.
- Keep the user's original wording where it was already precise.

## Worked example

Pirate-ship 3D scene, annotated — a\
well-formed thin prompt walked through all seven slots.

A second, shorter case, to show the skeleton isn't 3D-specific:

> Input: "Write a landing page for my bakery."
> ****Goal + register:** A production-ready, warm, appetite-forward bakery\
> landing page — not a wireframe or copy-only draft. \[inferred\]\
****Components:** hero (name + tagline), about blurb, menu/product\
> highlights, hours + location, a call to action, footer with contact.\
> \[inferred\]\
****Prohibitions:** no lorem ipsum, no generic stock-photo copy ("delicious\
> treats await"), no unstyled default HTML, no fabricated address or hours.\
> \[inferred\]\
****Pre-decided forks:** blank-slate build, single static HTML+CSS file, no\
> framework; no real photos — use CSS/SVG for visual interest; bakery name\
> and details are unknown, so use bracketed placeholders like \[BAKERY NAME\].\
> \[inferred\]\
****Tradeoff:** visual polish vs. build time — lean toward one smaller,\
> fully finished page over several thin sections. \[inferred\]\
****Verification:** open the file in a browser, confirm the layout holds at\
> mobile width, confirm no placeholder bracket was left unfilled where a\
> real value was available. \[inferred\]\
****Response shape:** return the file, then a two-line summary. \[inferred\]

One thing to know when saving it in AgentsRoom: the --ask mode delegates to the grilling skill, which lives in the harness farm, not the AgentsRoom library. If the AgentsRoom copy will be used from a context without grilling, the --ask branch is inert and the default infer-and-mark mode is what you'll get — which is the mode you chose anyway.