Create a one page AI prompt library and start using it

You can build a one‑page AI prompt library and have it ready to ship in a day by following a short, repeatable process. The result is a single Markdown (or plain‑text) file that any developer on your team can import and start using immediately.

What you’ll build and what you need

At the end of this guide you will have a file called prompts.md that contains every prompt your product uses, each labeled with a clear identifier and a brief usage note. To start you need:

• Access to a code repository or a shared drive where the file can live.
• A list of the functional areas (e.g., “summarize ticket”, “generate email”) you want to cover.
• One person to act as the reviewer for the day‑long sprint.

Define a naming convention

A consistent identifier makes retrieval fast and avoids duplicate work. Use a pattern that reads [module][action][target], for example ticket_summarize_brief. If you have many modules, prepend a short project tag: ops_ticket_summarize_brief. Test the pattern by writing three identifiers; they should all be under 30 characters and instantly recognizable. If any feel ambiguous, tweak the wording before moving on.

Create the prompt template

Create a skeleton that every entry will follow. A practical template looks like this:

### ID:
**Purpose:**
**Prompt:**

**Notes:**

Store this template in a file called template.md. Open it in your preferred editor and fill in the placeholders for the first prompt. The template ensures that every entry has the same structure, which is the foundation for automated parsing later.

Gather prompts in a single file

Photo by Brett Jordan on Unsplash

Open prompts.md and copy the template for each functional area you listed. Replace the placeholders with real values. For AcmeOps, a workflow‑automation SaaS, the first three entries might be:

### ID: ticket_summarize_brief
**Purpose:** Summarize a support ticket for quick triage.
**Prompt:**
Summarize the following ticket in 2 sentences, focusing on the problem and the requested action:

**Notes:** Keep tone neutral.

### ID: email_generate_welcome
**Purpose:** Create a welcome email for a new user.
**Prompt:**
Write a short welcome email for a user who just signed up for AcmeOps, highlighting key onboarding steps.
**Notes:** Use a friendly tone and include a call‑to‑action.

Continue until every major feature has an entry. A quick way to verify completeness is to search the file for the word “### ID:” and count the matches; the count should equal the number of functional areas you initially listed.

Set up a lightweight review workflow

Even a one‑day effort needs a sanity check. Use a two‑person checklist:

1. Author drafts the prompt using the template.
2. Reviewer reads the entry, verifies that the identifier follows the naming convention, and runs the prompt in a test environment.

If the reviewer spots a mismatch or an unclear description, they comment directly in the file (e.g., ). The author updates the entry and the reviewer signs off by adding at the end of the block. This minimal loop catches the most common errors without requiring a ticketing system. Comppound uses a similar checklist for its own prompt libraries, keeping the process fast and auditable.

Publish and test the library

Once every entry has the `` tag, merge the file into your main branch or copy it to the shared drive. To test, write a short script that reads prompts.md, parses the sections, and sends one prompt to your AI endpoint. Verify that the response matches the intended purpose. A successful test is an indication that the library is ready for developer consumption.

Common failures and how to spot them

Symptom	Likely cause	Quick fix
Duplicate identifiers appear	Naming convention not enforced	Run a search for ### ID: and check for repeats; rename duplicates using the pattern.
Prompts return errors from the AI API	Placeholder variables left unchanged	Scan the file for `` symbols; replace them with real variables or add clear instructions.
Review comments remain unresolved	Reviewer missed a block	Filter the file for lines without ``; address each missing sign‑off.
The file is difficult to navigate	Inconsistent formatting	Run a formatter (e.g., Prettier) on the Markdown to enforce uniform spacing and line breaks.

If you encounter any of these issues, fix them before considering the library “shipped”. The goal is a clean, searchable file that any developer can open and understand without additional context.

Now you have a one‑page AI prompt library that can be maintained in version control, reviewed quickly, and expanded as your product grows.

What you’ll build and what you need (expanded)

The prompts.md file will become the single source of truth for every AI‑driven interaction in your product. Treat it like any other code asset:

• Repository location – Put the file in a dedicated folder (e.g., docs/prompts/) inside the same git repository that holds your source code. This keeps version history together with feature changes.
• Access control – Restrict write permission to the small review team you identified. Readers can have read‑only access, which prevents accidental edits while still allowing developers to pull the file during builds.
• Initial inventory – Before you start, sit with product managers or engineers and list the functional areas that currently rely on AI. A typical early‑stage SaaS might include: ticket triage, onboarding email, churn prediction, dashboard summary, and custom report generation. Write each item on a separate line; this list will drive the number of entries you create.

Having this checklist in hand means you won’t discover a missing use case halfway through the day‑long sprint.

Define a naming convention (deeper dive)

A good convention does more than look tidy; it lets you locate a prompt with a simple grep. Follow these extra checks:

1. Scope prefix – If your codebase is split into micro‑services, add the service name as the first token (crm_, billing_, etc.). This avoids collisions when two services need a “generate_report” prompt.
2. Verb tense – Use present‑tense verbs for actions (summarize, generate, classify). Consistency makes it easier to autocomplete in IDEs.
3. Length guard – Aim for no more than three underscore‑separated segments. Longer identifiers become hard to read in logs.
4. Cross‑reference test – After drafting 5‑10 identifiers, run grep -R "your_prefix_" src/ to see if any already exist in code comments or configuration files. If a clash appears, adjust the token order or add a distinguishing qualifier.

Example validation

For the onboarding email, you might start with onboard_email_welcome. Running the grep shows no other matches, so the name is safe. If you later add a “welcome” email for the admin portal, rename the second one to admin_email_welcome to keep them distinct.

Create the prompt template (expanded)

The template should be easy to copy‑paste and should also support future tooling such as automated parsers. Add a YAML front‑matter block at the top of each entry; many markdown parsers can read it directly.

---
id: ticket_summarize_brief
purpose: Summarize a support ticket for quick triage
variables:
  - ticket_body
---
**Prompt:**
Summarize the following ticket in 2 sentences, focusing on the problem and the requested action:

{{ticket_body}}

**Notes:**
Keep tone neutral. Do not include any personally identifying information.

Why this helps:

• Structured data – The variables list tells developers exactly which placeholders must be filled before sending to the AI.
• Tool friendliness – Scripts can read the YAML block to auto‑generate type definitions or validation code.
• Readability – Keeping the “Prompt” section separate from the metadata reduces the chance of mixing instructions with variables.

Store the template as template.md and keep a copy in the repo’s docs/templates/ folder for reference.

Gather prompts in a single file (additional guidance)

When you copy the template for each functional area, follow these practices:

• Fill all variables – Replace every {{placeholder}} with a clear description of the expected input. If a prompt does not need variables, leave the list empty.
• Version comment – Add a short comment with the date and author at the end of each block, e.g., <!-- v1.0 – Jane, 2024-01-15 -->. This makes it easy to see who introduced a prompt and when.
• Link to documentation – If a prompt relies on an internal spec (like a ticket schema), add a markdown link inside the Notes section. Example: [Ticket schema](/docs/schemas/ticket.md).

After you finish, run a quick sanity check:

grep -c "^---" prompts.md   # counts how many YAML blocks you added

The count should match the number of functional areas you listed earlier.

Set up a lightweight review workflow (additional tips)

The two‑person checklist is the minimum, but you can tighten it without adding heavy ticketing:

• Inline linting – Use a pre‑commit hook that scans prompts.md for common problems: missing --- block, empty variables list, or identifiers longer than 30 characters. Tools like pre-commit with a custom Python script work well.
• Reviewer rubric – Give the reviewer a short rubric to speed the process:

Check	What to look for
Identifier	Matches naming convention, no duplicates
Variables	All placeholders documented, no stray {{ or }}
Prompt	Clear, concise, no internal jargon
Notes	Contains any required tone, length, or safety guidance

The reviewer marks each completed check with a tick (✅) in a comment block. When every line shows a tick, the prompt is considered approved.

Publish and test the library (further detail)

Automated testing can be as simple as a Node.js script that:

1. Reads prompts.md line by line.
2. Extracts the YAML front matter and the prompt body.
3. Substitutes dummy values for each listed variable.
4. Sends the formatted prompt to a sandbox AI endpoint.
5. Checks that the response contains the expected keywords (e.g., “summary”, “welcome”).

If any test fails, the script prints the prompt’s id and the error, allowing you to fix the issue before developers start using it.

Automate consistency checks (new step)

Even with a one‑day sprint you will eventually add new prompts. To keep the library clean over time, schedule a nightly CI job that runs the same linting and testing steps described above. The job should:

• Fail the build if duplicate identifiers appear.
• Warn if a prompt has not been tested in the last 30 days.
• Generate a short markdown report (prompt_report.md) that lists all prompts, their last test date, and any outstanding reviewer comments.

Having this automation in place means the file stays reliable as the product grows, and you avoid the “it works today but breaks tomorrow” scenario.

See how Comppound approaches SEO for B2B SaaS