@ckelsoe/prompt-architect 3.0.0

package/skills/prompt-architect/references/frameworks/least-to-most.md

@@ -0,0 +1,226 @@
+# Least-to-Most (LtM) Prompting
+
+## Overview
+
+Least-to-Most (LtM) prompting is a decomposition-first framework that breaks a complex problem into an ordered sequence of simpler subproblems, then solves them sequentially — using each prior answer as context for the next. Unlike Chain of Thought (which reasons through a problem in one pass), LtM explicitly separates decomposition from execution, and the subproblems are sequenced from simplest to most complex.
+
+**Research basis:** "Least-to-Most Prompting Enables Complex Reasoning in Large Language Models" (Zhou et al., Google Brain, arXiv:2205.10625, ICLR 2023). On SCAN compositional generalization: LtM achieves 99.7% vs. CoT's 16%. On GSM8K math: matches or exceeds CoT with fewer errors.
+
+## Why LtM Differs from Chain of Thought
+
+| | Chain of Thought | Least-to-Most |
+|---|---|---|
+| Structure | Single-pass linear reasoning | Explicit decompose → solve sequence |
+| Decomposition | Implicit (within the chain) | Explicit first step |
+| Subproblem order | Not explicitly structured | Simplest → most complex |
+| Answer reuse | May or may not reference prior steps | Each answer feeds explicitly into the next |
+| Best for | Known procedure, moderate complexity | Compositional tasks, building-block problems |
+
+## Components
+
+### Phase 1: Decomposition
+**Purpose:** Break the original problem into an ordered list of subproblems, from simplest to most complex. The key: later subproblems should build on earlier ones.
+
+**Trigger:** "To solve [problem], we need to first solve: [list subproblems in order]"
+
+**Questions to Ask:**
+- What is the simplest thing that must be true before we can answer the full question?
+- What building blocks does the final answer depend on?
+- What is the correct ordering — which must come first?
+
+### Phase 2: Sequential Solving
+**Purpose:** Solve each subproblem in order, explicitly using prior answers as context.
+
+**Pattern:** Answer subproblem 1 → use that answer when solving subproblem 2 → use both when solving subproblem 3 → ... → solve original problem.
+
+## Template Structure
+
+```
+PROBLEM:
+[The full, complex problem to solve]
+
+DECOMPOSE:
+Break this problem into ordered subproblems, from simplest to most complex.
+Each later subproblem should build on the answer to the previous.
+
+Subproblem 1: [Simplest prerequisite]
+Subproblem 2: [Next level, may depend on #1]
+Subproblem 3: [More complex, depends on #1-2]
+...
+Final: [The original problem, now solvable using all prior answers]
+
+SOLVE SEQUENTIALLY:
+Solve each subproblem in order. Use prior answers as context for each
+subsequent subproblem. Show each solution before moving to the next.
+```
+
+### Single-Pass Trigger (model decomposes and solves itself):
+```
+To solve the following problem, first identify the simpler subproblems
+that must be solved first (from least to most complex). Then solve each
+in sequence, using prior answers as context. Show decomposition, then
+sequential solutions.
+
+Problem: [your problem]
+```
+
+## Complete Examples
+
+### Example 1: Multi-Hop Reasoning
+
+**Before LtM:**
+"What would the tax implications be for a US remote employee working from Portugal for 3 months?"
+
+**After LtM:**
+```
+PROBLEM:
+What are the tax implications for a US citizen employed by a US company who
+works remotely from Portugal for 3 months in one calendar year?
+
+DECOMPOSE:
+Subproblem 1: What are the US tax rules for citizens earning income abroad
+(general principles, FEIE, FTC)?
+
+Subproblem 2: What is Portugal's tax rule for foreigners working there —
+specifically the threshold for establishing tax residency?
+
+Subproblem 3: Does 3 months in Portugal trigger Portuguese tax residency?
+(Use answers from 1 and 2)
+
+Subproblem 4: If both US and Portuguese tax obligations potentially apply,
+what does the US-Portugal tax treaty say about double taxation?
+
+Final: Given the above, what are the practical tax implications and what
+should the employee do?
+
+SOLVE SEQUENTIALLY:
+[Solve in order, each answer informing the next]
+```
+
+### Example 2: Code Architecture
+
+**Before LtM:**
+"How do I add real-time notifications to my Django app?"
+
+**After LtM:**
+```
+PROBLEM:
+I need to add real-time push notifications to a Django app with PostgreSQL.
+Users should receive browser notifications when certain database records change.
+
+DECOMPOSE:
+Subproblem 1: What are the available mechanisms for real-time browser
+communication in Django? (WebSockets, SSE, polling — trade-offs)
+
+Subproblem 2: For the chosen mechanism, what Django-specific libraries
+and setup are required?
+
+Subproblem 3: How do we detect database record changes and trigger
+notifications? (Django signals, PostgreSQL LISTEN/NOTIFY, or polling)
+
+Subproblem 4: How do we route a database event → notification trigger →
+connected browser client?
+
+Final: What is the complete implementation plan and any gotchas?
+
+SOLVE SEQUENTIALLY:
+[Solve in order]
+```
+
+### Example 3: Business Analysis
+
+**Before LtM:**
+"Should we expand to the European market?"
+
+**After LtM:**
+```
+PROBLEM:
+Our B2B SaaS has strong US traction. Should we expand to the European market
+now, given our current 20-person team and 18 months of runway?
+
+DECOMPOSE:
+Subproblem 1: What are the key differences between US and European B2B SaaS
+markets that affect a US-native product? (GDPR, sales cycles, localization needs)
+
+Subproblem 2: What resources are typically required for a credible EU market entry?
+(team, timeline, cost estimates)
+
+Subproblem 3: What are the signals that a company is or isn't ready for
+international expansion?
+
+Subproblem 4: Given our specific constraints (20 people, 18 months runway),
+how do our resources map to those requirements?
+
+Final: Should we expand to Europe now, wait, or explore a different
+expansion approach? With clear reasoning from the above.
+
+SOLVE SEQUENTIALLY:
+[Solve each in order, carry answers forward]
+```
+
+## Best Use Cases
+
+1. **Compositional Reasoning**
+   - Multi-hop questions requiring chained facts
+   - Problems where the answer depends on several intermediate results
+   - Any question with "it depends on X, which depends on Y"
+
+2. **Complex Technical Problems**
+   - Architecture decisions with prerequisites
+   - Debugging with unknown root cause
+   - Implementation planning with dependencies
+
+3. **Multi-Domain Questions**
+   - Questions spanning legal + technical, financial + operational, etc.
+   - Any question where different areas of knowledge must be combined
+
+4. **Long Math / Calculation Chains**
+   - Financial projections with multiple steps
+   - Physics problems with multiple formulas
+   - Anything where intermediate errors cascade
+
+5. **When Chain of Thought Keeps Failing**
+   - LtM's explicit decomposition reduces error propagation
+   - If CoT gives wrong answers, decomposing first often helps
+
+## Selection Criteria
+
+**Choose LtM when:**
+- ✅ Problem has multiple prerequisite subproblems
+- ✅ Subproblems have a natural ordering (simplest first)
+- ✅ Each answer genuinely builds on the previous
+- ✅ CoT gives shallow or wrong answers on this type of question
+- ✅ Decomposition is non-trivial (question is compositional)
+
+**Avoid LtM when:**
+- ❌ Problem is simple and self-contained → use CoT or APE
+- ❌ No natural decomposition exists → use Tree of Thought instead
+- ❌ Subproblems are independent (no ordering needed) → use SoT or ToT
+- ❌ Content creation task → use CO-STAR or BAB
+
+## Common Mistakes
+
+1. **Subproblems That Don't Build**
+   - Each subproblem should be a prerequisite for the next
+   - If they're independent, that's SoT or Tree of Thought, not LtM
+
+2. **Wrong Ordering**
+   - More complex ≠ later; it's about dependency, not complexity per se
+   - "What is X?" must come before "Given X, what is Y?"
+
+3. **Not Carrying Answers Forward**
+   - The key to LtM is that each answer is explicitly used in the next step
+   - Don't solve subproblems in isolation
+
+4. **Using LtM When CoT Is Sufficient**
+   - If the problem has one reasoning path, CoT is simpler
+   - LtM overhead is only worth it for genuinely compositional problems
+
+## Quick Reference
+
+| Phase | Purpose | Key Question |
+|-------|---------|--------------|
+| Decompose | Order the subproblems | "What must I know first?" |
+| Solve (simplest) | Build the foundation | "What's the answer to this piece?" |
+| Solve (sequentially) | Build on prior answers | "Given what we know, what's next?" |
+| Final solve | Assemble the answer | "Now that I have all pieces, what's the answer?" |

package/skills/prompt-architect/references/frameworks/plan-and-solve.md

@@ -0,0 +1,210 @@
+# Plan-and-Solve (PS+) Prompting
+
+## Overview
+
+Plan-and-Solve (PS+) is a zero-shot prompting technique that improves upon standard Chain of Thought by instructing the model to explicitly plan the solution approach before executing it — and to be careful about extracting variables and calculating intermediate results. It requires no examples or demonstrations and consistently outperforms Zero-Shot CoT ("Let's think step by step") on reasoning tasks.
+
+**Research basis:** "Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models" (Wang et al., ACL 2023, arXiv:2305.04091). Tested across 10 reasoning datasets — consistently outperforms Zero-Shot-CoT and is competitive with few-shot CoT.
+
+## The Core Trigger Phrases
+
+### PS (Basic):
+```
+Let's first understand the problem and devise a plan to solve it.
+Then, let's carry out the plan and solve the problem step by step.
+```
+
+### PS+ (Enhanced — recommended):
+```
+Let's first understand the problem, extract relevant variables and their
+corresponding numerals, and devise a complete plan. Then, let's carry out
+the plan, calculate intermediate values, pay attention to computation,
+and solve the problem step by step.
+```
+
+The PS+ additions over PS:
+1. **"Extract relevant variables"** — forces the model to identify all given information before starting
+2. **"Calculate intermediate values"** — prevents skipping computational steps
+3. **"Pay attention to computation"** — explicit reminder to be accurate with numbers
+
+## Template Structure
+
+```
+PROBLEM:
+[Your problem or question]
+
+INSTRUCTION:
+Let's first understand the problem, extract relevant variables and their
+corresponding numerals, and devise a complete plan. Then, let's carry out
+the plan, calculate intermediate values, pay attention to computation,
+and solve the problem step by step.
+```
+
+### Inline Version (append to any question):
+```
+[Your question]. Let's first understand the problem, extract relevant
+variables and their corresponding numerals, and devise a complete plan.
+Then let's carry out the plan, calculate intermediate values, and solve
+step by step.
+```
+
+## Complete Examples
+
+### Example 1: Math / Calculation
+
+**Before PS+:**
+"If a SaaS company has 500 customers at $200/month each, 5% monthly churn, and adds 30 new customers per month, what is the MRR in 6 months?"
+
+**After PS+:**
+```
+PROBLEM:
+A SaaS company has 500 customers paying $200/month each. Monthly churn
+is 5%. The company acquires 30 new customers per month. What is the MRR
+in 6 months?
+
+Let's first understand the problem, extract relevant variables and their
+corresponding numerals, and devise a complete plan. Then, let's carry out
+the plan, calculate intermediate values, pay attention to computation,
+and solve the problem step by step.
+```
+
+**Expected model behavior:**
+```
+Variables:
+- Starting customers: 500
+- Monthly price: $200/month
+- Monthly churn rate: 5% = 0.05
+- Monthly new customers: 30
+- Target period: 6 months
+
+Plan:
+1. Calculate customers lost per month (churn)
+2. Calculate net new customers per month (acquired - churned)
+3. Calculate customer count at end of each month (months 1-6)
+4. Calculate MRR for month 6
+
+Execution:
+Month 0: 500 customers, MRR = $100,000
+Month 1: 500 × (1 - 0.05) + 30 = 475 + 30 = 505 customers, MRR = $101,000
+Month 2: 505 × 0.95 + 30 = 479.75 + 30 = 509.75 ≈ 510 customers, MRR = $102,000
+...
+[continues through month 6]
+
+Final answer: Month 6 MRR = $X
+```
+
+### Example 2: Multi-Step Technical Problem
+
+**Before PS+:**
+"Our API is returning responses in 800ms average. We want to get it under 200ms. What should we do?"
+
+**After PS+:**
+```
+PROBLEM:
+Our REST API averages 800ms response time. Target is under 200ms.
+The API serves product catalog queries (read-heavy), is Node.js with
+PostgreSQL, and currently has no caching layer. Database queries are
+the main bottleneck (600ms average per request).
+
+Let's first understand the problem, extract relevant variables and their
+corresponding numerals, and devise a complete plan. Then, let's carry out
+the plan and solve step by step.
+```
+
+### Example 3: Business Calculation
+
+**Before PS+:**
+"What's our payback period if CAC is $1,200 and average MRR per customer is $150 with 70% gross margin?"
+
+**After PS+:**
+```
+PROBLEM:
+Customer Acquisition Cost (CAC): $1,200
+Average MRR per customer: $150
+Gross margin: 70%
+
+What is our payback period?
+
+Let's first understand the problem, extract relevant variables and their
+corresponding numerals, and devise a complete plan. Then, let's carry out
+the plan, calculate intermediate values, pay attention to computation,
+and solve the problem step by step.
+```
+
+### Example 4: Logic / Reasoning
+
+**Before PS+:**
+"Given these constraints [complex scheduling problem], is there a valid schedule?"
+
+**After PS+:**
+```
+PROBLEM:
+[Complex scheduling problem with constraints]
+
+Let's first understand the problem, extract all constraints and their
+relationships, and devise a complete plan for finding a valid schedule
+or proving none exists. Then, let's carry out the plan step by step.
+```
+
+## Best Use Cases
+
+1. **Numerical Reasoning**
+   - Financial calculations (MRR, CAC, payback, LTV)
+   - Math word problems
+   - Rate/proportion problems
+   - Statistical computations
+
+2. **Multi-Step Technical Problems**
+   - Performance optimization (where numbers matter)
+   - Resource estimation
+   - Capacity planning
+
+3. **Logic Problems**
+   - Constraint satisfaction
+   - Scheduling
+   - Eligibility determination
+
+4. **Zero-Shot Reasoning Improvement**
+   - When you don't have few-shot examples
+   - When vanilla CoT ("think step by step") isn't accurate enough
+   - Drop-in improvement for any reasoning prompt
+
+5. **Any Prompt Where Prior CoT Answers Were Wrong**
+   - PS+ reduces calculation errors
+   - Forces variable extraction before calculation
+   - Reduces "skipped step" errors
+
+## Selection Criteria
+
+**Choose PS+ when:**
+- ✅ Numerical calculation involved
+- ✅ Multi-step reasoning with intermediate values
+- ✅ No few-shot examples available (zero-shot context)
+- ✅ Prior CoT attempts gave calculation errors
+- ✅ Variables need explicit extraction before solving
+
+**Avoid PS+ when:**
+- ❌ Task is not a reasoning/calculation problem → use other frameworks
+- ❌ Few-shot examples are available → consider manual CoT instead
+- ❌ Problem requires branching (multiple approaches) → use Tree of Thought
+- ❌ Compositional multi-hop → use Least-to-Most
+
+## PS+ vs. Chain of Thought vs. Least-to-Most
+
+| | Zero-Shot CoT | PS+ | Least-to-Most |
+|---|---|---|---|
+| Trigger | "Think step by step" | "Plan first, then execute" | Decompose → solve sequentially |
+| Variable extraction | No | Yes (explicit) | Partial |
+| Planning step | No | Yes (explicit) | Decomposition step |
+| Best for | General reasoning | Numerical/variable problems | Compositional multi-hop |
+| Few-shot needed | No | No | Optional |
+
+## Quick Reference
+
+| Component | Purpose |
+|-----------|---------|
+| Understand problem | Ensure full comprehension before starting |
+| Extract variables | Identify all given values explicitly |
+| Devise plan | State the approach before executing |
+| Calculate intermediates | Show all calculation steps |
+| Solve step by step | Execute the plan with attention to detail |

package/skills/prompt-architect/references/frameworks/pre-mortem.md

@@ -0,0 +1,197 @@
+# Pre-Mortem Prompting
+
+## Overview
+
+Pre-Mortem Prompting adapts Gary Klein's prospective hindsight technique to AI prompting. Instead of asking "what could go wrong?" (which triggers optimism bias and produces vague risks), it instructs the AI to *assume* the project or decision has already failed catastrophically — then work backwards to identify the specific reasons why. This committed-failure frame consistently produces more specific, actionable failure identification than forward risk analysis.
+
+**Research basis:** Gary Klein's prospective hindsight research (Cognitive Systems Engineering; Brookings Institution). Studies show ~30% improvement in correct identification of failure causes compared to standard forward risk analysis. Application to LLM prompting is practitioner-level (no dedicated AI paper), but the cognitive mechanism is well-established.
+
+## Why Assumed Failure Outperforms Forward Risk Analysis
+
+Forward risk: *"What could go wrong?"* → Produces vague, hedged answers ("there might be delays", "adoption could be low")
+
+Pre-mortem: *"This has already failed — why did it fail?"* → Produces specific, committed answers ("the integration with Salesforce took 3x longer than estimated because we didn't account for their API rate limits")
+
+The difference: by committing to the failure frame, the model bypasses optimism bias and generates specific causal narratives rather than probabilistic hedges.
+
+## Components
+
+### Project/Decision Description
+**Purpose:** What is being analyzed. Include enough context for the model to generate specific (not generic) failure causes.
+
+### Future Date
+**Purpose:** Set the time horizon. "12 months from now" produces different analysis than "3 months from now." Match to the natural completion window of the project.
+
+### Failure Framing
+**Purpose:** The core assumption: this has failed. Not "might fail" — has failed. The framing is everything.
+
+**Standard framing:** *"It is [future date] and [project/decision] has completely and catastrophically failed."*
+
+### Domain Analysis
+**Purpose:** The specific dimensions to analyze for failure causes. More dimensions = more comprehensive coverage.
+
+**Standard domains:**
+- Technical / product
+- People / team / organizational
+- Market / customers / adoption
+- Financial / resource
+- External / dependencies
+- Timeline / scope
+
+### Warning Signs
+**Purpose:** For each failure cause, identify the earliest observable warning sign. This is what makes pre-mortem actionable — not just "this could fail" but "this is what we'd see 30 days before it fails."
+
+### Mitigation Pass (optional)
+**Purpose:** A second pass ranking the failure causes by likelihood × preventability and suggesting pre-emptive actions.
+
+## Template Structure
+
+```
+PRE-MORTEM ANALYSIS
+
+PROJECT/DECISION:
+[Describe the project, plan, or decision being analyzed]
+
+FAILURE ASSUMPTION:
+It is [DATE — e.g., 12 months from now] and [project/decision] has
+completely and catastrophically failed. It did not achieve [primary goal].
+
+FAILURE ANALYSIS:
+Describe the failure in 2-3 sentences from the perspective of someone
+looking back on it.
+
+Then identify [8-12] specific reasons this failed. For each reason:
+- CAUSE: [What specifically went wrong — be specific, not generic]
+- DOMAIN: [Technical / People / Market / Financial / External / Timeline]
+- WARNING SIGN: [What was the earliest observable indicator this was happening?]
+
+PRIORITY:
+After listing all causes, identify:
+1. The 3 most likely failure causes (given our specific situation)
+2. The 3 most preventable failure causes (where action now would help most)
+3. Any single point of failure that could kill the project alone
+```
+
+## Complete Examples
+
+### Example 1: Product Launch
+
+```
+PROJECT:
+We are launching a new B2B project management tool for engineering teams
+in Q3. Our team is 4 engineers, 1 designer, and 1 PM. We have 3 design
+partners signed up for beta. Target: 50 paying customers by end of Q4.
+
+FAILURE ASSUMPTION:
+It is December 31st and we have failed to reach 50 paying customers.
+The product launched in October with 8 beta customers but growth stalled.
+
+FAILURE ANALYSIS:
+Describe how this played out. Then identify 10 specific failure causes
+with domain, and earliest warning sign for each.
+
+PRIORITY:
+Rank by likelihood. Flag any single points of failure.
+```
+
+### Example 2: Organizational Change
+
+```
+PROJECT:
+We are implementing a company-wide shift to OKRs across a 200-person
+organization. Executive sponsorship is in place. We're starting with
+a 2-day offsite to train team leads, then cascading to individual
+contributors over the following 6 weeks.
+
+FAILURE ASSUMPTION:
+It is 6 months from now and the OKR implementation has failed.
+Most teams have abandoned OKRs and reverted to old goal-setting methods.
+
+FAILURE ANALYSIS:
+10 specific reasons the rollout failed. Include: leadership domain,
+middle management domain, cultural domain, process domain, and tooling.
+For each: earliest warning sign.
+
+PRIORITY:
+The 3 most likely. The most preventable. Any single point of failure.
+```
+
+### Example 3: Technical Decision
+
+```
+PROJECT:
+We are migrating our primary database from MySQL to PostgreSQL. Timeline:
+3 months. Team: 2 senior engineers part-time. We're running 2M daily
+active users with a 99.9% uptime SLA.
+
+FAILURE ASSUMPTION:
+It is 4 months from now and the migration has failed. We experienced
+significant downtime, data integrity issues, or were forced to roll back.
+
+FAILURE ANALYSIS:
+10 specific technical and organizational failure causes.
+Cover: migration strategy, testing gaps, rollback planning,
+team knowledge gaps, operational issues, and unforeseen dependencies.
+For each: earliest warning sign.
+
+PRIORITY:
+The 3 most likely. The most preventable. Any single point of failure
+that could cause a full rollback or data loss.
+```
+
+## Best Use Cases
+
+1. **Pre-Launch Risk Assessment**
+   - Product launches
+   - Marketing campaigns
+   - Feature releases
+
+2. **Organizational Initiatives**
+   - Process changes, reorgs, new methodologies
+   - Cultural initiatives
+
+3. **Technical Decisions**
+   - Migrations, rewrites, architecture changes
+   - High-risk deployments
+
+4. **Investment and Strategic Decisions**
+   - New market entry
+   - Major hires or partnerships
+   - Significant capital allocation
+
+5. **Any High-Stakes, Hard-to-Reverse Decision**
+
+## Selection Criteria
+
+**Choose Pre-Mortem when:**
+- ✅ You're about to commit to something with significant stakes
+- ✅ You want specific failure causes, not generic risks
+- ✅ Optimism bias is a risk (you're attached to this plan)
+- ✅ You want to surface the "what were we thinking?" failure modes
+
+**Avoid when:**
+- ❌ You want to attack the reasoning of a current position → use Devil's Advocate
+- ❌ You want iterative output improvement → use Self-Refine
+- ❌ The decision is already made and irreversible (too late for pre-mortem)
+
+## Pre-Mortem vs. Devil's Advocate
+
+| | Pre-Mortem | Devil's Advocate |
+|---|---|---|
+| Frame | "This has already failed" (committed) | "Here's why this is wrong" (oppositional) |
+| Output | Specific failure causes + warning signs | Strongest opposing argument |
+| Best for | Risk identification + mitigation | Testing reasoning + debiasing |
+| Bias bypass | Optimism bias | Confirmation bias / groupthink |
+
+**Combined use:** Run Devil's Advocate first (attack the reasoning), then Pre-Mortem (assume failure and find causes). They complement each other for high-stakes decisions.
+
+## Quick Reference
+
+| Component | Purpose |
+|-----------|---------|
+| Project Description | What's being analyzed |
+| Future Date | Time horizon |
+| Failure Framing | "Has already failed" (committed, not probabilistic) |
+| Domain Analysis | Dimensions to cover |
+| Warning Signs | Earliest observable indicators |
+| Priority Pass | Most likely + most preventable + single points of failure |