From a prompt to a tool your team can use

Someone on your team wrote a prompt that works. It turns a job description into 3 LinkedIn posts, and it does it well enough that 4 other people now paste it into a chat window every week.

Watch what those 4 people actually do. Each of them scrolls back to find the message. Each of them edits it a little before running it. One of them dropped a line last month and has been getting worse posts ever since, without knowing.

The prompt is fine. The way it gets used is the problem.

Split the instructions from the task

Here is the prompt, written the way people write them in a chat window:

Read this job description and write 3 LinkedIn posts announcing the role.
Keep them under 120 words, no hashtags, and mention that we're remote-first.

[paste the job description here]

2 different things are stuck together in that block. The instructions never change. The job description changes every time.

In Fireprompts they are separate. The instructions go in the document at the top of the builder. Below it you declare what the person running the tool has to supply. Whatever they type gets attached under your instructions when they press run.

So the tool is just this:

Read the job description below and write 3 LinkedIn posts announcing the role.

Rules:
- Under 120 words each
- No hashtags
- We are remote-first, say so

There is nothing to wire up. You do not name a variable in the text and then keep it matched to a field somewhere else. You write instructions, and the input arrives underneath them.

Notice what happened to "remote-first". It was a company fact that got typed inline because the author knew it. Now it lives in the tool, the same for everyone who runs it.

One input, not a form

A new tool starts with exactly 1 input. That is the default, and most tools should keep it.

With 1 input the run page draws a composer: one box, you type, you press Enter. Add a second field and the page turns into a form. Forms are sometimes right. They are also a decision you push onto the reader before they get anything back, and 3 half-filled fields produce worse output than 1 field somebody actually thought about.

The input can be long text, a link, a YouTube link, or a file. Pick whichever matches what the person already has in front of them. If the job description is in a PDF, make it a file input and stop asking them to copy and paste out of it.

Decide what comes out

"Write 3 LinkedIn posts" is a request, and the model will honour it in a different shape every time. Sometimes numbered. Sometimes with headers. Sometimes with a paragraph explaining what it did before it does it.

That works when a person reads the result and moves on. It breaks as soon as anything downstream depends on the shape.

So the tool declares its result up front. Markdown when a person reads it. HTML when it will be shown as a page. Image when the output is a picture. Data when the result is a table, which you can then export as CSV.

Data is the one people skip and shouldn't. Once a tool promises a fixed set of fields, the result stops being prose you have to re-read and becomes a value you can sort, filter and paste somewhere else.

Name it for the output

Job post writer is a name. LinkedIn v3 (new) is a filename.

This sounds small. It is the most common reason a good internal tool goes unused: the person who needed it did not recognise it in a list.

Name the tool after what comes out of it, not the technique inside it. "Support ticket from an email" beats "Email parser v2". Then write the description for somebody who has never done the task.

Send the link and say nothing

Until another person has run the tool without you in the room, you do not know whether the input makes sense, whether the instructions cover the case they brought, or whether the name means anything.

Send the link. Say nothing. Watch what they type in the box.

Next: why a shared prompt needs a version history.