Prompts.

The reference Context/Task/Standards prompt. Generic, tiny, and works for almost anything. Start here, then specialize.

## Context
You are [ROLE THE AI SHOULD TAKE].

Here is what you need to know:
[BACKGROUND THE AI NEEDS TO KNOW]

## Task
[WHAT YOU WANT DONE]

## Standards
[FORMAT, LENGTH, TONE, AND CONSTRAINTS]

If any part of the context is missing or unclear, ask me before answering.

---

**Why this works**

Context tells the AI who it is and what it knows. Task tells it what to do. Standards tells it what "done" looks like. Three blocks, three jobs. The final line forces the AI to ask instead of guess, which kills most bad outputs before they happen.

Paste in one military bullet. Get back three civilian versions in STAR style. No hype words. Pick the one that fits.

## Context
You are a resume editor who hires for civilian roles. You have read thousands of military-to-civilian resumes. You know which words land and which words confuse a hiring manager.

The candidate served in the [BRANCH] as a [MOS or rate or AFSC]. They are applying for a [TARGET ROLE] role.

Here is the raw bullet from their existing resume:
[RAW BULLET]

## Task
Rewrite the bullet three different ways. Each rewrite must be readable by a hiring manager who has never served. Each rewrite must follow STAR (Situation, Task, Action, Result) compressed into one line.

## Standards
- One line per rewrite, max 25 words.
- Lead with the verb.
- Quantify the result when possible. If the raw bullet has no number, leave the number blank as [NUMBER] so I can fill it in.
- Translate any acronym or jargon on first use.
- Banned words: leverage, utilize, spearhead, robust, synergy, transformative, world-class, cutting-edge.
- No "served as." Show the work, not the title.
- After the three rewrites, list any acronyms you translated and what you assumed.

---

**Why this works**

Three variants force the AI to find different angles instead of one safe rewrite. The banned-word list blocks the resume cliches that make a hiring manager skim. The [NUMBER] placeholder is honest, the AI does not invent metrics it cannot see. The acronym list at the end lets you catch any translation the AI got wrong before you ship the resume.

Paste a job description in. Get the day-to-day reality, the hidden requirements, the interview questions, and which of your bullets to feature.

## Context
You are a hiring manager who has written job descriptions for 15 years. You know what the words on a JD mean versus what the team actually needs. You also know which lines are HR boilerplate and which lines were written by the person who will manage the role.

Here is the job description:
[FULL JOB DESCRIPTION TEXT]

Here are my top 5 resume bullets:
[YOUR TOP 5 RESUME BULLETS]

## Task
Give me four sections in this exact order:

1. **What this job actually does day-to-day.** Three to five bullets. Plain language.
2. **Hidden requirements not stated in the JD.** What the hiring manager wants but did not write down. Three to five bullets.
3. **The five questions the interviewer probably wants me to answer.** Phrased as the questions, not the topics.
4. **Which of my bullets to feature.** Pick the two strongest from my list. Say why each one maps to this JD.

## Standards
- No filler. No "this is a great opportunity" framing.
- If the JD is vague, say what is vague and what you assumed.
- Do not invent qualifications I did not list.
- One screen of output total.

---

**Why this works**

A JD is a translation problem. The AI is good at reading subtext when you tell it the subtext is what you want. Asking for the five interview questions in advance lets you prep before you apply. Forcing the AI to pick only two bullets to feature is a constraint. It has to choose, which is the hard part of resume tailoring.

Give the AI a behavioral question and a rough story. Get back a STAR answer at the length you want, ready to practice out loud.

## Context
You are an interview coach. You have run behavioral interview prep for hundreds of candidates moving into civilian roles. You write answers people can say out loud, not answers people read off a page.

The behavioral question is:
[QUESTION]

My rough story for this question is:
[SITUATION SEED]

I want the spoken answer to be about [DESIRED LENGTH IN SECONDS] seconds.

## Task
Write a STAR-structured answer.
- **Situation:** Set the scene in 1-2 sentences.
- **Task:** What was on me specifically.
- **Action:** What I did. This is the longest section.
- **Result:** What changed. Include a number if my seed has one. If not, write [METRIC] so I can fill it in.

At the end, list:
- Two follow-up questions an interviewer is likely to ask.
- One spot in the answer where I should slow down and let it land.

## Standards
- Plain spoken English. Contractions are fine.
- Target word count: roughly 2.3 words per second of spoken time.
- No jargon the interviewer would not know.
- Do not invent details. If my seed is thin, say what you assumed.

---

**Why this works**

STAR is the format every interviewer is trained to score against. Asking for spoken English at a word-per-second target stops the AI from producing a wall of text you cannot deliver. The follow-up questions let you prep the second turn of the conversation, not just the first. The slow-down marker reminds you the answer is a performance, not a recital.

Get a one-paragraph civilian summary of your military role, three resume bullets, and two LinkedIn headline options. Plain English, no jargon.

## Context
You translate military roles for civilian hiring managers. You know that the manager has never served and does not know what an E-6, a platoon, or a watch section is. You translate to civilian language without dumbing down the work.

My military role:
- Branch: [BRANCH]
- Role: [ROLE / MOS / AFSC / rate]
- Target civilian role: [TARGET CIVILIAN ROLE]

## Task
Produce three outputs in this order:

1. **One paragraph (4-6 sentences) for the civilian hiring manager.** Explain what I did, who I led, what I was responsible for, and what scale looked like (people, budget, equipment). No acronyms without translation.
2. **Three resume bullets** mapped to the target civilian role. Each bullet leads with a verb. Each bullet has a quantified result or [NUMBER] placeholder if you do not know.
3. **Two LinkedIn headline options.** Each under 12 words. State the target civilian role plus one specific strength.

## Standards
- No jargon. No "led a platoon of 30." Use "led a 30-person team."
- No hype words. No "transformative," "elite," "world-class."
- No "served as." Show the work.
- If you have to make an assumption about scale or scope, mark it as [VERIFY] so I can confirm.
- All three outputs should feel like they describe the same person.

---

**Why this works**

Military roles do not translate by acronym lookup. They translate by responsibility and scale. The one-paragraph summary is what a recruiter screens with. The three bullets are what the hiring manager reads. The two headlines are what shows up before anyone clicks. Forcing all three to describe the same person keeps the story consistent across the funnel.

Write a 4-line cold email with a subject line. Direct, no fawning, ready to send.

## Context
You write cold outreach emails that get replies. You know that long emails get skipped and that fake warmth gets ignored. You are writing on behalf of a transitioning service member.

The target person is [TARGET NAME], who works as a [TARGET ROLE] at [TARGET COMPANY]. The mutual connection is [MUTUAL CONNECTION OR "NONE"]. What I am asking for is [WHAT YOU WANT: coffee, info, intro]. Here is one line about me: [ONE-LINE ABOUT YOU].

## Task
Write the email.
- One subject line, under 7 words.
- A body of exactly 4 lines.
  - Line 1: How I found them or the mutual connection. One sentence.
  - Line 2: Why I am writing to them specifically, not just anyone. One sentence.
  - Line 3: The ask. One sentence. Specific.
  - Line 4: An easy out. Give them permission to say no.

## Standards
- No "I hope this email finds you well."
- No "I am reaching out because."
- No "thank you for your service" framing in either direction.
- No bragging. State the ask plainly.
- If the mutual connection is "NONE," say how I found them honestly.
- The ask must be specific and small. "15 minutes on the phone next week" beats "would love to chat."

---

**Why this works**

A cold email's job is to make a reply easy. Four lines is the upper limit before a busy person scrolls past. The line-by-line spec forces the AI to do real work in each line instead of padding. The "easy out" line is counterintuitive. Letting someone say no honestly raises your reply rate.

Two or three lines. No catch-up theater. Get to the ask.

## Context
You write short emails between people who already know each other. You skip the catch-up theater because they already know the basics. You respect their time.

I am writing to [TARGET NAME]. How I know them: [HOW YOU KNOW THEM]. Last contact: [LAST CONTACT: when and what]. What I want: [WHAT YOU WANT].

## Task
Write the email.
- One subject line, under 6 words.
- A body of 2 or 3 lines max.
  - Line 1: A real anchor to our shared history. One sentence. Not "hope you are well."
  - Line 2: The ask. Specific.
  - Optional line 3: A short reason this person specifically, if it adds something.

## Standards
- Sound like a person, not a template.
- No "I know you are busy."
- No "long time no talk" unless that is literally the anchor.
- Specific ask. Specific time window if relevant.
- Sign off with first name only.

---

**Why this works**

With warm contacts, length is disrespect. They will reply if you make the ask easy and the anchor real. The optional third line is a safety valve for the case where the "why you" is genuinely useful. Otherwise it stays a two-liner.

Paste in a federal solicitation excerpt. Get back what the government actually wants, the scoring order, the disqualifiers, and the subtext.

## Context
You are a federal capture lead who has read hundreds of PWS, SOO, and SOW documents. You have sat on source selection boards. You know the difference between what a solicitation says and what an evaluator scores.

Here is the solicitation text:
[SOLICITATION TEXT: PWS, SOO, or SOW excerpt]

Contract vehicle: [CONTRACT VEHICLE IF KNOWN]
Agency: [AGENCY IF KNOWN]

## Task
Give me four sections in this exact order:

1. **What the government actually wants.** Plain English. 3 to 6 bullets.
2. **Scoring criteria in priority order.** Highest weight first. If the doc is silent on weights, say so and rank by inference.
3. **The 3 hard requirements that disqualify if missed.** Cite the section of the text for each.
4. **The 5 things the eval team is reading between the lines.** Unstated preferences, incumbent signals, agency culture cues.

## Standards
- Quote the source text once per claim. Short quotes only.
- If a section of the source is missing or you are inferring, say so explicitly.
- Do not invent FAR clauses.
- Do not recommend a price or a team. That is for the capture meeting.
- One page of output max.

---

**Why this works**

The four-section structure mirrors how a capture lead briefs the team after first read. Forcing citations stops the AI from drifting into generic federal-procurement talk. The between-the-lines section is the unique value. Anyone can summarize a SOW, but reading the subtext is what wins bids.

Generate the section headers and fill-in prompts for a 2-page federal capability statement. Tailored to a specific agency. You finish the prose.

## Context
You are a federal proposal writer who has shipped capability statements that won small business set-asides. You know the format: 2 pages, scannable, agency-tailored, no fluff. You build the skeleton. The operator writes the final prose.

Company: [COMPANY NAME]
Core competencies: [CORE COMPETENCIES: 3 to 5]
Past performance: [PAST PERFORMANCE: 3 examples]
Target agency: [TARGET AGENCY]
NAICS codes: [NAICS CODES]
DUNS/UEI: [DUNS/UEI]
POC: [POC]

## Task
Produce the skeleton for a 2-page federal capability statement.

For each section, give:
1. The section header.
2. A one-line description of what goes in the section.
3. The exact prompts I should answer to fill it in.

Include these sections in order:
- Company snapshot (top of page 1)
- Core competencies
- Differentiators (why us, not the other vendor)
- Past performance (three blocks, one per example)
- Agency-specific alignment (why we fit [TARGET AGENCY])
- Corporate data block (NAICS, UEI, CAGE, certifications, POC)

## Standards
- Skeleton only. Do not write the final prose.
- Each fill-in prompt should be a question, not a heading. "What is the one number that proves this competency?" not "Metric."
- Tailor the agency-alignment prompts to [TARGET AGENCY]. Name the agency's mission or recent priorities once if you know them. If you do not know them, say "verify before using."
- Keep the whole skeleton under one screen so I can see the shape of the document.

---

**Why this works**

A capability statement is a layout problem more than a writing problem. Building the skeleton with question-shaped prompts forces the operator to answer specifically instead of writing fluff. Tailoring the agency-alignment section is what separates a winning statement from a generic one. The "verify before using" instruction is the honest move when the AI does not actually know the agency's current priorities.

Generate the GOVERN function write-up for an NIST AI RMF profile. One paragraph per subcategory, grounded in your specific use case.

## Context
You are an AI governance lead writing an NIST AI RMF 1.0 profile. You know the GOVERN function covers culture, policies, accountability, workforce, third parties, and adverse incidents. You write in the voice of an organization documenting its own controls, not a vendor pitching.

The AI system is [SYSTEM NAME], owned by [ORG NAME].
Intended use: [INTENDED USE]
Potential harms: [POTENTIAL HARMS]
Who uses it: [WHO USES IT]

## Task
Draft one paragraph for each GOVERN subcategory, GOVERN.1 through GOVERN.6. Use the official NIST AI RMF subcategory names as the paragraph headers.

## Standards
- One paragraph per subcategory. 4 to 7 sentences.
- Reference specific roles, policies, or processes by name where I gave you enough to do so. Where I did not, write [TO BE NAMED] so I can fill it in.
- No marketing language. This is a control document.
- If a subcategory does not apply to this system, say so and say why. Do not pad.
- Cite NIST AI RMF 1.0 (2023) once at the top.

---

**Why this works**

NIST AI RMF write-ups fail when they are generic. Anchoring every paragraph to a named system, owner, and use case forces the AI to write something an evaluator can actually verify. The [TO BE NAMED] placeholder is the honest version. The AI should not invent a CISO or a policy that does not exist. Doing one function at a time (GOVERN here, MAP, MEASURE, MANAGE separately) keeps each output reviewable.

Generate the MAP function write-up for an NIST AI RMF profile. One paragraph per subcategory, grounded in your context.

## Context
You are an AI governance lead writing an NIST AI RMF 1.0 profile. The MAP function covers context, categorization, capabilities and limits, risk and benefit framing, and impact characterization. You write as the organization documenting its own analysis.

The AI system is [SYSTEM NAME], owned by [ORG NAME].
Intended use: [INTENDED USE]
Potential harms: [POTENTIAL HARMS]
Who uses it: [WHO USES IT]

## Task
Draft one paragraph for each MAP subcategory, MAP.1 through MAP.5. Use the official NIST AI RMF subcategory names as the paragraph headers.

## Standards
- One paragraph per subcategory. 4 to 7 sentences.
- Name the actual stakeholder groups, data sources, and deployment context I gave you. Where I did not give enough, write [TO BE NAMED].
- Be honest about the system's limits. The MAP function rewards specificity about what the system cannot do.
- If a subcategory does not apply, say so and say why.
- Cite NIST AI RMF 1.0 (2023) once at the top.

---

**Why this works**

MAP is where most AI RMF profiles get vague. The fix is to name the people and the data, not the abstractions. Forcing the AI to list limitations honestly is what makes the profile credible to an evaluator. Splitting MAP from GOVERN, MEASURE, and MANAGE keeps each paragraph specific to its function instead of repeating itself.

Generate the MEASURE function write-up for an NIST AI RMF profile. One paragraph per subcategory, with named metrics where possible.

## Context
You are an AI governance lead writing an NIST AI RMF 1.0 profile. The MEASURE function covers metric identification, evaluation, tracking, and feedback. You write for an evaluator who will check whether the metrics you list are real and whether they cover the risks you flagged in MAP.

The AI system is [SYSTEM NAME], owned by [ORG NAME].
Intended use: [INTENDED USE]
Potential harms: [POTENTIAL HARMS]
Who uses it: [WHO USES IT]
Metrics or evals already in place: [KNOWN METRICS OR EVALS]

## Task
Draft one paragraph for each MEASURE subcategory, MEASURE.1 through MEASURE.4. Use the official NIST AI RMF subcategory names as the paragraph headers.

## Standards
- One paragraph per subcategory. 4 to 7 sentences.
- Name actual metrics from my input. If I did not give a metric for a subcategory, write [METRIC TO BE DEFINED] so I can fill it in.
- Tie each metric back to a harm or risk named in MAP.
- State the cadence of measurement (daily, per-release, quarterly) where possible.
- No vague "appropriate metrics" language.
- Cite NIST AI RMF 1.0 (2023) once at the top.

---

**Why this works**

MEASURE is the function evaluators audit hardest because it has to be testable. Forcing the AI to name metrics and cadences keeps the paragraphs from drifting into platitudes. The [METRIC TO BE DEFINED] placeholder is the honest answer. Better than the AI inventing a metric you do not actually track.

Generate the MANAGE function write-up for an NIST AI RMF profile. One paragraph per subcategory, focused on prioritization and response.

## Context
You are an AI governance lead writing an NIST AI RMF 1.0 profile. The MANAGE function covers risk prioritization, response, third-party risk, and continuous improvement. You write for an evaluator who wants to see real decisions, not aspirations.

The AI system is [SYSTEM NAME], owned by [ORG NAME].
Intended use: [INTENDED USE]
Potential harms: [POTENTIAL HARMS]
Who uses it: [WHO USES IT]
Incident response owner: [INCIDENT RESPONSE OWNER]

## Task
Draft one paragraph for each MANAGE subcategory, MANAGE.1 through MANAGE.4. Use the official NIST AI RMF subcategory names as the paragraph headers.

## Standards
- One paragraph per subcategory. 4 to 7 sentences.
- Name the response owner, escalation path, and decision threshold where I gave you enough. Where I did not, write [TO BE NAMED].
- Show how risks are ranked, not just listed.
- Reference the rollback or shut-off path. If there is no rollback, say so.
- Cite NIST AI RMF 1.0 (2023) once at the top.

---

**Why this works**

MANAGE is the function that proves the rest of the profile is real. An evaluator wants to see an owner, a threshold, and a shut-off path. Forcing the AI to name those three keeps the paragraphs from sounding like a policy template. Saying "there is no rollback" out loud is better than pretending one exists.

Draft a blameless postmortem for an AI incident. Standard sections, no finger-pointing, action items that are actually actionable.

## Context
You are an SRE who has written postmortems for production AI systems. You write blameless postmortems. The goal is to fix the system, not blame the person. You know the difference between a root cause and a trigger.

System: [SYSTEM]
Incident start: [INCIDENT START]
Incident end: [INCIDENT END]
User impact: [USER IMPACT]
What we know about the root cause so far: [ROOT CAUSE: what you know so far]
How it was detected: [DETECTION METHOD]

## Task
Write the postmortem with these sections in order:

1. **Summary.** Three to five sentences. What happened, when, what was impacted, what we did.
2. **Timeline.** Bulleted, timestamped, in order. Include detection, escalation, mitigation, resolution.
3. **Root cause.** What actually broke and why. Distinguish root cause from trigger. If the root cause is still under investigation, say so.
4. **Impact.** Quantified where possible. Users affected, requests affected, dollar impact if known.
5. **Action items.** Each one has an owner, a due date, and a clear definition of done. No vague "improve monitoring."
6. **What went well.** Three things that worked. This is not filler. It is what we preserve.

## Standards
- Blameless. No names attached to mistakes. Roles only.
- Plain language. An exec and an engineer should both be able to read it.
- If I gave you incomplete information, say [UNKNOWN: investigate] and move on. Do not invent.
- One page max.

---

**Why this works**

The sections are the standard SRE structure for a reason: they cover what executives need (summary, impact) and what engineers need (timeline, root cause, action items). The "what went well" section is the one most postmortems skip and most teams regret skipping. Forcing action items to have an owner and a definition of done is what makes the postmortem produce change instead of just documentation.

Given your system prompt and use case, get 20 eval cases: 5 happy path, 5 edge, 5 adversarial, 5 known failure modes. Each case has input, expected output, and the reason it tests something.

## Context
You are an AI evaluation engineer. You build test sets for LLM systems before they ship. You know that good eval cases are specific, scoreable, and cover the four categories: happy path, edge, adversarial, and known failure modes.

Here is the system prompt being evaluated:
[SYSTEM PROMPT]

Here is the use case:
[USE CASE DESCRIPTION]

Here is what success looks like:
[SUCCESS CRITERIA]

## Task
Generate 20 evaluation cases. 5 happy path, 5 edge cases, 5 adversarial, 5 known failure modes.

Format each case as:
- **Case ID:** e.g. HAPPY-01, EDGE-01, ADV-01, FAIL-01
- **Input:** the user message the system would receive
- **Expected output:** what a passing response looks like, scoreable in one sentence
- **Why it tests something:** the specific behavior this case probes

## Standards
- Inputs should be realistic. Write them the way a real user would type them, typos and all where useful.
- Expected outputs must be scoreable. "Refuses politely" beats "handles the request well."
- Adversarial cases should attempt prompt injection, jailbreaks, or out-of-scope requests relevant to this system.
- Known failure modes should reflect known weaknesses of LLMs: hallucination, stale knowledge, format drift, refusal of valid requests.
- No two cases should test the same thing.
- If a category does not apply to this system, say so for that category and reduce the count, do not pad.

---

**Why this works**

Evals fail when they only cover the happy path. The four-category split forces coverage of the failure surfaces that ship-blocking bugs hide in. Asking for the "why it tests something" field makes the AI justify each case, which kills near-duplicates. Realistic inputs (typos and all) are how you find the bugs that synthetic clean inputs miss.