@ckelsoe/prompt-architect 3.2.2 → 3.3.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude-plugin/marketplace.json +3 -3
- package/.claude-plugin/plugin.json +2 -2
- package/CHANGELOG.md +116 -5
- package/MIGRATION.md +1 -1
- package/README.md +32 -47
- package/adapters/README.md +1 -1
- package/adapters/system-prompt.md +41 -11
- package/package.json +5 -4
- package/scripts/install.js +52 -22
- package/scripts/test.js +62 -40
- package/scripts/validate-skill.js +184 -56
- package/skills/prompt-architect/SKILL.md +49 -47
- package/skills/prompt-architect/assets/templates/chain-of-density_template.txt +60 -30
- package/skills/prompt-architect/assets/templates/iterative-compression_template.txt +59 -0
- package/skills/prompt-architect/references/frameworks/ape.md +2 -0
- package/skills/prompt-architect/references/frameworks/bab.md +2 -0
- package/skills/prompt-architect/references/frameworks/cai-critique-revise.md +1 -1
- package/skills/prompt-architect/references/frameworks/chain-of-density.md +95 -423
- package/skills/prompt-architect/references/frameworks/chain-of-thought.md +17 -12
- package/skills/prompt-architect/references/frameworks/co-star.md +2 -0
- package/skills/prompt-architect/references/frameworks/ctf.md +3 -1
- package/skills/prompt-architect/references/frameworks/iterative-compression.md +481 -0
- package/skills/prompt-architect/references/frameworks/pre-mortem.md +6 -6
- package/skills/prompt-architect/references/frameworks/race.md +2 -0
- package/skills/prompt-architect/references/frameworks/react.md +1 -1
- package/skills/prompt-architect/references/frameworks/reverse-role.md +1 -1
- package/skills/prompt-architect/references/frameworks/rise.md +27 -8
- package/skills/prompt-architect/references/frameworks/risen.md +2 -0
- package/skills/prompt-architect/references/frameworks/rtf.md +2 -0
- package/skills/prompt-architect/references/frameworks/skeleton-of-thought.md +1 -1
- package/skills/prompt-architect/references/frameworks/step-back.md +1 -1
- package/skills/prompt-architect/references/frameworks/tidd-ec.md +19 -6
- package/skills/prompt-architect/scripts/framework_analyzer.py +0 -807
- package/skills/prompt-architect/scripts/prompt_evaluator.py +0 -336
|
@@ -0,0 +1,481 @@
|
|
|
1
|
+
# Iterative Compression Framework
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
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.
|
|
6
|
+
|
|
7
|
+
**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`.
|
|
8
|
+
|
|
9
|
+
## Core Concept
|
|
10
|
+
|
|
11
|
+
Instead of requesting the perfect output immediately, Iterative Compression:
|
|
12
|
+
1. Starts with a basic/verbose version
|
|
13
|
+
2. Iteratively refines through multiple passes
|
|
14
|
+
3. Increases information density each time
|
|
15
|
+
4. Removes fluff and redundancy
|
|
16
|
+
5. Enhances clarity and precision
|
|
17
|
+
6. Converges on optimal output
|
|
18
|
+
|
|
19
|
+
Think of it as "progressive enhancement" for prompts.
|
|
20
|
+
|
|
21
|
+
## When to Use Iterative Compression
|
|
22
|
+
|
|
23
|
+
**Ideal for:**
|
|
24
|
+
- Summarization tasks
|
|
25
|
+
- Content compression
|
|
26
|
+
- Iterative improvement of writing
|
|
27
|
+
- Optimizing explanations
|
|
28
|
+
- Refining complex outputs
|
|
29
|
+
- Tasks where quality improves with iteration
|
|
30
|
+
|
|
31
|
+
**Not needed for:**
|
|
32
|
+
- Simple one-shot tasks
|
|
33
|
+
- When first draft is sufficient
|
|
34
|
+
- Time-critical quick tasks
|
|
35
|
+
- Tasks with fixed formats that can't improve
|
|
36
|
+
|
|
37
|
+
## Implementation Approaches
|
|
38
|
+
|
|
39
|
+
### Approach 1: Explicit Multi-Pass
|
|
40
|
+
Request multiple iterations upfront.
|
|
41
|
+
|
|
42
|
+
**Example:**
|
|
43
|
+
```
|
|
44
|
+
Create a summary of this article using Iterative Compression:
|
|
45
|
+
|
|
46
|
+
ITERATION 1:
|
|
47
|
+
Write a verbose summary hitting all main points (150-200 words)
|
|
48
|
+
|
|
49
|
+
ITERATION 2:
|
|
50
|
+
Refine the summary: increase information density, remove redundancy, keep it under 150 words
|
|
51
|
+
|
|
52
|
+
ITERATION 3:
|
|
53
|
+
Further refine: make every word count, increase precision, keep it under 120 words
|
|
54
|
+
|
|
55
|
+
ITERATION 4:
|
|
56
|
+
Final pass: maximize information density while maintaining clarity (100 words max)
|
|
57
|
+
|
|
58
|
+
ITERATION 5:
|
|
59
|
+
Ultimate compression: distill to absolute essentials (50 words max)
|
|
60
|
+
|
|
61
|
+
After all iterations, explain what improved in each pass.
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
### Approach 2: Recursive Refinement
|
|
65
|
+
Use output from one iteration as input to the next.
|
|
66
|
+
|
|
67
|
+
**Example:**
|
|
68
|
+
```
|
|
69
|
+
PASS 1: Write a first draft explanation of quantum entanglement for a general audience.
|
|
70
|
+
|
|
71
|
+
PASS 2: Review your explanation. What's unclear? What's redundant? Rewrite it, addressing these issues.
|
|
72
|
+
|
|
73
|
+
PASS 3: Review again. Where can you be more precise? Where can you use better examples? Rewrite.
|
|
74
|
+
|
|
75
|
+
PASS 4: Final review. Every sentence should earn its place. Remove or improve anything that doesn't. Final version.
|
|
76
|
+
|
|
77
|
+
Show all passes so we can see the evolution.
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
### Approach 3: Targeted Improvement
|
|
81
|
+
Focus each iteration on specific aspect.
|
|
82
|
+
|
|
83
|
+
**Example:**
|
|
84
|
+
```
|
|
85
|
+
Write a product description, then improve it iteratively:
|
|
86
|
+
|
|
87
|
+
DRAFT:
|
|
88
|
+
[Initial version]
|
|
89
|
+
|
|
90
|
+
ITERATION 1 - CLARITY:
|
|
91
|
+
Rewrite focusing on making it clearer and easier to understand.
|
|
92
|
+
|
|
93
|
+
ITERATION 2 - IMPACT:
|
|
94
|
+
Rewrite focusing on making it more compelling and persuasive.
|
|
95
|
+
|
|
96
|
+
ITERATION 3 - CONCISION:
|
|
97
|
+
Rewrite focusing on removing every unnecessary word.
|
|
98
|
+
|
|
99
|
+
ITERATION 4 - PRECISION:
|
|
100
|
+
Rewrite focusing on being more specific and accurate.
|
|
101
|
+
|
|
102
|
+
FINAL:
|
|
103
|
+
Combine the best elements from all iterations.
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
### Approach 4: Constraint-Based Refinement
|
|
107
|
+
Add tighter constraints with each iteration.
|
|
108
|
+
|
|
109
|
+
**Example:**
|
|
110
|
+
```
|
|
111
|
+
Explain this technical concept through progressive refinement:
|
|
112
|
+
|
|
113
|
+
VERSION 1: Explain in 500 words or less
|
|
114
|
+
VERSION 2: Reduce to 300 words without losing key information
|
|
115
|
+
VERSION 3: Reduce to 150 words, keeping only essentials
|
|
116
|
+
VERSION 4: Create a 50-word version capturing the core idea
|
|
117
|
+
VERSION 5: One sentence (25 words max)
|
|
118
|
+
|
|
119
|
+
Each version should be complete and self-contained.
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
## Best Practices
|
|
123
|
+
|
|
124
|
+
### 1. Define What to Optimize
|
|
125
|
+
```
|
|
126
|
+
Good:
|
|
127
|
+
"Iterate to improve:
|
|
128
|
+
- Information density
|
|
129
|
+
- Clarity
|
|
130
|
+
- Conciseness
|
|
131
|
+
- Precision"
|
|
132
|
+
|
|
133
|
+
Poor:
|
|
134
|
+
"Make it better"
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
### 2. Specify Number of Iterations
|
|
138
|
+
```
|
|
139
|
+
Good:
|
|
140
|
+
"Refine through 4 iterations, showing each version"
|
|
141
|
+
|
|
142
|
+
Poor:
|
|
143
|
+
"Keep improving until it's good"
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
### 3. Show Evolution
|
|
147
|
+
```
|
|
148
|
+
Good:
|
|
149
|
+
"Show each iteration and explain what changed and why"
|
|
150
|
+
|
|
151
|
+
Poor:
|
|
152
|
+
"Just give me the final version"
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
### 4. Set Clear Constraints
|
|
156
|
+
```
|
|
157
|
+
Good:
|
|
158
|
+
"Each iteration should be 20% shorter while maintaining completeness"
|
|
159
|
+
|
|
160
|
+
Poor:
|
|
161
|
+
"Make it shorter"
|
|
162
|
+
```
|
|
163
|
+
|
|
164
|
+
## Complete Examples
|
|
165
|
+
|
|
166
|
+
### Example 1: Summarization
|
|
167
|
+
|
|
168
|
+
**Without Iterative Compression:**
|
|
169
|
+
```
|
|
170
|
+
Summarize this research paper.
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
**With Iterative Compression:**
|
|
174
|
+
```
|
|
175
|
+
Summarize this research paper using Iterative Compression:
|
|
176
|
+
|
|
177
|
+
[Paper content]
|
|
178
|
+
|
|
179
|
+
ITERATION 1 (200 words):
|
|
180
|
+
Create a comprehensive summary covering all major points. Prioritize completeness over brevity.
|
|
181
|
+
|
|
182
|
+
ITERATION 2 (150 words):
|
|
183
|
+
Refine the summary:
|
|
184
|
+
- Remove redundant information
|
|
185
|
+
- Combine related points
|
|
186
|
+
- Increase information density
|
|
187
|
+
|
|
188
|
+
ITERATION 3 (100 words):
|
|
189
|
+
Further compression:
|
|
190
|
+
- Keep only essential information
|
|
191
|
+
- Make every sentence count
|
|
192
|
+
- Maintain accuracy
|
|
193
|
+
|
|
194
|
+
ITERATION 4 (75 words):
|
|
195
|
+
Maximum density:
|
|
196
|
+
- Distill to core findings
|
|
197
|
+
- Remove all fluff
|
|
198
|
+
- Preserve critical details
|
|
199
|
+
|
|
200
|
+
For each iteration, highlight what you removed and why.
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
### Example 2: Code Documentation
|
|
204
|
+
|
|
205
|
+
**Without Iterative Compression:**
|
|
206
|
+
```
|
|
207
|
+
Document this function.
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
**With Iterative Compression:**
|
|
211
|
+
```
|
|
212
|
+
Document this function through iterative refinement:
|
|
213
|
+
|
|
214
|
+
[Code]
|
|
215
|
+
|
|
216
|
+
DRAFT DOCUMENTATION:
|
|
217
|
+
Write complete documentation with examples, edge cases, everything.
|
|
218
|
+
|
|
219
|
+
ITERATION 1 - CLARITY:
|
|
220
|
+
Review and rewrite confusing sections. Add examples where helpful.
|
|
221
|
+
|
|
222
|
+
ITERATION 2 - CONCISION:
|
|
223
|
+
Remove redundancy. Combine related points. Make it tighter.
|
|
224
|
+
|
|
225
|
+
ITERATION 3 - PRECISION:
|
|
226
|
+
Be more specific about types, behaviors, edge cases.
|
|
227
|
+
|
|
228
|
+
ITERATION 4 - USABILITY:
|
|
229
|
+
Optimize for developer experience. What do they need to know most?
|
|
230
|
+
|
|
231
|
+
Show each version and explain key changes.
|
|
232
|
+
```
|
|
233
|
+
|
|
234
|
+
### Example 3: Email Refinement
|
|
235
|
+
|
|
236
|
+
**Without Iterative Compression:**
|
|
237
|
+
```
|
|
238
|
+
Write an email announcing this feature.
|
|
239
|
+
```
|
|
240
|
+
|
|
241
|
+
**With Iterative Compression:**
|
|
242
|
+
```
|
|
243
|
+
Draft an announcement email, then refine it:
|
|
244
|
+
|
|
245
|
+
DRAFT:
|
|
246
|
+
Write a first draft covering all important information.
|
|
247
|
+
|
|
248
|
+
ITERATION 1 - STRUCTURE:
|
|
249
|
+
Reorganize for better flow. Most important information first.
|
|
250
|
+
|
|
251
|
+
ITERATION 2 - CLARITY:
|
|
252
|
+
Simplify language. Remove jargon. Make it scannable.
|
|
253
|
+
|
|
254
|
+
ITERATION 3 - ENGAGEMENT:
|
|
255
|
+
Strengthen the call-to-action. Make it more compelling.
|
|
256
|
+
|
|
257
|
+
ITERATION 4 - POLISH:
|
|
258
|
+
Final edits for tone, concision, impact.
|
|
259
|
+
|
|
260
|
+
Show the evolution and explain major changes.
|
|
261
|
+
```
|
|
262
|
+
|
|
263
|
+
### Example 4: Technical Explanation
|
|
264
|
+
|
|
265
|
+
**Without Iterative Compression:**
|
|
266
|
+
```
|
|
267
|
+
Explain how this algorithm works.
|
|
268
|
+
```
|
|
269
|
+
|
|
270
|
+
**With Iterative Compression:**
|
|
271
|
+
```
|
|
272
|
+
Explain this algorithm through progressive refinement:
|
|
273
|
+
|
|
274
|
+
PASS 1 - COMPREHENSIVE:
|
|
275
|
+
Explain thoroughly, assuming no prior knowledge. Include:
|
|
276
|
+
- What it does
|
|
277
|
+
- How it works
|
|
278
|
+
- Why it's designed this way
|
|
279
|
+
- Example walkthrough
|
|
280
|
+
|
|
281
|
+
PASS 2 - REFINED:
|
|
282
|
+
Review Pass 1. What's unclear? What's redundant? Rewrite addressing these.
|
|
283
|
+
|
|
284
|
+
PASS 3 - OPTIMIZED:
|
|
285
|
+
Make it maximally clear and concise. Every paragraph must earn its place.
|
|
286
|
+
|
|
287
|
+
PASS 4 - POLISHED:
|
|
288
|
+
Final pass. Perfect clarity, zero fluff, optimal examples.
|
|
289
|
+
|
|
290
|
+
Show all passes and note significant improvements.
|
|
291
|
+
```
|
|
292
|
+
|
|
293
|
+
## Combining Iterative Compression with Other Frameworks
|
|
294
|
+
|
|
295
|
+
### Iterative Compression + CO-STAR
|
|
296
|
+
```
|
|
297
|
+
CONTEXT: [Background]
|
|
298
|
+
OBJECTIVE: [Goal]
|
|
299
|
+
STYLE: [Writing style]
|
|
300
|
+
TONE: [Tone]
|
|
301
|
+
AUDIENCE: [Readers]
|
|
302
|
+
|
|
303
|
+
RESPONSE PROCESS (Iterative Compression):
|
|
304
|
+
Draft 1: [Comprehensive version]
|
|
305
|
+
Draft 2: [Refined for clarity]
|
|
306
|
+
Draft 3: [Optimized for audience]
|
|
307
|
+
Draft 4: [Final polished version]
|
|
308
|
+
```
|
|
309
|
+
|
|
310
|
+
### Iterative Compression + RISEN
|
|
311
|
+
```
|
|
312
|
+
ROLE: [Expertise]
|
|
313
|
+
INSTRUCTIONS: Use iterative refinement
|
|
314
|
+
STEPS:
|
|
315
|
+
1. Create initial version
|
|
316
|
+
2. Review and identify weaknesses
|
|
317
|
+
3. Refine addressing weaknesses
|
|
318
|
+
4. Repeat until optimal
|
|
319
|
+
END GOAL: [Final quality criteria]
|
|
320
|
+
NARROWING: [Constraints on iterations]
|
|
321
|
+
```
|
|
322
|
+
|
|
323
|
+
### Iterative Compression + Chain of Thought
|
|
324
|
+
```
|
|
325
|
+
For each iteration of Iterative Compression, use Chain of Thought:
|
|
326
|
+
|
|
327
|
+
ITERATION 1:
|
|
328
|
+
Think through: What should this initial version include?
|
|
329
|
+
[Create version]
|
|
330
|
+
|
|
331
|
+
ITERATION 2:
|
|
332
|
+
Think through: What weaknesses exist? How to address them?
|
|
333
|
+
[Refine version]
|
|
334
|
+
|
|
335
|
+
ITERATION 3:
|
|
336
|
+
Think through: What can be compressed or improved?
|
|
337
|
+
[Further refine]
|
|
338
|
+
```
|
|
339
|
+
|
|
340
|
+
## Advanced Techniques
|
|
341
|
+
|
|
342
|
+
### Aspect-Focused Iteration
|
|
343
|
+
Each iteration improves a different dimension:
|
|
344
|
+
|
|
345
|
+
```
|
|
346
|
+
ITERATION 1 - ACCURACY: Get the facts right
|
|
347
|
+
ITERATION 2 - CLARITY: Make it understandable
|
|
348
|
+
ITERATION 3 - CONCISION: Remove waste
|
|
349
|
+
ITERATION 4 - IMPACT: Make it compelling
|
|
350
|
+
ITERATION 5 - STYLE: Polish the voice
|
|
351
|
+
```
|
|
352
|
+
|
|
353
|
+
### A/B Iteration Branches
|
|
354
|
+
Create alternative versions and merge best parts:
|
|
355
|
+
|
|
356
|
+
```
|
|
357
|
+
DRAFT: [Initial version]
|
|
358
|
+
|
|
359
|
+
BRANCH A - CONCISION:
|
|
360
|
+
[Optimize for brevity]
|
|
361
|
+
|
|
362
|
+
BRANCH B - COMPLETENESS:
|
|
363
|
+
[Optimize for thoroughness]
|
|
364
|
+
|
|
365
|
+
MERGE:
|
|
366
|
+
Combine the best elements of both branches.
|
|
367
|
+
```
|
|
368
|
+
|
|
369
|
+
### Constrained Progressive Compression
|
|
370
|
+
```
|
|
371
|
+
VERSION 1: 1000 words - Complete explanation
|
|
372
|
+
VERSION 2: 500 words - 50% compression
|
|
373
|
+
VERSION 3: 250 words - 75% compression
|
|
374
|
+
VERSION 4: 100 words - 90% compression
|
|
375
|
+
VERSION 5: 25 words - 97.5% compression
|
|
376
|
+
|
|
377
|
+
Each version must be self-contained and accurate.
|
|
378
|
+
```
|
|
379
|
+
|
|
380
|
+
### Quality Metric Iteration
|
|
381
|
+
```
|
|
382
|
+
ITERATION 1:
|
|
383
|
+
[Create initial version]
|
|
384
|
+
Self-assess (1-10): Clarity ___ Concision ___ Accuracy ___ Impact ___
|
|
385
|
+
|
|
386
|
+
ITERATION 2:
|
|
387
|
+
[Improve lowest scoring dimension]
|
|
388
|
+
Self-assess: Clarity ___ Concision ___ Accuracy ___ Impact ___
|
|
389
|
+
|
|
390
|
+
ITERATION 3:
|
|
391
|
+
[Improve next lowest dimension]
|
|
392
|
+
Self-assess: Clarity ___ Concision ___ Accuracy ___ Impact ___
|
|
393
|
+
|
|
394
|
+
Continue until all metrics > 8
|
|
395
|
+
```
|
|
396
|
+
|
|
397
|
+
## Refinement Strategies
|
|
398
|
+
|
|
399
|
+
### What to Remove
|
|
400
|
+
- Redundant information
|
|
401
|
+
- Obvious statements
|
|
402
|
+
- Unnecessary qualifiers ("very", "really")
|
|
403
|
+
- Passive voice (often)
|
|
404
|
+
- Filler words
|
|
405
|
+
- Overly general statements
|
|
406
|
+
|
|
407
|
+
### What to Add
|
|
408
|
+
- Specific examples
|
|
409
|
+
- Precise numbers
|
|
410
|
+
- Concrete details
|
|
411
|
+
- Missing context (if essential)
|
|
412
|
+
- Clarifying examples
|
|
413
|
+
|
|
414
|
+
### What to Improve
|
|
415
|
+
- Vague language → specific language
|
|
416
|
+
- Long sentences → shorter, punchier
|
|
417
|
+
- Complex words → simpler alternatives (if clearer)
|
|
418
|
+
- Weak verbs → strong verbs
|
|
419
|
+
- Passive voice → active voice
|
|
420
|
+
|
|
421
|
+
## Quality Indicators
|
|
422
|
+
|
|
423
|
+
**Good Iterative Compression iterations show:**
|
|
424
|
+
- ✅ Measurable improvement each pass
|
|
425
|
+
- ✅ Increased information density
|
|
426
|
+
- ✅ Reduced redundancy
|
|
427
|
+
- ✅ Maintained accuracy
|
|
428
|
+
- ✅ Enhanced clarity
|
|
429
|
+
- ✅ Clear evolution path
|
|
430
|
+
|
|
431
|
+
**Poor Iterative Compression iterations show:**
|
|
432
|
+
- ❌ No meaningful change
|
|
433
|
+
- ❌ Loss of important information
|
|
434
|
+
- ❌ Decreased clarity
|
|
435
|
+
- ❌ Introduced errors
|
|
436
|
+
- ❌ Just made it shorter without improvement
|
|
437
|
+
|
|
438
|
+
## Use Cases
|
|
439
|
+
|
|
440
|
+
### 1. Content Summarization
|
|
441
|
+
Taking long documents and progressively distilling essence
|
|
442
|
+
|
|
443
|
+
### 2. Message Refinement
|
|
444
|
+
Iteratively improving emails, announcements, communications
|
|
445
|
+
|
|
446
|
+
### 3. Documentation Optimization
|
|
447
|
+
Making docs clearer and more concise through iteration
|
|
448
|
+
|
|
449
|
+
### 4. Explanation Enhancement
|
|
450
|
+
Progressively improving how concepts are explained
|
|
451
|
+
|
|
452
|
+
### 5. Writing Polish
|
|
453
|
+
Iterative editing of creative or professional writing
|
|
454
|
+
|
|
455
|
+
### 6. Presentation Optimization
|
|
456
|
+
Refining slides/talks through multiple passes
|
|
457
|
+
|
|
458
|
+
## Assessment Checklist
|
|
459
|
+
|
|
460
|
+
When using Iterative Compression:
|
|
461
|
+
- [ ] Task benefits from iteration
|
|
462
|
+
- [ ] Number of iterations specified
|
|
463
|
+
- [ ] Optimization goals are clear
|
|
464
|
+
- [ ] Each iteration has purpose
|
|
465
|
+
- [ ] Constraints defined for each pass
|
|
466
|
+
- [ ] Evolution is tracked/shown
|
|
467
|
+
- [ ] Quality criteria established
|
|
468
|
+
- [ ] Stopping condition exists
|
|
469
|
+
- [ ] Final version is actually better
|
|
470
|
+
- [ ] Process improved understanding
|
|
471
|
+
|
|
472
|
+
## Tips for Success
|
|
473
|
+
|
|
474
|
+
1. **Start Verbose**: First iteration should be complete, even if wordy
|
|
475
|
+
2. **One Focus Per Iteration**: Don't try to improve everything at once
|
|
476
|
+
3. **Show Your Work**: Display each iteration to see progress
|
|
477
|
+
4. **Set Constraints**: Give specific targets (word counts, focus areas)
|
|
478
|
+
5. **Verify Improvement**: Check that each iteration actually improves quality
|
|
479
|
+
6. **Don't Over-Iterate**: 3-5 iterations usually sufficient
|
|
480
|
+
7. **Preserve Accuracy**: Never sacrifice correctness for brevity
|
|
481
|
+
8. **Explain Changes**: Note what improved and why
|
|
@@ -2,17 +2,17 @@
|
|
|
2
2
|
|
|
3
3
|
## Overview
|
|
4
4
|
|
|
5
|
-
Pre-Mortem Prompting adapts Gary Klein's prospective hindsight technique to AI prompting. Instead of asking "what could go wrong?" (which triggers optimism bias and produces vague risks), it instructs the AI to *assume* the project or decision has already failed catastrophically — then work backwards to identify the specific reasons why.
|
|
5
|
+
Pre-Mortem Prompting adapts Gary Klein's prospective hindsight technique to AI prompting. Instead of asking "what could go wrong?" (which triggers optimism bias and produces vague risks), it instructs the AI to *assume* the project or decision has already failed catastrophically — then work backwards to identify the specific reasons why. In practice this committed-failure frame tends to yield more specific, actionable failure identification than an open-ended "what could go wrong?" question.
|
|
6
6
|
|
|
7
|
-
**Research basis:**
|
|
7
|
+
**Research basis:** Mitchell, Russo & Pennington, "Back to the Future: Temporal Perspective in the Explanation of Events" (*Journal of Behavioral Decision Making*, 1989) found that prospective hindsight — imagining an event has *already occurred* — increases the ability to correctly identify **reasons for future outcomes** by ~30%, compared with imagining it *might* occur. Gary Klein popularized the technique as the "pre-mortem" (*Harvard Business Review*, September 2007), which is where the 30% figure is most often cited from. Note the measured comparison is already-happened vs. might-happen framing, not pre-mortem vs. forward risk analysis. Application to LLM prompting is practitioner-level (no dedicated AI paper), but the cognitive mechanism is well-established.
|
|
8
8
|
|
|
9
|
-
## Why Assumed
|
|
9
|
+
## Why the Assumed-Failure Frame Helps
|
|
10
10
|
|
|
11
|
-
Forward risk: *"What could go wrong?"* →
|
|
11
|
+
Forward risk: *"What could go wrong?"* → Tends to produce vague, hedged answers ("there might be delays", "adoption could be low")
|
|
12
12
|
|
|
13
|
-
Pre-mortem: *"This has already failed — why did it fail?"* →
|
|
13
|
+
Pre-mortem: *"This has already failed — why did it fail?"* → Tends to produce specific, committed answers ("the integration with Salesforce took 3x longer than estimated because we didn't account for their API rate limits")
|
|
14
14
|
|
|
15
|
-
The
|
|
15
|
+
The mechanism: committing to the failure frame bypasses optimism bias and elicits specific causal narratives rather than probabilistic hedges. This is the practitioner rationale for the technique — the 1989 study measured the certainty framing itself, not a head-to-head against forward risk analysis, so treat the comparison above as an observed pattern rather than a measured result.
|
|
16
16
|
|
|
17
17
|
## Components
|
|
18
18
|
|
|
@@ -4,6 +4,8 @@
|
|
|
4
4
|
|
|
5
5
|
RACE (Role, Action, Context, Expectation) is a medium-complexity framework that sits between RTF's simplicity and CO-STAR's richness. It adds two critical improvements over RTF: situational context (missing from RTF) and an explicit expectation of success (missing from both RTF and CTF). RACE is ideal when you need all four pillars — expertise framing, task clarity, background, and a defined success bar — without the full overhead of CO-STAR or RISEN.
|
|
6
6
|
|
|
7
|
+
**Origin:** No single documented originator. RACE is a community prompt-engineering convention documented in practitioner guides (e.g. fvivas.com, 20 April 2025) with no attributed creator, and does not appear in any peer-reviewed prompting survey. **Not to be confused with** the RACE digital-marketing planning model (Reach, Act, Convert, Engage), created by Dave Chaffey of Smart Insights in 2010 — an unrelated marketing framework that shares only the acronym.
|
|
8
|
+
|
|
7
9
|
## Components
|
|
8
10
|
|
|
9
11
|
### R - Role
|
|
@@ -6,7 +6,7 @@ ReAct (Reasoning + Acting) is an agentic prompting framework that interleaves re
|
|
|
6
6
|
|
|
7
7
|
ReAct is the framework of choice when the task requires using tools, querying external sources, writing and executing code, or navigating a multi-step process where each step's result informs the next.
|
|
8
8
|
|
|
9
|
-
**Research basis:** Introduced in "ReAct: Synergizing Reasoning and Acting in Language Models" (Yao et al., 2022).
|
|
9
|
+
**Research basis:** Introduced in "ReAct: Synergizing Reasoning and Acting in Language Models" (Yao et al., arXiv 2210.03629, 2022; ICLR 2023).
|
|
10
10
|
|
|
11
11
|
## Components
|
|
12
12
|
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
Reverse Role Prompting flips the traditional prompting dynamic: instead of you constructing a detailed prompt, you provide a minimal intent statement and the AI interviews you — asking targeted clarifying questions — until it has enough information to execute the task well. This is the framework for when you know what you want but struggle to articulate all the details needed for a good prompt.
|
|
6
6
|
|
|
7
|
-
**Research basis:** Widely circulated as "reverse prompting" in practitioner communities (2023–2024). Formalized academically as **FATA** (First Ask Then Answer), arXiv 2508.08308, August 2025 — showing ~40% improvement over standard prompting. Related to **Socratic Prompting** (Chang
|
|
7
|
+
**Research basis:** Widely circulated as "reverse prompting" in practitioner communities (2023–2024). Formalized academically as **FATA** (First Ask Then Answer), arXiv 2508.08308, August 2025 — showing ~40% improvement over standard prompting. Related to **Socratic Prompting** (Chang, arXiv 2303.08769, IEEE CCWC 2023).
|
|
8
8
|
|
|
9
9
|
## When to Use
|
|
10
10
|
|
|
@@ -2,9 +2,28 @@
|
|
|
2
2
|
|
|
3
3
|
## Overview
|
|
4
4
|
|
|
5
|
-
RISE is a streamlined 4-component framework
|
|
5
|
+
RISE is a streamlined 4-component framework for structuring prompts around a role, the material to work from, a process, and a target output. This skill supports two variants, described below.
|
|
6
6
|
|
|
7
|
-
**
|
|
7
|
+
**Origin:** Community convention with no identifiable originator and no academic basis. The dominant documented expansion is **Role, Input, Steps, Expectation** — Fabio Vivas (fvivas.com); Juuzt.ai; Damien Griffin, "AI Quick Tips 111: Prompt Framework — R.I.S.E." (Thoughts Brewing, 17 December 2024). RISE's first appearance and original author could not be established. Not research-backed. Distinct from **RISEN** (Role, Instructions, Steps, End goal, Narrowing), which is a separate framework.
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## Naming note — read before using this file
|
|
12
|
+
|
|
13
|
+
**"RISE-IE" and "RISE-IX" are this skill's internal shorthand.** They are not established terminology, and no external source uses either term. Do not present them to users as standard vocabulary — say "the Input-Expectation form of RISE" instead.
|
|
14
|
+
|
|
15
|
+
Verified published expansions of RISE:
|
|
16
|
+
|
|
17
|
+
| Expansion | Sources | Status |
|
|
18
|
+
|---|---|---|
|
|
19
|
+
| Role, **Input**, Steps, **Expectation** | fvivas.com; juuzt.ai; thoughtsbrewing.com; promptfoundry.me | **Dominant form** — 4+ independent sources |
|
|
20
|
+
| Role, **Instructions**, Steps, **Expectations** | promptwizz.com | Minority variant |
|
|
21
|
+
| Role, **Instruction**, **Specifics**, **Examples** | aipromptsx.com | Minority variant — note S = Specifics, not Steps |
|
|
22
|
+
| Role, Instructions, Steps, **Examples** | *none found* | **Unverified** — the pattern this file calls "RISE-IX" |
|
|
23
|
+
|
|
24
|
+
**RISE-IX is this skill's own composition, not a documented variant.** It remains a sound prompt pattern — role + directive + method + worked examples is good practice — but it is presented here as our construction, not as an established framework.
|
|
25
|
+
|
|
26
|
+
*Correction:* an earlier version of this file described both variants as "well-documented in authoritative sources." That was incorrect for RISE-IX. Of its three previously-cited sources: AiPromptsX defines S as "Specifics" rather than "Steps"; The Prompt Warrior documents RISEN and contains no RISE framework at all; and Thoughts Brewing documents the Input-Expectation form, making it a RISE-IE source. None supports Role/Instructions/Steps/Examples.
|
|
8
27
|
|
|
9
28
|
---
|
|
10
29
|
|
|
@@ -15,14 +34,14 @@ RISE is a streamlined 4-component framework that exists in **two legitimate vari
|
|
|
15
34
|
|
|
16
35
|
**Best for**: Data analysis, transformations, processing tasks
|
|
17
36
|
|
|
18
|
-
**
|
|
37
|
+
**Provenance**: The documented community form. Sources: Fabio Vivas (fvivas.com); Juuzt.ai; Damien Griffin / Thoughts Brewing (17 December 2024).
|
|
19
38
|
|
|
20
39
|
### RISE-IX: Instructions-Examples (Instruction-Focused)
|
|
21
40
|
**Components**: Role, **Instructions**, Steps, **Examples**
|
|
22
41
|
|
|
23
42
|
**Best for**: Content creation, learning tasks, example-based work
|
|
24
43
|
|
|
25
|
-
**
|
|
44
|
+
**Provenance**: This skill's own composition — no external source documents this exact expansion. The nearest published forms are Role/Instructions/Steps/**Expectations** (promptwizz.com) and Role/Instruction/**Specifics**/Examples (aipromptsx.com). Use as a house pattern; do not cite it as an established framework.
|
|
26
45
|
|
|
27
46
|
---
|
|
28
47
|
|
|
@@ -542,13 +561,13 @@ every wear while treading lightly on the planet..."
|
|
|
542
561
|
|
|
543
562
|
## Summary
|
|
544
563
|
|
|
545
|
-
|
|
564
|
+
This file documents two RISE patterns:
|
|
546
565
|
|
|
547
|
-
**RISE-IE (Input-Expectation)**: Best for data processing, analysis, and transformation tasks where you have specific input to work with.
|
|
566
|
+
**RISE-IE (Input-Expectation)**: The documented community form of RISE. Best for data processing, analysis, and transformation tasks where you have specific input to work with.
|
|
548
567
|
|
|
549
|
-
**RISE-IX (Instructions-Examples)**: Best for content creation, writing, and tasks where examples help clarify desired output style.
|
|
568
|
+
**RISE-IX (Instructions-Examples)**: This skill's own variant, not an externally documented form. Best for content creation, writing, and tasks where examples help clarify desired output style.
|
|
550
569
|
|
|
551
|
-
Both
|
|
570
|
+
Both are practically effective. Only RISE-IE has external documentation — say so if a user asks where these come from. Choose based on whether your task is more analytical/data-focused (IE) or creative/instruction-focused (IX).
|
|
552
571
|
|
|
553
572
|
When in doubt, ask: **"Am I processing data or creating content?"**
|
|
554
573
|
- Processing data → **RISE-IE**
|
|
@@ -4,6 +4,8 @@
|
|
|
4
4
|
|
|
5
5
|
RISEN is a methodology-focused framework that emphasizes process, steps, and boundaries. It's ideal for complex multi-step tasks where following a specific procedure matters, and where defining what NOT to do is as important as what to do.
|
|
6
6
|
|
|
7
|
+
**Origin:** Community framework, attributed to Kyle Balmer (AI educator, @iamkylebalmer). The earliest dated appearance is Moritz Kremb, "5 prompt frameworks to level up your prompts" (The Prompt Warrior, 13 October 2023), which credits Balmer with creating and sharing it; Balmer himself writes only "I call the RISEN framework" and makes no claim of invention. No academic source documents RISEN.
|
|
8
|
+
|
|
7
9
|
## Components
|
|
8
10
|
|
|
9
11
|
### R - Role
|
|
@@ -4,6 +4,8 @@
|
|
|
4
4
|
|
|
5
5
|
RTF is the simplest prompting framework, focusing on Role, Task, and Format. It's ideal for straightforward, well-defined tasks where minimal context is needed and the primary concern is output formatting.
|
|
6
6
|
|
|
7
|
+
**Origin:** No single documented originator. RTF circulated as an unattributed community convention by late 2023 — the earliest dated listing found (Moritz Kremb, The Prompt Warrior, 13 October 2023) presents it without credit while explicitly crediting named authors for other frameworks in the same article. It does not appear in any peer-reviewed prompting survey, including The Prompt Report (arXiv 2406.06608).
|
|
8
|
+
|
|
7
9
|
## Components
|
|
8
10
|
|
|
9
11
|
### R - Role
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
Skeleton of Thought (SoT) is a two-phase framework that first generates a concise structural outline ("skeleton") of the answer, then expands each skeleton point — either sequentially or in parallel — into full content. It improves both output quality (by forcing upfront structure) and can dramatically reduce latency when expansion is done in parallel API calls.
|
|
6
6
|
|
|
7
|
-
**Research basis:** "Skeleton-of-Thought: Prompting LLMs for Efficient Parallel Generation" (Ning et al., Microsoft Research, arXiv:2307.15337, ICLR 2024). Demonstrated 2x+ speedup on 8 of 12 tested models with
|
|
7
|
+
**Research basis:** "Skeleton-of-Thought: Prompting LLMs for Efficient Parallel Generation" (Ning et al., Microsoft Research, arXiv:2307.15337, ICLR 2024). Demonstrated 2x+ speedup (up to 2.39x) on 8 of 12 tested models, with quality parity in roughly 60% of cases; quality degrades on writing, math, and coding tasks.
|
|
8
8
|
|
|
9
9
|
## Components
|
|
10
10
|
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
Step-Back Prompting is a two-step reasoning technique where the model first answers a higher-level "step-back" question that retrieves the underlying principles, concepts, or facts relevant to the original problem — then uses those retrieved principles as context to answer the original question. By abstracting first, the model grounds its reasoning in first principles rather than diving directly into a potentially error-prone specific answer.
|
|
6
6
|
|
|
7
|
-
**Research basis:** "Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models" (Zheng et al., Google DeepMind, arXiv:2310.06117, ICLR 2024). Demonstrated +7
|
|
7
|
+
**Research basis:** "Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models" (Zheng et al., Google DeepMind, arXiv:2310.06117, ICLR 2024). Demonstrated +7% on MMLU Physics, +11% on Chemistry, +27% on TimeQA, and +7% on MuSiQue vs. direct prompting (PaLM-2L).
|
|
8
8
|
|
|
9
9
|
## Components
|
|
10
10
|
|