| name | mimesis-compile |
| description | Use when the user wants text written for a machine reader, not a human: "write a prompt for", "compress this for an LLM", "turn this into instructions for an agent", "make this a system prompt", "compile this into a prompt". Produces dense, structured, token-efficient instructions tuned to current frontier models, with the right delimiters, constraint ordering and the instruction sandwich. AI tells are acceptable here. Bypasses the humanisation linter by design. Not for human-facing prose, which is mimesis-human's job. |
mimesis-compile
Domain B: the machine-facing side, and the deliberate opposite of the rest of
mimesis. The reader here is a model, not a person. Density, structure and literal
precision win. AI tells are fine. Em dashes are fine. The humanisation linter
must never run on this output, and this skill shares no machinery with the Domain
A skills. That separation is the whole design; breaking it is a bug.
How a run works
- Read reference/compile.md on every run. It is the
L1 corpus, keyed to GPT-4.1 / GPT-5.x, Claude Opus 4.x and Gemini 3.x as of
mid-2026, and it flags advice that has gone stale.
- Establish the target. If the user named a model (
--model, or "for Claude",
"for an OpenAI agent"), apply that family's notes from the matrix. If not, ask
once, or write to the cross-provider common denominator and say so.
- Compile. Two modes, detected from phrasing:
- rewrite: tighten an existing prompt or instruction block. Strip
preamble, reorder constraints hard-to-easy, fix delimiters, apply the
instruction sandwich for long context.
- draft: build a new prompt from a loose intent, using the section
skeleton in compile.md.
- Hand back the compiled prompt. Do not run the prose linter on it.
The rules that matter most
From compile.md, in priority order:
- Context engineering beats phrasing. Decide what goes in and where before
polishing any sentence.
- Hard-to-easy constraint order. Most specific and restrictive first.
- The instruction sandwich. Critical rules at the start and the end of long
context.
- Right delimiter for the job: Markdown skeleton, XML for fenced content and
examples, not JSON for document wrapping.
- Be specific about length. "Limit to 2 to 3 sentences", never "be concise".
- Strip preamble and politeness. Zero semantic value, pure token cost.
- Do not compress examples, tool descriptions or critical constraints.
Guard against stale advice
compile.md carries an [outdated] list keyed to the version where each technique
broke. Actively avoid them when compiling: all-caps emphasis, tip and bribe
framing, CRITICAL: you MUST forcing language, prefilled assistant turns,
budget_tokens, JSON document wrapping, temperature below 1.0 for Gemini
reasoning, blanket negatives, and hand-injected tool schemas. If the user's draft
contains any of these, fix it and say what you changed and why.
Output
Return the compiled prompt in a fenced block so it copies clean. If you made
non-obvious structural choices (constraint reorder, delimiter switch, sandwiching),
add a short list underneath of what you changed and the reason, since the user may
want to keep or revert a specific decision. Keep that note brief.
What this skill never does
- Run the humanisation linter or apply Domain A craft rules. This is the wrong
domain for them.
- Strip em dashes or kill-list words from the output. They are not tells here.
- Humanise. If the user actually wanted human-facing prose, hand off to
/mimesis-human.
- Invent capabilities or parameters. Tie model-specific advice to the version it
was validated against, and flag when something needs checking against current
provider docs.
