@ckelsoe/prompt-architect 3.2.2 → 3.4.0

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.
 
-**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-27% accuracy on MMLU Physics and Chemistry, +27% on TimeQA, +25% on MuSiQue vs. direct prompting.
+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

@@ -2,7 +2,9 @@
 
 ## Overview
 
-TIDD-EC is a precision-focused prompt engineering framework that excels in providing clear boundaries and actionable guidance through explicit "Dos and Don'ts." Originally documented alongside CO-STAR, it emphasizes clarity and specificity in task execution, making it ideal for tasks requiring detailed instructions and explicit constraints.
+TIDD-EC is a precision-focused prompt template that provides clear boundaries and actionable guidance through explicit "Dos and Don'ts." It emphasizes clarity and specificity in task execution, making it useful for tasks requiring detailed instructions and explicit constraints.
+
+**Origin:** Community convention, no verified originator. The earliest traceable appearance is "Mastering Prompt Engineering: A Guide to the CO-STAR and TIDD-EC Frameworks," published 5 February 2024 on Medium by the corporate account **Vivas.AI** (Vuram Technology Solutions Pvt. Ltd., Chennai). That post names no individual author and cites no source, introducing the framework only as "another framework emerges on the horizon." No earlier source, named originator, or published evaluation of TIDD-EC could be found. Not research-backed.
 
 **Key Strength**: Explicit positive (Do) and negative (Don't) guidance prevents errors and misinterpretations.
 
@@ -98,33 +100,81 @@ TIDD-EC is a precision-focused prompt engineering framework that excels in provi
 
 ## 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
@@ -134,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
@@ -171,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
@@ -311,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**:
@@ -323,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
@@ -394,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)
 
@@ -435,18 +502,29 @@ When applying TIDD-EC, verify:
 - [ ] Context includes relevant constraints
 - [ ] All components work together coherently
 
-## Research Sources
+## Provenance
 
-Based on authoritative sources documenting TIDD-EC alongside CO-STAR:
+TIDD-EC has no verified originator and no academic basis. The full traceable source set is three items, honestly assessed:
 
-1. **Mastering Prompt Engineering: A Guide to the CO-STAR and TIDD-EC Frameworks** - Vivas.AI, Medium
+1. **Vivas.AI, "Mastering Prompt Engineering: A Guide to the CO-STAR and TIDD-EC Frameworks"** — Medium, 5 February 2024
    - [https://vivasai01.medium.com/mastering-prompt-engineering-a-guide-to-the-co-star-and-tidd-ec-frameworks-3334588cb908](https://vivasai01.medium.com/mastering-prompt-engineering-a-guide-to-the-co-star-and-tidd-ec-frameworks-3334588cb908)
+   - *This is the origin, not corroboration of it.* Corporate account, no individual byline, no citations. Every later mention traces back here.
 
-2. **Mastering Prompt Engineering: A Guide to the CO-STAR and TIDD-EC Frameworks** - GPT Teams
+2. **GPT Teams, same title**
    - [https://gptteams.ai/articles/mastering-prompt-engineering-a-guide-to-the-co-star-and-tidd-ec-frameworks](https://gptteams.ai/articles/mastering-prompt-engineering-a-guide-to-the-co-star-and-tidd-ec-frameworks)
+   - *Not independent.* Same title and content as (1), carrying a Vivas.AI-affiliated byline and pointing readers back to vivas.ai. A same-organization republication; it adds no evidentiary weight.
 
-3. **In conversation with AI - when Prompt Engineering meets Linguistics** - Scott Logic Blog
+3. **Hélène Sauvé, "In conversation with AI — when Prompt Engineering meets Linguistics"** — Scott Logic, 12 July 2024
    - [https://blog.scottlogic.com/2024/07/12/when-prompt-engineering-meets-linguistics.html](https://blog.scottlogic.com/2024/07/12/when-prompt-engineering-meets-linguistics.html)
+   - *Passing mention only.* TIDD-EC appears in a single clause, and is expanded there **without the E and C**. Evidence the acronym circulated; not evidence of origin or efficacy.
+
+**These are not "authoritative sources."** They are one origin post, one republication of it, and one one-line mention. The template below remains practically useful — explicit Do/Don't constraints are a sound prompting tactic independent of this acronym — but the acronym itself carries no authority.
+
+**Correction:** an earlier version of this file said TIDD-EC was "originally documented alongside CO-STAR." That was misleading. CO-STAR is separately attributable to **GovTech Singapore's Data Science & AI team** (popularized by Sheila Teo). Teo's article does not mention TIDD-EC, and no GovTech or Teo source connects the two. The only link is that one Medium post happened to describe both frameworks in the same article — which is not shared provenance.
+
+**Naming caution:** "Vivas.AI" above (a Chennai company) is unrelated to "Fabio Vivas" (fvivas.com), cited in `rise.md`. Do not merge them.
+
+**Confusable:** exabytes.my documents **TID-EC** = Task, Input, Desired Output, Example, Context. Different acronym, different framework.
 
 ## Key Takeaways