@ckelsoe/prompt-architect 3.0.0

package/skills/prompt-architect/assets/templates/tidd-ec_template.txt

@@ -0,0 +1,45 @@
+TASK TYPE:
+[Clear indication of the activity type - e.g., Data Analysis, Customer Support Response, Technical Documentation, Content Translation]
+
+INSTRUCTIONS:
+[Specific steps and guidelines to accomplish the task]
+1. [First step or action]
+2. [Second step or action]
+3. [Continue with methodology and sequence]
+4. [Add more steps as needed...]
+
+DO:
+[Specify actions, language, structures, and information that MUST be included]
+- [Required action or element #1]
+- [Language or tone to use]
+- [Structure or format to follow]
+- [Information that must be present]
+- [Add more as needed...]
+
+DON'T:
+[Highlight actions, elements, or approaches to AVOID]
+- [Error or mistake to prevent #1]
+- [Inappropriate language or approach to avoid]
+- [Common pitfall to prevent]
+- [Limitation or boundary not to cross]
+- [Add more as needed...]
+
+EXAMPLES:
+[Provide concrete examples of desired outcomes]
+
+Example 1 (Good):
+[Detailed example showing desired output, format, tone, and structure]
+
+Example 2 (Optional - Additional Good Example):
+[Another example demonstrating quality and approach]
+
+[Optional] Example 3 (What to Avoid):
+[Counter-example showing what NOT to do, if helpful]
+
+CONTEXT:
+[Background information and user-provided content that affects the task]
+- [Relevant background information]
+- [Business or domain constraints]
+- [User-provided data or content to reference]
+- [Situational factors affecting the task]
+- [Standards or guidelines that apply]

package/skills/prompt-architect/assets/templates/tree-of-thought_template.txt

@@ -0,0 +1,30 @@
+PROBLEM:
+[Define what needs to be solved:
+- What decision or problem are we addressing?
+- What constraints apply?
+- What does a good solution need to achieve?]
+
+EXPLORE THESE BRANCHES:
+Branch 1: [Name of approach/strategy]
+Branch 2: [Name of approach/strategy]
+Branch 3: [Name of approach/strategy]
+[Add or remove branches as needed — 2 to 5 is optimal]
+
+For each branch, analyze:
+- Describe the approach
+- Work through the core reasoning
+- Identify key strengths
+- Identify key weaknesses or risks
+- Note any edge cases or assumptions
+
+EVALUATION CRITERIA:
+[Define how branches will be compared:
+- What matters most? (list in priority order)
+- Any hard constraints that eliminate certain branches?
+- Is there one best answer, or does it depend on context?]
+
+CONCLUSION:
+[Synthesize the analysis:
+- Select the best branch with clear reasoning
+- OR explain trade-offs if the answer is context-dependent
+- State the single biggest assumption that could change the recommendation]

package/skills/prompt-architect/references/frameworks/ape.md

@@ -0,0 +1,200 @@
+# APE Framework
+
+## Overview
+
+APE (Action, Purpose, Expectation) is the most minimal structured prompt framework — even simpler than RTF or CTF. It is designed for ultra-quick, single-sentence or two-sentence prompts where adding more structure would be overkill. APE answers three essential questions in the fewest possible words: what to do, why it matters, and what success looks like.
+
+## Components
+
+### A - Action
+**Purpose:** State the core action to take. One clear verb-driven instruction.
+
+**Questions to Ask:**
+- What exactly should happen?
+- What is the deliverable?
+- What's the one thing needed?
+
+**Examples:**
+- "Write a function that..."
+- "Summarize this document..."
+- "Translate the following..."
+- "List three alternatives to..."
+
+### P - Purpose
+**Purpose:** State why this action is needed. Provides just enough context to calibrate the output without a full background brief.
+
+**Questions to Ask:**
+- Why is this needed?
+- What will this be used for?
+- Who needs it and why?
+
+**Examples:**
+- "...so a new engineer can understand the codebase quickly"
+- "...for inclusion in a weekly stakeholder email"
+- "...because our target market is in Brazil"
+- "...to help decide which approach to take"
+
+### E - Expectation
+**Purpose:** Define what a good result looks like. The standard for success.
+
+**Questions to Ask:**
+- What does a good result look like?
+- Any quality bar to meet?
+- Length, format, or tone requirements?
+
+**Examples:**
+- "Should be under 100 words and jargon-free"
+- "Should be actionable, not just descriptive"
+- "Should fit in a single Slack message"
+- "Should have a clear recommendation at the end"
+
+## Template Structure
+
+```
+ACTION: [What to do]
+PURPOSE: [Why it's needed]
+EXPECTATION: [What a good result looks like]
+```
+
+Or as a single sentence:
+```
+[ACTION] so that [PURPOSE], and it should [EXPECTATION].
+```
+
+## Complete Examples
+
+### Example 1: Code Comment
+
+**Before APE:**
+"Add a comment to this function."
+
+**After APE:**
+```
+ACTION: Write a JSDoc comment for this function.
+PURPOSE: So a new team member can understand what it does without reading the implementation.
+EXPECTATION: Should cover parameters, return value, and one usage example. Under 8 lines.
+```
+
+### Example 2: Meeting Summary
+
+**Before APE:**
+"Summarize this meeting."
+
+**After APE:**
+```
+ACTION: Summarize the key decisions and action items from this meeting transcript.
+PURPOSE: For team members who missed the meeting and need to catch up quickly.
+EXPECTATION: Bullet points only, max 10 bullets, each under 15 words.
+```
+
+### Example 3: Alternative Ideas
+
+**Before APE:**
+"Give me options."
+
+**After APE:**
+```
+ACTION: List 3 alternative approaches to the database indexing problem described below.
+PURPOSE: To help the team decide which direction to pursue in tomorrow's planning session.
+EXPECTATION: Each option needs a one-sentence tradeoff (pro and con). No implementation details yet.
+```
+
+### Example 4: Translation
+
+**Before APE:**
+"Translate this."
+
+**After APE:**
+```
+ACTION: Translate the following error message into Portuguese (Brazilian).
+PURPOSE: Our app is launching in Brazil and this error will be seen by end users.
+EXPECTATION: Natural-sounding Brazilian Portuguese, not a literal translation. Keep technical terms in English.
+```
+
+## Best Use Cases
+
+1. **Quick Tasks**
+   - Short code generation
+   - Simple translations
+   - Brief summaries
+   - List generation
+
+2. **When Speed Matters**
+   - Rapid iteration
+   - One-off requests
+   - Low-stakes outputs
+
+3. **When Role Is Obvious**
+   - The AI's role is implied by the action
+   - No persona setup needed
+
+4. **Single-Sentence Prompts Made Better**
+   - Takes any vague one-liner and adds just enough structure
+   - Minimal overhead
+
+## Selection Criteria
+
+**Choose APE when:**
+- ✅ Task is very simple and self-contained
+- ✅ Role/persona is obvious or irrelevant
+- ✅ You want minimum overhead
+- ✅ Quick iteration is needed
+- ✅ Expectation is the missing piece in your current prompt
+
+**Avoid APE when:**
+- ❌ Background/situation matters → use CTF
+- ❌ Expertise framing affects quality → use RTF
+- ❌ Complex multi-step → use RISEN
+- ❌ Audience and tone are critical → use CO-STAR
+- ❌ Transforming existing content → use BAB
+
+## APE vs. RTF vs. CTF
+
+| | APE | CTF | RTF |
+|---|---|---|---|
+| Complexity | Minimal | Simple | Simple |
+| Focus | Action + why + bar | Situation + task + format | Persona + task + format |
+| Role needed? | No | No | Yes |
+| Context needed? | Minimal (Purpose) | Yes | No |
+| Best for | Ultra-quick, one-off | Context-heavy | Expertise-driven |
+
+## Inline APE Pattern
+
+APE works especially well as a single sentence:
+
+```
+[ACTION] for [PURPOSE], and it should [EXPECTATION].
+```
+
+**Examples:**
+```
+Summarize this PR description for a non-technical stakeholder, and it should fit in two sentences.
+```
+```
+List three naming alternatives for this function for a code review discussion, and each should be self-explanatory without comments.
+```
+```
+Write a commit message for these changes for git history, and it should follow conventional commits format.
+```
+
+## Common Mistakes
+
+1. **Skipping Expectation**
+   - Most one-liner prompts have Action but no Expectation
+   - Expectation is what APE adds most value on
+
+2. **Over-engineering Purpose**
+   - Purpose should be one sentence, not a paragraph
+   - If it needs more context, upgrade to CTF
+
+3. **Using APE for Complex Tasks**
+   - If Action has multiple sub-steps, upgrade to RISEN
+   - If Expectation requires detailed format spec, upgrade to RTF
+
+## Quick Reference
+
+| Component | Focus | Key Question |
+|-----------|-------|--------------|
+| Action | What to do | "What should happen?" |
+| Purpose | Why it matters | "Why is this needed?" |
+| Expectation | Success bar | "What does good look like?" |

package/skills/prompt-architect/references/frameworks/bab.md

@@ -0,0 +1,242 @@
+# BAB Framework
+
+## Overview
+
+BAB (Before, After, Bridge) is a transformation-focused framework ideal for rewrite, refactor, and conversion tasks. It explicitly defines the current state, the desired state, and asks for the path between them. Nothing in the standard framework set handles "change this into that" as cleanly as BAB.
+
+## Components
+
+### B - Before
+**Purpose:** Describe the current state — what exists now, what's wrong with it, or what needs to change.
+
+**Questions to Ask:**
+- What is the current state?
+- What problem does it have?
+- What are the limitations?
+- What does it look like right now?
+
+**Examples:**
+- "This function uses nested callbacks and is difficult to read..."
+- "Our homepage copy is written for developers, not customers..."
+- "This README is disorganized with no clear structure..."
+
+### A - After
+**Purpose:** Describe the desired end state — what it should look like once the transformation is complete.
+
+**Questions to Ask:**
+- What should the result look like?
+- What qualities should it have?
+- What problems should be solved?
+- What does success look like?
+
+**Examples:**
+- "...should use async/await and be readable by a junior developer"
+- "...should speak to non-technical buyers who care about outcomes"
+- "...should have a clear structure with quick start and API docs sections"
+
+### B - Bridge
+**Purpose:** Describe how to get from Before to After — the approach, constraints, and rules for the transformation.
+
+**Questions to Ask:**
+- What rules govern the transformation?
+- What must be preserved?
+- What should be changed vs. left alone?
+- Any constraints on approach?
+
+**Examples:**
+- "Preserve all existing functionality, only change syntax"
+- "Keep the same information but reframe for a non-technical audience"
+- "Maintain existing section content, just restructure the order and add missing sections"
+
+## Template Structure
+
+```
+BEFORE:
+[Current state — what exists, what's wrong, what needs to change]
+
+AFTER:
+[Desired state — what it should look like, qualities it should have]
+
+BRIDGE:
+[How to get there — transformation rules, constraints, what to preserve]
+```
+
+## Complete Examples
+
+### Example 1: Code Refactoring
+
+**Before BAB:**
+"Refactor this code."
+
+**After BAB:**
+```
+BEFORE:
+This JavaScript function uses nested callbacks (callback hell) and is difficult
+to read, test, and maintain. It fetches user data, then fetches their orders,
+then fetches order details — all nested three levels deep.
+
+AFTER:
+The same logic implemented using async/await with proper error handling. Should
+be readable by a junior developer who is comfortable with ES6+ but unfamiliar
+with Promises. Each step should be clearly separated and independently testable.
+
+BRIDGE:
+- Preserve all existing functionality and API call structure
+- Replace only the async pattern (callbacks → async/await)
+- Add try/catch error handling at the top level
+- Do not change variable names or data structures
+- Add inline comments explaining the flow
+```
+
+### Example 2: Copy Rewrite
+
+**Before BAB:**
+"Rewrite our landing page."
+
+**After BAB:**
+```
+BEFORE:
+Our current homepage headline reads: "A robust, scalable event-driven
+microservices orchestration platform." It was written by engineers for
+engineers. Conversion rate is poor because our actual buyers are non-technical
+operations managers.
+
+AFTER:
+A headline and 3-sentence description that immediately communicates business
+value to an operations manager. Should answer "what problem does this solve
+for me?" within the first 10 words. Should not use any technical jargon.
+
+BRIDGE:
+- Keep the core value proposition (automation, reliability, scale)
+- Replace technical terms with business outcomes
+- Use active voice and plain language
+- Tone: confident, clear, outcome-focused
+- Length: headline (8 words max) + 2-3 supporting sentences
+```
+
+### Example 3: Documentation Restructure
+
+**Before BAB:**
+"Fix our README."
+
+**After BAB:**
+```
+BEFORE:
+Our README starts with a 500-word technical architecture explanation. New
+contributors can't find the quick start. There is no installation section —
+setup instructions are buried in a wiki link. The API docs section is empty.
+
+AFTER:
+A README that a new contributor can use to be productive within 15 minutes.
+Clear sections, scannable with headers, quick start in the first screen.
+
+BRIDGE:
+- Keep all existing content (do not delete information, only reorganize)
+- Reorder sections: Overview → Quick Start → Installation → Usage → API → Contributing
+- Move architecture explanation to a collapsible section or link to wiki
+- Add a minimal API docs skeleton with TODO placeholders
+- Add a table of contents at the top
+```
+
+### Example 4: Tone Transformation
+
+**Before BAB:**
+"Make this email sound better."
+
+**After BAB:**
+```
+BEFORE:
+This customer complaint response sounds defensive and shifts blame to the
+customer. It uses passive voice and doesn't offer a clear resolution path.
+
+AFTER:
+A response that acknowledges the problem, takes responsibility, and gives the
+customer a clear next step. Should feel warm, professional, and solution-focused.
+
+BRIDGE:
+- Keep the factual information (what happened, timeline)
+- Remove defensive language and blame shifting
+- Add an explicit apology in the first sentence
+- End with a single, specific action item the customer should take
+- Tone: empathetic but professional, not overly apologetic
+- Length: match original (under 150 words)
+```
+
+## Best Use Cases
+
+1. **Code Transformations**
+   - Refactoring (callbacks → async/await, class → functional, etc.)
+   - Language migration
+   - Pattern replacement (e.g., raw SQL → ORM)
+
+2. **Content Rewrites**
+   - Tone changes (technical → business-friendly)
+   - Audience shifts (developers → executives)
+   - Style changes (formal → casual)
+
+3. **Document Restructuring**
+   - README reorganization
+   - Proposal reformatting
+   - Report restructuring
+
+4. **Version Upgrades**
+   - API migration guides
+   - Framework upgrades
+   - Standard/spec changes
+
+5. **Communication Transforms**
+   - Email tone adjustments
+   - Feedback softening
+   - Stakeholder translation
+
+## Selection Criteria
+
+**Choose BAB when:**
+- ✅ You have existing content that needs transformation
+- ✅ There is a clear current state and desired state
+- ✅ Rules for transformation need to be explicit
+- ✅ Something must be preserved while something else changes
+- ✅ The task is "change this into that"
+
+**Avoid BAB when:**
+- ❌ Creating from scratch (no "before" exists) → use CO-STAR, RISEN, or RTF
+- ❌ Reasoning through a problem → use Chain of Thought
+- ❌ Need to specify audience, tone, style in detail → use CO-STAR
+- ❌ Complex multi-step process → use RISEN
+
+## Common Mistakes
+
+1. **Vague Before**
+   - Include specific details about current problems, not just "it's bad"
+   - Quote actual content when possible
+
+2. **Vague After**
+   - Define success criteria explicitly
+   - Include the audience/consumer of the result
+
+3. **Missing Bridge Rules**
+   - Always specify what must be preserved
+   - Define constraints on the transformation approach
+   - State what should NOT change
+
+4. **Using BAB for Net-New Creation**
+   - If there's no "before", use a different framework
+   - BAB requires something to transform
+
+## Quick Reference
+
+| Component | Focus | Key Question |
+|-----------|-------|--------------|
+| Before | Current state | "What exists now / what's wrong?" |
+| After | Desired state | "What should it become?" |
+| Bridge | Transformation rules | "How do we get there?" |
+
+## BAB vs. Other Frameworks
+
+| Situation | Framework |
+|---|---|
+| Transform existing content | **BAB** |
+| Create from scratch for an audience | CO-STAR |
+| Simple task, no transformation | RTF / CTF |
+| Multi-step process | RISEN |
+| Reasoning through a problem | Chain of Thought |