Build a Local Prompt Library for Maker Tasks

If you use a local language model for maker work, you have probably written a great prompt once and then lost it. A prompt library fixes that. It is just a folder of prompts you can reuse, improve, and test when you change models. This guide shows a simple structure that works with any local runner, including Ollama, llama.cpp, and LM Studio.

Why bother

• Consistency. The same OpenSCAD or firmware review prompt gives you comparable results each time.
• Improvement. When a prompt fails, you fix it once and the fix sticks.
• Model changes. When you try a new model, you can rerun your library and see what got better or worse instead of guessing.

Keep it in plain text and Git

Prompts are text, so treat them like code. A Git repository gives you history, diffs, and the ability to roll back a "clever" change that made results worse. A layout like this is enough:

prompts/
  cad/
    openscad-parametric-part.md
    cadquery-review.md
  firmware/
    esp32-code-review.md
    serial-log-triage.md
  printing/
    print-failure-triage.md
  tests/
    openscad-parametric-part/
      input-bracket.txt
      checks.md
  README.md

A prompt file format that scales

Put a small header at the top of each prompt so you know what it is for and what it expects:

---
name: openscad-parametric-part
purpose: Turn a part description into OpenSCAD with named parameters
inputs: 
models_tested: 
last_reviewed: 2026-10-01
---
Write OpenSCAD for the part described below.
Rules:
- Put every dimension in a named variable at the top of the file.
- Use only the measurements provided. If a dimension is missing,
  list it under "Assumptions" instead of inventing a number.
- Use modules for repeated features.
- End with a short list of what the user should check before printing.

Part description:
{{part_description}}

Measured dimensions (mm):
{{measured_dimensions}}

The {{variable}} style is just a convention. Fill the variables by hand, with a small script, or with your runner's templating if it has one.

Patterns that make maker prompts reliable

• Demand an assumptions list. The most common failure is a confident made-up dimension, pin number, or setting. Asking for assumptions makes gaps visible.
• Give measured numbers, not descriptions. "Hole 5.5 mm" beats "a hole for an M5 bolt."
• Constrain the output format. Ask for a single code block, a table, or a numbered checklist so results are easy to compare.
• Ask for verification steps. For firmware, ask what to test on the bench. For CAD, ask what to measure on the first print.
• Keep prompts short and specific. Small local models follow a few clear rules better than a page of instructions.

Bake prompts into the runner

With Ollama, a Modelfile can set a system prompt and parameters for a named model, so a frequently used role is one command away:

FROM your-base-model
PARAMETER temperature 0.2
SYSTEM """Review ESP32 Arduino code. Point out bugs, blocking calls in loop(),
missing error handling, and pin conflicts. Do not invent library functions.
If unsure, say so."""

Build it with ollama create esp32-review -f Modelfile. Keep the Modelfile in the same repository as your prompts. Lower temperatures are a common choice for code and review tasks where you want consistent answers.

Test prompts like code

1. Save a few real inputs for each prompt: a part description, a log excerpt, a code file.
2. Write down what a good answer must contain, such as "all dimensions are variables," "lists missing hole spacing as an assumption," or "flags the delay() in loop()."
3. Rerun the inputs when you edit the prompt or switch models, and check the list.
4. Record the model and version that passed in the prompt header.

This does not need a framework. A checklist in a Markdown file and a few minutes of reading output is enough for a personal library.

Common mistakes

• Keeping prompts in chat history only, where they are hard to find and impossible to diff.
• Changing several things in a prompt at once, so you cannot tell which change helped.
• Assuming a prompt tuned for a large hosted model works the same on a small local one.
• Trusting output without verification. Code still needs to compile and run; dimensions still need calipers.
• Pasting secrets, API keys, or private customer data into prompts that get committed to a repository.

Summary

Store prompts as plain text in Git, give each one a header with its purpose and tested models, write rules that force assumptions into the open, and keep a few test inputs so you can tell when a change or a new model helps. It takes an afternoon to set up and saves you from rewriting your best prompts from memory.

Related

• Projects hub
• Newsletter
• Books for deeper reading