@ckelsoe/prompt-architect 3.3.1 → 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.3.1",
+      "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.3.1",
+  "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,40 @@ 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.
+
+### Added
+- **Optional `SOURCE MATERIAL` block on every template that operates on an artifact.** It names the artifact concretely (never a generic "content"), ties it to the task with one carrier sentence, and self-deletes for from-scratch tasks. Three frameworks are deliberately exempt because they have no pasted-material slot: **ReAct** (material arrives as live tool output), **Reverse Role** (everything is gathered through the interview), and **RISE-IX** (its samples land in the EXAMPLES slot).
+- **Emission-contract test guard.** `scripts/test.js` now fails if the load-bearing output-delivery rules (no section headers in the deliverable, paste-verbatim, "revised prompt is last element", the negation-survival and no-defaulting rules, and the worked example obeying them) diverge between `SKILL.md` and `adapters/system-prompt.md`. The prior drift checks compared only step headings and framework names, so prose drift — like the adapter shipping a BAB example *with* `BEFORE:/AFTER:/BRIDGE:` headers — passed silently.
+
+### Changed
+- **All 28 framework reference docs rewritten for the emission contract.** Each Overview now states how the framework emits; each component's guidance says whether its slot must be a complete sentence or ships inside a carrier sentence; and every Complete Example is shown in emitted form — with the `SOURCE MATERIAL` block, "the … above" references, and at least one from-scratch variant showing the block deleted. Origin/citation facts were preserved verbatim throughout.
+- **Elicitation questions in `SKILL.md` and the adapter now ask for the user's own material** ("Paste the Q3 revenue report here", "paste 2-3 actual samples whose style should be matched") instead of one-word checklists ("Context, audience, tone?"). A framework that operates on an artifact and never asks for it will otherwise invent one. The material-question exemptions above are documented inline.
+- **APE loses its collapsed single-sentence form.** The two inconsistent inline syntaxes it advertised were never implemented by the template and break when source material or multi-clause expectations are present; the doc now explains why. A complete APE prompt is still three sentences.
+- **`RISE` → `RISE-IE` in cross-references.** Docs that pointed to RISE as the input-transformation framework now use the skill's `RISE-IE` shorthand consistently. `RISEN` references are unchanged.
+
+### Fixed
+- **`RACE` examples no longer dangle.** Two examples referenced material "described below" when the `SOURCE MATERIAL` block places it above; they now say "above", matching the template's positioning rule.
+
+---
+
 ## [3.3.1] - 2026-07-19
 
 ### Fixed

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.*
 
 ---
 
@@ -127,7 +131,13 @@ Most prompts need exactly one framework. Combine only when the task genuinely ha
 | Multi-step procedure executed with tools | **RISEN + ReAct** | RISEN specifies the steps and success criteria; ReAct governs the tool-use cycle within each step |
 | Business deliverable with a hostile audience | **BROKE + Devil's Advocate** | BROKE sets objective and key results; Devil's Advocate stress-tests them before they reach a stakeholder |
 
-When you combine, state plainly in your analysis which framework owns which phase. Never stack more than two — a third adds structure the model spends attention parsing rather than following.
+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.
 
 ---
 
@@ -137,61 +147,92 @@ 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:
 
-**For CO-STAR**: Context, audience, tone, style, objective, format?
-**For RISEN**: Role, principles, steps, success criteria, constraints?
-**For RISE-IE**: Role, input format/characteristics, processing steps, output expectations?
-**For RISE-IX**: Role, task instructions, workflow steps, reference examples?
-**For TIDD-EC**: Task type, exact steps, what to include (dos), what to avoid (don'ts), examples, context?
-**For CTF**: What is the situation/background, exact task, output format?
-**For RTF**: Expertise needed, exact task, output format?
-**For APE**: Core action, why it's needed, what success looks like?
-**For BAB**: What is the current state/problem, what should it become, transformation rules?
-**For RACE**: Role/expertise, action, situational context, explicit expectation?
-**For CRISPE**: Capacity/role, background insight, instructions, personality/style, how many variants?
-**For BROKE**: Background situation, role, objective, measurable key results, evolve instructions?
-**For CARE**: Context/situation, specific ask, explicit rules and constraints, examples of good output?
-**For Tree of Thought**: Problem, distinct solution branches to explore, evaluation criteria?
-**For ReAct**: Goal, available tools, constraints and stop condition?
-**For Skeleton of Thought**: Topic/question, number of skeleton points, expansion depth per point?
-**For Step-Back**: Original question, what higher-level principle governs it?
-**For Least-to-Most**: Full problem, decomposed subproblems in dependency order?
-**For Plan-and-Solve**: Problem with all relevant numbers/variables?
-**For Chain of Thought**: Problem, reasoning steps, verification?
-**For Chain of Density**: Source document to summarize, fixed target length, number of iterations?
-**For Iterative Compression**: Content to compress, target length, optimization goal, stopping criterion?
-**For Self-Refine**: Output to improve, feedback dimensions, stop condition?
-**For CAI Critique-Revise**: The principle to enforce, output to critique?
-**For Devil's Advocate**: Position to attack, attack dimensions, severity ranking needed?
-**For Pre-Mortem**: Project/decision, time horizon, domains to analyze?
-**For RCoT**: Question with all conditions, initial answer to verify?
-**For RPEF**: Output sample to reverse-engineer, input data if available?
-**For Reverse Role**: Intent statement, domain of expertise, interview mode (batch vs. conversational)?
+**For CO-STAR**: Paste the material this is built from if any, the situation and constraints behind it, who the audience is and what you want them to do, the tone and style to write in, the output format and length?
+**For RISEN**: Paste the material the procedure runs on if any, the expertise and methodology to adopt, the steps in order, what must be true when it is done, what is out of scope or must not happen?
+**For RISE-IE**: Paste the actual data to be processed (not a description of it), its format and any quirks to expect, the expertise needed, the processing steps in order, what the output must look like?
+**For RISE-IX**: The expertise to embody, what to create and its core requirements, the workflow steps, paste 2-3 actual samples whose style and format the output should match?
+**For TIDD-EC**: Paste the material this task operates on (the message, document, or dataset itself, not a description of it), what kind of task this is and the background that shapes it, the exact steps in order, what must always be included and what must never happen (state each as a prohibition, not a topic), examples of a good result?
+**For CTF**: Paste the artifact this operates on if you have one, the situation and background around it, the exact task and deliverable, the output format?
+**For RTF**: Paste the material the task applies to if any, the expertise needed, the exact task and deliverable, the output format and length?
+**For APE**: Paste the material the action applies to if any, the one action to perform, why it is needed and who uses the result, what a good result looks like?
+**For BAB**: Paste the actual artifact being transformed, what is wrong with it now, what it should become, what rules govern the transformation?
+**For RACE**: Paste the material the task applies to if any, the role and expertise needed, the action to perform, the situational context and audience, what a successful output looks like?
+**For CRISPE**: The expertise and role to embody, paste the data or style sample it should work from, the background it needs, the exact task and deliverable, the tone and how many variants?
+**For BROKE**: Paste the supporting material or performance data if you have it, the current situation and why this task exists, the role to embody, the specific deliverable and the structure and length the response should have, the measurable business outcome it should move?
+**For CARE**: Paste the source document or draft this works from if any, your situation and why this task exists, the specific ask and deliverable, what must be included and what would make this output wrong or unusable, an example of what good looks like?
+**For Tree of Thought**: The decision or problem and its constraints, paste the evidence the branches must be judged against, the 2-5 distinct approaches to compare, the criteria that decide between them?
+**For ReAct**: Does the environment this runs in actually have callable tools — if not, stop and use Chain of Thought instead, which tools are available and how each is invoked, what end state counts as success, what limits apply and when to stop?
+**For Skeleton of Thought**: The topic or question to outline, paste the document, data, or notes the answer must be drawn from if you have any, who the answer is for and what scope it should cover, how far each point should be expanded (a few sentences, a paragraph, full detail)?
+**For Step-Back**: The specific question you want answered, paste the code, document, or design it is about if any, what higher-level principle or concept governs it?
+**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?
+**For CAI Critique-Revise**: Paste the actual output to be critiqued, the specific standard it must satisfy stated precisely enough to be checkable, what would make this output wrong or unusable?
+**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?
+
+Every set above asks for the user's own material, because a framework that operates on an
+artifact and never asks for it will invent one. Three frameworks are deliberately exempt:
+**ReAct** (its material arrives as live tool output, not pasted text), **Reverse Role** (it
+elicits everything through the interview and its template has no material slot), and
+**RISE-IX** (its samples land in the EXAMPLES slot, which its own question already covers).
+Do not add a material question to those three.
 
 ### 5. Apply Framework
 
 Using gathered information:
 1. Apply the appropriate framework structure from your knowledge of the framework
 2. Map user's information to framework components
-3. Fill missing elements with reasonable defaults
+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.
+
+**Never soften or drop a prohibition.** If the user said something must not happen, it must survive into the emitted prompt as an explicit "Do not…" or "Never…" instruction. It cannot rely on a section header to carry the negation, because headers are stripped at emission (see step 6).
 
 ### 6. Present Improvements
 
-Show improved prompt with:
-- Clear before/after comparison
-- Explanation of changes made
+Structure your output in this exact order:
+
+**A. Analysis section** (comes first):
+- Framework selected and why
+- Changes made and reasoning
 - Framework components applied
-- Reasoning for improvements
+
+**B. Usage instructions** (transition block, immediately before the prompt):
+
+> **Your revised prompt is ready.**
+> - **New chat**: Copy the prompt below and paste it as your first message in a new conversation.
+> - **Same chat**: Tell the assistant: *"Use the revised prompt you just provided as a new instruction and execute it."*
+
+**C. The revised prompt** (comes last, in a fenced code block):
+- Present as a clean, flat-text block inside triple backticks
+- **No framework section headers** (no "BEFORE:", "BRIDGE:", "CONTEXT:", etc.) — these are scaffolding, not part of the deliverable
+- **No indentation** beyond what the prompt itself genuinely requires
+- **No markdown formatting** inside the block unless the prompt explicitly needs it (e.g., it asks for tables)
+- The user must be able to copy the entire block contents and paste it verbatim with zero editing — the one exception is `[...]` placeholders for material or facts only the user can supply (see step 5). Keep these to a minimum, make each self-explanatory, and name them in the analysis section so the user knows exactly what to fill in before sending.
+- **Nothing after the code block** — the revised prompt must be the absolute last element in the response. No trailing suggestions, tips, or follow-up text after the closing backticks.
 
 ### 7. Iterate
 
@@ -244,25 +285,25 @@ Frameworks add structure — but structure has overhead. Skip them when:
 **Improved Prompt** (BAB):
 
 ```
-BEFORE (current state):
 [Paste the current job posting here]
-This posting suffers from: corporate-speak, passive voice, overly formal tone,
-and generic language that doesn't reflect actual team culture.
-
-AFTER (desired state):
-A job posting that sounds like it was written by engineers, for engineers.
-Early-career developers should read it and think "I want to work there."
-It should feel honest, direct, and human — not like legal boilerplate.
-
-BRIDGE (transformation rules):
-1. Replace all passive constructions with active voice
-2. Convert corporate jargon to plain English (e.g., "leverage" → "use")
-3. Add one specific, concrete detail about the team/culture per section
-4. Keep all technical requirements and must-haves verbatim
-5. Target reading level: conversational, not academic
-6. Length: same or shorter than original — cut fluff, don't add it
+
+The job posting above suffers from corporate-speak, passive voice, overly formal tone, and generic language that doesn't reflect actual team culture.
+
+The rewritten version should sound like it was written by engineers, for engineers. Early-career developers should read it and think "I want to work there." It should feel honest, direct, and human — not like legal boilerplate.
+
+Follow these rules:
+- Replace all passive constructions with active voice.
+- Convert corporate jargon to plain English (e.g., "leverage" → "use").
+- Add one specific, concrete detail about the team or culture per section.
+- Keep all technical requirements and must-haves verbatim — do not change these.
+- Target reading level: conversational, not academic.
+- Length: same or shorter than the original. Cut fluff, don't add it.
+
+Now rewrite the job posting above.
 ```
 
+Note that the emitted prompt carries no `BEFORE:` / `AFTER:` / `BRIDGE:` headers. The BAB structure shaped what the prompt says; it is not part of what the user receives.
+
 ## Usage Notes
 
 - Always start by analyzing the original prompt

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@ckelsoe/prompt-architect",
-  "version": "3.3.1",
-  "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.3.1",
+    "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

@@ -183,6 +183,38 @@ test('Adapter has not drifted from SKILL.md', () => {
     throw new Error(`Frameworks in SKILL.md but missing from adapter: ${dropped.join(', ')}`);
   }
   void missing;
+
+  // 4. Load-bearing rules must be present in BOTH files.
+  //    Checks 1-3 compare only step headings and framework names, so they cannot
+  //    see prose drift. The adapter shipped without SKILL.md's entire output
+  //    delivery contract -- the rules that define what the skill actually emits --
+  //    while this test passed. Any rule that changes the emitted artifact goes here.
+  const invariants = [
+    'No framework section headers',
+    'scaffolding, not part of the deliverable',
+    'paste it verbatim with zero editing',
+    'the absolute last element in the response',
+    'Your revised prompt is ready.',
+    '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.',
+  ];
+  const divergent = invariants.filter(r => skill.includes(r) !== adapter.includes(r));
+  if (divergent.length > 0) {
+    const detail = divergent
+      .map(r => `${JSON.stringify(r)} (SKILL.md: ${skill.includes(r) ? 'yes' : 'NO'}, adapter: ${adapter.includes(r) ? 'yes' : 'NO'})`)
+      .join('\n  ');
+    throw new Error(`Emission-contract rules differ between SKILL.md and the adapter:\n  ${detail}`);
+  }
 });
 
 // Agent Skills compliance tests