@ckelsoe/prompt-architect 3.2.2 → 3.4.0

package/skills/prompt-architect/references/frameworks/iterative-compression.md

@@ -0,0 +1,448 @@
+# Iterative Compression Framework
+
+## Overview
+
+Iterative Compression progressively tightens a piece of text through multiple passes. Each iteration cuts redundancy, sharpens phrasing, and raises information density — typically while reducing overall length toward a target. It rests on the observation that successive editing passes usually beat trying to get everything right in one shot.
+
+**Origin:** General practitioner technique with no single documented originator — the multi-pass editing loop long predates LLMs. This is a house pattern, not a published method, and it is not research-backed. **Not to be confused with Chain of Density** (Adams et al., arXiv 2309.04269), which holds length *fixed* while raising entity density. The two techniques are frequently conflated, including in earlier versions of this package. If your goal is a shorter text, use this framework; if your goal is more information in the *same* number of words, use `chain-of-density.md`.
+
+## Core Concept
+
+Instead of requesting the perfect output immediately, Iterative Compression:
+1. Starts with a basic/verbose version
+2. Iteratively refines through multiple passes
+3. Increases information density each time
+4. Removes fluff and redundancy
+5. Enhances clarity and precision
+6. Converges on optimal output
+
+Think of it as "progressive enhancement" for prompts.
+
+## When to Use Iterative Compression
+
+**Ideal for:**
+- Summarization tasks
+- Content compression
+- Iterative improvement of writing
+- Optimizing explanations
+- Refining complex outputs
+- Tasks where quality improves with iteration
+
+**Not needed for:**
+- Simple one-shot tasks
+- When first draft is sufficient
+- Time-critical quick tasks
+- Tasks with fixed formats that can't improve
+
+## Best Practices
+
+### 1. Define What to Optimize
+```
+Good:
+"Iterate to improve:
+- Information density
+- Clarity
+- Conciseness
+- Precision"
+
+Poor:
+"Make it better"
+```
+
+### 2. Specify Number of Iterations
+```
+Good:
+"Refine through 4 iterations, showing each version"
+
+Poor:
+"Keep improving until it's good"
+```
+
+### 3. Show Evolution
+```
+Good:
+"Show each iteration and explain what changed and why"
+
+Poor:
+"Just give me the final version"
+```
+
+### 4. Set Clear Constraints
+```
+Good:
+"Each iteration should be 20% shorter while maintaining completeness"
+
+Poor:
+"Make it shorter"
+```
+
+## Template Structure
+
+Section headers are stripped at emission, along with the divider rules that separate them in the shipped `.txt`, so every slot's meaning is carried by the unbracketed prose that travels with it rather than by the header above it. The one exception is the `Iteration 1:` / `Iteration 2:` / `Iteration 3:` labels — those are literal labels inside the protocol, not section headers, and they must survive into the emitted prompt exactly as written.
+
+```
+SOURCE MATERIAL:
+[Paste the full text to be compressed here.]
+Use the material above as the text to be compressed for the work described below.
+Every version must be a rewrite of that material — never introduce a claim it does
+not support.
+
+OPTIMIZATION GOAL:
+Every pass must move the text toward this goal:
+[A full sentence naming what improves and by how much, not a bare label like
+"concision." For example: "Reduce word count by 20% each pass while retaining all key
+information," or "Raise information density — cut filler until every sentence earns
+its place."]
+
+TARGET:
+The final version must reach this end state:
+[A phrase completing the sentence above, e.g. "under 150 words and readable by a
+non-specialist." Name the unit, not a bare number.]
+
+NUMBER OF ITERATIONS:
+Run this many passes in total:
+[The count as a phrase completing the sentence above, e.g. "three passes."
+Typical: 2-4]
+Iteration 1: [What this first pass must do to the source text, as a full sentence.]
+Iteration 2: [How this pass tightens the result of pass 1, as a full sentence.]
+Iteration 3: [Optional — what this final polish pass must do, as a full sentence.
+Delete this line if running fewer than three passes; add further Iteration lines in
+the same form if running more.]
+
+ITERATION INSTRUCTIONS:
+In each pass, identify what can be cut, compressed, or clarified, apply the changes,
+then check both that the result serves the goal above better than the version before
+it and that nothing the goal requires keeping was lost. Stop when [a clause completing
+this sentence, e.g. "no filler words remain" or "all three passes are complete"].
+
+OUTPUT FORMAT:
+Deliver the final version in this format:
+[A phrase completing the sentence above, e.g. "a single paragraph of continuous
+prose," a bullet list, or a one-sentence summary.]
+
+INTERMEDIATE VERSIONS:
+[Optional — keep exactly one of these two sentences as the entire content of this
+block, or delete the block: "Show the output of every iteration in order, labelled by
+pass number." / "Show only the final version — do not print the intermediate
+passes."]
+
+Compression has a floor. Past a point, passes strip meaning rather than filler. If a
+pass would remove something a reader needs, stop at the previous version and deliver
+that.
+```
+
+Two slots behave differently from their counterparts in other frameworks in this package. `SOURCE MATERIAL` is **not** optional here — several frameworks let you delete that block when you have nothing to paste, but this one cannot: compression is defined as a rewrite of supplied text, so with no source there is nothing to compress. `INTERMEDIATE VERSIONS` is the opposite — it is genuinely optional, and when kept it takes exactly one of the two supplied sentences as its entire content rather than free-form instructions.
+
+The closing paragraph about compression's floor is unbracketed prose, not a fillable slot. It ships verbatim in every emitted prompt and is the stopping condition that keeps the last pass from stripping meaning.
+
+The `Iteration N:` lines admit two shapes. A **length ladder** names a shrinking word count for each pass (200 → 150 → 100 → 75), which suits material with a hard limit to hit. **Progressive tightening** instead names what each pass removes — restatement first, then inferable detail, then hedges — which suits material where the floor matters more than the number. Either shape is on-method; what is not is assigning each pass a *different quality dimension* (clarity, then impact, then tone). That is multi-dimensional refinement rather than compression, the text does not get shorter, and it is what `self-refine.md` is for. Use this framework only when the text should shrink.
+
+## Complete Examples
+
+Every example below is shown in emitted form: each slot carries its own role in prose.
+Read the section headers as scaffolding that will be deleted — the examples are written
+so that nothing is lost when it is. The `Iteration N:` lines are the exception: they are
+literal labels inside the protocol, not section headers, and they survive emission
+exactly as written.
+
+### Example 1: Summarization
+
+**Without Iterative Compression:**
+```
+Summarize this research paper.
+```
+
+**With Iterative Compression:**
+```
+SOURCE MATERIAL:
+[Paste the full text of the research paper here]
+Use the material above as the text to be compressed for the work described below.
+Every version must be a rewrite of that material — never introduce a claim it does
+not support.
+
+OPTIMIZATION GOAL:
+Every pass must move the text toward this goal:
+Cut roughly a quarter of the word count on each pass while retaining every finding,
+the method that produced it, and the limitations the authors state.
+
+TARGET:
+The final version must reach this end state:
+Under 75 words, covering the core findings, and readable by someone outside the field.
+
+NUMBER OF ITERATIONS:
+Run this many passes in total:
+four passes.
+Iteration 1: Write a comprehensive summary of roughly 200 words covering every major
+point, prioritizing completeness over brevity.
+Iteration 2: Cut that summary to roughly 150 words by removing repeated information
+and combining related points.
+Iteration 3: Cut to roughly 100 words, keeping only what a reader needs in order to
+understand what was found and how it was established.
+Iteration 4: Cut to 75 words, distilling to the core findings while preserving the
+numbers and qualifiers that keep them accurate.
+
+ITERATION INSTRUCTIONS:
+In each pass, identify what can be cut, compressed, or clarified, apply the changes,
+then check both that the result serves the goal above better than the version before
+it and that nothing the goal requires keeping was lost. Stop when all four passes are
+complete.
+
+OUTPUT FORMAT:
+Deliver the final version in this format:
+a single paragraph of continuous prose.
+
+INTERMEDIATE VERSIONS:
+Show the output of every iteration in order, labelled by pass number.
+
+Compression has a floor. Past a point, passes strip meaning rather than filler. If a
+pass would remove something a reader needs, stop at the previous version and deliver
+that.
+```
+
+### Example 2: Code Documentation
+
+**Without Iterative Compression:**
+```
+Document this function.
+```
+
+**With Iterative Compression:**
+```
+SOURCE MATERIAL:
+[Paste the function's signature and its existing documentation here]
+Use the material above as the text to be compressed for the work described below.
+Every version must be a rewrite of that material — never introduce a claim it does
+not support.
+
+OPTIMIZATION GOAL:
+Every pass must move the text toward this goal:
+Cut length while keeping every parameter, return value, raised exception, and edge
+case a caller must know about — remove restatement of what the signature already
+shows, not the behaviour it does not.
+
+TARGET:
+The final version must reach this end state:
+Under 120 words, readable without scrolling, and complete enough that a caller never
+has to open the implementation.
+
+NUMBER OF ITERATIONS:
+Run this many passes in total:
+three passes.
+Iteration 1: Cut every sentence that restates the signature or names types the
+signature already declares.
+Iteration 2: Merge the remaining prose so each parameter, return value, and raised
+exception is described exactly once, in one place.
+Iteration 3: Cut to 120 words by reducing the examples to the single shortest call
+that still shows the edge case a caller is most likely to hit.
+
+ITERATION INSTRUCTIONS:
+In each pass, identify what can be cut, compressed, or clarified, apply the changes,
+then check both that the result serves the goal above better than the version before
+it and that nothing the goal requires keeping was lost. Stop when all three passes are
+complete.
+
+OUTPUT FORMAT:
+Deliver the final version in this format:
+a docstring with a one-line summary, a parameter list, a return description, and at
+most one example.
+
+INTERMEDIATE VERSIONS:
+Show only the final version — do not print the intermediate passes.
+
+Compression has a floor. Past a point, passes strip meaning rather than filler. If a
+pass would remove something a reader needs, stop at the previous version and deliver
+that.
+```
+
+### Example 3: Email Refinement
+
+**Without Iterative Compression:**
+```
+Write an email announcing this feature.
+```
+
+**With Iterative Compression:**
+```
+SOURCE MATERIAL:
+[Paste the full draft of the announcement email here]
+Use the material above as the text to be compressed for the work described below.
+Every version must be a rewrite of that material — never introduce a claim it does
+not support.
+
+OPTIMIZATION GOAL:
+Every pass must move the text toward this goal:
+Cut roughly a third of the word count on each pass while keeping what the feature
+does, who it affects, when it ships, and what the reader has to do about it.
+
+TARGET:
+The final version must reach this end state:
+Under 120 words, scannable in fifteen seconds, with the action the reader must take
+stated in the first two sentences.
+
+NUMBER OF ITERATIONS:
+Run this many passes in total:
+three passes.
+Iteration 1: Move the action the reader must take to the opening and cut the
+throat-clearing that currently precedes it.
+Iteration 2: Cut the background to the single sentence a reader needs in order to
+understand why the change is happening.
+Iteration 3: Cut to 120 words by removing hedges, restated benefits, and any sentence
+whose removal a reader would not notice.
+
+ITERATION INSTRUCTIONS:
+In each pass, identify what can be cut, compressed, or clarified, apply the changes,
+then check both that the result serves the goal above better than the version before
+it and that nothing the goal requires keeping was lost. Stop when all three passes are
+complete.
+
+OUTPUT FORMAT:
+Deliver the final version in this format:
+a subject line followed by no more than three short paragraphs.
+
+INTERMEDIATE VERSIONS:
+Show the output of every iteration in order, labelled by pass number.
+
+Compression has a floor. Past a point, passes strip meaning rather than filler. If a
+pass would remove something a reader needs, stop at the previous version and deliver
+that.
+```
+
+### Example 4: Technical Explanation
+
+**Without Iterative Compression:**
+```
+Explain how this algorithm works.
+```
+
+**With Iterative Compression:**
+```
+SOURCE MATERIAL:
+[Paste the full existing explanation of the algorithm here]
+Use the material above as the text to be compressed for the work described below.
+Every version must be a rewrite of that material — never introduce a claim it does
+not support.
+
+OPTIMIZATION GOAL:
+Every pass must move the text toward this goal:
+Roughly halve the word count on each pass while keeping the algorithm's inputs, its
+outputs, the step that does the real work, and its complexity.
+
+TARGET:
+The final version must reach this end state:
+Under 100 words, understandable by a developer who has never seen the algorithm, with
+no step omitted that they would need in order to implement it.
+
+NUMBER OF ITERATIONS:
+Run this many passes in total:
+three passes.
+Iteration 1: Cut to roughly 400 words by removing history, motivation, and
+comparisons to other algorithms.
+Iteration 2: Cut to roughly 200 words by reducing the worked example to its shortest
+form and dropping any step the reader can infer from the ones around it.
+Iteration 3: Cut to 100 words, keeping the inputs, the outputs, the central step, and
+the complexity, and nothing else.
+
+ITERATION INSTRUCTIONS:
+In each pass, identify what can be cut, compressed, or clarified, apply the changes,
+then check both that the result serves the goal above better than the version before
+it and that nothing the goal requires keeping was lost. Stop when all three passes are
+complete.
+
+OUTPUT FORMAT:
+Deliver the final version in this format:
+a numbered list of steps followed by one sentence naming the time and space
+complexity.
+
+INTERMEDIATE VERSIONS:
+Show the output of every iteration in order, labelled by pass number.
+
+Compression has a floor. Past a point, passes strip meaning rather than filler. If a
+pass would remove something a reader needs, stop at the previous version and deliver
+that.
+```
+
+## Refinement Strategies
+
+### What to Remove
+- Redundant information
+- Obvious statements
+- Unnecessary qualifiers ("very", "really")
+- Passive voice (often)
+- Filler words
+- Overly general statements
+
+### What to Add
+- Specific examples
+- Precise numbers
+- Concrete details
+- Missing context (if essential)
+- Clarifying examples
+
+### What to Improve
+- Vague language → specific language
+- Long sentences → shorter, punchier
+- Complex words → simpler alternatives (if clearer)
+- Weak verbs → strong verbs
+- Passive voice → active voice
+
+## Quality Indicators
+
+**Good Iterative Compression iterations show:**
+- ✅ Measurable improvement each pass
+- ✅ Increased information density
+- ✅ Reduced redundancy
+- ✅ Maintained accuracy
+- ✅ Enhanced clarity
+- ✅ Clear evolution path
+
+**Poor Iterative Compression iterations show:**
+- ❌ No meaningful change
+- ❌ Loss of important information
+- ❌ Decreased clarity
+- ❌ Introduced errors
+- ❌ Just made it shorter without improvement
+
+## Use Cases
+
+### 1. Content Summarization
+Taking long documents and progressively distilling essence
+
+### 2. Message Refinement
+Iteratively improving emails, announcements, communications
+
+### 3. Documentation Optimization
+Making docs clearer and more concise through iteration
+
+### 4. Explanation Enhancement
+Progressively improving how concepts are explained
+
+### 5. Writing Polish
+Iterative editing of creative or professional writing
+
+### 6. Presentation Optimization
+Refining slides/talks through multiple passes
+
+## Assessment Checklist
+
+When using Iterative Compression:
+- [ ] Task benefits from iteration
+- [ ] Number of iterations specified
+- [ ] Optimization goals are clear
+- [ ] Each iteration has purpose
+- [ ] Constraints defined for each pass
+- [ ] Evolution is tracked/shown
+- [ ] Quality criteria established
+- [ ] Stopping condition exists
+- [ ] Final version is actually better
+- [ ] Process improved understanding
+
+## Tips for Success
+
+1. **Start Verbose**: First iteration should be complete, even if wordy
+2. **One Focus Per Iteration**: Don't try to improve everything at once
+3. **Show Your Work**: Display each iteration to see progress
+4. **Set Constraints**: Give specific targets (word counts, focus areas)
+5. **Verify Improvement**: Check that each iteration actually improves quality
+6. **Don't Over-Iterate**: 3-5 iterations usually sufficient
+7. **Preserve Accuracy**: Never sacrifice correctness for brevity
+8. **Explain Changes**: Note what improved and why

package/skills/prompt-architect/references/frameworks/least-to-most.md

@@ -4,6 +4,8 @@
 
 Least-to-Most (LtM) prompting is a decomposition-first framework that breaks a complex problem into an ordered sequence of simpler subproblems, then solves them sequentially — using each prior answer as context for the next. Unlike Chain of Thought (which reasons through a problem in one pass), LtM explicitly separates decomposition from execution, and the subproblems are sequenced from simplest to most complex.
 
+When the prompt is emitted, its section headers — PROBLEM, SOURCE MATERIAL, DECOMPOSE, SOLVE SEQUENTIALLY — are stripped and the model receives a flat block; the decomposition and solving instructions are written as complete sentences, and the `Subproblem 1:` / `Final:` labels survive as literal labels inside the protocol, so the ordered structure is preserved without the headers.
+
 **Research basis:** "Least-to-Most Prompting Enables Complex Reasoning in Large Language Models" (Zhou et al., Google Brain, arXiv:2205.10625, ICLR 2023). On SCAN compositional generalization: LtM achieves 99.7% vs. CoT's 16%. On GSM8K math: matches or exceeds CoT with fewer errors.
 
 ## Why LtM Differs from Chain of Thought
@@ -19,7 +21,7 @@ Least-to-Most (LtM) prompting is a decomposition-first framework that breaks a c
 ## Components
 
 ### Phase 1: Decomposition
-**Purpose:** Break the original problem into an ordered list of subproblems, from simplest to most complex. The key: later subproblems should build on earlier ones.
+**Purpose:** Break the original problem into an ordered list of subproblems, from simplest to most complex. The key: later subproblems should build on earlier ones. The DECOMPOSE header is stripped at emission, so the instruction that opens this phase must be a complete sentence; the numbered `Subproblem 1:`, `Subproblem 2:`, `Final:` labels are literal labels in the protocol and survive the stripping, which is what preserves the ordering once the header is gone.
 
 **Trigger:** "To solve [problem], we need to first solve: [list subproblems in order]"
 
@@ -29,29 +31,39 @@ Least-to-Most (LtM) prompting is a decomposition-first framework that breaks a c
 - What is the correct ordering — which must come first?
 
 ### Phase 2: Sequential Solving
-**Purpose:** Solve each subproblem in order, explicitly using prior answers as context.
+**Purpose:** Solve each subproblem in order, explicitly using prior answers as context. Once the SOLVE SEQUENTIALLY header is removed, the only thing telling the model to reuse earlier answers is this instruction, so it ships as an explicit sentence — carry each answer forward as context for the next subproblem — rather than resting on the header.
 
 **Pattern:** Answer subproblem 1 → use that answer when solving subproblem 2 → use both when solving subproblem 3 → ... → solve original problem.
 
 ## Template Structure
 
+Section headers — `PROBLEM:`, `SOURCE MATERIAL:`, `DECOMPOSE:`, `SOLVE SEQUENTIALLY:` —
+are stripped at emission, so the instruction beneath each one carries its meaning, and the
+`Subproblem N:` / `Final:` labels stay as literal labels rather than headings. The
+`SOURCE MATERIAL` block is optional: it names the artifact the subproblems reason over and
+is deleted when the problem is self-contained.
+
 ```
 PROBLEM:
 [The full, complex problem to solve]
 
+SOURCE MATERIAL:
+[Optional — paste the source material this problem depends on here (the dataset, figures, code, or document the subproblems must reason over). Delete this line and the one below it if the problem above is self-contained.]
+Every subproblem below must be answered against the material above, not from assumption.
+
 DECOMPOSE:
-Break this problem into ordered subproblems, from simplest to most complex.
+Break this problem into ordered subproblems, from simplest prerequisite to most complex.
 Each later subproblem should build on the answer to the previous.
 
-Subproblem 1: [Simplest prerequisite]
-Subproblem 2: [Next level, may depend on #1]
-Subproblem 3: [More complex, depends on #1-2]
-...
+Subproblem 1: [Simplest prerequisite — must be answered first]
+Subproblem 2: [Builds on #1]
+Subproblem 3: [Builds on #1-2]
+[Add subproblems as needed]
 Final: [The original problem, now solvable using all prior answers]
 
 SOLVE SEQUENTIALLY:
-Solve each subproblem in order. Use prior answers as context for each
-subsequent subproblem. Show each solution before moving to the next.
+Solve each subproblem in order. Use prior answers explicitly as context
+for each subsequent subproblem. Show each solution before moving to the next.
 ```
 
 ### Single-Pass Trigger (model decomposes and solves itself):
@@ -66,12 +78,17 @@ Problem: [your problem]
 
 ## Complete Examples
 
+Every example below is shown in emitted form. Where the subproblems reason over an existing
+artifact, the `SOURCE MATERIAL` block carries it and later subproblems refer to "the
+material above"; where the problem is self-contained, that block is deleted.
+
 ### Example 1: Multi-Hop Reasoning
 
 **Before LtM:**
 "What would the tax implications be for a US remote employee working from Portugal for 3 months?"
 
-**After LtM:**
+**After LtM** (no source material — the problem is self-contained, so the `SOURCE MATERIAL`
+block is deleted):
 ```
 PROBLEM:
 What are the tax implications for a US citizen employed by a US company who
@@ -102,7 +119,8 @@ SOLVE SEQUENTIALLY:
 **Before LtM:**
 "How do I add real-time notifications to my Django app?"
 
-**After LtM:**
+**After LtM** (no source material — the problem is self-contained, so the `SOURCE MATERIAL`
+block is deleted):
 ```
 PROBLEM:
 I need to add real-time push notifications to a Django app with PostgreSQL.
@@ -132,12 +150,16 @@ SOLVE SEQUENTIALLY:
 **Before LtM:**
 "Should we expand to the European market?"
 
-**After LtM:**
+**After LtM** (source material supplied):
 ```
 PROBLEM:
 Our B2B SaaS has strong US traction. Should we expand to the European market
 now, given our current 20-person team and 18 months of runway?
 
+SOURCE MATERIAL:
+[Paste the current financials, team breakdown, and US traction metrics here]
+Every subproblem below must be answered against the material above, not from assumption.
+
 DECOMPOSE:
 Subproblem 1: What are the key differences between US and European B2B SaaS
 markets that affect a US-native product? (GDPR, sales cycles, localization needs)
@@ -148,7 +170,7 @@ Subproblem 2: What resources are typically required for a credible EU market ent
 Subproblem 3: What are the signals that a company is or isn't ready for
 international expansion?
 
-Subproblem 4: Given our specific constraints (20 people, 18 months runway),
+Subproblem 4: Given the team size, runway, and traction shown in the material above,
 how do our resources map to those requirements?
 
 Final: Should we expand to Europe now, wait, or explore a different

package/skills/prompt-architect/references/frameworks/plan-and-solve.md

@@ -4,6 +4,8 @@
 
 Plan-and-Solve (PS+) is a zero-shot prompting technique that improves upon standard Chain of Thought by instructing the model to explicitly plan the solution approach before executing it — and to be careful about extracting variables and calculating intermediate results. It requires no examples or demonstrations and consistently outperforms Zero-Shot CoT ("Let's think step by step") on reasoning tasks.
 
+When the prompt is emitted, the `PROBLEM:` and `SOURCE MATERIAL:` headers are stripped and the instruction reaches the model as a flat block. The plan-and-solve trigger is already a complete sentence, so it survives the stripping intact and needs no carrier sentence; the optional `SOURCE MATERIAL` block names the figures the calculation runs on and ties them to the problem in prose, and is deleted when the problem already states every value.
+
 **Research basis:** "Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models" (Wang et al., ACL 2023, arXiv:2305.04091). Tested across 10 reasoning datasets — consistently outperforms Zero-Shot-CoT and is competitive with few-shot CoT.
 
 ## The Core Trigger Phrases
@@ -29,11 +31,22 @@ The PS+ additions over PS:
 
 ## Template Structure
 
+Section headers — `PROBLEM:` and `SOURCE MATERIAL:` — are stripped at emission, so the
+trigger that follows is written as a complete sentence and survives on its own; it was
+already prose, not a header, which is why PS+ needs no carrier sentence for it. The template
+drops the old `INSTRUCTION:` header for the same reason: a header there would only be
+stripped anyway, so the trigger now sits as bare prose. The `SOURCE MATERIAL` block is
+optional — it names the dataset or table the calculation runs on and is deleted when the
+problem already states every value needed.
+
 ```
 PROBLEM:
-[Your problem or question]
+[Your question, calculation, or reasoning problem]
+
+SOURCE MATERIAL:
+[Optional — paste the source data the problem depends on here (the dataset, table, figures, or constraint list the calculation runs on). Delete this line and the one below it if the problem above already states every value needed.]
+The figures and constraints in the material above are authoritative — extract from them rather than from assumed or recalled values.
 
-INSTRUCTION:
 Let's first understand the problem, extract relevant variables and their
 corresponding numerals, and devise a complete plan. Then, let's carry out
 the plan, calculate intermediate values, pay attention to computation,
@@ -50,12 +63,19 @@ step by step.
 
 ## Complete Examples
 
+Every example below is shown in emitted form. The plan-and-solve trigger is the same
+complete sentence in each — it is what survives header stripping. Where the calculation runs
+on a pasted dataset or constraint list, the `SOURCE MATERIAL` block carries it and the
+problem refers to "the material above"; where every value is already in the problem
+statement, that block is deleted.
+
 ### Example 1: Math / Calculation
 
 **Before PS+:**
 "If a SaaS company has 500 customers at $200/month each, 5% monthly churn, and adds 30 new customers per month, what is the MRR in 6 months?"
 
-**After PS+:**
+**After PS+** (no source material — every value is stated in the problem, so the
+`SOURCE MATERIAL` block is deleted):
 ```
 PROBLEM:
 A SaaS company has 500 customers paying $200/month each. Monthly churn
@@ -98,13 +118,16 @@ Final answer: Month 6 MRR = $X
 **Before PS+:**
 "Our API is returning responses in 800ms average. We want to get it under 200ms. What should we do?"
 
-**After PS+:**
+**After PS+** (source material supplied):
 ```
 PROBLEM:
 Our REST API averages 800ms response time. Target is under 200ms.
 The API serves product catalog queries (read-heavy), is Node.js with
-PostgreSQL, and currently has no caching layer. Database queries are
-the main bottleneck (600ms average per request).
+PostgreSQL, and currently has no caching layer.
+
+SOURCE MATERIAL:
+[Paste the endpoint's profiling output and the current server and database configuration here]
+The figures and constraints in the material above are authoritative — extract from them rather than from assumed or recalled values.
 
 Let's first understand the problem, extract relevant variables and their
 corresponding numerals, and devise a complete plan. Then, let's carry out
@@ -116,7 +139,8 @@ the plan and solve step by step.
 **Before PS+:**
 "What's our payback period if CAC is $1,200 and average MRR per customer is $150 with 70% gross margin?"
 
-**After PS+:**
+**After PS+** (no source material — every value is stated in the problem, so the
+`SOURCE MATERIAL` block is deleted):
 ```
 PROBLEM:
 Customer Acquisition Cost (CAC): $1,200
@@ -136,10 +160,15 @@ and solve the problem step by step.
 **Before PS+:**
 "Given these constraints [complex scheduling problem], is there a valid schedule?"
 
-**After PS+:**
+**After PS+** (source material supplied):
 ```
 PROBLEM:
-[Complex scheduling problem with constraints]
+Determine whether a valid schedule exists that satisfies every constraint,
+or prove that none does.
+
+SOURCE MATERIAL:
+[Paste the full list of scheduling constraints — resources, time windows, and dependencies — here]
+The figures and constraints in the material above are authoritative — extract from them rather than from assumed or recalled values.
 
 Let's first understand the problem, extract all constraints and their
 relationships, and devise a complete plan for finding a valid schedule