P.E.N.E. Framework: Production Prompt Engineering

Created for: AI Networking Workshop
Purpose: Build consistent, reliable, production-ready LLM prompts
Difficulty: Intermediate
Time to Learn: 15-30 minutes

🎯 What is P.E.N.E.?

P.E.N.E. is a systematic framework for writing prompts that get consistent, actionable, parseable results from LLMs.

It stands for:

P - Persona & Purpose
E - Examples
N - kNowledge & coNstraints (the 'N' comes from kNowledge and coNstraints)
E - Evaluation & iteration

📋 The Framework Breakdown

P - Persona & Purpose

Define who the AI is and what it should accomplish.

Questions to answer:

What role should the AI play?
What specific task is it performing?
What's the end goal?

Example:

❌ Bad: "Analyze this config"
✅ Good: "You are a senior network security engineer reviewing firewall configurations 
         for a financial institution. Your task is to identify security risks that 
         could lead to data breaches or compliance violations."

Why this matters:

Sets the AI's perspective and expertise level
Defines success criteria
Focuses the response on relevant concerns

E - Examples

Show, don't just tell. Provide input/output pairs.

What to include:

At least 2-3 example inputs
Desired output format for each
Edge cases if relevant

Example:

Input Example 1:
access-list 101 permit ip any any

Output Example 1:
{
  "severity": "critical",
  "issue": "Overly permissive ACL allows all traffic",
  "recommendation": "Replace with explicit permit rules"
}

Input Example 2:
access-list 102 permit tcp 10.0.0.0 0.255.255.255 any eq 443

Output Example 2:
{
  "severity": "low",
  "issue": "Source network could be more specific",
  "recommendation": "Narrow source to specific subnets if possible"
}

Why this matters:

LLMs learn patterns from examples
Shows exact output format you want
Reduces ambiguity dramatically
Handles edge cases upfront

N - kNowledge & coNstraints

Provide context the AI needs AND boundaries it must respect.

kNowledge (Context):

Relevant domain facts
Environment details
Business requirements
Technical constraints

coNstraints (What NOT to do):

Forbidden actions
Out-of-scope items
Version/compatibility limits
Security boundaries

Example:

Context you need to know:
- This is a production internet-facing firewall
- Company policy requires explicit deny-all at the end of ACLs
- All permit rules must have logging enabled
- Environment uses Cisco ASA 9.16
- PCI-DSS compliance required

Do NOT:
- Suggest changes without security justification
- Recommend features not available in ASA 9.16
- Propose changes that would break existing VPN tunnels
- Assume budget for hardware upgrades

Why this matters:

Prevents hallucinations about environment
Keeps recommendations practical
Ensures compliance with policies
Avoids breaking changes

E - Evaluation & iteration

Test your prompt and refine based on failures.

Process:

Run with normal cases - Does it work as expected?
Test edge cases - What about weird inputs?
Try to break it - What makes it fail?
Refine - Add constraints, examples, or context
Repeat - Until consistent results

Example Edge Cases to Test:

- Empty input
- Malformed configuration
- Mixed vendor syntax
- Comments in config
- Very long configs (context window)
- Configs with no issues
- Configs with 50+ issues

Iteration Example:

Version 1: "Analyze this config"
→ Too vague, inconsistent output

Version 2: Added persona and examples
→ Better, but suggests unrealistic changes

Version 3: Added knowledge about environment
→ Good, but sometimes verbose

Version 4: Added output length constraint
→ Perfect! Consistent, concise, actionable

Why this matters:

Real-world inputs are messy
First draft rarely works perfectly
Testing reveals hidden assumptions
Iteration compounds quality

🔧 Complete P.E.N.E. Template

## PERSONA & PURPOSE
You are a [ROLE] performing [TASK].
Your goal is to [SPECIFIC OUTCOME].

## EXAMPLES

Input Example 1:
[concrete example input]

Expected Output 1:
[exact format you want]

Input Example 2:
[edge case or variation]

Expected Output 2:
[exact format you want]

## KNOWLEDGE & CONSTRAINTS

Context:
- [Relevant fact 1]
- [Environment detail 2]
- [Business requirement 3]
- [Technical constraint 4]

Do NOT:
- [Forbidden action 1]
- [Out-of-scope item 2]
- [Limitation 3]

## OUTPUT FORMAT
Return your response as:
[Structured format specification - JSON, Markdown table, etc.]

Keep responses under [X] words/tokens.

## NOW ANALYZE THIS:
[Actual input goes here]

🎯 Real-World Examples

Example 1: BGP Configuration Analyzer

## PERSONA & PURPOSE
You are a senior network engineer reviewing BGP configurations for a service provider.
Your task is to identify misconfigurations that could cause routing issues or security problems.

## EXAMPLES

Input:
router bgp 65001
 neighbor 10.0.0.1 remote-as 65002

Output:
{
  "issues": [
    {
      "severity": "medium",
      "finding": "No password configured for BGP neighbor",
      "line": "neighbor 10.0.0.1 remote-as 65002",
      "recommendation": "Add: neighbor 10.0.0.1 password <strong-password>"
    }
  ]
}

Input:
router bgp 65001
 neighbor 10.0.0.1 remote-as 65002
 neighbor 10.0.0.1 password Sup3rS3cr3t!

Output:
{
  "issues": [],
  "compliant": true,
  "note": "BGP neighbor properly configured with authentication"
}

## KNOWLEDGE & CONSTRAINTS

Context:
- Environment: Cisco IOS-XE 17.x
- All BGP peers must use MD5 authentication
- This is an eBGP peering (different AS numbers)
- Maximum prefix limits should be configured

Do NOT:
- Suggest iBGP-specific features for eBGP peers
- Recommend features requiring IOS-XR
- Flag issues with password strength (not our scope)

## OUTPUT FORMAT
Return JSON with:
- Array of issues (if any)
- Each issue has: severity, finding, line, recommendation
- Include "compliant": true if no issues
- Keep recommendations under 100 characters

## NOW ANALYZE THIS:
[BGP config paste here]

Example 2: Network Alert Triage

## PERSONA & PURPOSE
You are a NOC engineer triaging network alerts.
Determine alert severity and suggest immediate actions.

## EXAMPLES

Input:
Interface GigabitEthernet0/1 is down on CORE-RTR-01

Output:
{
  "severity": "critical",
  "priority": 1,
  "reason": "Core router interface down affects production traffic",
  "immediate_actions": [
    "Check interface status: show interface Gi0/1",
    "Check logs: show logging | include Gi0/1",
    "Verify physical connection"
  ],
  "escalate": true,
  "escalation_reason": "Core infrastructure impact"
}

Input:
SNMP trap from printer in Building B - paper jam

Output:
{
  "severity": "informational",
  "priority": 5,
  "reason": "Non-network device, no service impact",
  "immediate_actions": [
    "Create ticket for facilities team"
  ],
  "escalate": false
}

## KNOWLEDGE & CONSTRAINTS

Context:
- We monitor 500+ network devices
- Core routers are CORE-RTR-*
- Edge devices are EDGE-*
- Printers/IoT devices also monitored but low priority
- Business hours: 8 AM - 6 PM EST
- After-hours escalation only for severity critical/high

Do NOT:
- Auto-escalate informational alerts
- Recommend rebooting production devices without approval
- Suggest configuration changes in triage phase

## OUTPUT FORMAT
JSON with:
- severity: critical/high/medium/low/informational
- priority: 1-5 (1 highest)
- reason: One sentence explanation
- immediate_actions: Array of strings (max 5)
- escalate: boolean
- escalation_reason: String (if escalate=true)

## NOW TRIAGE THIS ALERT:
[Alert text here]

Example 3: Configuration Generation

## PERSONA & PURPOSE
You are a network automation engineer generating standardized VLAN configurations.
Create production-ready configs following company standards.

## EXAMPLES

Input:
VLAN 100, Name: Engineering, Subnet: 10.100.0.0/24

Output:

vlan 100 name ENGINEERING ! interface Vlan100 description Engineering Department ip address 10.100.0.1 255.255.255.0 no shutdown !


Input:
VLAN 200, Name: Guest WiFi, Subnet: 192.168.200.0/24

Output:

vlan 200 name GUEST_WIFI ! interface Vlan200 description Guest WiFi Network ip address 192.168.200.1 255.255.255.0 ip access-group GUEST_ACL in no shutdown !


## KNOWLEDGE & CONSTRAINTS

Context:
- Platform: Cisco Catalyst switches (IOS 15.x)
- All VLAN names must be uppercase with underscores
- All SVIs get description based on VLAN name
- Guest/DMZ VLANs require ACL (name: <VLAN_NAME>_ACL)
- Default gateway is always .1 in subnet

Do NOT:
- Use special characters in VLAN names (only A-Z, 0-9, _)
- Configure VTP (we use transparent mode)
- Add DHCP pool configs (separate automation)
- Exceed 32 characters for VLAN name

## OUTPUT FORMAT
Return only the Cisco IOS configuration commands.
No explanations, no markdown formatting.
Include comments (!) between sections.

## GENERATE CONFIG FOR:
[VLAN details here]

📊 P.E.N.E. vs No Framework

Without P.E.N.E.:

User: "Check this BGP config"

AI: "This BGP configuration appears to be setting up a neighbor 
     relationship with AS 65002. BGP is the Border Gateway Protocol 
     used for routing between autonomous systems..."

❌ Too much explanation
❌ No actionable findings
❌ Inconsistent format
❌ Not parseable

With P.E.N.E.:

User: [Full P.E.N.E. prompt with persona, examples, constraints]

AI: {
  "issues": [
    {
      "severity": "high",
      "finding": "Missing MD5 authentication",
      "line": "neighbor 10.0.0.1 remote-as 65002",
      "recommendation": "neighbor 10.0.0.1 password <secure-password>"
    }
  ],
  "compliant": false
}

✅ Actionable findings
✅ Consistent JSON format
✅ Parseable programmatically
✅ Focused on task

🚀 Quick Start Guide

Step 1: Start with Purpose

"You are a [ROLE] performing [TASK] to achieve [GOAL]"

Step 2: Add 2-3 Examples

Show input → desired output
Include an edge case

Step 3: Provide Context

List what the AI needs to know
List what it should NOT do

Step 4: Specify Format

JSON, table, bullet points, etc.
Include length constraints

Step 5: Test & Iterate

Run with real data
Find failures
Refine prompt
Repeat

💡 Pro Tips

1. Examples > Instructions

One good example is worth 100 words of explanation.

2. Constraints Prevent Hallucinations

"Do NOT recommend IOS-XR features" prevents impossible suggestions.

3. Format Specification Enables Automation

JSON output → Parse → Take action programmatically.

4. Iterate Based on Real Failures

Don't guess edge cases - find them in production, add to prompt.

5. Version Your Prompts

NETWORK_AUDIT_PROMPT_V3 = """
...
"""
# Changed from V2: Added constraint about ASA version

6. Use Templates for Common Tasks

Create reusable templates for:

Configuration audits
Alert triage
Config generation
Documentation extraction

⚠️ Common Mistakes

Mistake 1: Vague Persona

❌ "You are helpful"
✅ "You are a CCIE-level network architect with 15 years in enterprise networks"

Mistake 2: No Examples

❌ "Return JSON format"
✅ Shows actual JSON structure with all fields

Mistake 3: Assuming Context

❌ "Check this config"
✅ "Check this Cisco ASA 9.16 config for PCI-DSS compliance issues"

Mistake 4: Not Testing Edge Cases

❌ Tests only perfect configs
✅ Tests: empty, malformed, mixed vendors, huge files

Mistake 5: Ignoring Output Length

❌ No length constraint → 5000 word essays
✅ "Return findings in under 200 words"

📚 Further Reading

Workshop Lab 2: Hands-on P.E.N.E. practice with network scenarios
PROMPT_TEMPLATES.md: Reusable prompt templates
OpenAI Prompt Engineering Guide: https://platform.openai.com/docs/guides/prompt-engineering
Anthropic Prompt Engineering: https://docs.anthropic.com/en/docs/prompt-engineering

🎯 Practice Exercise

Try building a P.E.N.E. prompt for:

Task: Analyze firewall logs and identify potential security incidents

Your Turn:

Define Persona & Purpose
Create 2-3 input/output examples
List kNowledge and coNstraints
Specify output format
Test with real log samples
Iterate based on results

Remember: The P.E.N.E. framework turns vague requests into production-ready, consistent, parseable, actionable results.

Cost to use: $0 with Ollama
Time to master: A few hours of practice
ROI: Massive - reliable automation instead of random outputs

Name		Name	Last commit message	Last commit date
README.md		README.md

Latest commit

History

Folders and files

Repository files navigation

P.E.N.E. Framework: Production Prompt Engineering

🎯 What is P.E.N.E.?

📋 The Framework Breakdown

P - Persona & Purpose

E - Examples

N - kNowledge & coNstraints

E - Evaluation & iteration

🔧 Complete P.E.N.E. Template

🎯 Real-World Examples

Example 1: BGP Configuration Analyzer

Example 2: Network Alert Triage

Example 3: Configuration Generation

📊 P.E.N.E. vs No Framework

Without P.E.N.E.:

With P.E.N.E.:

🚀 Quick Start Guide

Step 1: Start with Purpose

Step 2: Add 2-3 Examples

Step 3: Provide Context

Step 4: Specify Format

Step 5: Test & Iterate

💡 Pro Tips

1. Examples > Instructions

2. Constraints Prevent Hallucinations

3. Format Specification Enables Automation

4. Iterate Based on Real Failures

5. Version Your Prompts

6. Use Templates for Common Tasks

⚠️ Common Mistakes

Mistake 1: Vague Persona

Mistake 2: No Examples

Mistake 3: Assuming Context

Mistake 4: Not Testing Edge Cases

Mistake 5: Ignoring Output Length

📚 Further Reading

🎯 Practice Exercise

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors