@ckelsoe/prompt-architect 3.3.1 → 3.5.0

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

package/skills/prompt-architect/references/frameworks/step-back.md

@@ -4,12 +4,14 @@
 
 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.
 
+When the finished prompt is emitted, its section headers — ORIGINAL QUESTION, SOURCE MATERIAL, STEP-BACK, PRINCIPLE APPLICATION — are stripped, and the model receives a flat block of prose. Each slot is therefore written as a complete instruction that still reads correctly once its header is gone: the step-back question ships inside "Before answering directly, first answer this higher-level question," and the final step inside "Using the principles you just described, now answer the original question."
+
 **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).
 
 ## Components
 
 ### Step 1: The Step-Back Question
-**Purpose:** Reformulate the original question into a higher-level, more abstract question that retrieves the underlying principles or concepts needed.
+**Purpose:** Reformulate the original question into a higher-level, more abstract question that retrieves the underlying principles or concepts needed. Because the STEP-BACK header disappears at emission, the abstract question cannot stand as a bare fragment; it ships inside the carrier sentence `Before answering directly, first answer this higher-level question: …`, which keeps it readable as an instruction on its own.
 
 **Pattern:** Strip away specifics → ask for the general principle/rule/concept.
 
@@ -19,26 +21,40 @@ Step-Back Prompting is a two-step reasoning technique where the model first answ
 - Original: "Was the Battle of Stalingrad a turning point?" → Step-back: "What factors define a military turning point in a campaign?"
 
 ### Step 2: Principle Retrieval
-**Purpose:** Answer the step-back question to retrieve the relevant principles/concepts/facts. This becomes the reasoning context.
+**Purpose:** Answer the step-back question to retrieve the relevant principles/concepts/facts. This becomes the reasoning context. This is not a written slot — nothing is typed here at emission. It is the model's response to the step-back question, produced between the abstraction and the final answer, and it becomes the context the final step draws on.
 
 ### Step 3: Final Answer
-**Purpose:** Use the retrieved principles as context to answer the original specific question.
+**Purpose:** Use the retrieved principles as context to answer the original specific question. It ships inside the carrier sentence `Using the principles/concepts you just described, now answer the original question: …`, so the restated question reads as a directive once the PRINCIPLE APPLICATION header is stripped.
 
 **Trigger:** "Based on these principles, now answer the original question: [original question]"
 
 ## Template Structure
 
+Section headers — `ORIGINAL QUESTION:`, `SOURCE MATERIAL:`, `STEP-BACK:`,
+`PRINCIPLE APPLICATION:` — are stripped at emission, so each slot's meaning has to be
+carried by the sentence in and around it rather than by the header above it. The step-back
+question and the final question therefore ship inside carrier sentences, and the
+`SOURCE MATERIAL` block is optional prose that names the artifact and ties it to the
+reasoning below.
+
 ```
 ORIGINAL QUESTION:
 [The specific question you want answered]
 
+SOURCE MATERIAL:
+[Optional — paste the code, document, or system design the question above is about 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 reasoning below — evaluate what is
+actually there, not what is typical or assumed.
+
 STEP-BACK:
 Before answering directly, first answer this higher-level question:
-[Step-back question — the abstract principle/concept behind the original]
+[Rephrase the original into a more abstract question about underlying principles, concepts, or rules]
 
 PRINCIPLE APPLICATION:
 Using the principles/concepts you just described, now answer the original question:
-[Restate original question]
+[Restate original question here]
 ```
 
 ### Auto Step-Back (Model generates its own step-back question):
@@ -52,12 +68,18 @@ Question: [your question]
 
 ## Complete Examples
 
+Every example below is shown in emitted form: each slot reads as a complete instruction,
+so nothing is lost when the section headers are stripped. Where the question is about an
+existing artifact, the `SOURCE MATERIAL` block carries it and the reasoning refers to "the
+X above"; where the task starts from nothing, that block is deleted.
+
 ### Example 1: Technical Decision
 
 **Before Step-Back:**
 "Should I use PostgreSQL or MongoDB for a social feed application?"
 
-**After Step-Back:**
+**After Step-Back** (no source material — the question is self-contained, so the
+`SOURCE MATERIAL` block is deleted):
 ```
 ORIGINAL QUESTION:
 Should I use PostgreSQL or MongoDB for a social feed application?
@@ -79,19 +101,24 @@ feed of posts, and can like/comment?
 **Before Step-Back:**
 "Why does my async function return undefined when I call it?"
 
-**After Step-Back:**
+**After Step-Back** (source material supplied):
 ```
 ORIGINAL QUESTION:
 Why does my async function return undefined when I call it?
 
+SOURCE MATERIAL:
+[Paste the async function and the code that calls it here]
+Use the material above as the factual basis for the reasoning below — evaluate what is
+actually there, not what is typical or assumed.
+
 STEP-BACK:
 First explain: What are the core principles of how JavaScript async/await
 works, specifically regarding what an async function returns and how callers
 must handle it?
 
 PRINCIPLE APPLICATION:
-Using those principles, diagnose this specific issue: [paste code].
-Why does this return undefined, and what is the fix?
+Using those principles, diagnose the specific issue in the code above:
+why does it return undefined, and what is the fix?
 ```
 
 ### Example 3: Architecture Review
@@ -99,21 +126,25 @@ Why does this return undefined, and what is the fix?
 **Before Step-Back:**
 "Is our current authentication flow secure?"
 
-**After Step-Back:**
+**After Step-Back** (source material supplied):
 ```
 ORIGINAL QUESTION:
 Is our current authentication flow secure?
 
+SOURCE MATERIAL:
+[Paste the authentication flow — the login sequence, session handling, and token logic — here]
+Use the material above as the factual basis for the reasoning below — evaluate what is
+actually there, not what is typical or assumed.
+
 STEP-BACK:
-Before reviewing our specific implementation, first outline: What are the
+Before reviewing the specific implementation, first outline: What are the
 fundamental security principles and threat models that a well-designed
 authentication flow must address? Include: credential handling, session
 management, token security, and common attack vectors.
 
 PRINCIPLE APPLICATION:
-Using those security principles as a checklist, review our authentication
-flow below and identify any gaps or vulnerabilities.
-[Paste authentication flow]
+Using those security principles as a checklist, review the authentication
+flow above and identify any gaps or vulnerabilities.
 ```
 
 ### Example 4: Content/Writing
@@ -121,7 +152,8 @@ flow below and identify any gaps or vulnerabilities.
 **Before Step-Back:**
 "Write an introduction for my article about climate change and agriculture."
 
-**After Step-Back:**
+**After Step-Back** (no source material — the introduction is written from scratch, so the
+`SOURCE MATERIAL` block and the sentence below it are both deleted):
 ```
 ORIGINAL QUESTION:
 Write an introduction for my article about climate change and agriculture.

package/skills/prompt-architect/references/frameworks/tidd-ec.md

@@ -100,33 +100,81 @@ TIDD-EC is a precision-focused prompt template that provides clear boundaries an
 
 ## Template Structure
 
+Section headers are stripped at emission, so every slot's meaning is carried by the prose
+around and inside it rather than by the header above it. This matters most for the Don't
+list: the negation must live in each bullet itself. A bare noun phrase under a `DON'T:`
+header reads as an instruction to DO the very thing being forbidden once the header is
+gone. Do not reintroduce header-only structure.
+
 ```
+SOURCE MATERIAL:
+[Optional — paste the artifact this task operates on here, naming it concretely, e.g. "Paste
+the customer's message here" or "Paste the draft to translate here". If this task generates
+from scratch, delete this bracketed block along with the sentence directly below it.]
+Use the material above as the content for the work described below.
+
 TASK TYPE:
-[Clear indication of activity type]
+The category of task you are performing is: [name the activity category only — e.g. "Customer
+Support Response", "Data Analysis and Summarization", "Content Translation with Context
+Preservation". Specifics of this particular case belong in the background at the end.]
 
 INSTRUCTIONS:
-[Specific steps and guidelines]
-1. [Step 1]
-2. [Step 2]
-3. [Continue...]
+Carry out the task as follows.
+1. [First step, as a complete imperative sentence beginning with a verb — e.g. "Read the
+customer's message and identify the specific problem they report."]
+2. [Continue in the same form, one step per line, for as many steps as the methodology needs.
+If standing guidelines govern this task rather than an ordered procedure, delete the numbered
+list and keep only the standards below.]
+
+Observe these standards throughout:
+[Optional — one per line, each a complete imperative sentence, e.g. "Follow the company style
+guide.", "Use a three-paragraph structure: problem, solution, next steps." If the numbered
+steps are the whole methodology, delete this bracketed block along with the sentence above it.]
 
 DO:
-- [Action or element to include]
-- [Required approach or language]
-- [Structure to follow]
+The output must satisfy every requirement below:
+- [Always <required action, element, or information>]
+- [Use <required language, tone, or terminology>]
+- [Follow <required structure or format>]
+- [Add more as needed, each led by "Always" or an imperative verb so it reads as a
+requirement on its own line.]
 
 DON'T:
-- [Action or element to avoid]
-- [Error to prevent]
-- [Inappropriate approach]
+The output must respect every prohibition below:
+- [Do not <error or mistake to prevent>]
+- [Never <inappropriate language or approach>]
+- [Do not <common pitfall to prevent>]
+- [Do not <exceed a stated limit or cross a boundary>]
+- [Add more as needed, each led by "Do not" or "Never". The negation must live in the item
+itself — a bare noun phrase reads as an instruction to DO the very thing being forbidden.]
 
 EXAMPLES:
-[Concrete examples of desired outcome]
-Example 1: [...]
-Example 2: [...]
+[Optional — if no reference sample is needed, delete everything from this line through the
+counter-example below.]
+The examples below set the standard your output must meet. Match their format, tone,
+structure, and level of detail.
+
+Example 1 — produce output like this:
+[Write the desired output in full — the actual text, not a description of it. If the user
+supplied an approved sample or boilerplate, reproduce it here.]
+
+Example 2 — also produce output like this:
+[Optional — a second full example at the same quality bar. If one is enough, delete this
+bracketed block along with the label line above it.]
+
+Counter-example — do NOT produce output like this:
+[Optional — a full counter-example of the failure mode, opening with a sentence naming it
+unacceptable, e.g. "The following response would be unacceptable because it deflects blame:",
+so the warning survives without its label. If not useful, delete this bracketed block along
+with the label line above it.]
 
 CONTEXT:
-[Background information and user-provided content]
+The background below describes the situation this task takes place in.
+- [Optional — state each supplied background fact, constraint, situational factor, or
+applicable standard as a complete sentence, one per line. Include only what the user supplied;
+never invent one — if a needed fact is missing, leave a visible [you fill this in: <what is
+needed>] placeholder instead of a guess. If the task needs no background, delete this
+bracketed block along with the sentence above it.]
 ```
 
 ## Complete Example
@@ -136,35 +184,48 @@ CONTEXT:
 
 ### After TIDD-EC:
 ```
+SOURCE MATERIAL:
+"I ordered the ceramic serving set for my daughter's engagement party this Saturday
+and it turned up in pieces. The box looked fine from the outside. I've been buying
+from you for two years and this is the first time anything like this has happened,
+but the timing could not be worse."
+Use the material above as the content for the work described below.
+
 TASK TYPE:
-Customer Support Response - Complaint Resolution
+The category of task you are performing is: Customer Support Response.
 
 INSTRUCTIONS:
-1. Acknowledge the customer's frustration and validate their concern
-2. Apologize for the inconvenience caused
-3. Explain what happened (if known) in simple terms
-4. Provide a concrete solution or next steps
-5. Include timeline for resolution
-6. Offer additional support contact information
+Carry out the task as follows.
+1. Acknowledge the customer's frustration and validate their concern.
+2. Apologize for the inconvenience caused.
+3. Explain what happened, in simple terms, if the cause is known.
+4. Provide a concrete solution and the next steps you are taking.
+5. State a specific timeline for resolution.
+6. Offer a direct contact route for further support.
 
 DO:
-- Use empathetic, professional language
-- Personalize the response with customer name
-- Provide specific action items with timeframes
-- Include direct contact information for follow-up
-- Express genuine concern for their experience
-- Keep response between 150-250 words
+The output must satisfy every requirement below:
+- Always use empathetic, professional language.
+- Always address the customer by name.
+- Always give specific action items with timeframes attached.
+- Always include direct contact information for follow-up.
+- Always express genuine concern for their experience.
+- Keep the response between 150 and 250 words.
 
 DON'T:
-- Make excuses or deflect blame
-- Use template language that sounds robotic
-- Make promises you can't keep
-- Include technical jargon or system error codes
-- Use passive voice ("mistakes were made")
-- Exceed 250 words or write less than 150
+The output must respect every prohibition below:
+- Do not make excuses or deflect blame onto the customer, a carrier, or a system.
+- Never use template language that sounds robotic.
+- Do not promise anything you cannot guarantee.
+- Do not include technical jargon or internal system error codes.
+- Never use passive voice to describe the failure (for example, "mistakes were made").
+- Do not exceed 250 words, and do not write fewer than 150.
 
 EXAMPLES:
-Example 1 - Good Response:
+The examples below set the standard your output must meet. Match their format, tone,
+structure, and level of detail.
+
+Example 1 — produce output like this:
 "Dear Sarah, I'm truly sorry that your order arrived damaged. I understand how
 frustrating this must be, especially since you needed it for this weekend's event.
 This happened because of a packaging error in our warehouse. Here's what I'm doing
@@ -173,16 +234,20 @@ you'll have it by Friday 2 PM, (2) You'll receive a full refund for the original
 order within 24 hours. If you have any concerns, please reach me directly at
 sarah.smith@company.com or 555-1234. We value your business and will make this right."
 
-Example 2 - Bad Response (What to Avoid):
+Counter-example — do NOT produce output like this:
+The following response would be unacceptable because it hides behind passive voice,
+blames a system rather than taking responsibility, offers no remedy or timeline, and
+redirects the customer to a ticket number instead of a person:
 "We apologize for any inconvenience. Due to system errors, your order was damaged.
 Please contact our support team for further assistance. Ticket #12345."
 
 CONTEXT:
-- Company: E-commerce retailer specializing in home goods
-- Customer: Premium member who shops regularly
-- Issue: Damaged item received, needed for event
-- Previous interactions: Generally positive, 4.5/5 satisfaction rating
-- Company policy: Full refunds + replacement for damaged items
+The background below describes the situation this task takes place in.
+- The company is an e-commerce retailer specializing in home goods.
+- The customer is a premium member who shops regularly.
+- The customer received a damaged item that they needed for an event.
+- Previous interactions have been generally positive, at a 4.5/5 satisfaction rating.
+- Company policy allows a full refund plus a replacement for damaged items.
 ```
 
 ## Best Use Cases
@@ -313,7 +378,7 @@ CONTEXT:
 
 **Good**:
 - DO: "Use formal language, address customer by name, include specific metrics"
-- DON'T: "Use contractions, include unverified information, exceed 300 words"
+- DON'T: "Do not use contractions, do not include unverified information, and do not exceed 300 words"
 
 ### 2. Contradictory Instructions
 **Bad**:
@@ -325,7 +390,7 @@ DON'T: Exceed 100 words
 **Good**:
 ```
 DO: Include top 3 key points with supporting data
-DON'T: Include tangential information or exceed 150 words
+DON'T: Do not include tangential information, and do not exceed 150 words
 ```
 
 ### 3. Missing Context
@@ -396,8 +461,8 @@ For simpler tasks that don't need all components:
 ```
 TASK TYPE: [task]
 INSTRUCTIONS: [steps]
-DO: [requirements]
-DON'T: [restrictions]
+DO: [requirements, each led by "Always" or an imperative verb]
+DON'T: [restrictions, each led by "Do not" or "Never" so the negation survives header stripping]
 ```
 (Omit Examples and Context if not needed)