@ckelsoe/prompt-architect 3.3.1 → 3.4.0

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

@@ -19,76 +19,133 @@ Reverse Prompt Engineering (RPEF) inverts the normal prompt-to-output direction.
 ### Input Sample (optional but powerful)
 **Purpose:** If the output was generated from specific input data, include it. The model uses the relationship between input and output to infer transformation rules and prompt logic.
 
+**Template slot:** `SOURCE MATERIAL — ORIGINAL INPUT`. It is the only optional block in the template, and it is deleted together with the sentence directly beneath it when the recovery is output-only.
+
 ### Output Sample (required)
 **Purpose:** The existing output you want to reverse-engineer. This is the primary source of truth — what you want to be able to reproduce.
 
+**Template slot:** `SOURCE MATERIAL — OUTPUT SAMPLE`. Paste it verbatim; paraphrasing the sample destroys exactly the formatting and phrasing signals the analysis is meant to read.
+
 ### Analysis Instruction
-**Purpose:** Directs the model to analyze the output for its implicit prompt properties: tone, structure, reasoning style, constraints, format, level of detail, persona, and assumptions.
+**Purpose:** Directs the model to analyze the output for its implicit prompt properties, and to *report* that analysis before writing anything else.
+
+**Template slot:** `ANALYSIS INSTRUCTIONS`, which names six dimensions: implied role or persona, tone and voice, structural and formatting patterns, level of detail and scope, implicit constraints (what it did NOT do), and reasoning style. Structure and format are one merged dimension, not two. An earlier revision of *this document* listed seven by splitting them apart; that was drift in the doc's copy, not a change to the template, which has carried the merged dimension unchanged since it was introduced.
+
+### Confidence Threshold
+**Purpose:** Stops the model from presenting a guess as a recovered prompt when one sample is too thin to support one.
 
-### Confidence Threshold (optional)
-**Purpose:** Instructs the model to only generate the recovered prompt when confident enough. Default: 80-90%.
+**Template slot:** the closing sentences of `RECOVERED PROMPT`. The threshold is only useful when it is paired with a defined alternative action — see the note under Template Structure on why the earlier "only proceed when 80% confident" phrasing did nothing.
 
 ### Generalization Directive
 **Purpose:** Specifies whether the recovered prompt should be a specific single-use template or a generalized meta-prompt with fill-in placeholders.
 
+**Template slot:** folded into `RECOVERED PROMPT` as the `[PLACEHOLDER]` instruction — the template always asks for the generalized form, and marks variability at the token level rather than asking a separate yes/no question about it.
+
 ## Template Structure
 
+Section headers are stripped at emission, so every slot's meaning is carried by the
+unbracketed prose around it rather than by the header above it. This template also depends
+on sequencing — the analysis must be reported *before* the recovered prompt is written —
+and that sequencing lives in the prose ("First, examine…", "After completing that
+analysis…"), not in the order the headers happen to appear. Do not reintroduce
+header-only structure.
+
 ```
 You are an expert Prompt Engineer performing reverse prompt engineering.
 
 TASK:
-Analyze the following [input and] output. Reconstruct the prompt that would
-consistently produce this type of output. Your recovered prompt should be
-reusable — replace specific details with clearly marked [PLACEHOLDER] variables.
+Analyze the sample material below and reconstruct the prompt that would
+consistently produce this type of output.
 
-[INPUT DATA (if applicable):]
-[Paste input here, or omit if output-only]
+SOURCE MATERIAL — ORIGINAL INPUT:
+[Optional — paste here, verbatim, the input that originally produced the output
+sample below. If you have nothing to paste, delete this bracketed block along with
+the sentence directly below it.]
+Use the material above as the input that produced the output sample below.
 
-OUTPUT SAMPLE:
-[Paste the output you want to reverse-engineer]
+SOURCE MATERIAL — OUTPUT SAMPLE:
+[Paste here, verbatim, the output you want to reverse-engineer.]
+Use the material above as the finished output to reverse-engineer.
 
 ANALYSIS INSTRUCTIONS:
-Examine the output for:
-- Implied role or persona (who generated this?)
-- Tone and voice (formal, casual, technical, etc.)
-- Structural patterns (how is it organized?)
+First, examine the output above and report what you find for each of these dimensions:
+- Implied role or persona
+- Tone and voice
+- Structural and formatting patterns
 - Level of detail and scope
-- Any implicit constraints (what did it not do?)
-- Format conventions (length, sections, bullet style, etc.)
-- Reasoning style (step-by-step, direct, narrative?)
+- Implicit constraints (what it did NOT do)
+- Reasoning style
 
 RECOVERED PROMPT:
-Generate a reusable prompt template that would reliably reproduce this
-type of output. Use [PLACEHOLDER] notation for variable elements.
-Only proceed when at least 80% confident in the reconstruction.
+After completing that analysis, write out a reusable prompt template that reliably
+reproduces this type of output. Mark every variable element with the literal token
+[PLACEHOLDER], written exactly that way rather than replaced with a specific value.
+If you are less than 80% confident in the reconstruction, do not guess: say so, and
+name the additional sample material that would resolve the uncertainty.
 ```
 
+Two sentences in `RECOVERED PROMPT` do work that is easy to lose when editing this
+template, and both replaced phrasings that failed in a specific way:
+
+- **"written exactly that way rather than replaced with a specific value."** The earlier
+  phrasing, "Use [PLACEHOLDER] for variable elements," reads two ways: emit the literal
+  token, or fill each position with a plausible concrete value. The second reading returns
+  a filled-in example rather than the reusable template that is the entire point of the
+  framework, so the instruction is made explicit to close it off. How often the ambiguity
+  actually resolves the wrong way has not been measured here.
+- **"If you are less than 80% confident … say so, and name the additional sample
+  material."** The earlier phrasing, "Only proceed when at least 80% confident," named no
+  alternative action, so it gated nothing: no behavior was defined for the failing branch,
+  leaving nothing in the text to stop the model proceeding anyway. A threshold is only a
+  gate when the below-threshold
+  path is spelled out, and naming the missing material makes that path useful rather than
+  merely a refusal.
+
+Because RPEF's source material is the user's own pasted sample, the two `SOURCE MATERIAL`
+blocks are the framework's legitimate `[...]` placeholders under SKILL.md step 5 — they are
+material only the user can supply, not defaults the model should invent.
+
 ## Complete Examples
 
+Every example below is shown in emitted form: each slot carries its own role in prose, so
+nothing is lost when the headers are deleted. The output samples are filled with real
+material rather than left as paste instructions, because an RPEF prompt with an empty
+sample demonstrates nothing — the sample is the only thing the framework operates on.
+
 ### Example 1: Recovering a Writing Style
 
-**Scenario:** You got a great product description once and want to reproduce that tone.
+**Scenario:** You got a great product description once and want to reproduce that tone. Output-only, so the `ORIGINAL INPUT` block and the sentence below it are both deleted.
 
 ```
 You are an expert Prompt Engineer performing reverse prompt engineering.
 
 TASK:
-Analyze the following product description. Reconstruct the prompt that
-would consistently produce this style of writing for other products.
+Analyze the sample material below and reconstruct the prompt that would
+consistently produce this type of output.
 
-OUTPUT SAMPLE:
-"Mira is the meeting companion that thinks ahead. While you're present
-in the conversation, Mira is quietly capturing every decision, action
-item, and insight — then turning them into a clean summary the moment
-you close your laptop. No more frantic note-taking. No more 'wait, what
-did we decide?' Just clarity, automatically."
+SOURCE MATERIAL — OUTPUT SAMPLE:
+"Mira is the meeting companion that thinks ahead. While you're present in the
+conversation, Mira is quietly capturing every decision, action item, and insight
+— then turning them into a clean summary the moment you close your laptop. No
+more frantic note-taking. No more 'wait, what did we decide?' Just clarity,
+automatically."
+Use the material above as the finished output to reverse-engineer.
 
 ANALYSIS INSTRUCTIONS:
-Examine for: implied persona, tone, structure, what it does vs. doesn't
-say, sentence length patterns, opening hook strategy, implicit audience.
+First, examine the output above and report what you find for each of these dimensions:
+- Implied role or persona
+- Tone and voice
+- Structural and formatting patterns
+- Level of detail and scope
+- Implicit constraints (what it did NOT do)
+- Reasoning style
 
 RECOVERED PROMPT:
-Generate a reusable template for writing product descriptions in this style.
+After completing that analysis, write out a reusable prompt template that reliably
+reproduces this type of output. Mark every variable element with the literal token
+[PLACEHOLDER], written exactly that way rather than replaced with a specific value.
+If you are less than 80% confident in the reconstruction, do not guess: say so, and
+name the additional sample material that would resolve the uncertainty.
 ```
 
 **Recovered prompt output:**
@@ -110,48 +167,159 @@ STYLE RULES:
 
 ### Example 2: Recovering an Analysis Format
 
-**Scenario:** A colleague produced a competitive analysis you want to replicate.
+**Scenario:** A colleague produced a competitive analysis you want to replicate. You have both the brief they worked from and the analysis itself, so both `SOURCE MATERIAL` blocks are used.
 
 ```
 You are an expert Prompt Engineer performing reverse prompt engineering.
 
 TASK:
-Analyze the following competitive analysis excerpt. Reconstruct the prompt
-template that produced this format and analytical approach.
+Analyze the sample material below and reconstruct the prompt that would
+consistently produce this type of output.
 
-INPUT DATA:
+SOURCE MATERIAL — ORIGINAL INPUT:
 Companies to compare: Notion vs. Confluence vs. Linear
 Use case: Engineering team wiki and documentation
-
-OUTPUT SAMPLE:
-[Paste the analysis here]
+Audience: VP Engineering, 200-person org
+Use the material above as the input that produced the output sample below.
+
+SOURCE MATERIAL — OUTPUT SAMPLE:
+"**Structure and hierarchy.** Confluence wins outright here. Spaces, page trees,
+and page-level restrictions map cleanly onto how engineering orgs already think
+about ownership. Notion's database-plus-nesting model is more flexible but
+degrades past roughly 500 pages without deliberate curation. Linear's documents
+are deliberately shallow — they attach to projects rather than organizing
+independently — so it is not a wiki candidate at all on this dimension.
+
+**Search.** Confluence's search is the weakest of the three despite being the
+oldest: it indexes attachments well but ranks stale pages highly. Notion's search
+handles partial-title matching acceptably since its 2023 rebuild. Linear's search
+is the fastest and best-scoped, but there is comparatively little to search.
+
+**Permissioning.** Confluence again, and the gap widens with headcount. Notion's
+permissions are workspace- and page-level but become expensive to audit past
+about 100 seats. Linear does not attempt document-level permissioning.
+
+**Recommendation.** For an engineering wiki proper: Confluence above roughly 150
+engineers, where permissioning and hierarchy dominate; Notion below that, where
+flexibility outweighs structure. Linear is complementary rather than a candidate
+— pair it with whichever wiki you choose.
+
+*Caveat: the page-count and seat-count thresholds above come from practitioner
+reports, not vendor benchmarks.*"
+Use the material above as the finished output to reverse-engineer.
 
 ANALYSIS INSTRUCTIONS:
-Identify: comparison dimensions, how trade-offs are framed, what's
-prioritized, how conclusions are drawn, what data is cited vs. inferred.
+First, examine the output above and report what you find for each of these dimensions:
+- Implied role or persona
+- Tone and voice
+- Structural and formatting patterns
+- Level of detail and scope
+- Implicit constraints (what it did NOT do)
+- Reasoning style
 
 RECOVERED PROMPT:
-Template should work for any set of tools in any category.
+After completing that analysis, write out a reusable prompt template that reliably
+reproduces this type of output. Mark every variable element with the literal token
+[PLACEHOLDER], written exactly that way rather than replaced with a specific value.
+If you are less than 80% confident in the reconstruction, do not guess: say so, and
+name the additional sample material that would resolve the uncertainty.
+```
+
+**Recovered prompt output:**
+```
+ROLE: You are a senior technical evaluator who compares tools for engineering
+leadership audiences.
+
+TASK: Compare [TOOL A], [TOOL B], and [TOOL C] for [USE CASE], writing for
+[AUDIENCE AND ORG SIZE].
+
+METHOD:
+- Choose 3-4 dimensions that actually matter for the stated use case. Use the same
+  dimensions for every tool, as bold headings.
+- Under each dimension, name the winner in the first sentence, then justify it.
+- Where a tool is not a genuine candidate on a dimension, say so plainly instead of
+  scoring it — do not manufacture a three-way comparison that isn't there.
+- Close with a recommendation conditional on a named threshold (org size, seat count,
+  volume) rather than a single unqualified pick.
+- Mark any figure sourced from practitioner reports rather than vendor benchmarks
+  with an explicit caveat line at the end.
+
+TONE: Direct and evaluative — verdict first, reasoning second. No feature-matrix
+tables, no vendor marketing language, no hedging on the recommendation.
 ```
 
-### Example 3: Output-Only Recovery
+### Example 3: Output-Only Recovery, Where the Confidence Gate Fires
 
-**Scenario:** You have a great email you wrote with AI assistance but can't find the original prompt.
+**Scenario:** You have an email you're happy with but lost the prompt. One sample is often too thin to generalize from — this example shows what the template's confidence rule is for.
 
 ```
-You are an expert Prompt Engineer.
+You are an expert Prompt Engineer performing reverse prompt engineering.
 
 TASK:
-I have an email I'm happy with but lost the prompt that generated it.
-Reverse-engineer a reusable prompt from the email so I can produce
-similar emails for other clients.
+Analyze the sample material below and reconstruct the prompt that would
+consistently produce this type of output.
+
+SOURCE MATERIAL — OUTPUT SAMPLE:
+"Hi Dana,
+
+Quick update on the Q3 rollout: we're on track for the Sept 15 launch, but I want
+to flag something early rather than at the last minute. The data migration is
+running about 30% longer than we scoped, which eats most of our buffer. That
+doesn't put the date at risk yet — it means we've lost the room to absorb a
+second surprise.
+
+Two options. We hold the date and move the reporting dashboard to a fast-follow
+in early October, or we hold scope and move the launch to Sept 29. I'd recommend
+the first: the dashboard is the piece your team flagged as least useful in month
+one.
+
+Happy to talk it through Thursday if that's easier. Either way you'll have a firm
+recommendation from me by Friday.
 
-OUTPUT SAMPLE:
-[Paste the email]
+Best,
+Ray"
+Use the material above as the finished output to reverse-engineer.
+
+ANALYSIS INSTRUCTIONS:
+First, examine the output above and report what you find for each of these dimensions:
+- Implied role or persona
+- Tone and voice
+- Structural and formatting patterns
+- Level of detail and scope
+- Implicit constraints (what it did NOT do)
+- Reasoning style
 
 RECOVERED PROMPT:
-Create a template with [CLIENT NAME], [SITUATION], and [SPECIFIC REQUEST]
-as placeholder variables. Capture the tone, structure, and approach precisely.
+After completing that analysis, write out a reusable prompt template that reliably
+reproduces this type of output. Mark every variable element with the literal token
+[PLACEHOLDER], written exactly that way rather than replaced with a specific value.
+If you are less than 80% confident in the reconstruction, do not guess: say so, and
+name the additional sample material that would resolve the uncertainty.
+```
+
+**Recovered prompt output** — here the gate fires, which is the correct behavior rather than a failure:
+```
+Confidence in a reusable reconstruction: roughly 60%. That is below the 80% bar you
+set, so I am not going to hand you a template and let it look more reliable than it is.
+
+What the sample supports confidently: the structure is stable and readable — status
+line, early flag, explicit statement of what the impact is and is not, exactly two
+named options, a recommendation justified by the recipient's own stated priority, an
+offer to discuss, and a committed date for the firm answer. The register is candid and
+non-defensive; the bad news arrives in the second sentence rather than buried below a
+paragraph of reassurance.
+
+What one sample cannot settle, and why each matters:
+- Whether "exactly two options" is a rule or an artifact of this situation. A template
+  that hardcodes two will force false binaries where the honest answer is one or three.
+- Whether the recommendation systematically favors protecting the date, or whether that
+  was specific to this trade-off.
+- Whether this register holds for an external client, or only for an internal
+  stakeholder like Dana with whom the writer has standing rapport.
+
+Send two or three more emails you were happy with — ideally one carrying
+straightforwardly good news, and one written to a client rather than a colleague — and
+I can separate the fixed structure from this instance's specifics.
 ```
 
 ## Best Use Cases
@@ -187,9 +355,10 @@ as placeholder variables. Capture the tone, structure, and approach precisely.
 
 ## Quick Reference
 
-| Component | Purpose |
-|-----------|---------|
-| Input Sample | The input data (if any) that produced the output |
-| Output Sample | The output to reverse-engineer (required) |
-| Analysis Instructions | What dimensions to examine |
-| Recovered Prompt | Reusable template with [PLACEHOLDER] variables |
+| Component | Template slot | Purpose |
+|-----------|---------------|---------|
+| Input Sample | `SOURCE MATERIAL — ORIGINAL INPUT` | The input data (if any) that produced the output — optional, deleted with its trailing sentence when unused |
+| Output Sample | `SOURCE MATERIAL — OUTPUT SAMPLE` | The output to reverse-engineer, pasted verbatim (required) |
+| Analysis Instruction | `ANALYSIS INSTRUCTIONS` | The six dimensions to examine, reported before anything else is written |
+| Generalization Directive | `RECOVERED PROMPT` | Reusable template marking variables with the literal token `[PLACEHOLDER]` |
+| Confidence Threshold | `RECOVERED PROMPT` (closing) | Below 80%, say so and name the sample material that would resolve it |

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

@@ -156,7 +156,7 @@ FORMAT: Provide as:
 - ❌ Rich context needed (use CO-STAR)
 - ❌ Audience/tone matters (use CO-STAR)
 - ❌ Specific methodology required (use RISEN)
-- ❌ Input transformation needed (use RISE)
+- ❌ Input transformation needed (use RISE-IE)
 
 ## Common Mistakes
 
@@ -221,7 +221,7 @@ FORMAT: [Follow this structure]
 
 ## When to Upgrade from RTF
 
-**Upgrade to RISE if:**
+**Upgrade to RISE-IE if:**
 - Need to specify input characteristics
 - Processing steps matter
 - Input → output transformation

package/skills/prompt-architect/references/frameworks/self-refine.md

@@ -4,7 +4,9 @@
 
 Self-Refine is an iterative output improvement framework where a single model acts as its own generator, critic, and refiner — with no external training, no additional models, and no labeled data required. The core loop: generate an initial output → produce specific, actionable feedback → refine using that feedback → repeat until a stopping criterion is met.
 
-**Research basis:** "Self-Refine: Iterative Refinement with Self-Feedback" (Madaan et al., arXiv 2303.17651, NeurIPS 2023). Tested across 7 task types — improvement of 5-40% over single-pass generation from GPT-3.5 and GPT-4. Humans preferred Self-Refined outputs in blind evaluation. Project site: selfrefine.info.
+**Research basis:** "Self-Refine: Iterative Refinement with Self-Feedback" (Madaan et al., arXiv 2303.17651, NeurIPS 2023). Evaluated across 7 diverse tasks using GPT-3.5, ChatGPT, and GPT-4. The abstract reports that Self-Refine outputs are "preferred by humans and automatic metrics over those generated with the same LLM using conventional one-step generation, improving by ~20% absolute on average in task performance." That ~20% is an *average across the 7 tasks* — per-task gains vary substantially, and the abstract gives no range. Project site: selfrefine.info.
+
+*Correction:* an earlier version of this file reported "improvement of 5-40% over single-pass generation from GPT-3.5 and GPT-4." Neither bound appears in the paper, and ChatGPT was omitted from the model list. Verified against the arXiv abstract.
 
 ## The Core Loop
 
@@ -190,7 +192,7 @@ biggest single point of failure identified.
 
 | | Self-Refine | CAI Critique-Revise | BAB | Chain of Density |
 |---|---|---|---|---|
-| Direction | Any output → improvement | Output vs. explicit principle | Before state → after state | Content → denser compression |
+| Direction | Any output → improvement | Output vs. explicit principle | Before state → after state | Same length → higher entity density |
 | Critique type | Multi-dimensional quality | Principle-aligned alignment | Transformation rules | Density/information |
 | Iterations | Configurable loop | One cycle (or more) | Single transform | N passes |
 | Best for | General quality improvement | Alignment/compliance | Rewriting existing content | Summarization |

package/skills/prompt-architect/references/frameworks/skeleton-of-thought.md

@@ -34,22 +34,48 @@ Point X: [point name] — [one-line description]
 
 ## 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.
+
 ```
-PHASE 1 — SKELETON:
-Generate a skeleton outline for the following question. List only key points,
-one per line, in the format: [number]. [Point name] | [One-sentence description].
-Do not expand yet.
+SOURCE MATERIAL:
+[Optional — paste the document, data, or notes the answer must be drawn from 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.
 
-QUESTION/TOPIC:
-[Your question or topic]
+Answer the topic or question below in two phases: first a skeleton outline, then a full
+expansion of every point in that skeleton.
 
-PHASE 2 — EXPAND:
-Now expand each point into [2-4 sentences / a paragraph / detailed explanation].
-Each point should be self-contained and complete.
+TOPIC / QUESTION:
+[Write out the full topic or question as a complete, self-contained sentence rather than a
+bare noun phrase, including any audience, scope, or depth of coverage specified]
 
-[Optional: expand points in parallel by sending each as a separate request]
+PHASE 1 — SKELETON:
+First, outline the topic above. List only the key points, one per line, in this format:
+N. [Point name] | [One-sentence description of what this point covers]
+Replace N with the point's number and fill in both bracketed parts, keeping that line's
+format exactly. Produce the skeleton and nothing else — do not expand any point yet.
+
+PHASE 2 — EXPAND:
+Once the skeleton is complete, expand each of its points into [2-4 sentences / a paragraph /
+detailed coverage]. Restate a point's name before expanding it, and make each expansion
+self-contained.
 ```
 
+The two-phase framing sentence sits before `TOPIC / QUESTION` so that both phases are
+announced before the topic appears; the topic in turn sits before both phases so that
+Phase 1's "the topic above" resolves once the headers are gone.
+
+**Parallel expansion is not part of the emitted prompt.** The template runs both phases in
+a single self-contained prompt. Splitting Phase 2 into one request per skeleton point — the
+source of the paper's latency gain — is a workflow the sender builds around the model, not
+an instruction the model can act on. A line such as "[Optional: expand points in parallel by
+sending each as a separate request]" addresses the human holding the prompt, and a
+header-stripped prompt has nowhere to put a note to the sender: the model would read it as
+an instruction it cannot execute. If that note is ever added for the sender's benefit, it
+must be deleted before the prompt is sent.
+
 ### Minimal Single-Pass SoT
 For use in a single prompt when parallel API calls aren't available:
 ```
@@ -67,14 +93,23 @@ Present as: Skeleton → then Full Expansion.
 
 **After SoT:**
 ```
+Answer the topic or question below in two phases: first a skeleton outline, then a full
+expansion of every point in that skeleton.
+
+TOPIC / QUESTION:
+Explain microservices architecture to a senior engineer who is evaluating whether to
+migrate an existing monolith, covering the trade-offs that bear on that decision.
+
 PHASE 1 — SKELETON:
-Create a skeleton outline for explaining microservices architecture to a
-senior engineer evaluating whether to migrate from a monolith. List 5-7 key
-points in format: N. [name] | [one-sentence description]. Do not expand.
+First, outline the topic above. List 5-7 key points, one per line, in this format:
+N. [Point name] | [One-sentence description of what this point covers]
+Replace N with the point's number and fill in both bracketed parts, keeping that line's
+format exactly. Produce the skeleton and nothing else — do not expand any point yet.
 
 PHASE 2 — EXPAND:
-Expand each skeleton point into 2-3 paragraphs. Each section should be
-self-contained. Include specific trade-offs relevant to a migration decision.
+Once the skeleton is complete, expand each of its points into 2-3 paragraphs. Restate a
+point's name before expanding it, and make each expansion self-contained. Include the
+specific trade-offs that bear on a migration decision.
 ```
 
 **Skeleton output (Phase 1):**
@@ -104,15 +139,26 @@ risk of scope creep, integration failures, and a multi-month feature freeze...
 
 **After SoT:**
 ```
+Answer the topic or question below in two phases: first a skeleton outline, then a full
+expansion of every point in that skeleton.
+
+TOPIC / QUESTION:
+Write a competitive analysis comparing our product against [you fill this in: name of the
+first competitor] and [you fill this in: name of the second competitor], for an internal
+audience deciding where to invest next.
+
 PHASE 1 — SKELETON:
-Create a skeleton for a competitive analysis covering our product vs. [Competitor A]
-and [Competitor B]. List 6-8 comparison dimensions in format:
-N. [dimension] | [what to compare]. Do not write the analysis yet.
+First, outline the topic above. List 6-8 comparison dimensions, one per line, in this
+format:
+N. [Dimension name] | [One-sentence description of what to compare on that dimension]
+Replace N with the dimension's number and fill in both bracketed parts, keeping that line's
+format exactly. Produce the skeleton and nothing else — do not write the analysis yet.
 
 PHASE 2 — EXPAND:
-For each dimension, write 1 paragraph analyzing how our product compares on that
-dimension. Include specific, concrete observations. Flag any dimension where we
-have a clear advantage or significant gap.
+Once the skeleton is complete, expand each dimension into one paragraph analyzing how our
+product compares on it. Restate the dimension's name before expanding it, and make each
+expansion self-contained. Use specific, concrete observations, and flag any dimension where
+we have a clear advantage or a significant gap.
 ```
 
 ### Example 3: Learning Content