Software Applications: Development Prompts
5 specialized prompts for software engineering - code reviews, documentation, tests, and more
Overview: From Theory to Production
You've built 5 powerful software engineering prompts:
- Unit Test Generator - Comprehensive test coverage fast
- Code Documentation Generator - Auto-document functions and modules
- Git Commit Message Generator - Clear, conventional commits every time
- Code Refactoring Suggester - Identify improvement opportunities
- API Endpoint Designer - Design RESTful endpoints following best practices
Now see them in action across real development workflows. Each scenario includes:
- Before: Traditional manual approach (time + pain points)
- After: Prompt-powered workflow (time + quality improvements)
- Measurable gains: Specific productivity metrics
Duration: 15 minutes per workflow. This section demonstrates realistic productivity gains with measurable time savings and quality improvements.
Workflow 1: Complete Feature Implementation (30 minutes)
Scenario: Add Rate Limiting to Authentication Endpoint
Context: You need to add rate limiting to prevent brute-force attacks on your login API. This requires:
- Designing the rate-limiting mechanism
- Implementing the code
- Writing comprehensive tests
- Documenting the new behavior
- Creating a clear commit
Traditional Approach (120 minutes):
- 30 min: Design rate-limiting strategy, research best practices
- 40 min: Write implementation code
- 30 min: Write unit tests (often incomplete)
- 10 min: Update documentation
- 5 min: Write commit message
- 5 min: Code review prep
Total: 2 hours, often with gaps in test coverage and documentation
Prompt-Powered Workflow (30 minutes)
Design the API (5 minutes)
Use Prompt: API Endpoint Designer
Input:
Design rate limiting for an authentication endpoint. Users should be limited to 5 login attempts per 15-minute window. Need to track attempts, return appropriate errors, and allow for configuration.Output:
ENDPOINTS:
1. POST /auth/login (Modified)
- Purpose: Authenticate user with rate limiting
- Request:
{
"email": "string (valid email)",
"password": "string (min 8 chars)"
}
- Response (200):
{
"token": "string (JWT)",
"expires_at": "string (ISO 8601)"
}
- Error responses:
- 400: Invalid credentials format
- 401: Invalid email/password
- 429: Rate limit exceeded
{
"error": "Too many login attempts",
"retry_after": "number (seconds until reset)",
"attempts_remaining": 0
}
- 500: Server error
2. GET /auth/rate-limit-status (New)
- Purpose: Check rate limit status for debugging
- Response (200):
{
"email": "string",
"attempts_used": "number (0-5)",
"attempts_remaining": "number",
"window_reset_at": "string (ISO 8601)"
}
API DESIGN PRINCIPLES APPLIED:
- HTTP 429 for rate limiting (standard)
- retry_after header for client guidance
- Separate status endpoint for transparency
- Configuration via environment variables
SECURITY CONSIDERATIONS:
- Use Redis for distributed rate limiting
- Track by IP + email to prevent credential stuffing
- Exponential backoff recommended for clients
- Log rate limit violations for monitoringTime saved: 25 minutes of research and design
Quality gain: Standards-compliant, security-conscious design
Implement the Code (10 minutes)
Write implementation:
# src/auth/rate_limiter.py
import redis
from datetime import datetime, timedelta
from typing import Tuple, Optional
class RateLimiter:
"""Rate limiter for authentication attempts."""
def __init__(self, redis_client: redis.Redis,
max_attempts: int = 5,
window_seconds: int = 900):
self.redis = redis_client
self.max_attempts = max_attempts
self.window_seconds = window_seconds
def check_rate_limit(self, identifier: str) -> Tuple[bool, int, Optional[int]]:
"""
Check if identifier is within rate limit.
Returns:
(is_allowed, attempts_remaining, retry_after_seconds)
"""
key = f"rate_limit:auth:{identifier}"
# Get current attempt count
attempts = self.redis.get(key)
if attempts is None:
# First attempt, initialize counter
self.redis.setex(key, self.window_seconds, 1)
return (True, self.max_attempts - 1, None)
attempts = int(attempts)
if attempts >= self.max_attempts:
# Rate limit exceeded
ttl = self.redis.ttl(key)
return (False, 0, ttl)
# Increment and allow
self.redis.incr(key)
return (True, self.max_attempts - attempts - 1, None)
# src/auth/login.py
from fastapi import HTTPException, status
from .rate_limiter import RateLimiter
async def login(email: str, password: str, rate_limiter: RateLimiter):
"""Authenticate user with rate limiting."""
# Check rate limit
identifier = f"{email}" # Could add IP address
is_allowed, attempts_remaining, retry_after = rate_limiter.check_rate_limit(identifier)
if not is_allowed:
raise HTTPException(
status_code=status.HTTP_429_TOO_MANY_REQUESTS,
detail={
"error": "Too many login attempts",
"retry_after": retry_after,
"attempts_remaining": 0
}
)
# Authenticate user (existing logic)
user = authenticate_user(email, password)
if not user:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="Invalid credentials"
)
# Generate token
token = generate_jwt_token(user)
return {
"token": token,
"expires_at": datetime.utcnow() + timedelta(hours=24)
}Generate Comprehensive Tests (5 minutes)
Use Prompt: Unit Test Generator
Input:
def check_rate_limit(self, identifier: str) -> Tuple[bool, int, Optional[int]]:
"""
Check if identifier is within rate limit.
Returns:
(is_allowed, attempts_remaining, retry_after_seconds)
"""
key = f"rate_limit:auth:{identifier}"
attempts = self.redis.get(key)
if attempts is None:
self.redis.setex(key, self.window_seconds, 1)
return (True, self.max_attempts - 1, None)
attempts = int(attempts)
if attempts >= self.max_attempts:
ttl = self.redis.ttl(key)
return (False, 0, ttl)
self.redis.incr(key)
return (True, self.max_attempts - attempts - 1, None)Output:
import pytest
from unittest.mock import Mock, MagicMock
from auth.rate_limiter import RateLimiter
class TestRateLimiter:
"""Test suite for RateLimiter class."""
@pytest.fixture
def redis_mock(self):
"""Mock Redis client."""
return Mock()
@pytest.fixture
def rate_limiter(self, redis_mock):
"""Rate limiter instance with mocked Redis."""
return RateLimiter(redis_mock, max_attempts=5, window_seconds=900)
def test_first_attempt_allowed(self, rate_limiter, redis_mock):
"""First attempt should be allowed and initialize counter."""
redis_mock.get.return_value = None
is_allowed, remaining, retry_after = rate_limiter.check_rate_limit("user@example.com")
assert is_allowed is True
assert remaining == 4
assert retry_after is None
redis_mock.setex.assert_called_once_with(
"rate_limit:auth:user@example.com", 900, 1
)
def test_subsequent_attempt_within_limit(self, rate_limiter, redis_mock):
"""Subsequent attempts within limit should be allowed."""
redis_mock.get.return_value = b"3"
is_allowed, remaining, retry_after = rate_limiter.check_rate_limit("user@example.com")
assert is_allowed is True
assert remaining == 1
assert retry_after is None
redis_mock.incr.assert_called_once_with("rate_limit:auth:user@example.com")
def test_rate_limit_exceeded(self, rate_limiter, redis_mock):
"""Attempts exceeding limit should be blocked."""
redis_mock.get.return_value = b"5"
redis_mock.ttl.return_value = 450
is_allowed, remaining, retry_after = rate_limiter.check_rate_limit("user@example.com")
assert is_allowed is False
assert remaining == 0
assert retry_after == 450
redis_mock.incr.assert_not_called()
def test_exactly_at_limit(self, rate_limiter, redis_mock):
"""Attempt at exactly max_attempts should be blocked."""
redis_mock.get.return_value = b"5"
redis_mock.ttl.return_value = 300
is_allowed, remaining, retry_after = rate_limiter.check_rate_limit("test@test.com")
assert is_allowed is False
assert remaining == 0
assert retry_after == 300
def test_different_identifiers_tracked_separately(self, rate_limiter, redis_mock):
"""Different identifiers should have independent rate limits."""
redis_mock.get.return_value = None
rate_limiter.check_rate_limit("user1@example.com")
rate_limiter.check_rate_limit("user2@example.com")
assert redis_mock.setex.call_count == 2
keys_created = [call[0][0] for call in redis_mock.setex.call_args_list]
assert "rate_limit:auth:user1@example.com" in keys_created
assert "rate_limit:auth:user2@example.com" in keys_created
def test_custom_max_attempts(self, redis_mock):
"""Rate limiter should respect custom max_attempts."""
limiter = RateLimiter(redis_mock, max_attempts=3, window_seconds=900)
redis_mock.get.return_value = None
is_allowed, remaining, _ = limiter.check_rate_limit("user@example.com")
assert remaining == 2 # max_attempts (3) - 1
def test_custom_window_seconds(self, redis_mock):
"""Rate limiter should respect custom window_seconds."""
limiter = RateLimiter(redis_mock, max_attempts=5, window_seconds=600)
redis_mock.get.return_value = None
limiter.check_rate_limit("user@example.com")
redis_mock.setex.assert_called_once_with(
"rate_limit:auth:user@example.com", 600, 1
)
# COVERAGE SUMMARY:
# - Happy path tests: 2 (first attempt, subsequent attempt)
# - Edge case tests: 4 (at limit, exceeded, different identifiers, custom config)
# - Total coverage: ~85%Time saved: 25 minutes of test writing
Quality gain: 8 comprehensive tests covering edge cases
Generate Documentation (3 minutes)
Use Prompt: Code Documentation Generator
Output:
class RateLimiter:
"""
Redis-backed rate limiter for authentication attempts.
Implements a sliding window rate limiting algorithm using Redis for
distributed rate limiting across multiple server instances. Tracks
attempts per identifier (email, IP, or combination) and blocks requests
that exceed the configured threshold.
Attributes:
redis (redis.Redis): Redis client for storing rate limit state
max_attempts (int): Maximum allowed attempts within the time window
window_seconds (int): Time window duration in seconds
Example:
>>> redis_client = redis.Redis(host='localhost', port=6379)
>>> limiter = RateLimiter(redis_client, max_attempts=5, window_seconds=900)
>>>
>>> # Check rate limit for user
>>> allowed, remaining, retry_after = limiter.check_rate_limit("user@example.com")
>>> if not allowed:
... print(f"Rate limited. Retry after {retry_after} seconds")
>>> else:
... print(f"{remaining} attempts remaining")
"""
def check_rate_limit(self, identifier: str) -> Tuple[bool, int, Optional[int]]:
"""
Check if identifier is within rate limit and increment counter.
This method checks the current attempt count for the given identifier
and determines if a new request should be allowed. If allowed, it
increments the counter. The counter automatically expires after
window_seconds.
Args:
identifier (str): Unique identifier to rate limit (email, IP, etc.)
Must be non-empty string.
Returns:
Tuple[bool, int, Optional[int]]: A tuple containing:
- is_allowed (bool): True if request is within rate limit
- attempts_remaining (int): Number of attempts left (0 if blocked)
- retry_after (Optional[int]): Seconds until rate limit resets
(None if allowed, integer if blocked)
Example:
>>> limiter = RateLimiter(redis_client, max_attempts=5, window_seconds=900)
>>>
>>> # First attempt - allowed
>>> allowed, remaining, retry = limiter.check_rate_limit("user@example.com")
>>> print(allowed, remaining) # True, 4
>>>
>>> # After 5 attempts - blocked
>>> allowed, remaining, retry = limiter.check_rate_limit("user@example.com")
>>> print(allowed, retry) # False, 850 (seconds remaining)
Notes:
- Uses Redis SETEX for atomic initialization with expiration
- Uses Redis INCR for atomic increment operations
- Thread-safe and works across distributed systems
"""Time saved: 7 minutes of documentation writing
Quality gain: Complete docstrings with examples
Create Professional Commit (2 minutes)
Use Prompt: Git Commit Message Generator
Input:
Changes:
- Added RateLimiter class with Redis backend
- Modified login endpoint to enforce rate limiting
- Configured max attempts (5) and window (15 min)
- Added rate limit status endpoint for debugging
- Implemented comprehensive unit tests
- Added documentation with examples
- Updated API error responses to include retry_afterOutput:
feat(auth): add Redis-based rate limiting to login endpoint
- Implement RateLimiter class with configurable thresholds
- Enforce 5 attempts per 15-minute window
- Return HTTP 429 with retry_after on limit exceeded
- Add /auth/rate-limit-status debug endpoint
- Include comprehensive unit tests (8 test cases)
- Document all public methods with examples
Prevents brute-force attacks on authentication.
Closes #156Time saved: 3 minutes of commit message crafting
Quality gain: Clear, conventional format that passes CI commit linting
Workflow 1 Results
Time Saved
90 minutes per feature (75% reduction from 120 min to 30 min)
Test Coverage
+25% improvement (from ~60% rushed coverage to ~85% comprehensive)
Documentation
100% improvement in completeness (minimal to complete with examples)
Annual ROI
156 hours/year saved (implementing 2 features per week)
Before (Traditional):
- Time: 120 minutes
- Test coverage: ~60% (rushed, incomplete)
- Documentation: Minimal docstrings
- Commit message: Vague ("Added rate limiting")
After (Prompt-Powered):
- Time: 30 minutes (75% reduction)
- Test coverage: ~85% (comprehensive edge cases)
- Documentation: Complete with examples
- Commit message: Professional, conventional
Workflow 2: Code Review & Refactoring (20 minutes)
Scenario: Inherit Legacy Codebase Module
Context: You're taking over a payment processing module. It works, but the code is messy. You need to understand what it does, identify problems, suggest improvements, and implement refactoring.
Traditional Approach (90 minutes):
- 30 min: Read code, understand logic
- 20 min: Identify code smells manually
- 30 min: Research refactoring patterns
- 10 min: Implement improvements
Prompt-Powered Workflow (20 minutes)
Review the Code (8 minutes)
Use Prompt: Code Refactoring Suggester
Input:
def process_payment(user_id, amount, card_number, expiry, cvv):
if amount <= 0:
return {"error": "Invalid amount"}
if len(card_number) != 16:
return {"error": "Invalid card"}
if len(cvv) != 3:
return {"error": "Invalid CVV"}
# Calculate fee
fee = 0
if amount < 10:
fee = 0.5
elif amount < 100:
fee = amount * 0.05
else:
fee = amount * 0.03
total = amount + fee
# Process payment
try:
stripe_charge = stripe.Charge.create(
amount=int(total * 100),
currency="usd",
source=card_number,
description=f"Payment for user {user_id}"
)
db.execute(f"INSERT INTO payments VALUES ({user_id}, {total}, '{stripe_charge.id}')")
send_email(user_id, f"Payment of ${total} processed")
return {"success": True, "charge_id": stripe_charge.id}
except:
return {"error": "Payment failed"}Output:
CODE SMELLS DETECTED:
1. Smell: SQL injection vulnerability
Location: db.execute line
Impact: Security - CRITICAL
2. Smell: Bare except clause
Location: Exception handling
Impact: Debugging - swallows all errors
3. Smell: Mixed concerns
Location: Entire function
Impact: Maintainability - validation, business logic, persistence, notifications all mixed
4. Smell: Magic numbers
Location: Fee calculation
Impact: Maintainability - hardcoded validation rules
5. Smell: Missing type hints
Location: Function signature
Impact: Maintainability - unclear parameter types
---
REFACTORING RECOMMENDATIONS:
Priority 1 (Critical - affects functionality/security):
1. Fix SQL injection vulnerability
Current code:
db.execute(f"INSERT INTO payments VALUES ({user_id}, {total}, '{stripe_charge.id}')")
Refactored code:
db.execute(
"INSERT INTO payments (user_id, amount, stripe_id) VALUES (?, ?, ?)",
(user_id, total, stripe_charge.id)
)
Benefit: Prevents SQL injection attacks
2. Add specific exception handling
Current code:
except:
return {"error": "Payment failed"}
Refactored code:
except stripe.CardError as e:
logger.error(f"Card error: {e}")
return {"error": f"Card declined: {e.user_message}"}
except stripe.StripeError as e:
logger.error(f"Stripe error: {e}")
return {"error": "Payment processing failed"}
except Exception as e:
logger.exception("Unexpected payment error")
return {"error": "Internal error"}
Benefit: Better error handling, debugging, user feedback
Priority 2 (Important - affects maintainability):
3. Extract fee calculation
4. Separate validation
5. Use data classes for parameters
6. Add type hints
ESTIMATED EFFORT:
- Priority 1: 2 hours (critical, do immediately)
- Priority 2: 3 hours (important, schedule this week)
- Total: 5 hoursTime saved: 20 minutes of manual code review
Quality gain: Security vulnerability caught, systematic improvement plan
Implement Critical Fix (5 minutes)
Fix the SQL injection (Priority 1):
# Before
db.execute(f"INSERT INTO payments VALUES ({user_id}, {total}, '{stripe_charge.id}')")
# After
db.execute(
"INSERT INTO payments (user_id, amount, stripe_id) VALUES (?, ?, ?)",
(user_id, total, stripe_charge.id)
)Generate Tests for Refactored Code (5 minutes)
Use Prompt: Unit Test Generator on the new validation function
def test_validate_payment_valid_request():
"""Valid payment request should pass validation."""
card = Card(number="4242424242424242", expiry="12/25", cvv="123")
result = validate_payment_request(Decimal("50.00"), card)
assert result is None
def test_validate_payment_negative_amount():
"""Negative amount should be rejected."""
card = Card(number="4242424242424242", expiry="12/25", cvv="123")
result = validate_payment_request(Decimal("-10.00"), card)
assert result == "Amount must be positive"
def test_validate_payment_invalid_card_number_length():
"""Card number with wrong length should be rejected."""
card = Card(number="424242", expiry="12/25", cvv="123")
result = validate_payment_request(Decimal("50.00"), card)
assert result == "Card number must be 16 digits"Time saved: 15 minutes of test writing
Quality gain: 100% coverage of validation logic
Document the Refactored Function (2 minutes)
Use Prompt: Code Documentation Generator
Output:
def validate_payment_request(amount: Decimal, card: Card) -> Optional[str]:
"""
Validate payment request parameters before processing.
Performs comprehensive validation of payment amount and card details
to ensure request meets business rules and security requirements.
Args:
amount (Decimal): Payment amount in dollars. Must be positive.
card (Card): Card object containing number, expiry, CVV.
Returns:
Optional[str]: Error message if validation fails, None if valid.
Examples:
>>> card = Card(number="4242424242424242", expiry="12/25", cvv="123")
>>> validate_payment_request(Decimal("50.00"), card)
None
>>> validate_payment_request(Decimal("-10"), card)
'Amount must be positive'
Notes:
- Call this before any payment processing to fail fast
- Does not validate card with payment processor (no network call)
"""Workflow 2 Results
Time Saved
70 minutes per code review (78% reduction from 90 min to 20 min)
Security
Critical vulnerability caught (SQL injection prevented)
Quality Plan
Systematic refactoring with prioritized effort estimates
Annual ROI
182 hours/year saved (reviewing 3 modules per week)
Workflow 3: Documentation Sprint (15 minutes)
Scenario: Document Undocumented Codebase Module
Context: Your team has a 500-line authentication module with zero documentation. New team member starts Monday. You need function-level documentation, module overview, API reference, and usage examples.
Traditional Approach (180 minutes):
- 60 min: Read and understand each function
- 60 min: Write docstrings
- 30 min: Create module-level docs
- 30 min: Write usage examples
Prompt-Powered Workflow (15 minutes)
Document Individual Functions (5 minutes)
Use Prompt: Code Documentation Generator
Input:
def verify_token(token, secret_key):
try:
payload = jwt.decode(token, secret_key, algorithms=["HS256"])
user_id = payload.get("user_id")
expiry = payload.get("exp")
if datetime.utcnow().timestamp() > expiry:
return None
user = db.query("SELECT * FROM users WHERE id = ?", (user_id,))
return user
except jwt.InvalidTokenError:
return NoneOutput (in 30 seconds):
def verify_token(token: str, secret_key: str) -> Optional[User]:
"""
Verify JWT token and return associated user if valid.
Decodes JWT token, validates expiration, and retrieves user from database.
Returns None if token is invalid, expired, or user not found.
Args:
token (str): JWT token string to verify
secret_key (str): Secret key used to sign the token
Returns:
Optional[User]: User object if token valid, None otherwise
Examples:
>>> token = generate_token(user_id=123, secret_key="secret")
>>> user = verify_token(token, "secret")
>>> print(user.id)
123
>>> # Expired token
>>> old_token = "eyJ..."
>>> verify_token(old_token, "secret")
None
Security:
- Validates token signature using secret_key
- Checks token expiration before use
- Returns None rather than exposing error details
"""Repeat for 10 functions = 5 minutes total
Generate Module-Level Documentation (5 minutes)
Use Prompt: Code Documentation Generator (module-level)
Output:
# Authentication Module (auth.py)
## Overview
Provides JWT-based authentication and session management for the application.
Handles token generation/validation, password hashing, and session lifecycle.
## Features
- **JWT Tokens**: HS256-signed tokens with configurable expiration
- **Password Security**: bcrypt hashing with automatic salt generation
- **Session Management**: Database-backed sessions for stateful auth
- **Route Protection**: Decorator-based authentication for endpoints
## Quick Start
```python
from auth import generate_token, verify_token, hash_password, require_auth
# Register user
hashed = hash_password("user_password123")
user_id = db.insert_user(email="user@example.com", password_hash=hashed)
# Login (after password verification)
token = generate_token(user_id, secret_key="your-secret-key")
# Verify token in subsequent requests
user = verify_token(token, secret_key="your-secret-key")
if user:
print(f"Authenticated as {user.email}")
# Protect routes
@require_auth
def get_profile(request):
return {"user_id": request.user.id}Configuration
Set environment variables:
JWT_SECRET_KEY: Secret for signing tokens (required)JWT_EXPIRATION_HOURS: Token lifetime in hours (default: 24)BCRYPT_ROUNDS: Password hashing rounds (default: 12)
Security Considerations
- Store
JWT_SECRET_KEYin environment, never in code - Use HTTPS in production to prevent token interception
- Tokens are stateless - revocation requires session management
- Password hashes use bcrypt with salts (rainbow table resistant)
</Step>
<Step>
### Create Usage Examples (5 minutes)
**Use existing prompts to generate realistic scenarios:**
```python
# Example 1: User registration flow
from auth import hash_password, generate_token
def register_user(email: str, password: str):
"""Register new user with hashed password."""
# Validate password strength
if len(password) < 8:
return {"error": "Password too short"}
# Hash password
password_hash = hash_password(password)
# Store user
user_id = db.execute(
"INSERT INTO users (email, password_hash) VALUES (?, ?)",
(email, password_hash)
).lastrowid
# Generate token for immediate login
token = generate_token(user_id, os.environ["JWT_SECRET_KEY"])
return {
"user_id": user_id,
"token": token,
"expires_in": 86400 # 24 hours
}
# Example 2: Protected API endpoint
from auth import require_auth
@app.get("/api/profile")
@require_auth
def get_user_profile(request):
"""Get current user profile (requires authentication)."""
# request.user populated by @require_auth decorator
user = request.user
return {
"id": user.id,
"email": user.email,
"created_at": user.created_at
}
# Example 3: Token refresh flow
def refresh_token(old_token: str):
"""Issue new token if old token is still valid."""
user = verify_token(old_token, os.environ["JWT_SECRET_KEY"])
if not user:
return {"error": "Invalid or expired token"}
new_token = generate_token(user.id, os.environ["JWT_SECRET_KEY"])
return {
"token": new_token,
"expires_in": 86400
}Workflow 3 Results
Time Saved
165 minutes per module (92% reduction from 180 min to 15 min)
Documentation
Professional docs ready for new team members
Onboarding
Reduced onboarding time with clear examples
Annual ROI
33 hours/year saved (documenting 1 module per month)
Combined Productivity Impact
Total Time Savings Across 3 Workflows:
Prop
Type
Quality Improvements Summary
Beyond time savings, your prompt library delivers measurable quality gains:
Test Coverage
- Before: 60% coverage (rushed, incomplete)
- After: 85%+ coverage (comprehensive edge cases)
- Impact: Fewer production bugs, faster debugging
Documentation Completeness
- Before: Minimal docstrings, no examples
- After: Complete API docs with usage examples
- Impact: Faster onboarding, reduced support questions
Code Quality
- Before: Code smells go unnoticed
- After: Systematic identification and prioritization
- Impact: More maintainable codebase, less technical debt
Security
- Before: Manual review misses vulnerabilities
- After: Prompts flag security issues (SQL injection, etc.)
- Impact: Prevented potential security breaches
Git History
- Before: Vague commits ("Fixed stuff")
- After: Professional, conventional commits
- Impact: Better team collaboration, easier debugging
Success Criteria: Self-Assessment
Check each criterion to verify mastery of software engineering prompt applications:
Workflow Competency
- Can implement a complete feature (design → code → tests → docs → commit) in under 40 minutes
- Can review and refactor legacy code with systematic improvement plan in under 25 minutes
- Can document an entire module comprehensively in under 20 minutes
Prompt Effectiveness
- Unit Test Generator produces 80%+ coverage on first run
- Code Documentation Generator output requires minimal editing
- Git Commit Message Generator passes conventional commit linting
- Code Refactoring Suggester identifies security vulnerabilities
- API Endpoint Designer produces standards-compliant designs
Measurable Impact
- Time saved on feature development: 60%+ reduction
- Test coverage improvement: 20%+ increase
- Documentation completeness: 2× improvement
- Code review thoroughness: Catches security issues
Production Readiness
- Used prompts on at least 3 real work tasks
- Customized at least 1 prompt for team-specific needs
- Shared prompts with teammates
- Prompts integrated into regular development workflow
Target: 12/12 criteria met
Next Steps
Apply to Real Work
Use prompts on your next 3 development tasks and measure impact
Expand Your Library
Add domain-specific prompts for integration tests, architecture decisions, and more
Advanced Applications
Process entire codebases with Claude Projects, automate in CI/CD, build agents
Immediate Actions (This Week)
- Apply to real work: Use prompts on your next 3 development tasks
- Measure impact: Track time saved and quality improvements
- Customize: Adapt prompts for your team's coding standards
- Share: Introduce one prompt to your team
Expand Your Library (This Month)
Add domain-specific prompts for:
- Integration test generation (API endpoint testing)
- Code review checklist generator (team-specific standards)
- Architecture decision records (ADR) writer
- Performance optimization suggester
- Database migration generator
Advanced Applications (Next Quarter)
- T1.2: Use prompts with Claude Projects to process entire codebases
- T2.1: Automate prompts via CLI for CI/CD integration
- T3.2: Build agents that use your prompts as tools
Conclusion
You've now seen your 5 software engineering prompts in action across realistic, production workflows:
- Unit Test Generator - 85% coverage in 5 minutes vs. 30 minutes manually
- Code Documentation Generator - Professional docs in 2 minutes vs. 10 minutes
- Git Commit Message Generator - Conventional commits in 2 minutes vs. 5 minutes
- Code Refactoring Suggester - Systematic improvement plans in 8 minutes vs. 30 minutes
- API Endpoint Designer - Standards-compliant designs in 5 minutes vs. 30 minutes
Total productivity gain: 371 hours/year (9+ weeks of recovered time)
Quality improvements:
- Test coverage: +25%
- Documentation completeness: 2×
- Security vulnerability detection: Critical issues caught
- Code maintainability: Systematic refactoring
You're ready to code faster, better, and more confidently with AI-powered workflows.
Economics Applications: Research-Specific Prompts
5 specialized prompts for economics research - literature reviews, data analysis, citations, and more
Business Applications: Management Prompts
5 specialized prompts for business management - competitive analysis, market sizing, customer insights, and more