Keeping a Frozen Prompt Set: Spreadsheet and Plain-Text Templates for Repeatable Comparisons

What belongs in a frozen prompt set

A frozen prompt set is a reference collection, not a folder of frequently edited working instructions. Its purpose is to preserve the exact wording and context needed to make a later comparison meaningful. Each entry should include the prompt text, a unique identifier, a version number and the date on which that version was saved. The original should remain unchanged after publication into the archive.

A prompt rarely operates independently of its surrounding conditions. Record the intended task, required input format, relevant system instructions and any tool dependencies. If a routine relies on file uploads, a particular output format or a named model, those details belong in the record. The archive should distinguish required conditions from optional preferences so that a future comparison does not silently change the task.

• Permanent prompt ID, such as P-001.
• Prompt version, such as 1.0.
• Date saved in YYYY-MM-DD format.
• Exact prompt wording and associated instructions.
• Dependencies, intended task and expected output characteristics.

The spreadsheet as an index and control sheet

A spreadsheet provides a searchable inventory of the archive. Use one row per prompt version, not one row per general task. This distinction matters when a prompt is revised: version 1.1 should have its own row while version 1.0 remains available. Suggested columns include Prompt ID, Version, Date Saved, Task, Model Reference, Input Requirements, Output Requirements, Source File and Change Reason.

For example, P-001 might describe a request to summarise a meeting transcript in five bullet points. Its record could specify a maximum of 150 words, preservation of named decisions and an explicit instruction to separate unresolved questions. These are reference conditions, not claims about what a particular model will produce. A later editor can use the same record to identify whether the task definition itself has changed.

• Use one row for each immutable version.
• Keep dates in a consistent ISO format.
• Use controlled values for status, such as active, archived and superseded.
• Store a filename or document identifier for the complete prompt.
• Record who authorised a new version when organisational controls require it.

The plain-text version preserves exact wording

A spreadsheet cell is convenient for short instructions, but long prompts often contain paragraph breaks, quoted material, formatting requirements and structured input examples. A plain-text file preserves these elements in a form that can be opened, copied and compared without relying on spreadsheet display settings. Save one file per prompt version and use a consistent character encoding, preferably UTF-8.

A practical filename might be P-001-v1.0-2026-10-30.txt. The first lines can contain the identifier, version and saved date, followed by the complete prompt. Keep descriptive metadata outside the prompt body or mark it clearly as archive metadata. Otherwise, someone copying the file may accidentally include administrative notes in the instruction sent to the AI tool.

• Use a consistent filename structure.
• Preserve paragraph breaks and punctuation.
• Avoid silently correcting spelling or grammar in archived versions.
• Keep metadata visibly separate from executable prompt text.

A small template that supports both formats

The spreadsheet and plain-text files should share the same identifiers and version references. The spreadsheet points to the preserved file; the file carries the corresponding metadata. This arrangement avoids maintaining two competing copies of the prompt wording. A simple folder structure can separate current references from historical versions, with an additional index recording where each file belongs.

For example, an archive might contain a P-001 folder with versions 1.0 and 1.1, alongside a master spreadsheet. Version 1.1 could change the required summary length from 150 to 180 words. The change reason should describe that editorial decision, while the older file remains intact. A person reviewing a later comparison can then distinguish a prompt revision from a change in the AI tool.

• Prompt ID:
• Version:
• Saved date:
• Purpose:
• Exact prompt text:
• Change reason:

Keeping the archive useful when products change

An AI tool's surrounding conditions can change independently of its prompt interface. AI tool terms of service changes may affect permitted uses, retention conditions or access to particular capabilities. AI pricing page changes may alter the plan associated with a routine, including a free tier changing to a trial. Record the applicable source, publication date and wording separately from the frozen prompt itself.

A plan change does not automatically create a new prompt version. Instead, record the commercial or access change in a separate dependency field or linked change record. Include the affected plan, relevant region, effective date and any transition conditions stated by the provider. Existing accounts may have different arrangements from newly opened accounts, so preserve the distinction where the published information makes it. The provider's current terms and account-specific documentation remain the deciding sources.

• Keep prompt changes separate from product and plan changes.
• Date each archived terms or pricing reference.
• Record the applicable region and account conditions.
• Identify prompts dependent on features included in a particular plan.

Version control and retrieval rules

The archive needs a simple rule for creating new versions. A change to wording, required input or output constraints creates a new prompt version. A correction to an unrelated index description does not. Record the reason for every substantive revision and preserve the previous version. Avoid reusing an identifier for a different task, even when the replacement appears similar.

Access controls should prevent routine editors from overwriting frozen files. A designated archive owner can approve new versions and periodically confirm that the spreadsheet index still points to existing files. For a small team, a read-only folder and a controlled submission process may be sufficient. Larger teams may need repository permissions and a formal review record.

Questions readers ask