@ckelsoe/prompt-architect 3.2.2 → 3.4.0

package/skills/prompt-architect/references/frameworks/cai-critique-revise.md

@@ -4,7 +4,7 @@
 
 CAI Critique-Revise is a two-phase output improvement pattern derived from Anthropic's Constitutional AI methodology. A model generates an initial response, explicitly critiques it against a stated principle or standard, then revises the response to align with that principle. Unlike Self-Refine (which uses multi-dimensional quality feedback), CAI Critique-Revise is principle-driven: the critique is always measured against a specific, explicitly stated standard — a "constitution" of one or more principles.
 
-**Research basis:** "Constitutional AI: Harmlessness from AI Feedback" (Bai et al., Anthropic, arXiv 2212.08073, 2022). Originally a training methodology; the critique-revise loop is directly usable as a prompting pattern. Key finding: generating an explicit critique before revising produces better alignment than asking for direct revision without a critique step.
+**Research basis:** "Constitutional AI: Harmlessness from AI Feedback" (Bai et al., Anthropic, arXiv 2212.08073, 2022). Originally a training methodology; the critique-revise loop is directly usable as a prompting pattern. Key finding: generating an explicit critique before revising produces better alignment than asking for direct revision without a critique step. The effect is strongest for smaller models; the authors found no noticeable difference at 52B and retained critiques primarily for transparency into the model's reasoning.
 
 ## The Key Insight
 
@@ -27,151 +27,259 @@ The intermediate critique step is load-bearing — it forces the model to identi
 - "No hedging language ('might', 'could', 'perhaps') unless genuine uncertainty exists"
 
 ### Initial Generation
-**Purpose:** The output to evaluate. Can be AI-generated or human-written.
+**Purpose:** The output to evaluate. Can be AI-generated or human-written. This fills the template's `SOURCE MATERIAL` slot, and unlike in frameworks that generate from scratch, it is required — there is nothing to critique without it.
 
 ### Critique Step
-**Purpose:** Explicit evaluation of the output against the principle. The critique must be specific and quote the problematic passages.
+**Purpose:** Explicit evaluation of the material against the principle. The critique must be specific and quote the problematic passages. It is the first of the template's two phases, and the framing paragraph exists to stop the model collapsing it into the rewrite.
 
-**Critique trigger:** *"Identify specific ways in which the response above violates or falls short of the following principle: [principle]. Quote the specific passages that are problematic. Explain why each violates the principle."*
+**Critique trigger:** *"Before rewriting anything, identify the specific ways the material above violates or falls short of the principle. Quote the specific passages that are problematic. Explain precisely why each passage violates the principle."*
 
 ### Revision Step
-**Purpose:** Rewrite the response to satisfy the principle. The revision should address every critique point.
+**Purpose:** Rewrite the material to satisfy the principle. The revision should address every critique point.
 
-**Revision trigger:** *"Revise the response to fully satisfy the principle. Address every critique point. Preserve all content that already satisfies the principle."*
+**Revision trigger:** *"Then rewrite the material above so it fully satisfies the principle. Address every critique point identified above. Preserve all content that already satisfies the principle."*
 
 ### Iteration (optional)
 **Purpose:** Run the critique-revise cycle again against the same principle (to catch remaining issues) or a different principle (multi-principle alignment).
 
 ## Template Structure
 
+Section headers are stripped at emission, so every header's meaning is carried by
+unbracketed prose that ships with the prompt. Do not reintroduce header-only structure.
+
+The two-phase rule is stated once, in the opening framing paragraph, and the pasted
+material is delimited by the `SOURCE MATERIAL:` block together with the anchor sentence
+directly beneath it. That anchor sentence is what keeps the pasted text readable as
+material to be critiqued rather than as instructions to follow — do not delete it while
+keeping the block.
+
 ```
+You are enforcing a stated principle against an existing piece of writing. This is a
+two-phase task: write a critique, then write a revision. Do not skip the critique and go
+straight to the rewrite, and do not merge the two.
+
 PRINCIPLE:
-[State the specific standard the output must satisfy]
+The principle to enforce is this:
+[State the standard the output must satisfy — one principle or a small set — as complete
+sentences whose compliance a reader could check. Be precise and measurable.]
 
-INITIAL OUTPUT:
-[The output to evaluate — AI-generated or human-written]
+SOURCE MATERIAL:
+[Paste the output to be critiqued here — AI-generated or human-written.]
+Use the material above as the text to be critiqued and revised for the work described
+below.
 
 CRITIQUE:
-Identify specific ways the output above violates or falls short of
-the principle stated above.
+Before rewriting anything, identify the specific ways the material above violates or falls
+short of the principle.
 - Quote the specific passages that are problematic
 - Explain precisely why each passage violates the principle
-- Do not mention positives — focus only on failures
+- Focus only on failures against the principle, not general quality
 
 REVISION:
-Rewrite the output to fully satisfy the principle.
+Then rewrite the material above so it fully satisfies the principle.
 - Address every critique point identified above
-- Preserve all content that already meets the principle
+- Preserve all content that already satisfies the principle
 - Do not introduce new violations
 ```
 
+The slot is named `SOURCE MATERIAL`, not `INITIAL OUTPUT`, and it is not optional here —
+unlike the same-named slot in frameworks that generate from scratch, this framework has
+nothing to critique without it.
+
 ### Multi-Principle Version
-```
-PRINCIPLES:
-P1: [First principle]
-P2: [Second principle]
-P3: [Third principle]
 
-INITIAL OUTPUT:
-[The output]
+Same shape as above. The principles are enumerated in the single `PRINCIPLE` slot with
+stable labels, and the critique phase is run once per principle in the order they were
+listed. The framing paragraph, the `SOURCE MATERIAL` anchor sentence, and the revision
+prose are unchanged.
 
-CRITIQUE — P1:
-[Critique against P1]
+```
+You are enforcing a set of stated principles against an existing piece of writing. This is
+a two-phase task: write a critique, then write a revision. Do not skip the critique and go
+straight to the rewrite, and do not merge the two.
 
-CRITIQUE — P2:
-[Critique against P2]
+PRINCIPLE:
+The principles to enforce are the following, and only the following:
+P1: [State the first standard as complete, checkable sentences.]
+P2: [State the second one the same way.]
+P3: [State the third one the same way.]
+"P1", "P2" and "P3" are literal labels used by the critique below — keep them exactly as
+written. [Add or remove P lines, then delete this line.]
+
+SOURCE MATERIAL:
+[Paste the output to be critiqued here — AI-generated or human-written.]
+Use the material above as the text to be critiqued and revised for the work described
+below.
 
-CRITIQUE — P3:
-[Critique against P3]
+CRITIQUE:
+Before rewriting anything, work through the principles in order and, for each one
+separately, identify the specific ways the material above violates or falls short of it.
+Label each group of findings with the principle it belongs to.
+- Quote the specific passages that are problematic
+- Explain precisely why each passage violates that principle
+- Focus only on failures against the principles, not general quality
+- Where one passage violates more than one principle, say so under each
 
 REVISION:
-Rewrite addressing all critique points across all three principles.
+Then rewrite the material above so it fully satisfies every principle.
+- Address every critique point identified above, across all principles
+- Preserve all content that already satisfies the principles
+- Do not introduce new violations
+- Where two principles pull against each other, satisfy the earlier-listed one and say
+  which trade-off you made
 ```
 
 ## Complete Examples
 
+Every example below is shown in emitted form: the framing paragraph first, then each slot
+carrying its own role in prose. Read the headers as scaffolding that will be deleted — the
+examples are written so that nothing is lost when it is. Only the `SOURCE MATERIAL` block
+keeps a `[...]` placeholder, because the text to be critiqued is the one thing the user
+must supply.
+
 ### Example 1: Plain Language Compliance
 
 ```
-PRINCIPLE:
-Plain language only. Every sentence must be understandable by someone
-with no technical background. No jargon without immediate plain-language
-definition. Maximum sentence length: 20 words.
+You are enforcing a stated principle against an existing piece of writing. This is a
+two-phase task: write a critique, then write a revision. Do not skip the critique and go
+straight to the rewrite, and do not merge the two.
 
-INITIAL OUTPUT:
-Our API leverages asynchronous microservice orchestration to facilitate
-real-time event-driven data synchronization across distributed endpoints,
-enabling seamless interoperability between heterogeneous enterprise systems.
+PRINCIPLE:
+The principle to enforce is this:
+Plain language only. Every sentence must be understandable by a reader with no technical
+background. No jargon may appear without an immediate plain-language definition. No
+sentence may exceed 20 words.
+
+SOURCE MATERIAL:
+Our API leverages asynchronous microservice orchestration to facilitate real-time
+event-driven data synchronization across distributed endpoints, enabling seamless
+interoperability between heterogeneous enterprise systems.
+Use the material above as the text to be critiqued and revised for the work described
+below.
 
 CRITIQUE:
-Identify every phrase that violates the plain language principle above.
-Quote each problematic phrase and explain the violation.
+Before rewriting anything, identify the specific ways the material above violates or falls
+short of the principle.
+- Quote every phrase that is jargon, that stands undefined, or that carries a sentence
+  past 20 words
+- Explain precisely which part of the principle each quoted phrase breaks
+- Focus only on failures against the principle, not general quality
 
 REVISION:
-Rewrite the description so a non-technical reader understands exactly
-what the product does.
+Then rewrite the material above so it fully satisfies the principle.
+- Address every critique point identified above
+- Preserve all content that already satisfies the principle
+- Do not introduce new violations
+- State plainly what the product does; do not compensate for lost jargon with new
+  abstraction
 ```
 
 ### Example 2: Evidence-Backed Claims
 
 ```
+You are enforcing a stated principle against an existing piece of writing. This is a
+two-phase task: write a critique, then write a revision. Do not skip the critique and go
+straight to the rewrite, and do not merge the two.
+
 PRINCIPLE:
-Every claim must be backed by reasoning, data, or an example.
-No assertion may stand without support. Hedging language ("might",
-"could") is acceptable only when genuine uncertainty exists.
+The principle to enforce is this:
+Every claim must be backed by reasoning, data, or an example. No assertion may stand
+without support. Hedging language such as "might" or "could" is acceptable only where
+genuine uncertainty exists, and the uncertainty must be named.
 
-INITIAL OUTPUT:
-[Paste an analysis or recommendation]
+SOURCE MATERIAL:
+[Paste the analysis or recommendation to be critiqued here.]
+Use the material above as the text to be critiqued and revised for the work described
+below.
 
 CRITIQUE:
-Identify every unsupported claim. Quote the specific assertion and
-state what type of support is missing (reasoning, data, or example).
+Before rewriting anything, identify the specific ways the material above violates or falls
+short of the principle.
+- Quote each unsupported assertion in full
+- For each one, name which type of support is missing: reasoning, data, or example
+- Quote separately any hedge that stands in for evidence rather than marking real
+  uncertainty
+- Focus only on failures against the principle, not general quality
 
 REVISION:
-Rewrite adding appropriate support for every flagged claim.
-If a claim cannot be supported, remove it or explicitly mark it
-as an assumption.
+Then rewrite the material above so it fully satisfies the principle.
+- Address every critique point identified above
+- Preserve all content that already satisfies the principle
+- Do not introduce new violations
+- Where a claim cannot be supported from the material given, either cut it or mark it
+  explicitly as an assumption; do not invent supporting data
 ```
 
 ### Example 3: User Agency Preservation
 
 ```
-PRINCIPLE:
-The response must preserve user agency. It may present options and
-tradeoffs but must not make decisions for the user. The final choice
-should always be explicitly left to the user with clear reasoning
-for each option.
+You are enforcing a stated principle against an existing piece of writing. This is a
+two-phase task: write a critique, then write a revision. Do not skip the critique and go
+straight to the rewrite, and do not merge the two.
 
-INITIAL OUTPUT:
-[Paste an AI recommendation that made a firm choice for the user]
+PRINCIPLE:
+The principle to enforce is this:
+The response must preserve the reader's agency. It may lay out options and their
+trade-offs, but it must not make the decision for them. The final choice must be left to
+the reader explicitly, with the reasoning for each option stated so the reader can weigh
+them.
+
+SOURCE MATERIAL:
+[Paste the recommendation to be critiqued here — the one that made a firm choice on the
+reader's behalf.]
+Use the material above as the text to be critiqued and revised for the work described
+below.
 
 CRITIQUE:
-Identify every place where the response makes a decision for the user
-or removes their agency. Quote the specific passages.
+Before rewriting anything, identify the specific ways the material above violates or falls
+short of the principle.
+- Quote every passage that settles the decision for the reader or narrows it to one option
+- Explain precisely how each quoted passage removes the reader's choice
+- Quote any option that is presented without the reasoning needed to weigh it
+- Focus only on failures against the principle, not general quality
 
 REVISION:
-Rewrite so the user has full information and clear options, but the
-final decision remains with them.
+Then rewrite the material above so it fully satisfies the principle.
+- Address every critique point identified above
+- Preserve all content that already satisfies the principle
+- Do not introduce new violations
+- Keep every substantive recommendation intact as a stated option with its reasoning;
+  preserving agency means returning the choice, not withholding the analysis
 ```
 
 ### Example 4: Factual Precision
 
 ```
+You are enforcing a stated principle against an existing piece of writing. This is a
+two-phase task: write a critique, then write a revision. Do not skip the critique and go
+straight to the rewrite, and do not merge the two.
+
 PRINCIPLE:
-The response must distinguish between: (1) established facts,
-(2) inferences based on evidence, and (3) speculation. Each claim
-must be labeled accordingly. No mixing of categories without labels.
+The principle to enforce is this:
+The response must distinguish established fact from evidence-based inference and from
+speculation. Every claim must be labeled as one of those three. No sentence may blend
+categories without labeling each part.
 
-INITIAL OUTPUT:
-[Paste a technical or analytical response]
+SOURCE MATERIAL:
+[Paste the technical or analytical response to be critiqued here.]
+Use the material above as the text to be critiqued and revised for the work described
+below.
 
 CRITIQUE:
-Identify claims that mix categories or present inferences as facts.
-Quote each and categorize it.
+Before rewriting anything, identify the specific ways the material above violates or falls
+short of the principle.
+- Quote each claim that is unlabeled, mislabeled, or blends two categories in one sentence
+- State which of the three categories each quoted claim actually belongs to, and why
+- Focus only on failures against the principle, not general quality
 
 REVISION:
-Rewrite with explicit labeling: [FACT], [INFERENCE], [SPECULATION]
-where appropriate.
+Then rewrite the material above so it fully satisfies the principle.
+- Address every critique point identified above
+- Preserve all content that already satisfies the principle
+- Do not introduce new violations
+- Label every claim [FACT], [INFERENCE], or [SPECULATION], splitting any sentence that
+  carries more than one category
+- Do not promote a claim to a stronger category to avoid an awkward label
 ```
 
 ## Best Use Cases
@@ -222,9 +330,9 @@ where appropriate.
 
 ## Quick Reference
 
-| Component | Purpose |
-|-----------|---------|
-| Principle | The specific standard to enforce |
-| Initial Output | The output to evaluate |
-| Critique | Quote-specific violations of the principle |
-| Revision | Rewrite satisfying all critique points |
+| Component | Template slot | Purpose |
+|-----------|---------------|---------|
+| Principle | `PRINCIPLE` | The specific standard to enforce |
+| Initial Generation | `SOURCE MATERIAL` | The output to evaluate (required) |
+| Critique | `CRITIQUE` | Quote-specific violations of the principle |
+| Revision | `REVISION` | Rewrite satisfying all critique points |

package/skills/prompt-architect/references/frameworks/care.md

@@ -2,14 +2,14 @@
 
 ## Overview
 
-CARE (Context, Ask, Rules, Examples) is a practitioner framework from Nielsen Norman Group that adds an explicit **Rules** component to the standard context-task-examples pattern. This makes it particularly effective for tasks where constraints, guardrails, or quality standards need to be enforced — the Rules component directly addresses what the AI should and should not do, reducing the need for post-hoc correction.
+CARE (Context, Ask, Rules, Examples) is a practitioner framework from Nielsen Norman Group that adds an explicit **Rules** component to the standard context-task-examples pattern. This makes it particularly effective for tasks where constraints, guardrails, or quality standards need to be enforced — the Rules component directly addresses what the AI should and should not do, reducing the need for post-hoc correction. Section headers are stripped at emission, so a CARE prompt lands as a flat block — a paragraph of context, a sentence naming the ask, a list of self-standing rules, and one or more labelled examples — preceded by an optional source-material block whenever the task works from a document or draft the user already has.
 
 **Origin:** Nielsen Norman Group (nngroup.com) — a leading UX and AI research firm. The NNg formulation focuses on making prompts "CAREFUL" — ensuring AI outputs are constrained, targeted, and appropriately scoped.
 
 ## Components
 
 ### C — Context
-**Purpose:** Provide the background and situation needed to understand the task — who you are, what the situation is, and why this task matters.
+**Purpose:** Provide the background and situation needed to understand the task — who you are, what the situation is, and why this task matters. It fills as a self-contained paragraph and survives header stripping on its own, so long as it reads as description of a situation rather than a bare label.
 
 **Questions to Ask:**
 - Who are you in this situation?
@@ -17,24 +17,24 @@ CARE (Context, Ask, Rules, Examples) is a practitioner framework from Nielsen No
 - Why is this task being done?
 
 **Examples:**
-- "I am a UX designer preparing for a usability study..."
-- "We are a healthcare startup building a patient-facing mobile app..."
-- "I am a manager writing a performance review for a direct report..."
+- "I am a UX designer preparing for a usability study on our mobile banking app."
+- "We are a healthcare startup building a patient-facing mobile app for people with low health literacy."
+- "I am a manager writing a performance review for a direct report."
 
 ### A — Ask
-**Purpose:** State the specific request — what you want the AI to produce or do.
+**Purpose:** State the specific request — what you want the AI to produce or do — as one complete imperative sentence. When source material is supplied above, refer to it as "the … above," never "below," so the reference still points at the pasted artifact once the header is gone.
 
 **Questions to Ask:**
 - What is the exact deliverable?
 - What should the output be?
 
 **Examples:**
-- "Write a set of 5 interview questions for testing navigation usability..."
-- "Draft a 3-paragraph executive summary of this technical report..."
-- "Create a rubric for evaluating onboarding email effectiveness..."
+- "Write a set of 5 interview questions for testing navigation usability."
+- "Draft a 3-paragraph executive summary of the technical report above."
+- "Create a rubric for evaluating onboarding email effectiveness."
 
 ### R — Rules
-**Purpose:** Define explicit constraints, guardrails, standards, and dos/don'ts that govern the output. This is the defining component of CARE — it makes requirements explicit rather than assumed.
+**Purpose:** Define explicit constraints, guardrails, standards, and dos/don'ts that govern the output. This is the defining component of CARE — it makes requirements explicit rather than assumed. Each rule must be a complete, self-standing clause, and every prohibition must carry its own negation ("Do not…", "Never…", "No…"): the `RULES` header is stripped at emission, and a bare noun phrase left in its place reads as a thing to do rather than a thing to avoid.
 
 **Questions to Ask:**
 - What must be included?
@@ -44,12 +44,12 @@ CARE (Context, Ask, Rules, Examples) is a practitioner framework from Nielsen No
 - What would make this output wrong or unusable?
 
 **Examples:**
-- "Rules: Use plain language (max grade 8 reading level). Avoid medical jargon. Each question must be open-ended, not yes/no. Do not suggest answers in the question wording."
-- "Rules: Under 300 words. No bullet points — prose only. Must include a clear recommendation. Do not mention competitor names."
-- "Rules: Must comply with ADA language guidelines. No deficit-based language. First-person framing only."
+- "Use plain language (max grade 8 reading level). Avoid medical jargon. Each question must be open-ended, not yes/no. Do not suggest answers in the question wording."
+- "Keep it under 300 words. No bullet points — prose only. Include a clear recommendation. Do not mention competitor names."
+- "Comply with ADA language guidelines. Use no deficit-based language. Use first-person framing only."
 
 ### E — Examples
-**Purpose:** Provide 1-3 examples that demonstrate the desired output format, tone, style, or quality level.
+**Purpose:** Provide 1-3 examples that demonstrate the desired output format, tone, style, or quality level. Label each example in prose — "Good:", "Bad:", or a short framing sentence — because the `EXAMPLES` header is stripped, and an unlabelled sample dropped into the flat block reads as part of the instructions rather than as a reference.
 
 **Questions to Ask:**
 - Is there an existing example of what good looks like?
@@ -57,36 +57,62 @@ CARE (Context, Ask, Rules, Examples) is a practitioner framework from Nielsen No
 - What tone should it mirror?
 
 **Examples:**
-- "Example question: 'Walk me through how you would find the settings for your account.'"
-- "Example summary paragraph: [paste existing example]"
-- "Example format: [show template]"
+- "Good question: 'Walk me through how you would find the settings for your account.'"
+- "Good summary paragraph: [paste existing example]"
+- "Example format to match: [show template]"
 
 ## Template Structure
 
+Section headers are stripped at emission, so every slot's meaning is carried by the prose
+around and inside it rather than by the header above it. This matters most for the Rules
+list: each rule must be a complete clause, and every prohibition must keep its own negation.
+A bare noun phrase left where the `RULES` header used to be reads as an instruction to do
+the very thing it was meant to forbid. Examples must be labelled in prose for the same
+reason — an unlabelled sample reads as part of the ask once its header is gone.
+
 ```
+SOURCE MATERIAL:
+[Optional — include only if this task works from material you already have. Paste the source document, data, or draft this task operates on here. If you have nothing to paste, delete this bracketed block along with the sentence directly below it.]
+Use the material above as the factual basis for the work described below.
+
 CONTEXT:
-[Who you are, the situation, why this task exists]
+[Who you are, the situation you're in, and why this task exists]
 
 ASK:
 [The specific request and deliverable]
 
 RULES:
-[Explicit constraints — what must be included, what must be avoided,
-quality standards, format requirements, length limits, tone requirements,
-compliance requirements, reading level, etc.]
+[Explicit constraints governing the output:
+- What must be included
+- What must be avoided
+- Format and length requirements
+- Tone and reading level standards
+- Quality bar or compliance requirements]
 
 EXAMPLES:
-[1-3 examples of desired output format, tone, or style]
+[1-3 examples showing the desired output format, tone, or quality standard]
 ```
 
+`SOURCE MATERIAL` is a fifth block in a four-letter acronym, and it carries no letter
+because it is optional. When a CARE task works from something that already exists — a
+report to summarize, clinical guidance to translate, a draft to revise — that artifact is
+pasted here and the Ask refers to it as "the … above." Delete the block and the sentence
+beneath it whenever the task generates from scratch, which for constraint-driven CARE tasks
+is common.
+
 ## Complete Examples
 
+Every example below is shown in emitted form: each slot carries its own role in prose.
+Read the headers as scaffolding that will be deleted — the examples are written so that
+nothing is lost when it is.
+
 ### Example 1: UX Research
 
 **Before CARE:**
 "Write interview questions for our usability study."
 
-**After CARE:**
+**After CARE** (no source material — the questions are written from scratch, so the
+`SOURCE MATERIAL` block and the sentence below it are both deleted):
 ```
 CONTEXT:
 I am a UX researcher preparing for a moderated usability study on our
@@ -102,9 +128,9 @@ RULES:
 - All questions must be open-ended (no yes/no questions)
 - Use plain, everyday language — no banking or UX jargon
 - Do not suggest answers within the question (no leading questions)
-- Each question should address one thing only (no double-barreled)
+- Each question should address one thing only (no double-barreled questions)
 - Avoid "why" questions (use "what made you..." instead)
-- Questions should take no more than 3 minutes each to answer
+- Each question should take no more than 3 minutes to answer
 
 EXAMPLES:
 Good: "What went through your mind when you reached the confirmation screen?"
@@ -116,24 +142,28 @@ Bad: "Was the confirmation screen clear and easy to understand?" (yes/no, leadin
 **Before CARE:**
 "Write patient education content about diabetes management."
 
-**After CARE:**
+**After CARE** (source material supplied):
 ```
+SOURCE MATERIAL:
+[Paste the clinical guidance on blood sugar monitoring here]
+Use the material above as the factual basis for the work described below.
+
 CONTEXT:
 I am a health content writer for a patient portal used by adults with
 Type 2 diabetes. Many patients have low health literacy. The content
 will appear in a mobile app alongside their care plan.
 
 ASK:
-Write a 200-word article explaining why blood sugar monitoring matters
-and how often to check.
+Rewrite the clinical guidance above into a 200-word article explaining why
+blood sugar monitoring matters and how often to check.
 
 RULES:
 - Maximum 6th grade reading level (use Flesch-Kincaid as guide)
-- Avoid medical jargon; if medical term must be used, define it
+- Avoid medical jargon; if a medical term must be used, define it
 - Use active voice and second-person ("you") throughout
-- No numbers or statistics unless critical — prefer plain descriptions
+- Do not include numbers or statistics unless critical — prefer plain descriptions
 - Must include a clear, simple call to action at the end
-- Do not recommend specific monitoring frequency — use "as directed by your doctor"
+- Do not recommend a specific monitoring frequency — use "as directed by your doctor"
 - Comply with plain language guidelines (short sentences, common words)
 
 EXAMPLES:
@@ -148,7 +178,8 @@ response to dietary and physical stimuli."
 **Before CARE:**
 "Write error messages for our app."
 
-**After CARE:**
+**After CARE** (no source material — the messages are written from scratch, so the
+`SOURCE MATERIAL` block and the sentence below it are both deleted):
 ```
 CONTEXT:
 I am a product designer writing UI error messages for a B2B data analytics
@@ -161,12 +192,12 @@ Write error messages for these 3 error states: (1) file format not supported,
 
 RULES:
 - Maximum 2 sentences per error message
-- Must include: what happened + what the user can do about it
+- Each message must include what happened and what the user can do about it
 - Use plain language — no HTTP status codes, no stack traces, no internal IDs
-- Active voice, direct address ("You can..." not "The user can...")
+- Use active voice and direct address ("You can..." not "The user can...")
 - Do not blame the user ("You uploaded the wrong format" is bad)
-- Must include a specific actionable next step (not just "try again")
-- Tone: calm, helpful, matter-of-fact — not apologetic or alarming
+- Each message must include a specific actionable next step, not just "try again"
+- Keep the tone calm, helpful, and matter-of-fact — not apologetic or alarming
 
 EXAMPLES:
 Good: "This file type isn't supported. Try uploading a .CSV or .XLSX file."