@ckelsoe/prompt-architect 3.4.0 → 3.5.0

package/.claude-plugin/marketplace.json

@@ -5,14 +5,14 @@
     "email": "charles@kelsoe.com"
   },
   "metadata": {
-    "description": "Prompt engineering skill using 29 frameworks across 7 intent categories"
+    "description": "Prompt engineering skill using 31 frameworks across 7 intent categories"
   },
   "plugins": [
     {
       "name": "prompt-architect",
       "source": "./",
-      "description": "Analyzes and improves prompts using 29 frameworks. Intent-based selection routes to the right framework — from ultra-minimal (APE) to agentic (ReAct).",
-      "version": "3.4.0",
+      "description": "Analyzes and improves prompts using 31 frameworks. Intent-based selection routes to the right framework — from ultra-minimal (APE) to agentic (ReAct).",
+      "version": "3.5.0",
       "keywords": ["prompt-engineering", "prompt-frameworks", "agent-skills"],
       "category": "productivity"
     }

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "prompt-architect",
-  "description": "29-framework prompt engineering skill for analyzing and improving prompts across 7 intent categories",
-  "version": "3.4.0",
+  "description": "31-framework prompt engineering skill for analyzing and improving prompts across 7 intent categories",
+  "version": "3.5.0",
   "author": {
     "name": "Charles Kelsoe",
     "email": "charles@kelsoe.com"

package/CHANGELOG.md

@@ -5,6 +5,21 @@ All notable changes to the Prompt Architect Claude Code skill will be documented
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [3.5.0] - 2026-07-22
+
+Adds two research-backed frameworks, one composable technique, and a guardrail against unfalsifiable framework-selection rationale. Framework count is now 31.
+
+### Added
+- **Self-Consistency** (REASON) — sample the same reasoning prompt N times at non-zero temperature and take a plain majority vote over the final answers, aggregated *outside* the model. Cited to Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models" (arXiv 2203.11171, ICLR 2023). The doc is explicit that this is *not* self-assessment (asking one model to judge its own paths) and that the emitted prompt is a single solve-prompt ending in a parseable `FINAL ANSWER:` line — the N-sample vote is an operational step the analysis section instructs, not something one pasted prompt can do. Absolute figures (56.5% → 74.4%, PaLM 540B / GSM8K) are labeled Table 1 body figures; the +17.9% is the abstract's relative delta.
+- **Chain-of-Verification** (CRITIQUE) — draft an answer, plan verification questions, answer them **independently of the draft**, then revise. That independence is the mechanism: it stops the verification from inheriting the draft's errors. Cited to Dhuliawala et al. (arXiv 2309.11495, Findings of ACL 2024). Distinct from RCoT, which reconstructs the question to catch missed *conditions*; CoVe fact-checks *claims*.
+- **Few-shot / in-context learning** as a **composable technique**, not a routed framework. It lives in `references/techniques/few-shot.md` and layers onto whichever framework was chosen — covering when examples help, how many (2–5), ordering and recency effects (Lu et al., ACL 2022), what examples actually teach (format and label space over per-example correctness — Min et al., EMNLP 2022), and calibration/bias balancing (Zhao et al., ICML 2021). Brown et al. (arXiv 2005.14165) is cited only for the term, never for a number. A new "Composable Techniques" section in `SKILL.md` and the adapter routes to it.
+
+### Changed
+- **Anti-false-narration guardrail.** Because section headers are stripped at emission, the framework choice is often invisible in the delivered prompt — so `SKILL.md` and the adapter now instruct: when two frameworks would produce the same prompt, say so, pick the simpler one, and do not manufacture a distinction the output won't show. A new drift-test invariant keeps the rule present in both files.
+- Framework count 29 → 31 across all advertised sites (`package.json` description and `claudeCode.frameworks`, `plugin.json`, `marketplace.json`, `README.md`, `SKILL.md`, adapter).
+
+---
+
 ## [3.4.0] - 2026-07-22
 
 This release makes the **emission contract** explicit and consistent across the whole skill. When Prompt Architect delivers the final prompt, framework section headers (`CONTEXT:`, `ROLE:`, `BEFORE:`, …) are stripped — the user pastes a flat block of prose with no labels. Previously the framework docs and templates were written as if those headers would survive, so slots that were bare fragments ("meeting summary", "busy professionals") lost their meaning once the header was removed. Every framework now carries its own meaning in prose.

package/README.md

@@ -1,6 +1,6 @@
 # Prompt Architect
 
-Transform vague prompts into expert-level, structured prompts using 29 frameworks across 7 intent categories.
+Transform vague prompts into expert-level, structured prompts using 31 frameworks across 7 intent categories.
 
 Works with **Claude Code, ChatGPT, Gemini CLI, Cursor, GitHub Copilot, Windsurf, OpenAI Codex**, and [30+ Agent Skills compatible tools](https://agentskills.io).
 
@@ -60,7 +60,7 @@ Prompt Architect is an [Agent Skills](https://agentskills.io) compatible skill t
 
 ## Key Features
 
-### 29 Frameworks Across 7 Intent Categories
+### 31 Frameworks Across 7 Intent Categories
 
 | Framework | Best For | Complexity |
 |-----------|----------|------------|
@@ -84,6 +84,7 @@ Prompt Architect is an [Agent Skills](https://agentskills.io) compatible skill t
 | **Least-to-Most** | Compositional multi-hop problems (simplest first) | Medium |
 | **Plan-and-Solve (PS+)** | Zero-shot numerical/calculation reasoning | Low |
 | **Chain of Thought** | Reasoning, problem-solving | Medium |
+| **Self-Consistency** | Robust answers: sample many reasoning paths, majority-vote | Medium |
 | **Chain of Density** | Summarization at fixed length, maximum information density | Medium |
 | **Iterative Compression** | Shortening text toward a target length | Low |
 | **Self-Refine** | Iterative output quality improvement (any task) | Medium |
@@ -91,9 +92,12 @@ Prompt Architect is an [Agent Skills](https://agentskills.io) compatible skill t
 | **Devil's Advocate** | Strongest opposing argument against a position | Low |
 | **Pre-Mortem** | Assume failure, identify specific causes | Low |
 | **RCoT** | Verify reasoning by reconstructing the question | Medium |
+| **Chain-of-Verification** | Fact-check a draft by verifying each claim independently | Medium |
 | **RPEF** | Recover/reconstruct a prompt from an existing output | Low |
 | **Reverse Role Prompting** | AI interviews you before executing | Low |
 
+**Composable technique** (layered onto any framework, not one of the 31): **Few-shot / in-context examples** — the discipline of adding well-chosen, well-ordered worked examples to a prompt.
+
 ### Quality Scoring System
 
 Every prompt is evaluated across:
@@ -908,7 +912,7 @@ prompt-architect/
 
 **Core Components:**
 - **SKILL.md** - Main skill logic and instructions (intent-based selection system)
-- **Framework Reference Docs** - 28 files covering all 29 frameworks, with examples (RISE documents two variants)
+- **Framework Reference Docs** - 30 files covering all 31 frameworks, with examples (RISE documents two variants)
 - **Templates** - 30 ready-to-use structures: one per framework, plus `hybrid_template.txt` for combinations
 
 ---

package/adapters/system-prompt.md

@@ -36,7 +36,9 @@ Score the prompt *as written*, not as you charitably interpret it — the gap be
 
 ### 2. Intent-Based Framework Selection
 
-With 29 frameworks, identify the user's **primary intent** first, then use the discriminating questions within that category.
+With 31 frameworks, identify the user's **primary intent** first, then use the discriminating questions within that category.
+
+**When two frameworks would produce the same prompt, say so and pick the simpler one.** Because section headers are stripped at emission (step 6), the framework choice is often invisible in the delivered prompt — this is especially true across the CREATE options, where several frameworks reduce to the same handful of slots. When you cannot point to a concrete difference the *emitted* prompt would show, do not manufacture one: name the tie plainly, choose the simpler framework, and move on. A confident rationale for an unobservable choice is exactly the overstatement this skill exists to remove.
 
 ---
 
@@ -94,6 +96,7 @@ With 29 frameworks, identify the user's **primary intent** first, then use the d
 | Multiple distinct approaches to compare | **Tree of Thought** |
 | Verify reasoning didn't overlook conditions | **RCoT** |
 | Linear step-by-step reasoning | **Chain of Thought** |
+| Answer must be robust; sample many paths and majority-vote | **Self-Consistency** |
 
 ---
 
@@ -106,8 +109,9 @@ With 29 frameworks, identify the user's **primary intent** first, then use the d
 | Find the strongest opposing argument | **Devil's Advocate** |
 | Identify failure modes before they happen | **Pre-Mortem** |
 | Verify reasoning didn't miss conditions | **RCoT** |
+| Draft may contain hallucinated facts; verify each claim | **Chain-of-Verification** |
 
-*Self-Refine = any quality. CAI = principle compliance. Devil's Advocate = opposing arguments. Pre-Mortem = failure analysis. RCoT = condition verification.*
+*Self-Refine = any quality. CAI = compliance with an **explicitly stated** standard or requirement set (and aligning the artifact to it — e.g. auditing a plan against a brief's constraints). Devil's Advocate = opposing arguments. Pre-Mortem = failure analysis. RCoT = an answer or plan overlooked a condition **implicit in the problem** (units, edge cases, unstated dependencies). Chain-of-Verification = independent fact-checking of a draft's factual claims.*
 
 ---
 
@@ -129,6 +133,12 @@ Most prompts need exactly one framework. Combine only when the task genuinely ha
 
 When you combine, state plainly in your analysis which framework owns which phase. Never stack more than two — beyond that the frameworks' instructions start to overlap and contradict, and no single framework clearly owns any phase.
 
+#### Composable Techniques
+
+Some techniques are not frameworks you choose *between* — they are layers you add *on top of* whichever framework you picked, so they never appear in the routing tables above.
+
+- **Few-shot / in-context examples** — showing 2–5 worked input→output examples inside the emitted prompt. This is the highest-leverage technique in prompting and applies to almost any framework, not just the two with a dedicated examples slot (CARE, RISE-IX). After you draft the framework prompt, decide whether examples earn their place; if they do, insert them before the final instruction, in the exact target output format, and end with the actual task. Keep examples to a handful, put the most representative one last (models weight the most recent example most heavily), keep every example in the exact format you want back, and balance the label set. Never invent examples the user or their material did not supply — fall back to a precise instruction instead.
+
 ---
 
 ### 3. Framework Quick Reference
@@ -137,12 +147,14 @@ When you combine, state plainly in your analysis which framework owns which phas
 **Medium:** RACE | CARE | BAB | BROKE | CRISPE
 **Comprehensive:** CO-STAR | RISEN | TIDD-EC
 **Data:** RISE-IE | RISE-IX
-**Reasoning:** Plan-and-Solve | Chain of Thought | Least-to-Most | Step-Back | Tree of Thought | RCoT
+**Reasoning:** Plan-and-Solve | Chain of Thought | Least-to-Most | Step-Back | Tree of Thought | RCoT | Self-Consistency
 **Structure/Iteration:** Skeleton of Thought | Chain of Density | Iterative Compression
-**Critique/Quality:** Self-Refine | CAI Critique-Revise | Devil's Advocate | Pre-Mortem
+**Critique/Quality:** Self-Refine | CAI Critique-Revise | Devil's Advocate | Pre-Mortem | Chain-of-Verification
 **Meta/Reverse:** RPEF | Reverse Role Prompting
 **Agentic:** ReAct
 
+**Composable technique (layered onto any framework, not selected between):** Few-shot / in-context examples
+
 ### 4. Clarification Questions
 
 Ask targeted questions (3-5 at a time) based on identified gaps:
@@ -167,6 +179,7 @@ Ask targeted questions (3-5 at a time) based on identified gaps:
 **For Least-to-Most**: The full problem in one statement, paste the material the subproblems must reason over, what is the simplest thing that must be answered first, what does the final answer depend on?
 **For Plan-and-Solve**: The problem with every number, unit, and constraint written out, paste the dataset or figures the calculation runs on if any, which values are given and which must be derived?
 **For Chain of Thought**: The problem with all its conditions stated, paste the code, data, or document to reason over if any, what the reasoning steps should be?
+**For Self-Consistency**: The problem with all its conditions stated, paste the data or figures it runs on if any, what the single final answer should look like so every sampled run ends in a comparable `FINAL ANSWER:` line, how many samples to run and majority-vote over (the paper uses 40; 5-10 is usually enough)?
 **For Chain of Density**: Paste the full document to summarize, the fixed word budget every summary must hit, how many densification passes (the paper uses 5)?
 **For Iterative Compression**: Paste the content to compress, where it should end up (word count, reading level, single paragraph), what should improve on each pass, how many passes and when to stop?
 **For Self-Refine**: Paste the actual draft to improve, which dimensions the critique should cover (clarity, completeness, tone), what would make this output wrong or unusable?
@@ -174,6 +187,7 @@ Ask targeted questions (3-5 at a time) based on identified gaps:
 **For Devil's Advocate**: The position, plan, or decision to attack, paste the proposal or memo that sets it out if you have one, which dimensions the attack should cover?
 **For Pre-Mortem**: The project or decision being analyzed with its team, timeline, and goals, paste the plan or proposal document if you have one, how far in the future the imagined failure should be dated?
 **For RCoT**: The question with every condition and constraint written out, paste the document those conditions come from if any, any implicit requirement not yet written into the question (units, deadlines, exclusions, edge cases) that a correct answer must still satisfy?
+**For Chain-of-Verification**: Paste the draft answer to fact-check if you have one, or the factual question to answer carefully, which specific claims are most at risk of being wrong, what a correct final answer must not get wrong?
 **For RPEF**: Paste the actual output sample to reverse-engineer, paste the input that produced it or confirm it is output-only, which details are one-off specifics that should become [PLACEHOLDER] variables?
 **For Reverse Role**: What you want to achieve in one or two sentences, the domain of expertise to consult, questions one at a time or all at once, should it then do the task or synthesize a structured prompt for you to approve?
 
@@ -191,6 +205,7 @@ Using gathered information:
 2. Map user's information to framework components
 3. Fill missing elements with reasonable defaults — **with two exceptions, below**
 4. Structure according to framework format
+5. **Decide whether worked examples would materially improve the output**; if so, layer in few-shot examples as described in Composable Techniques above — this applies to any framework, not only the two with a built-in examples slot. Reach for it especially on classification, extraction, strict-format, and style-matching tasks, and only when the user or their material supplies real examples.
 
 **Never default a fact about the user's world.** Their business, metrics, history, policies, staff, customers, data, or constraints are things only they know. A plausible-sounding default here is a fabrication the user may not notice before sending — asserting "our first price increase in three years" in an email to paying customers, or inventing a phone number in a published review reply. Where such a slot is unanswered, emit a visible `[you fill this in: <what is needed>]` placeholder and list every placeholder in your analysis section.
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@ckelsoe/prompt-architect",
-  "version": "3.4.0",
-  "description": "Agent skill for analyzing and improving prompts using 29 frameworks across 7 intent categories. Works with Claude Code, Gemini CLI, Cursor, Copilot, and 30+ Agent Skills compatible tools.",
+  "version": "3.5.0",
+  "description": "Agent skill for analyzing and improving prompts using 31 frameworks across 7 intent categories. Works with Claude Code, Gemini CLI, Cursor, Copilot, and 30+ Agent Skills compatible tools.",
   "main": "skills/prompt-architect/SKILL.md",
   "keywords": [
     "claude-code",
@@ -81,7 +81,7 @@
     "type": "skill",
     "skillName": "prompt-architect",
     "skillPath": "skills/prompt-architect",
-    "version": "3.4.0",
+    "version": "3.5.0",
     "compatibility": {
       "claudeCode": ">=1.0.0"
     },
@@ -123,7 +123,9 @@
       "Pre-Mortem",
       "RCoT",
       "RPEF",
-      "Reverse-Role-Prompting"
+      "Reverse-Role-Prompting",
+      "Self-Consistency",
+      "Chain-of-Verification"
     ],
     "features": {
       "promptAnalysis": true,

package/scripts/test.js

@@ -198,6 +198,12 @@ test('Adapter has not drifted from SKILL.md', () => {
     'Never stack more than two',
     'Never default a fact about the user',
     'Never soften or drop a prohibition',
+    // The anti-false-narration guardrail: the model must not invent a rationale
+    // for a framework choice the stripped output cannot show. Lives in both files.
+    'A confident rationale for an unobservable choice',
+    // The few-shot hook must live in the Apply-Framework step of BOTH files, or
+    // the composable technique is documented but never reached at build time.
+    'Decide whether worked examples would materially improve the output',
     // The worked example must demonstrate the emission rules, not violate them.
     // The adapter previously shipped a BAB example with BEFORE:/AFTER:/BRIDGE: headers.
     'Now rewrite the job posting above.',

package/skills/prompt-architect/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: prompt-architect
-description: Analyzes and improves prompts using 29 frameworks across 7 intent categories. Use when a user wants to improve, rewrite, structure, or engineer a prompt — including requests like "help me write a better prompt", "improve this prompt", "what framework should I use", "make this prompt more effective", or any prompt engineering task. Recommends the right framework based on intent (create, transform, reason, critique, recover, clarify, agentic), asks targeted questions, and delivers a structured, high-quality result.
+description: Analyzes and improves prompts using 31 frameworks across 7 intent categories. Use when a user wants to improve, rewrite, structure, or engineer a prompt — including requests like "help me write a better prompt", "improve this prompt", "what framework should I use", "make this prompt more effective", or any prompt engineering task. Recommends the right framework based on intent (create, transform, reason, critique, recover, clarify, agentic), asks targeted questions, and delivers a structured, high-quality result.
 license: MIT
 compatibility: Requires no external dependencies. Works with any Agent Skills compatible tool.
 metadata:
   author: ckelsoe
-  version: "3.4.0"
+  version: "3.5.0"
   homepage: https://github.com/ckelsoe/prompt-architect
 ---
 
@@ -40,7 +40,9 @@ Score the prompt *as written*, not as you charitably interpret it — the gap be
 
 ### 2. Intent-Based Framework Selection
 
-With 29 frameworks, identify the user's **primary intent** first, then use the discriminating questions within that category.
+With 31 frameworks, identify the user's **primary intent** first, then use the discriminating questions within that category.
+
+**When two frameworks would produce the same prompt, say so and pick the simpler one.** Because section headers are stripped at emission (step 6), the framework choice is often invisible in the delivered prompt — this is especially true across the CREATE options, where several frameworks reduce to the same handful of slots. When you cannot point to a concrete difference the *emitted* prompt would show, do not manufacture one: name the tie plainly, choose the simpler framework, and move on. A confident rationale for an unobservable choice is exactly the overstatement this skill exists to remove.
 
 ---
 
@@ -98,6 +100,7 @@ With 29 frameworks, identify the user's **primary intent** first, then use the d
 | Multiple distinct approaches to compare | **Tree of Thought** |
 | Verify reasoning didn't overlook conditions | **RCoT** |
 | Linear step-by-step reasoning | **Chain of Thought** |
+| Answer must be robust; sample many paths and majority-vote | **Self-Consistency** |
 
 ---
 
@@ -110,8 +113,9 @@ With 29 frameworks, identify the user's **primary intent** first, then use the d
 | Find the strongest opposing argument | **Devil's Advocate** |
 | Identify failure modes before they happen | **Pre-Mortem** |
 | Verify reasoning didn't miss conditions | **RCoT** |
+| Draft may contain hallucinated facts; verify each claim | **Chain-of-Verification** |
 
-*Self-Refine = any quality. CAI = principle compliance. Devil's Advocate = opposing arguments. Pre-Mortem = failure analysis. RCoT = condition verification.*
+*Self-Refine = any quality. CAI = compliance with an **explicitly stated** standard or requirement set (and aligning the artifact to it — e.g. auditing a plan against a brief's constraints). Devil's Advocate = opposing arguments. Pre-Mortem = failure analysis. RCoT = an answer or plan overlooked a condition **implicit in the problem** (units, edge cases, unstated dependencies). Chain-of-Verification = independent fact-checking of a draft's factual claims.*
 
 ---
 
@@ -133,6 +137,12 @@ Most prompts need exactly one framework. Combine only when the task genuinely ha
 
 When you combine, load `assets/templates/hybrid_template.txt` and state plainly in your analysis which framework owns which phase. Never stack more than two — beyond that the frameworks' instructions start to overlap and contradict, and no single framework clearly owns any phase.
 
+#### Composable Techniques
+
+Some techniques are not frameworks you choose *between* — they are layers you add *on top of* whichever framework you picked. They answer "how should this prompt be built?", not "which shape is it?", so they never appear in the routing tables above.
+
+- **Few-shot / in-context examples** — showing 2–5 worked input→output examples inside the emitted prompt. This is the highest-leverage technique in prompting and applies to almost any framework, not just the two with a dedicated examples slot (CARE, RISE-IX). After you draft the framework prompt, decide whether examples earn their place; if they do, insert them before the final instruction, in the exact target output format, and end with the actual task. Load `references/techniques/few-shot.md` for when to use it, how many, ordering and recency effects, and the label-space rules — and for the rule that you never invent examples the user or their material did not supply.
+
 ---
 
 ### 3. Framework Quick Reference
@@ -143,12 +153,14 @@ One-line per framework (load `references/frameworks/` for full detail):
 **Medium:** RACE | CARE | BAB | BROKE | CRISPE
 **Comprehensive:** CO-STAR | RISEN | TIDD-EC
 **Data:** RISE-IE | RISE-IX
-**Reasoning:** Plan-and-Solve | Chain of Thought | Least-to-Most | Step-Back | Tree of Thought | RCoT
+**Reasoning:** Plan-and-Solve | Chain of Thought | Least-to-Most | Step-Back | Tree of Thought | RCoT | Self-Consistency
 **Structure/Iteration:** Skeleton of Thought | Chain of Density | Iterative Compression
-**Critique/Quality:** Self-Refine | CAI Critique-Revise | Devil's Advocate | Pre-Mortem
+**Critique/Quality:** Self-Refine | CAI Critique-Revise | Devil's Advocate | Pre-Mortem | Chain-of-Verification
 **Meta/Reverse:** RPEF | Reverse Role Prompting
 **Agentic:** ReAct
 
+**Composable technique (layered onto any framework, not selected between):** Few-shot / in-context examples
+
 ### 4. Clarification Questions
 
 Ask targeted questions (3-5 at a time) based on identified gaps:
@@ -173,6 +185,7 @@ Ask targeted questions (3-5 at a time) based on identified gaps:
 **For Least-to-Most**: The full problem in one statement, paste the material the subproblems must reason over, what is the simplest thing that must be answered first, what does the final answer depend on?
 **For Plan-and-Solve**: The problem with every number, unit, and constraint written out, paste the dataset or figures the calculation runs on if any, which values are given and which must be derived?
 **For Chain of Thought**: The problem with all its conditions stated, paste the code, data, or document to reason over if any, what the reasoning steps should be?
+**For Self-Consistency**: The problem with all its conditions stated, paste the data or figures it runs on if any, what the single final answer should look like so every sampled run ends in a comparable `FINAL ANSWER:` line, how many samples to run and majority-vote over (the paper uses 40; 5-10 is usually enough)?
 **For Chain of Density**: Paste the full document to summarize, the fixed word budget every summary must hit, how many densification passes (the paper uses 5)?
 **For Iterative Compression**: Paste the content to compress, where it should end up (word count, reading level, single paragraph), what should improve on each pass, how many passes and when to stop?
 **For Self-Refine**: Paste the actual draft to improve, which dimensions the critique should cover (clarity, completeness, tone), what would make this output wrong or unusable?
@@ -180,6 +193,7 @@ Ask targeted questions (3-5 at a time) based on identified gaps:
 **For Devil's Advocate**: The position, plan, or decision to attack, paste the proposal or memo that sets it out if you have one, which dimensions the attack should cover?
 **For Pre-Mortem**: The project or decision being analyzed with its team, timeline, and goals, paste the plan or proposal document if you have one, how far in the future the imagined failure should be dated?
 **For RCoT**: The question with every condition and constraint written out, paste the document those conditions come from if any, any implicit requirement not yet written into the question (units, deadlines, exclusions, edge cases) that a correct answer must still satisfy?
+**For Chain-of-Verification**: Paste the draft answer to fact-check if you have one, or the factual question to answer carefully, which specific claims are most at risk of being wrong, what a correct final answer must not get wrong?
 **For RPEF**: Paste the actual output sample to reverse-engineer, paste the input that produced it or confirm it is output-only, which details are one-off specifics that should become [PLACEHOLDER] variables?
 **For Reverse Role**: What you want to achieve in one or two sentences, the domain of expertise to consult, questions one at a time or all at once, should it then do the task or synthesize a structured prompt for you to approve?
 
@@ -197,6 +211,7 @@ Using gathered information:
 2. Map user's information to framework components
 3. Fill missing elements with reasonable defaults — **with two exceptions, below**
 4. Structure according to framework format
+5. **Decide whether worked examples would materially improve the output**; if so, layer in few-shot examples per `references/techniques/few-shot.md` — this applies to any framework, not only the two with a built-in examples slot. Reach for it especially on classification, extraction, strict-format, and style-matching tasks, and only when the user or their material supplies real examples.
 
 **Never default a fact about the user's world.** Their business, metrics, history, policies, staff, customers, data, or constraints are things only they know. A plausible-sounding default here is a fabrication the user may not notice before sending — asserting "our first price increase in three years" in an email to paying customers, or inventing a phone number in a published review reply. Where such a slot is unanswered, emit a visible `[you fill this in: <what is needed>]` placeholder and list every placeholder in your analysis section.
 
@@ -263,9 +278,14 @@ Detailed framework docs in `references/frameworks/`:
 - `rcot.md` - Reverse Chain-of-Thought: verify by reconstructing the question
 - `rpef.md` - Reverse Prompt Engineering: recover prompt from output (EMNLP 2025)
 - `reverse-role.md` - AI-Led Interview: AI asks you questions first (FATA)
+- `self-consistency.md` - Sample N reasoning paths, majority-vote externally (Wang et al., ICLR 2023)
+- `chain-of-verification.md` - Draft, plan checks, verify independently, revise (Dhuliawala et al., Findings of ACL 2024)
 
 Load these when applying specific frameworks for detailed component guidance, selection criteria, and examples.
 
+**Composable techniques** (layered onto a framework, not selected from the routing tables) live in `references/techniques/`:
+- `few-shot.md` - In-context examples: when to add them, how many, ordering, label-space rules
+
 ## Templates
 
 Every framework has a fill-in template at `assets/templates/<framework>_template.txt`, named after the framework's reference doc (e.g. `co-star.md` → `co-star_template.txt`). RISE has two: `rise-ie_template.txt` and `rise-ix_template.txt`. One extra template, `hybrid_template.txt`, is for combined-framework prompts (see **Combining Frameworks**).

package/skills/prompt-architect/assets/templates/chain-of-verification_template.txt

@@ -0,0 +1,26 @@
+SOURCE MATERIAL:
+[Optional — paste the draft answer you want fact-checked here, OR the factual
+question you want answered with verification built in. If you are asking a fresh
+question rather than checking an existing draft, delete this bracketed block and
+the sentence directly below it.]
+Treat the material above as the subject to be verified in the steps below.
+
+Work through the following four steps in order, in a single response.
+
+First, write a baseline answer to the question. Do not polish it — this draft is
+what you will fact-check. (If a draft was supplied above, treat that draft as your
+baseline answer instead of writing a new one.)
+
+Second, list the specific factual claims your draft makes — every name, date,
+quantity, entity, and list member — and write one short verification question for
+each claim. Each question must target one claim and be answerable on its own; do
+not write a single broad question that re-asks the whole task.
+
+Third, answer each verification question independently. Do not look back at your
+draft while answering these questions — answer each one on its own, as if seeing
+it fresh, so your checks are not biased into agreeing with whatever the draft
+already says.
+
+Fourth, write a final verified answer. Keep every claim your independent answers
+confirmed, correct every claim they contradicted, and drop any claim you could
+not verify. Note briefly what changed from the draft.

package/skills/prompt-architect/assets/templates/self-consistency_template.txt

@@ -0,0 +1,12 @@
+PROBLEM:
+[Your question, calculation, or reasoning problem]
+
+SOURCE MATERIAL:
+[Optional — paste the problem data the solution runs on here (the word problem, dataset, table, figures, or constraint list). Delete this line and the one below it if the problem above already states every value needed.]
+The figures and constraints in the material above are authoritative — extract from them rather than from assumed or recalled values.
+
+Solve the problem above. Work through it step by step, showing your reasoning
+at each stage. When you reach an answer, state it on its own line, in exactly
+this form and with nothing else on that line:
+
+FINAL ANSWER: [answer]

package/skills/prompt-architect/references/frameworks/chain-of-verification.md

@@ -0,0 +1,231 @@
+# CoVe (Chain-of-Verification)
+
+## Overview
+
+Chain-of-Verification (CoVe) is a verification framework that reduces hallucinated facts by making the model check its own draft against answers it produces without looking at that draft. The model first writes a baseline response, then plans a set of targeted verification questions aimed at the discrete factual claims the draft makes, then answers those questions independently — crucially without reference to the baseline — and finally regenerates the response, correcting anything the independent answers contradicted. The whole procedure fits inside a single pasted prompt: one response that walks through all four steps in order.
+
+**Origin:** Dhuliawala et al., "Chain-of-Verification Reduces Hallucination in Large Language Models" (arXiv 2309.11495). First posted as a preprint in September 2023, it was published in the **Findings of the Association for Computational Linguistics: ACL 2024** (anthology id 2024.findings-acl.212) — so cite the venue as Findings of ACL **2024**, not 2023. The work is a collaboration: the first author holds a dual affiliation with **ETH Zürich** alongside Meta AI, so it is not accurate to credit Meta AI alone. Note also that the paper's **abstract contains no numbers** — it states qualitatively that CoVe decreases hallucinations across tasks. The frequently quoted precision improvement on list-based Wikidata questions (0.17 to 0.36 for Llama 65B) is a **body figure from the experiments**, not an abstract claim; only present it as a body/table result, and do not attach it to the abstract.
+
+## Why CoVe Works
+
+Hallucinated facts in a baseline draft are internally consistent and fluent, which is exactly why re-reading the draft does not catch them — the model that wrote the error will happily reaffirm it when asked to review its own text. CoVe breaks that loop by structural means rather than by asking harder:
+
+- The draft is decomposed into discrete factual claims, each of which becomes a short, answerable verification question.
+- Each verification question is answered **on its own**, not conditioned on the draft, so the model retrieves the fact fresh instead of echoing what it already wrote.
+- The regenerated answer is forced to reconcile with those independent answers, so contradictions surface as edits.
+
+**The independence of the verification step is the entire mechanism.** If the model answers the verification questions while looking at the baseline, it tends to repeat the baseline's errors — the check collapses into agreement with the thing being checked. The paper studies factored variants (answering verifications separately from the original draft) precisely to preserve this independence, and reports the largest gains when the verification answers are not conditioned on the initial response.
+
+**Limitation:** CoVe targets hallucinated facts — fabricated names, dates, quantities, citations, list members. It is weaker on reasoning that is factually grounded but logically flawed, and it cannot verify a claim the model has no better knowledge of on the second pass than the first.
+
+## Distinction from RCoT
+
+CoVe and RCoT are both verification frameworks in this package, and they address different failure modes with different mechanisms. Keep them separate:
+
+- **RCoT verifies reasoning.** It reconstructs the original question from a candidate answer and cross-checks the reconstruction against the actual question to find overlooked conditions, misinterpreted constraints, and unstated assumptions. Its failure mode is a *missed condition*.
+- **CoVe verifies facts.** It drafts an answer, generates targeted verification questions about the claims in that draft, answers them independently, and revises. Its failure mode is a *hallucinated fact*.
+
+Put plainly: RCoT asks "what question would produce this answer, and does it match what was actually asked?" CoVe asks "which specific claims did I just assert, are they individually true when I check each one cold, and what must change?" Reach for RCoT on multi-condition logic and constraint problems; reach for CoVe on fact-dense output like biographies, entity lists, and cited summaries.
+
+## Components
+
+### Baseline Response
+**Purpose:** Draft an initial answer to the question. This draft is expected to be fluent and may contain hallucinated facts — it is the material to be checked, not the final output.
+
+### Plan Verification Questions
+**Purpose:** Break the draft into its discrete factual claims and turn each into a short, self-contained fact-checking question. Good verification questions are answerable on their own and target one claim each ("In what year was X founded?"), not the draft's conclusion as a whole.
+
+**Trigger:** *"List the specific factual claims your draft makes, then write one short verification question for each claim."*
+
+### Answer Verifications Independently
+**Purpose:** Answer every verification question on its own terms, **without** consulting the baseline draft. This is the step that does the work: answering cold prevents the model from biasing the verification into simply confirming what it already wrote.
+
+**Trigger:** *"Answer each verification question independently. Do not look back at your draft while answering — answer as if seeing each question fresh."*
+
+### Final Verified Response
+**Purpose:** Regenerate the answer, keeping what the independent answers confirmed and correcting anything they contradicted. Discrepancies between the draft and the independent answers become explicit edits.
+
+## Template Structure
+
+Section headers are stripped at emission, so every instruction below has to carry its meaning in prose — the model receives flat text, not a labeled form. The independence requirement is the one thing most easily lost when the `ANSWER VERIFICATIONS` header disappears, so it is written as an explicit "Do not…" sentence inside the step itself, where it survives stripping.
+
+```
+SOURCE MATERIAL:
+[Optional — paste the draft answer you want fact-checked here, OR the factual
+question you want answered with verification built in. If you are asking a fresh
+question rather than checking an existing draft, delete this bracketed block and
+the sentence directly below it.]
+Treat the material above as the subject to be verified in the steps below.
+
+Work through the following four steps in order, in a single response.
+
+First, write a baseline answer to the question. Do not polish it — this draft is
+what you will fact-check.
+
+Second, list the specific factual claims your draft makes (names, dates,
+quantities, entities, list members), and write one short verification question
+for each claim.
+
+Third, answer each verification question independently. Do not look back at your
+draft while answering these questions — answer each one on its own, as if seeing
+it fresh, so your checks are not biased into agreeing with the draft.
+
+Fourth, write a final verified answer. Keep every claim your independent answers
+confirmed, correct every claim they contradicted, and drop any claim you could
+not verify. Note briefly what changed from the draft.
+```
+
+The `SOURCE MATERIAL` block carries no step number because it is optional and holds either of two things: an existing draft to be checked, or the factual question to be answered from scratch with verification built in. When it holds a draft, the first step reviews that draft rather than writing a new one. When there is no draft, delete the block and the sentence beneath it, and the model produces its own baseline in step one.
+
+## Complete Examples
+
+Every example below is shown in emitted form: the step headers are gone and each instruction carries its own role in prose, so nothing is lost when the scaffolding is deleted.
+
+### Example 1: Fact-Checking an Existing Draft (source material supplied)
+
+**Before CoVe:**
+"Is this bio accurate?"
+
+**After CoVe:**
+```
+SOURCE MATERIAL:
+[Paste the draft biography you want fact-checked here]
+Treat the material above as the subject to be verified in the steps below.
+
+Work through the following four steps in order, in a single response.
+
+First, treat the draft above as your baseline answer.
+
+Second, list the specific factual claims the draft makes — every name, date,
+title, place, and quantity — and write one short verification question for each.
+
+Third, answer each verification question independently. Do not look back at the
+draft while answering — answer each question on its own so your checks are not
+biased into confirming what the draft already says.
+
+Fourth, write a corrected version of the bio: keep every claim your independent
+answers confirmed, fix every claim they contradicted, and remove any claim you
+could not verify. List what you changed.
+```
+
+### Example 2: Named-Entity List Question (no source material)
+
+**Before CoVe:**
+"Name some politicians born in New York City."
+
+**After CoVe** (no source material — the answer is generated from scratch, so the
+`SOURCE MATERIAL` block and the sentence below it are both deleted):
+```
+Work through the following four steps in order, in a single response.
+
+First, write a baseline answer listing politicians born in New York City. Do not
+polish it — this draft is what you will fact-check.
+
+Second, for each name on your list, write one short verification question of the
+form "Was [name] born in New York City?"
+
+Third, answer each verification question independently. Do not look back at your
+list while answering — answer each question on its own, so a wrong name on the
+draft does not get waved through.
+
+Fourth, write a final list that keeps only the names your independent answers
+confirmed were born in New York City, and drop the rest. Note which names you
+removed and why.
+```
+
+### Example 3: Cited Factual Summary (source material supplied)
+
+**Before CoVe:**
+"Summarize this article and make sure the numbers are right."
+
+**After CoVe:**
+```
+SOURCE MATERIAL:
+[Paste the article you want summarized here]
+Treat the material above as the subject to be verified in the steps below.
+
+Work through the following four steps in order, in a single response.
+
+First, write a baseline summary of the article above, including its key figures,
+dates, and named parties.
+
+Second, list every factual claim in your summary — each figure, date, and name —
+and write one short verification question for each that can be checked against
+the article.
+
+Third, answer each verification question independently by locating the supporting
+passage in the article. Do not answer from your summary — answer from the source,
+so a number you misremembered while summarizing gets caught.
+
+Fourth, write a final summary in which every figure, date, and name matches what
+you verified against the article. Flag anything the article does not actually
+state.
+```
+
+## Best Use Cases
+
+1. **Fact-Dense Generation**
+   - Biographies, company profiles, historical summaries
+   - Anything where fabricated names, dates, or quantities are the main risk
+
+2. **List and Entity Questions**
+   - "Name all X that Y" questions, where the paper shows the clearest gains
+   - Each list member becomes its own cheap verification question
+
+3. **Cited or Sourced Summaries**
+   - Summaries whose figures must match a supplied document
+   - Verification questions check each figure against the source
+
+4. **A Verification Layer for Draft Output**
+   - Drop CoVe in after any first-pass factual draft
+   - Especially before publishing or sending fact-heavy text
+
+## Selection Criteria
+
+**Choose CoVe when:**
+- ✅ The output is fact-dense and hallucinated details are the main risk
+- ✅ The claims decompose into discrete, individually checkable questions
+- ✅ You are checking a draft you already have, or generating one you don't trust
+- ✅ The model plausibly knows each fact better in isolation than buried in a paragraph
+
+**Avoid CoVe when:**
+- ❌ The failure mode is a missed condition or constraint → use RCoT
+- ❌ The task is reasoning or arithmetic, not factual recall → use Plan-and-Solve or CoT
+- ❌ Facts genuinely require external lookup the model cannot do → use a tool-grounded method (CRITIC)
+- ❌ The task is creative or generative with no facts to verify
+
+## CoVe vs. Other Verification Frameworks
+
+| | CoVe | RCoT | Self-Refine | CRITIC |
+|---|---|---|---|---|
+| Verifies | Facts | Reasoning conditions | General quality | Facts (tool-grounded) |
+| Failure mode caught | Hallucinated facts | Overlooked conditions | Vague weaknesses | Hallucinated facts |
+| Mechanism | Independent re-answering of claims | Question reconstruction | Self-critique then revise | External tool checks |
+| Key requirement | Verification not conditioned on draft | Reconstruct without re-reading question | Honest self-critique | Access to tools |
+| Fits one prompt? | Yes | Yes | Yes | No (needs tool calls) |
+
+## Common Mistakes
+
+1. **Letting the verification see the draft**
+   - This is the cardinal error — if the model answers verification questions while looking at its draft, it confirms its own hallucinations
+   - The "Do not look back at your draft" instruction is load-bearing; do not drop it
+
+2. **Verification questions that are too broad**
+   - "Is this bio accurate?" is not a verification question — it just re-asks the whole task
+   - Each question must target one discrete claim: one name, one date, one figure
+
+3. **Skipping the correction step**
+   - Finding contradictions is not the goal; fixing them is
+   - The final answer must reconcile with the independent answers, not just report the mismatch
+
+4. **Using CoVe where facts aren't the risk**
+   - On reasoning or constraint problems, CoVe's questions have nothing factual to grip; RCoT fits those
+
+## Quick Reference
+
+| Step | Purpose |
+|------|---------|
+| Baseline Response | Draft an initial answer (may contain hallucinations) |
+| Plan Verification Questions | Turn each discrete claim into a short fact-check question |
+| Answer Independently | Answer each question cold — not conditioned on the draft |
+| Final Verified Response | Regenerate, correcting whatever the checks contradicted |

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

@@ -0,0 +1,195 @@
+# Self-Consistency Framework
+
+## Overview
+
+Self-Consistency is a reasoning technique that replaces a single greedy answer with a majority vote over many independently sampled reasoning paths. Instead of asking the model to think step by step once and trust the result, you run the *same* prompt several times at non-zero temperature, collect the final answer from each run, and return the answer that appears most often. The reasoning inside each run still looks like Chain-of-Thought; what changes is that the decision is made across runs rather than within one. The insight is that a correct answer tends to be reachable by several different valid lines of reasoning, while the various ways of being wrong scatter — so agreement across independent samples is itself evidence.
+
+When prompt-architect emits a Self-Consistency prompt, its framework section headers — `PROBLEM:` and `SOURCE MATERIAL:` — are stripped and the model receives a flat block. The solve instruction is written as a complete sentence so it survives on its own, and the `FINAL ANSWER: [answer]` line is a literal output label the model is being told to produce, not a section header, so it stays in place exactly as written. The optional `SOURCE MATERIAL` block holds the data the solution runs on and is deleted when the problem is self-contained.
+
+**Origin:** "Self-Consistency Improves Chain of Thought Reasoning in Language Models" (Wang et al., arXiv 2203.11171, ICLR 2023). The abstract reports the technique's headline gain as a relative delta of **+17.9%** on GSM8K. The corresponding absolute figures — greedy Chain-of-Thought decoding at **56.5%** rising to **74.4%** with a majority vote over 40 sampled paths, using PaLM 540B — are **Table 1** body figures, not abstract figures. A notable finding: the plain, unweighted majority vote matched or beat every weighted aggregation scheme the authors tested, so there is no need to weight votes by probability or confidence.
+
+## How This Framework Is Delivered
+
+Self-Consistency is operational, not a single instruction: the gain comes from *sampling the same prompt N times and voting across the results*. A single pasted prompt cannot run itself N times, so no one prompt can perform the vote on its own. That constraint is handled honestly rather than hidden:
+
+- **The emitted prompt** is a clean solve-prompt. It forces step-by-step reasoning and ends with a machine-parseable `FINAL ANSWER:` line so the outputs of separate runs can be lined up and tallied. It is a single-path prompt by design.
+- **The skill's ANALYSIS section** is where the user is told to run that prompt N times at non-zero temperature and take the majority vote *externally* — in a script, a notebook, or by hand. The voting lives outside the model.
+
+Do not pretend one prompt does the voting. Stating plainly that the aggregation happens outside the model is a feature: it is what keeps the technique faithful to the paper instead of collapsing it into something weaker.
+
+## Components
+
+### The Solve Prompt (emitted)
+**Purpose:** Produce one full reasoning path and one cleanly extractable answer. The prompt demands step-by-step work — the diversity of reasoning across runs is the whole engine, so each run must actually reason rather than guess — and pins the answer to a fixed `FINAL ANSWER: [answer]` line so a program can find it identically in every sample.
+
+**What it must contain:**
+- A complete solve instruction that survives header stripping ("Solve the problem above. Work through it step by step…").
+- The exact terminal line `FINAL ANSWER: [answer]`, with nothing else on that line, so every run's answer sits in the same parseable position.
+- Optionally, a `SOURCE MATERIAL` block naming the data the solution runs on.
+
+### The Sampling Parameters (analysis-side)
+**Purpose:** Generate the independent reasoning paths. The paper samples **40**; in practice **5-10** is usually enough to see the benefit. Sampling must be at **non-zero temperature** — **~0.7** is a reasonable default — because temperature 0 collapses every run to the same greedy path and destroys the diversity the vote depends on.
+
+### The Aggregation (analysis-side)
+**Purpose:** Turn N answers into one. Extract the `FINAL ANSWER:` value from each sample, count how often each distinct answer appears, and return the most frequent one. This is a **plain, unweighted majority vote** — not a confidence-weighted or probability-weighted scheme, both of which the authors found no better. A near-tie is a signal of genuine uncertainty, not an invitation to ask the model to break the tie.
+
+## Template Structure
+
+Section headers — `PROBLEM:` and `SOURCE MATERIAL:` — are stripped at emission, so the solve instruction that follows is written as a complete sentence and survives on its own. The `FINAL ANSWER:` line is a literal output label, not a header, and survives verbatim. The `SOURCE MATERIAL` block is optional and is deleted when the problem already states every value needed.
+
+```
+PROBLEM:
+[Your question, calculation, or reasoning problem]
+
+SOURCE MATERIAL:
+[Optional — paste the problem data the solution runs on here (the word problem, dataset, table, figures, or constraint list). Delete this line and the one below it if the problem above already states every value needed.]
+The figures and constraints in the material above are authoritative — extract from them rather than from assumed or recalled values.
+
+Solve the problem above. Work through it step by step, showing your reasoning
+at each stage. When you reach an answer, state it on its own line, in exactly
+this form and with nothing else on that line:
+
+FINAL ANSWER: [answer]
+```
+
+## Complete Examples
+
+Every example below is shown in emitted form: the solve instruction and the `FINAL ANSWER:` line are the same in each — they are what survives header stripping. Where the reasoning runs on a pasted dataset or constraint list, the `SOURCE MATERIAL` block carries it and the problem refers to "the problem above"; where every value is already in the problem statement, that block is deleted. In every case the emitted artifact is a single-path solve-prompt, and the vote is run afterward per the analysis note.
+
+### Example 1: Math / Word Problem
+
+**Before Self-Consistency:**
+"A shipment has 3 crates of 24 units and 5 crates of 18 units. If 12% are defective, how many good units are there?"
+
+**After Self-Consistency** (no source material — every value is stated in the problem, so the `SOURCE MATERIAL` block is deleted):
+```
+PROBLEM:
+A shipment has 3 crates of 24 units and 5 crates of 18 units. 12% of all
+units are defective. How many good (non-defective) units are there?
+
+Solve the problem above. Work through it step by step, showing your reasoning
+at each stage. When you reach an answer, state it on its own line, in exactly
+this form and with nothing else on that line:
+
+FINAL ANSWER: [answer]
+```
+
+**Analysis note handed to the user:** Run this prompt 5-10 times at temperature ~0.7. Extract each run's `FINAL ANSWER:` value, count them, and return the most frequent. If two answers tie, treat that as real uncertainty and inspect the reasoning rather than asking the model to pick.
+
+### Example 2: Logic / Reasoning Over Pasted Constraints
+
+**Before Self-Consistency:**
+"Given these seating constraints, who sits in seat 3?"
+
+**After Self-Consistency** (source material supplied):
+```
+PROBLEM:
+Determine who sits in seat 3, working only from the constraints in the
+problem above.
+
+SOURCE MATERIAL:
+[Paste the full list of seating constraints — people, seats, and adjacency rules — here]
+The figures and constraints in the material above are authoritative — extract from them rather than from assumed or recalled values.
+
+Solve the problem above. Work through it step by step, showing your reasoning
+at each stage. When you reach an answer, state it on its own line, in exactly
+this form and with nothing else on that line:
+
+FINAL ANSWER: [answer]
+```
+
+### Example 3: Business Calculation
+
+**Before Self-Consistency:**
+"If CAC is $1,200, MRR per customer is $150, and gross margin is 70%, what's the payback period in months?"
+
+**After Self-Consistency** (no source material — every value is stated, so the `SOURCE MATERIAL` block is deleted):
+```
+PROBLEM:
+Customer Acquisition Cost (CAC): $1,200. Average MRR per customer: $150.
+Gross margin: 70%. What is the payback period in months?
+
+Solve the problem above. Work through it step by step, showing your reasoning
+at each stage. When you reach an answer, state it on its own line, in exactly
+this form and with nothing else on that line:
+
+FINAL ANSWER: [answer]
+```
+
+Because a payback-period calculation admits several valid routes — dividing CAC by gross-margin-adjusted MRR, or building up contribution month by month — Self-Consistency is well suited here: independent runs that reach the same number through different arithmetic reinforce the result, and a run that fumbles the margin adjustment is outvoted.
+
+## Best Use Cases
+
+1. **High-Stakes Single Answers**
+   - Numerical problems where one wrong step flips the result
+   - Financial calculations where accuracy is worth the extra compute
+   - Answers you will act on and cannot easily re-check by hand
+
+2. **Problems With Multiple Valid Solution Routes**
+   - Word problems solvable by more than one method
+   - Logic puzzles with several deduction orders
+   - Any task where convergent independent reasoning is meaningful evidence
+
+3. **When Greedy Chain-of-Thought Is Almost Right**
+   - Prior single-path CoT gave inconsistent answers across attempts
+   - The model clearly can solve it but sometimes slips
+   - You can afford N samples and want to buy down the error rate
+
+4. **Discrete, Comparable Answers**
+   - The final answer is a number, a label, or a short choice that can be compared for equality across runs and tallied
+
+## Selection Criteria
+
+**Choose Self-Consistency when:**
+- ✅ The answer is discrete and comparable across runs (a number, a category, a choice)
+- ✅ You can sample the prompt multiple times at non-zero temperature
+- ✅ You can aggregate the results outside the model (script, notebook, or by hand)
+- ✅ Accuracy justifies spending N times the compute of a single run
+- ✅ Single-path CoT is close but not reliable enough
+
+**Avoid Self-Consistency when:**
+- ❌ You can only run the prompt once → use Chain-of-Thought instead
+- ❌ The output is open-ended prose with no comparable "final answer" to vote on
+- ❌ The task needs to explore and keep branching structure → use Tree of Thought
+- ❌ The problem must be decomposed into dependent sub-problems → use Least-to-Most
+- ❌ You need explicit variable extraction and planning within one run → use Plan-and-Solve
+
+## Self-Consistency vs. Chain-of-Thought vs. Tree of Thought
+
+Chain-of-Thought is the single-path neighbor of Self-Consistency: they use the *same* kind of step-by-step reasoning prompt. The distinction is entirely in how the answer is chosen. CoT commits to one path (typically greedy); Self-Consistency samples many CoT paths and lets them vote. Tree of Thought is different again — it explores and prunes a branching search *within* a single run rather than voting across independent runs.
+
+| | Chain-of-Thought | Self-Consistency | Tree of Thought |
+|---|---|---|---|
+| Reasoning paths | One | Many, independently sampled | One branching search |
+| Temperature | Any (often greedy) | Non-zero (~0.7) required | Any |
+| How the answer is chosen | The single run's output | Majority vote across runs | Best surviving branch |
+| Aggregation location | None | Outside the model | Inside the run |
+| Runs needed | 1 | N (5-10 typical; 40 in paper) | 1 |
+| Best for | General step-by-step reasoning | Discrete answers worth N-fold compute | Problems needing lookahead/backtracking |
+
+## Common Mistakes
+
+1. **Asking the model to vote on itself**
+   - Self-Consistency is *not* asking the model to generate several approaches in one response and then judge which it likes best. That is self-assessment — a different and weaker technique, because the model is not a reliable judge of its own reasoning. The vote must happen across independent runs, outside the model.
+
+2. **Sampling at temperature 0**
+   - Greedy decoding produces the same path every time, so N identical runs vote unanimously for one answer and the method reduces to plain CoT with wasted compute. Sampling must be at non-zero temperature.
+
+3. **Weighting the votes**
+   - The paper found an unweighted majority vote matched or beat every weighted scheme tested. Confidence- or probability-weighting adds complexity for no gain.
+
+4. **Omitting or reformatting the FINAL ANSWER line**
+   - If runs end their answers differently, they cannot be extracted and compared programmatically. The `FINAL ANSWER: [answer]` line must appear verbatim, alone on its line, in every run.
+
+5. **Forcing a tie-break**
+   - A near-tie means genuine uncertainty. Asking the model to break it discards the very signal the method surfaced; inspect the split reasoning instead.
+
+## Quick Reference
+
+| Component | Location | Purpose |
+|-----------|----------|---------|
+| Solve prompt | Emitted | One reasoning path plus a parseable `FINAL ANSWER:` line |
+| Step-by-step instruction | Emitted | Forces reasoning so independent paths diverge meaningfully |
+| Sampling (N, temperature) | Analysis-side | Generate independent paths; N≈5-10 (40 in paper), temp ~0.7 |
+| Aggregation | Analysis-side | Plain unweighted majority vote over extracted answers |
+| Tie handling | Analysis-side | Treat near-ties as uncertainty, not as a prompt to break the tie |

package/skills/prompt-architect/references/techniques/few-shot.md

@@ -0,0 +1,121 @@
+# Few-Shot / In-Context Learning (Composable Technique)
+
+## What this is, and why it is not a framework
+
+Few-shot prompting means showing the model a small number of worked examples —
+input paired with the desired output — inside the prompt itself, so it induces the
+pattern rather than working from an instruction alone. It is the single most
+load-bearing prompting technique in general use, and it is deliberately **not** one
+of this skill's routed frameworks.
+
+The reason is structural. A framework answers "how should this request be shaped?"
+and you pick exactly one. Few-shot answers "should this prompt carry examples, and if
+so, which ones and in what order?" — and the answer can be yes for almost any
+framework. It is a **layer**, not a choice. RACE-with-examples, CO-STAR-with-examples,
+and Plan-and-Solve-with-examples are all still RACE, CO-STAR, and Plan-and-Solve. So
+few-shot is applied *on top of* the chosen framework's emitted prompt, never selected
+*instead of* it.
+
+Two frameworks already carry a dedicated examples slot — **CARE** (its `E`) and
+**RISE-IX** (its samples). Few-shot is the discipline of choosing, ordering, and
+formatting those examples well. That discipline applies equally to the many frameworks
+that have no examples slot at all, which is exactly why it lives here as a technique
+instead of inside any one framework.
+
+**Origin:** In-context / few-shot learning was named and popularized by Brown et al.,
+"Language Models are Few-Shot Learners" (arXiv 2005.14165, NeurIPS 2020) — cite that
+paper only for the *term*, not for any benchmark number; its abstract reports model
+scale ("175 billion parameters"), not prompt-construction results. The practical
+guidance below rests on later work that actually measured how example choice changes
+outputs.
+
+## When to add examples — and when not to
+
+Add examples when:
+
+- **The output format is easier to show than to describe.** A specific JSON shape, a
+  table layout, a citation style, a commit-message convention — one example settles
+  what a paragraph of instructions leaves ambiguous.
+- **A consistent structure must repeat** across many outputs (every entry gets the same
+  four fields in the same order).
+- **A voice or style must be matched** and the user can supply samples of it.
+- **The task is classification or extraction with a fixed label set**, where examples
+  pin down the label space and the decision boundary.
+- **Edge cases matter** that an instruction cannot cleanly enumerate — show the tricky
+  input handled correctly.
+
+Do **not** add examples when:
+
+- **The task is open-ended reasoning.** Few-shot examples can lock the model into
+  imitating the *surface pattern* of the examples instead of reasoning freshly;
+  zero-shot chain-of-thought often beats few-shot on novel multi-step problems.
+- **One clear instruction already fixes the output.** Examples are tokens; every one
+  costs context and adds a pattern the model will over-fit to.
+- **You would have to invent the examples.** A fabricated example teaches a fabricated
+  standard. If neither the user nor the source material supplies a real one, prefer a
+  precise instruction — do not manufacture a sample and present it as the target.
+
+## How many, and in what order
+
+- **Count:** 2–5 is the usual working range. Returns diminish fast; more examples is
+  not reliably better, and past a handful the marginal example mostly adds cost and
+  over-fitting risk. Start with the fewest that disambiguate the task.
+- **Order is not neutral.** Models are measurably sensitive to example ordering, and to
+  the point of a strong **recency bias** — the last example carries extra weight (Lu et
+  al., "Fantastically Ordered Prompts…", ACL 2022, arXiv 2104.08786, which reports a 13%
+  relative improvement across eleven text-classification tasks purely from ordering).
+  Put the most representative example last, and do not accidentally sort all of one
+  class to the end.
+
+## What the examples actually teach
+
+- **Format and label *space* teach more than per-example correctness.** Min et al.
+  ("Rethinking the Role of Demonstrations…", EMNLP 2022, arXiv 2202.12837) found that
+  randomly replacing the labels in demonstrations barely hurt performance — what the
+  model reads off the examples is the *shape* of the task: the input distribution, the
+  set of possible answers, and the output format. Practical consequence: keep every
+  example in the **exact** format you want back, and make sure the examples span the
+  real label set. A perfectly-labeled set of examples in the wrong format teaches the
+  wrong thing.
+- **Balance the examples to counter built-in bias.** Zhao et al. ("Calibrate Before
+  Use…", ICML 2021, arXiv 2102.09690) documented majority-label bias, recency bias, and
+  common-token bias — models drift toward whichever label appears most, appears last, or
+  is lexically common (their contextual calibration recovered up to 30.0% absolute on
+  the tasks studied). You will not calibrate logits inside a pasted prompt, but you get
+  most of the benefit for free by **balancing label frequencies** and not stacking
+  same-class examples.
+
+## How it composes with a framework's emitted prompt
+
+Because section headers are stripped at emission (see SKILL.md step 6), examples cannot
+live under an `EXAMPLES:` label that survives — they have to read as part of the flat
+prompt. After the chosen framework's prompt is drafted, and only if examples earn their
+place:
+
+1. Draft the framework prompt as normal.
+2. Insert the examples **before the final instruction**, introduced by a plain prose
+   line the stripped output can keep, e.g. *"Follow the format of these examples:"* —
+   each example showing input and the exact desired output.
+3. End with the actual task so the model acts after seeing the pattern, not before.
+
+Emitted shape (the `Follow the format…` line and the examples are ordinary text in the
+flat block; there are no headers):
+
+```
+[The framework-shaped instruction and context.]
+
+Follow the format of these examples:
+
+Input: <real example input 1>
+Output: <desired output 1, in the exact target format>
+
+Input: <real example input 2>
+Output: <desired output 2>
+
+Now do the same for:
+[Paste the actual input here]
+```
+
+If the user has no real examples to supply and you cannot draw them from pasted source
+material, say so and fall back to a precise instruction rather than inventing samples —
+the same rule the frameworks follow for facts about the user's world.