@ckelsoe/prompt-architect 3.0.0

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

@@ -0,0 +1,297 @@
+# RISEN Framework
+
+## Overview
+
+RISEN is a methodology-focused framework that emphasizes process, steps, and boundaries. It's ideal for complex multi-step tasks where following a specific procedure matters, and where defining what NOT to do is as important as what to do.
+
+## Components
+
+### R - Role
+**Purpose:** Define the persona, expertise level, or perspective Claude should adopt.
+
+**Questions to Ask:**
+- What expertise should be demonstrated?
+- What perspective is needed?
+- Should Claude adopt a specific persona?
+- What level of knowledge should be shown?
+
+**Examples:**
+- "Act as a senior software architect..."
+- "Take the perspective of a security auditor..."
+- "You are a patient teacher explaining to beginners..."
+
+### I - Instructions
+**Purpose:** Provide high-level guidance, principles, and overarching direction.
+
+**Questions to Ask:**
+- What are the governing principles?
+- What approach should be taken?
+- Are there important guidelines to follow?
+- What methodology should guide the work?
+
+**Examples:**
+- "Follow test-driven development principles..."
+- "Prioritize security over convenience..."
+- "Use clear, simple language throughout..."
+
+### S - Steps
+**Purpose:** Break down the task into detailed, sequential actions.
+
+**Questions to Ask:**
+- What's the exact sequence of actions?
+- What substeps are involved?
+- Are there dependencies between steps?
+- What should happen in what order?
+
+**Examples:**
+- "1. Analyze requirements, 2. Design architecture, 3. Implement core..."
+- "First validate input, then process, finally output..."
+
+### E - End Goal
+**Purpose:** Define success criteria and the final desired outcome.
+
+**Questions to Ask:**
+- What does success look like?
+- What should be true when complete?
+- How will we know it's done correctly?
+- What are the acceptance criteria?
+
+**Examples:**
+- "A fully tested API with 95%+ code coverage..."
+- "A comprehensive report that stakeholders can act on..."
+- "Working code that passes all integration tests..."
+
+### N - Narrowing
+**Purpose:** Set constraints, boundaries, and explicitly state what NOT to do.
+
+**Questions to Ask:**
+- What should be avoided?
+- What's out of scope?
+- What constraints exist?
+- What approaches should NOT be used?
+- What common mistakes to avoid?
+
+**Examples:**
+- "Do NOT use deprecated libraries..."
+- "Avoid premature optimization..."
+- "Stay within the current architecture; don't redesign..."
+
+## Template Structure
+
+```
+ROLE:
+[Expertise, perspective, or persona to adopt]
+
+INSTRUCTIONS:
+[High-level principles and guidance]
+
+STEPS:
+1. [First action]
+2. [Second action]
+3. [Third action]
+[Continue with detailed sequence]
+
+END GOAL:
+[Success criteria and final outcome]
+
+NARROWING:
+- Do NOT: [Constraint 1]
+- Avoid: [Constraint 2]
+- Out of scope: [Constraint 3]
+- Stay within: [Boundary]
+```
+
+## Complete Example
+
+### Before RISEN:
+"Help me review this codebase."
+
+### After RISEN:
+```
+ROLE:
+You are a senior code reviewer with expertise in Python and system security. You have 10+ years of experience identifying vulnerabilities and architectural issues.
+
+INSTRUCTIONS:
+Conduct a thorough security-focused code review following OWASP guidelines. Prioritize identifying security vulnerabilities over style issues. Consider both the code itself and its architectural implications.
+
+STEPS:
+1. Scan for common security vulnerabilities (SQL injection, XSS, auth issues)
+2. Review authentication and authorization logic
+3. Examine data validation and sanitization
+4. Check for sensitive data exposure
+5. Analyze third-party dependencies for known vulnerabilities
+6. Assess error handling and logging practices
+7. Evaluate API security measures
+8. Review configuration and secrets management
+9. Document findings with severity ratings
+10. Provide remediation recommendations
+
+END GOAL:
+A comprehensive security assessment report that:
+- Categorizes vulnerabilities by severity (Critical, High, Medium, Low)
+- Includes specific code references with line numbers
+- Provides concrete remediation steps for each issue
+- Prioritizes fixes by risk and effort
+- Can be shared with development team for action
+
+NARROWING:
+- Do NOT focus on code style or formatting issues
+- Do NOT suggest complete rewrites; focus on targeted fixes
+- Avoid generic security advice; be specific to this codebase
+- Do NOT include theoretical vulnerabilities that don't apply
+- Stay within Python ecosystem; don't suggest language changes
+- Do NOT redesign the architecture; work within current structure
+```
+
+## Best Use Cases
+
+1. **Development Tasks**
+   - Code generation with specific methodology
+   - Refactoring with constraints
+   - Testing with particular approach
+
+2. **Analysis Projects**
+   - Data analysis with defined process
+   - Audits following standards
+   - Research with methodology
+
+3. **Process Documentation**
+   - Creating procedures
+   - Workflow documentation
+   - Standard operating procedures
+
+4. **Complex Multi-Step Tasks**
+   - Tasks with clear sequential dependencies
+   - Projects with important boundaries
+   - Work with specific methodology requirements
+
+## Selection Criteria
+
+**Choose RISEN when:**
+- ✅ Task has clear sequential steps
+- ✅ Process needs to be followed precisely
+- ✅ Multiple approaches exist but one is preferred
+- ✅ Important to define what NOT to do
+- ✅ Role/expertise context matters
+- ✅ Methodology or principles are important
+- ✅ Success criteria need explicit definition
+
+**Avoid RISEN when:**
+- ❌ Task is simple and doesn't need steps
+- ❌ No specific process required
+- ❌ Boundaries and constraints don't matter
+- ❌ Any approach is acceptable
+- ❌ Quick, simple transformation needed
+
+## Common Mistakes
+
+1. **Steps Too High-Level**
+   - Be specific and actionable
+   - Break down complex steps into substeps
+   - Include decision points
+
+2. **Narrowing Too Restrictive**
+   - Don't over-constrain unnecessarily
+   - Focus on important boundaries
+   - Explain why constraints exist
+
+3. **Missing Dependencies**
+   - Note when steps depend on each other
+   - Clarify what needs to complete first
+   - Mention parallel vs. sequential
+
+4. **Vague End Goal**
+   - Make success criteria measurable
+   - Be specific about deliverables
+   - Include quality standards
+
+## Variations and Combinations
+
+### RISEN + CO-STAR
+For procedural tasks with audience considerations:
+```
+ROLE: [From RISEN]
+CONTEXT: [From CO-STAR]
+INSTRUCTIONS: [From RISEN]
+STEPS: [From RISEN]
+END GOAL: [From RISEN]
+AUDIENCE: [From CO-STAR]
+NARROWING: [From RISEN]
+```
+
+### RISEN + Chain of Thought
+For complex reasoning with process:
+```
+[Standard RISEN structure]
+
+Within each step, add:
+REASONING: Think through why and how for this step
+```
+
+### Simplified RISEN (RISE)
+When narrowing isn't critical:
+```
+ROLE:
+INPUT:
+STEPS:
+EXPECTATION:
+```
+
+## Quick Reference
+
+| Component | Focus | Key Question |
+|-----------|-------|--------------|
+| Role | Expertise | "What perspective is needed?" |
+| Instructions | Principles | "What approach should guide this?" |
+| Steps | Process | "What's the exact sequence?" |
+| End Goal | Success | "What defines completion?" |
+| Narrowing | Boundaries | "What should be avoided?" |
+
+## Step Design Best Practices
+
+### Good Steps:
+```
+1. Validate input data against schema (check types, ranges, required fields)
+2. Sanitize user input (escape HTML, strip dangerous chars)
+3. Query database with parameterized statements
+4. Transform results into response format
+5. Log operation with timestamp and user ID
+```
+
+### Poor Steps:
+```
+1. Get the data
+2. Process it
+3. Return results
+```
+
+### Effective Narrowing:
+```
+NARROWING:
+- Do NOT trust user input without validation
+- Avoid loading entire dataset into memory (use pagination)
+- Do NOT use string concatenation for SQL queries
+- Stay within 200ms response time target
+- Avoid external API calls in this phase
+```
+
+### Ineffective Narrowing:
+```
+NARROWING:
+- Be careful
+- Don't make mistakes
+```
+
+## Assessment Checklist
+
+When applying RISEN, verify:
+- [ ] Role defines clear expertise or perspective
+- [ ] Instructions provide guiding principles
+- [ ] Steps are specific, actionable, and sequential
+- [ ] Dependencies between steps are noted
+- [ ] End goal has measurable success criteria
+- [ ] Narrowing identifies important constraints
+- [ ] Narrowing explains why boundaries exist
+- [ ] All steps contribute to end goal
+- [ ] Nothing in narrowing contradicts instructions
+- [ ] Process is feasible and practical

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

@@ -0,0 +1,195 @@
+# Reverse Prompt Engineering Framework (RPEF)
+
+## Overview
+
+Reverse Prompt Engineering (RPEF) inverts the normal prompt-to-output direction. Instead of writing a prompt to get a desired output, you provide an existing output (or input+output pair) and ask the model to reconstruct the reusable prompt template that would consistently produce it. This is the framework for learning from outputs you already like — recovering what made them work.
+
+**Research basis:** Li & Klabjan, "Reverse Prompt Engineering" (arXiv 2411.06729, EMNLP 2025). Practitioner template formalized by inaiwetrust.com as RPEF.
+
+## When to Use RPEF
+
+- You have an output you love and want to reproduce it reliably
+- You want to build a reusable template from a successful one-time result
+- You want to understand why a prompt worked
+- You're trying to approximate a system prompt from observed AI behavior
+- You want to generalize from a specific example to a repeatable pattern
+
+## Components
+
+### Input Sample (optional but powerful)
+**Purpose:** If the output was generated from specific input data, include it. The model uses the relationship between input and output to infer transformation rules and prompt logic.
+
+### Output Sample (required)
+**Purpose:** The existing output you want to reverse-engineer. This is the primary source of truth — what you want to be able to reproduce.
+
+### Analysis Instruction
+**Purpose:** Directs the model to analyze the output for its implicit prompt properties: tone, structure, reasoning style, constraints, format, level of detail, persona, and assumptions.
+
+### Confidence Threshold (optional)
+**Purpose:** Instructs the model to only generate the recovered prompt when confident enough. Default: 80-90%.
+
+### Generalization Directive
+**Purpose:** Specifies whether the recovered prompt should be a specific single-use template or a generalized meta-prompt with fill-in placeholders.
+
+## Template Structure
+
+```
+You are an expert Prompt Engineer performing reverse prompt engineering.
+
+TASK:
+Analyze the following [input and] output. Reconstruct the prompt that would
+consistently produce this type of output. Your recovered prompt should be
+reusable — replace specific details with clearly marked [PLACEHOLDER] variables.
+
+[INPUT DATA (if applicable):]
+[Paste input here, or omit if output-only]
+
+OUTPUT SAMPLE:
+[Paste the output you want to reverse-engineer]
+
+ANALYSIS INSTRUCTIONS:
+Examine the output for:
+- Implied role or persona (who generated this?)
+- Tone and voice (formal, casual, technical, etc.)
+- Structural patterns (how is it organized?)
+- Level of detail and scope
+- Any implicit constraints (what did it not do?)
+- Format conventions (length, sections, bullet style, etc.)
+- Reasoning style (step-by-step, direct, narrative?)
+
+RECOVERED PROMPT:
+Generate a reusable prompt template that would reliably reproduce this
+type of output. Use [PLACEHOLDER] notation for variable elements.
+Only proceed when at least 80% confident in the reconstruction.
+```
+
+## Complete Examples
+
+### Example 1: Recovering a Writing Style
+
+**Scenario:** You got a great product description once and want to reproduce that tone.
+
+```
+You are an expert Prompt Engineer performing reverse prompt engineering.
+
+TASK:
+Analyze the following product description. Reconstruct the prompt that
+would consistently produce this style of writing for other products.
+
+OUTPUT SAMPLE:
+"Mira is the meeting companion that thinks ahead. While you're present
+in the conversation, Mira is quietly capturing every decision, action
+item, and insight — then turning them into a clean summary the moment
+you close your laptop. No more frantic note-taking. No more 'wait, what
+did we decide?' Just clarity, automatically."
+
+ANALYSIS INSTRUCTIONS:
+Examine for: implied persona, tone, structure, what it does vs. doesn't
+say, sentence length patterns, opening hook strategy, implicit audience.
+
+RECOVERED PROMPT:
+Generate a reusable template for writing product descriptions in this style.
+```
+
+**Recovered prompt output:**
+```
+ROLE: You are a B2B SaaS copywriter who specializes in product descriptions
+for productivity tools.
+
+TASK: Write a product description for [PRODUCT NAME], a tool that [CORE FUNCTION].
+
+STYLE RULES:
+- Open with the product name as subject in a short declarative sentence
+- Use "while you [user action], [product] is [working for you]" structure for the value prop
+- Contrast the painful before-state with the effortless after-state
+- No feature lists — benefits only, in plain language
+- End with a 3-word payoff phrase: "[adjective], [adverb]."
+- Target: 3-4 sentences, under 80 words
+- Voice: confident, warm, smart — like a trusted colleague, not a marketer
+```
+
+### Example 2: Recovering an Analysis Format
+
+**Scenario:** A colleague produced a competitive analysis you want to replicate.
+
+```
+You are an expert Prompt Engineer performing reverse prompt engineering.
+
+TASK:
+Analyze the following competitive analysis excerpt. Reconstruct the prompt
+template that produced this format and analytical approach.
+
+INPUT DATA:
+Companies to compare: Notion vs. Confluence vs. Linear
+Use case: Engineering team wiki and documentation
+
+OUTPUT SAMPLE:
+[Paste the analysis here]
+
+ANALYSIS INSTRUCTIONS:
+Identify: comparison dimensions, how trade-offs are framed, what's
+prioritized, how conclusions are drawn, what data is cited vs. inferred.
+
+RECOVERED PROMPT:
+Template should work for any set of tools in any category.
+```
+
+### Example 3: Output-Only Recovery
+
+**Scenario:** You have a great email you wrote with AI assistance but can't find the original prompt.
+
+```
+You are an expert Prompt Engineer.
+
+TASK:
+I have an email I'm happy with but lost the prompt that generated it.
+Reverse-engineer a reusable prompt from the email so I can produce
+similar emails for other clients.
+
+OUTPUT SAMPLE:
+[Paste the email]
+
+RECOVERED PROMPT:
+Create a template with [CLIENT NAME], [SITUATION], and [SPECIFIC REQUEST]
+as placeholder variables. Capture the tone, structure, and approach precisely.
+```
+
+## Best Use Cases
+
+1. **Template Recovery**
+   - Lost prompts that worked well
+   - Successful AI outputs from colleagues or tools
+
+2. **Style Codification**
+   - Turn a one-off great result into a repeatable standard
+   - Establish brand voice templates from approved examples
+
+3. **System Prompt Approximation**
+   - Understanding what instructions produce specific AI behaviors
+   - Debugging AI product behavior
+
+4. **Learning from Excellence**
+   - Study what makes a well-structured prompt by working backwards
+   - Train yourself in prompt engineering by reverse-engineering results
+
+## Selection Criteria
+
+**Choose RPEF when:**
+- ✅ You have an existing output you want to reproduce or templatize
+- ✅ A prompt worked once but you can't replicate it
+- ✅ You want to extract generalizable rules from specific examples
+- ✅ You want to understand *why* an output was good
+
+**Avoid RPEF when:**
+- ❌ You're creating from scratch (no existing output) → use another framework
+- ❌ You want to improve an output → use Self-Refine or BAB
+- ❌ You need requirements gathered first → use Reverse Role Prompting
+
+## Quick Reference
+
+| Component | Purpose |
+|-----------|---------|
+| Input Sample | The input data (if any) that produced the output |
+| Output Sample | The output to reverse-engineer (required) |
+| Analysis Instructions | What dimensions to examine |
+| Recovered Prompt | Reusable template with [PLACEHOLDER] variables |