prompt-mechanics
Prompt mechanics
Engineer prompts against how LLMs process text. The default failure mode in prompt authoring is writing by feel: adding a rule because it sounds right, stacking emphasis, hoping the model complies. This skill replaces feel with a method. Every change names the mechanism that makes it work, and every change is verified against that named mechanism rather than against a self-report or a vibe.
Two things live here. The method is the spine: how to evaluate a prompt, change it, and check the change. The techniques are named moves that hang off the method, each carrying its own mechanism and its own test for when it does not apply. Apply the method always. Reach for a technique only when its mechanism is actually present in the artifact in front of you. A glossary on a prompt that has no vocabulary drift is wasted tokens; a gold trace in a render path that displays it is a bug. The method is what tells you which.
Glossary
One canonical term per concept, used everywhere below.
| Term | Meaning |
|---|---|
| artifact | The prompt-like thing being authored or revised: system prompt, agent instruction set, skill, tool-use policy, CLAUDE.md, long rule block |
| mechanism | The reason a change works, grounded in how the model processes text (attention, induction, superposition, etc.), not in taste |
| tier | How settled a mechanism is: [established] or [bet] |
| target harness | The runtime the artifact executes in: its position, render path, tools, and length budget |
| render path | Which channels the harness shows or hides (pre-tool text, reasoning, tool calls) |
| gold trace | One complete worked example near the top of an artifact, consistent with every rule below it |
| mismatch | A place where an instruction fights the mechanism the model actually applies to it |