A structured way to document and share effective prompts within the organization.
The following template is from the Google Prompt Engineering document, credited to and authored by Lee Boonstra. It was published in February 2025
Comprehensive Prompt Template
This template incorporates best practices for crafting effective prompts, aligning with the Vibe Coding Framework's S.C.A.F.F. methodology.
# Prompt Engineering Template
## Prompt Identification
- **Name**: [Unique identifier for this prompt]
- **Version**: [Version number]
- **Created By**: [Author name]
- **Last Modified**: [Date]
- **Category**: [Component type: Authentication, Data Access, UI, etc.]
## Purpose and Goals
- **Primary Goal**: [Clear description of what this prompt should accomplish]
- **Use Cases**: [Specific scenarios where this prompt is effective]
- **Expected Output**: [What the generated code should include/accomplish]
## Technical Configuration
- **Target Model**: [AI model this prompt was designed for]
- **Parameters**:
* Temperature: [0.0-1.0; lower for factual tasks, higher for creative ones]
* Token Limit: [Maximum tokens in response]
* Top-K: [If applicable]
* Top-P: [If applicable]
## S.C.A.F.F. Structure
### Situation
[Project context, existing architecture, technology stack]
### Challenge
[Specific coding task to be accomplished]
### Audience
[Experience level of developers who will maintain the code]
### Format
[Coding style, patterns, and organization preferences]
### Foundations
[Security requirements, performance considerations, and constraints]
## Examples
[Example inputs/outputs to guide the model]
**Example 1**:
- Input: [Sample requirement]
- Output: [Expected code pattern]
**Example 2**:
- Input: [Sample requirement]
- Output: [Expected code pattern]
## Usage Guidelines
- **For Security-Critical Components**:
- Set temperature: 0.0-0.2
- Include explicit security requirements
- Request detailed documentation of security measures
- **For Performance-Sensitive Components**:
- Specify performance constraints
- Request optimization techniques
- Require complexity analysis
- **For UI Components**:
- Include accessibility requirements
- Specify responsive design needs
- Reference design system patterns
## Effectiveness Metrics
- **Success Rate**: [% of usable outputs on first attempt]
- **Iteration Count**: [Average refinements needed]
- **Issues Found**: [Common issues during verification]
- **Time Savings**: [Estimated time saved vs manual coding]
## Documentation
- **Related Components**: [Links to related components]
- **Security Review**: [Security verification status]
- **Notes and Insights**: [Learnings and special considerations]
- **Improvement History**: [Record of prompt refinements and their effects]
Example Implementation
# Authentication Service Prompt
## Prompt Identification
- **Name**: secure-jwt-authentication-service
- **Version**: 1.2
- **Created By**: Sarah Chen
- **Last Modified**: 2025-03-15
- **Category**: Authentication
## Purpose and Goals
- **Primary Goal**: Generate a secure JWT-based authentication service for REST APIs
- **Use Cases**: User login, registration, password reset, token refresh
- **Expected Output**: Complete authentication service with security best practices
## Technical Configuration
- **Target Model**: Claude 3 Opus
- **Parameters**:
* Temperature: 0.2
* Token Limit: 4000
## S.C.A.F.F. Structure
### Situation
Building a Node.js Express API for an e-commerce application using MongoDB for data storage. The application follows a microservices architecture with separate services for users, products, and orders.
### Challenge
Create a complete authentication service with login, registration, password reset, and token refresh functionality. The service must be secure, scalable, and follow best practices.
### Audience
Mid-level developers familiar with Express but not security experts. The team uses TypeScript and follows clean architecture principles.
### Format
- Use TypeScript with proper interfaces and types
- Follow RESTful API design principles
- Implement controller-service-repository pattern
- Include comprehensive error handling
- Follow team naming conventions (camelCase for variables, PascalCase for classes)
### Foundations
- Must implement OWASP security best practices
- Must use JWT for authentication with refresh tokens
- Must implement proper password hashing with bcrypt (cost factor 12)
- Must include rate limiting (max 100 requests per 15 minutes)
- Must validate all inputs using Joi or Zod
- Must provide comprehensive API documentation
- Must implement proper logging (no sensitive data)
## Examples
**Example 1**:
- Input: User login with email and password
- Output:
```typescript
// Example of expected controller method
async login(req: Request, res: Response): Promise<void> {
try {
const { email, password } = req.body;
// Validate input
const schema = Joi.object({
email: Joi.string().email().required(),
password: Joi.string().min(8).required()
});
const { error } = schema.validate({ email, password });
if (error) {
res.status(400).json({ message: error.details[0].message });
return;
}
// Authenticate user
const user = await this.userService.findByEmail(email);
if (!user) {
res.status(401).json({ message: 'Invalid credentials' });
return;
}
const isPasswordValid = await bcrypt.compare(password, user.password);
if (!isPasswordValid) {
// Update failed attempt count
await this.userService.incrementLoginAttempts(user.id);
res.status(401).json({ message: 'Invalid credentials' });
return;
}
// Generate tokens
const accessToken = this.tokenService.generateAccessToken(user);
const refreshToken = this.tokenService.generateRefreshToken(user);
// Store refresh token
await this.tokenService.saveRefreshToken(user.id, refreshToken);
// Send response
res.status(200).json({
accessToken,
refreshToken,
expiresIn: 900 // 15 minutes
});
} catch (error) {
logger.error('Login error', { error: error.message });
res.status(500).json({ message: 'Internal server error' });
}
}
Usage Guidelines
Set temperature to 0.2 for security-critical code
Include test cases for all authentication paths
Request explicit error handling for all edge cases
Specify rate limiting parameters based on environment
Effectiveness Metrics
Success Rate: 85% usable on first attempt
Iteration Count: Typically 1-2 refinements needed
Issues Found: Occasionally misses CSRF protection
Time Savings: Approximately 3-4 hours per implementation
Documentation
Related Components: user-service, email-service
Security Review: Approved by security team on 2025-03-20
Notes and Insights: Adding explicit CSRF protection requirements improves results
Improvement History:
v1.0: Initial version
v1.1: Added rate limiting requirements
v1.2: Added refresh token rotation for improved security
## Implementation Guidelines
When creating prompt library entries for your organization:
1. **Standardize Categories**: Create a consistent categorization system for different prompt types
2. **Version Control**: Track changes to prompts over time with proper versioning
3. **Effectiveness Tracking**: Document the success rate and refinements needed
4. **Security Focus**: Always include explicit security requirements for all components
5. **Knowledge Sharing**: Include notes and insights to help other team members
6. **Continuous Improvement**: Regularly update prompts based on verification findings
The prompt library should be maintained in a central, accessible location for all team members, with proper access controls for sensitive prompts. Consider implementing a review process for critical prompt templates to ensure quality and security.