@ckelsoe/prompt-architect 3.0.0

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

@@ -0,0 +1,186 @@
+# Skeleton of Thought (SoT) Framework
+
+## Overview
+
+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.
+
+**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 maintained or improved quality.
+
+## Components
+
+### Phase 1: Skeleton Generation
+**Purpose:** Generate a concise, ordered list of the key points, sections, or sub-answers that will form the complete response. No expansion yet — just the bare bones.
+
+**Trigger prompt:**
+```
+You're an organizer of responses. Please provide me with a one-line point outline
+of [topic/question] without any explanation. Your outline must be:
+X. [brief point name] | [one-line description]
+```
+
+### Phase 2: Point Expansion
+**Purpose:** Expand each skeleton point into full content. Each point is independent and can be expanded in isolation (enabling parallelism).
+
+**Trigger prompt per point:**
+```
+Please expand on the following point in 3-5 sentences:
+Point X: [point name] — [one-line description]
+```
+
+### SoT-R Variant (Router)
+**Purpose:** Adds a routing step before Phase 1. If the question is NOT suitable for SoT (e.g., requires continuous prose, math derivation, or linear reasoning), the router falls back to standard generation.
+
+**Not suitable for SoT:** Mathematical proofs, code that must flow sequentially, narrative story, continuous logical arguments where each step depends on the last.
+
+## Template 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.
+
+QUESTION/TOPIC:
+[Your question or topic]
+
+PHASE 2 — EXPAND:
+Now expand each point into [2-4 sentences / a paragraph / detailed explanation].
+Each point should be self-contained and complete.
+
+[Optional: expand points in parallel by sending each as a separate request]
+```
+
+### Minimal Single-Pass SoT
+For use in a single prompt when parallel API calls aren't available:
+```
+First, create a brief skeleton outline of [topic] (one line per point).
+Then, expand each skeleton point into [length/detail level].
+Present as: Skeleton → then Full Expansion.
+```
+
+## Complete Examples
+
+### Example 1: Technical Explanation
+
+**Before SoT:**
+"Explain microservices architecture."
+
+**After SoT:**
+```
+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.
+
+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.
+```
+
+**Skeleton output (Phase 1):**
+```
+1. Core concept | Each service owns one business capability and runs independently
+2. Service boundaries | How to decompose a monolith into services without creating distributed spaghetti
+3. Communication patterns | Sync (REST/gRPC) vs async (events) and when each applies
+4. Data ownership | Each service owns its database; consequences for queries and consistency
+5. Operational complexity | What microservices add: service mesh, CI per service, distributed tracing
+6. Migration strategy | Strangler fig vs. big-bang; risk profile of each
+7. When NOT to use | Scale thresholds below which microservices create more problems than they solve
+```
+
+**Expansion (Phase 2, point 6):**
+```
+Migration Strategy: The strangler fig pattern incrementally wraps the monolith
+by routing new traffic to microservices while the legacy system handles the rest.
+This allows parallel operation and rollback if needed, making it the lower-risk
+option for most teams. The big-bang rewrite is faster in theory but carries high
+risk of scope creep, integration failures, and a multi-month feature freeze...
+```
+
+### Example 2: Structured Report
+
+**Before SoT:**
+"Write a competitive analysis of our product vs. competitors."
+
+**After SoT:**
+```
+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.
+
+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.
+```
+
+### Example 3: Learning Content
+
+**Before SoT:**
+"Explain how React hooks work."
+
+**After SoT (single-pass):**
+```
+First, create a 5-7 point skeleton outline of the key concepts needed to
+understand React hooks (for a developer who knows JavaScript but is new to React).
+Format: N. [concept] | [one sentence]
+
+Then expand each skeleton point into 1-2 paragraphs with a code example where relevant.
+Show: skeleton first, then full expansion.
+```
+
+## Best Use Cases
+
+1. **Structured Explanations**
+   - Technical docs
+   - Tutorial content
+   - Concept breakdowns
+
+2. **Long-Form Content Where Structure Matters**
+   - Reports and analyses
+   - Documentation sections
+   - Comparative content
+
+3. **When Parallel Generation is Available**
+   - API workflows where each skeleton point can be expanded concurrently
+   - Systems requiring minimum latency
+   - Batch content generation
+
+4. **Improving Output Organization**
+   - When prose responses tend to meander
+   - When you need consistent structure across multiple outputs
+   - When you want to review/approve structure before full generation
+
+## Selection Criteria
+
+**Choose SoT when:**
+- ✅ Output has multiple semi-independent sections
+- ✅ You want to validate structure before full generation
+- ✅ Parallel expansion would reduce latency
+- ✅ Content organization is a primary concern
+- ✅ Multiple similar documents need consistent structure
+
+**Avoid SoT when:**
+- ❌ Answer requires continuous linear reasoning → use Chain of Thought
+- ❌ Mathematical proof or derivation → use Plan-and-Solve or CoT
+- ❌ Narrative that flows as a whole → use CO-STAR
+- ❌ Simple, short answer → use APE or RTF
+- ❌ Each section depends on the previous → use Least-to-Most
+
+## SoT vs. Other Frameworks
+
+| | SoT | Chain of Thought | RISEN | CO-STAR |
+|---|---|---|---|---|
+| Structure | Skeleton → expansion | Linear steps | Methodology-driven | Audience/context-driven |
+| Parallelizable | Yes | No | No | No |
+| Best for | Structured multi-section content | Reasoning | Complex procedures | Writing |
+| Shows work | Structure only | Reasoning steps | Process | N/A |
+
+## Quick Reference
+
+| Phase | Purpose | Key Question |
+|-------|---------|--------------|
+| Skeleton | Structure first | "What are the key points?" |
+| Expansion | Fill each point | "What does each point contain?" |
+| Router (SoT-R) | Appropriateness check | "Is this suitable for SoT?" |

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

@@ -0,0 +1,206 @@
+# Step-Back Prompting
+
+## Overview
+
+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.
+
+## 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.
+
+**Pattern:** Strip away specifics → ask for the general principle/rule/concept.
+
+**Examples:**
+- Original: "What happens to water pressure at 100m depth in salt water?" → Step-back: "What are the physics principles governing fluid pressure?"
+- Original: "How should I structure a React component that fetches user data?" → Step-back: "What are the principles of separation of concerns in React component design?"
+- 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.
+
+### Step 3: Final Answer
+**Purpose:** Use the retrieved principles as context to answer the original specific question.
+
+**Trigger:** "Based on these principles, now answer the original question: [original question]"
+
+## Template Structure
+
+```
+ORIGINAL QUESTION:
+[The specific question you want answered]
+
+STEP-BACK:
+Before answering directly, first answer this higher-level question:
+[Step-back question — the abstract principle/concept behind the original]
+
+PRINCIPLE APPLICATION:
+Using the principles/concepts you just described, now answer the original question:
+[Restate original question]
+```
+
+### Auto Step-Back (Model generates its own step-back question):
+```
+Before answering the following question, first identify the underlying
+principles or concepts that govern it. State those principles clearly.
+Then use them as a foundation to answer the specific question.
+
+Question: [your question]
+```
+
+## Complete Examples
+
+### Example 1: Technical Decision
+
+**Before Step-Back:**
+"Should I use PostgreSQL or MongoDB for a social feed application?"
+
+**After Step-Back:**
+```
+ORIGINAL QUESTION:
+Should I use PostgreSQL or MongoDB for a social feed application?
+
+STEP-BACK:
+Before answering, first answer: What are the core principles that govern
+database selection for applications requiring feed-style queries, social graphs,
+and high read throughput? Consider data model fit, query patterns, and
+consistency requirements.
+
+PRINCIPLE APPLICATION:
+Using those principles, now evaluate: should I use PostgreSQL or MongoDB
+for a social feed application where users follow other users, see a ranked
+feed of posts, and can like/comment?
+```
+
+### Example 2: Debugging
+
+**Before Step-Back:**
+"Why does my async function return undefined when I call it?"
+
+**After Step-Back:**
+```
+ORIGINAL QUESTION:
+Why does my async function return undefined when I call it?
+
+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?
+```
+
+### Example 3: Architecture Review
+
+**Before Step-Back:**
+"Is our current authentication flow secure?"
+
+**After Step-Back:**
+```
+ORIGINAL QUESTION:
+Is our current authentication flow secure?
+
+STEP-BACK:
+Before reviewing our 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]
+```
+
+### Example 4: Content/Writing
+
+**Before Step-Back:**
+"Write an introduction for my article about climate change and agriculture."
+
+**After Step-Back:**
+```
+ORIGINAL QUESTION:
+Write an introduction for my article about climate change and agriculture.
+
+STEP-BACK:
+First answer: What are the rhetorical principles of an effective article
+introduction? What should it accomplish, and what structural elements
+make introductions work?
+
+PRINCIPLE APPLICATION:
+Using those principles, write an introduction for an article about how
+climate change is disrupting agricultural yield patterns globally.
+Target audience: policy-informed general readers. Goal: create urgency
+without alarmism.
+```
+
+## Best Use Cases
+
+1. **STEM Reasoning**
+   - Physics, chemistry, math problems
+   - Engineering trade-offs
+   - Scientific analysis
+
+2. **Technical Decision-Making**
+   - Architecture and design choices
+   - Technology selection
+   - Security analysis
+
+3. **Historical and Causal Analysis**
+   - Evaluating decisions and their consequences
+   - Understanding complex events
+   - Root cause analysis
+
+4. **Complex Debugging**
+   - When the specific error needs first-principles understanding
+   - Novel or unclear failure modes
+
+5. **Any Task Where Principles Matter More Than Pattern-Matching**
+
+## Selection Criteria
+
+**Choose Step-Back when:**
+- ✅ Task requires principled reasoning, not just recall
+- ✅ Direct answers tend to be shallow or incorrect
+- ✅ Underlying principles are known and applicable
+- ✅ The question is specific but has a generalizable foundation
+- ✅ Errors in past attempts suggest lack of principled grounding
+
+**Avoid Step-Back when:**
+- ❌ Task is straightforward and factual — overhead not worth it → use APE or RTF
+- ❌ Content creation (no abstract principle needed) → use CO-STAR or BAB
+- ❌ Already reasoning step-by-step → CoT may suffice
+- ❌ The principle is unknowable or irrelevant
+
+## Step-Back vs. Chain of Thought
+
+| | Step-Back | Chain of Thought |
+|---|---|---|
+| Direction | Abstract → Specific | Step 1 → Step 2 → ... → Answer |
+| Starting point | Higher-level principle | The problem itself |
+| Best for | Principle-grounded reasoning | Known procedure, sequential steps |
+| Failure mode | Step-back question too vague | Errors compound through chain |
+
+**Rule of thumb:** If the question has a known procedure → CoT. If the question requires first-principles reasoning → Step-Back.
+
+## Generating Good Step-Back Questions
+
+**Pattern:** Remove specifics → ask for the governing rule/principle
+
+| Original (Specific) | Step-Back (Abstract) |
+|---|---|
+| "What happens when thread A and thread B access shared memory?" | "What are the principles of memory consistency in concurrent programming?" |
+| "How should I price my SaaS product?" | "What are the principles of value-based pricing for B2B software?" |
+| "Was this code change the cause of our performance regression?" | "What are the principles for diagnosing performance regressions in production systems?" |
+
+## Quick Reference
+
+| Step | Purpose | Key Question |
+|------|---------|--------------|
+| Step-Back Question | Abstract the problem | "What principle governs this?" |
+| Principle Retrieval | Get the foundation | "What are the rules?" |
+| Final Answer | Apply principles to specifics | "Given these principles, what's the answer?" |