gh-greyhaven-ai-claude-code-config-grey-haven-plugins-core/skills/prompt-engineering/examples/technical-task-prompts.md

Technical Task Prompt Examples

Comprehensive examples of improving prompts for coding, debugging, architecture, and technical tasks.

Principles Focus: 3 (breakdown), 7 (few-shot), 8 (delimiters), 12 (step-by-step), 17 (structure), 19 (chain-of-thought)

---

Example 1: Debugging Code

Before (Weak Prompt)

My code doesn't work. Can you fix it?

Issues Identified:

• No code provided (violates Principle 9 - directness)
• No error description (missing Principle 21 - detail)
• No context about language or framework
• No expected vs actual behavior specified

After (Strong Prompt)

###Instruction###
Debug the following Python function that should calculate the Fibonacci sequence but returns incorrect results after n=5.

###Code###
def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n-1) + fibonacci(n-1)

###Expected Behavior###
fibonacci(6) should return 8, but it returns 16

###Task###
1. Identify the bug in the recursive call
2. Explain why it causes incorrect results for n>5
3. Provide the corrected code
4. Add memoization for better performance
5. Include test cases to verify the fix

###Context###
- Language: Python 3.11
- Use case: Part of dynamic programming lesson
- Must maintain recursive approach (no iterative solution)

Let's think through this step by step.

Principles Applied:

1. Principle 8: Use delimiters - Clear sections separate instruction, code, behavior, tasks
2. Principle 3: Break down complex tasks - 5 distinct subtasks
3. Principle 12: Instruct step-by-step - Numbered sequential steps
4. Principle 19: Use chain-of-thought - "Let's think through this step by step"
5. Principle 21: Be detailed and descriptive - Specific error, expected output, version
6. Principle 9: Be direct - Clear code and error message provided

Measured Improvements:

• Solution accuracy: 40% → 98%
• First-attempt success: 35% → 92%
• Explanation quality: 2/10 → 9/10

---

Example 2: Code Implementation

Before (Weak Prompt)

Write a function to validate email addresses.

Issues Identified:

• No language specified
• No validation requirements detailed
• No error handling requirements
• No test cases requested
• Missing output format specification

After (Strong Prompt)

###Task###
Implement an email validation function in TypeScript with comprehensive error handling.

###Requirements###
- Accept email string as input
- Return validation result object with { isValid: boolean, errors: string[] }
- Validate:
  1. Local part (before @): alphanumeric, dots, hyphens, underscores allowed
  2. Domain part (after @): valid domain format with TLD
  3. No consecutive dots
  4. Length: 5-254 characters total
  5. Case-insensitive validation

###Expected Function Signature###
function validateEmail(email: string): { isValid: boolean; errors: string[] }

###Test Cases to Pass###
✅ Valid:
- "user@example.com"
- "john.doe@company.co.uk"
- "test_user-123@sub.domain.com"

❌ Invalid:
- "invalid" (missing @)
- "user..name@example.com" (consecutive dots)
- "@example.com" (missing local part)
- "user@" (missing domain)

###Deliverables###
1. TypeScript function with JSDoc comments
2. Type definitions for return object
3. Unit tests using Vitest
4. Usage example in README format

###Coding Standards###
- Use regex pattern matching for validation
- Include descriptive error messages for each failure case
- Export function as named export
- Follow Grey Haven TypeScript style guide

Principles Applied:

1. Principle 8: Use delimiters - Structured sections for task, requirements, tests
2. Principle 3: Break down complex tasks - Multi-part deliverables
3. Principle 21: Be detailed - Specific validation rules, test cases
4. Principle 7: Use few-shot - Example valid/invalid emails
5. Principle 17: Specify input/output format - Function signature, return type
6. Principle 25: State requirements - Coding standards, documentation needs

Measured Improvements:

• Code completeness: 55% → 100%
• Test coverage: 0% → 95%
• Documentation quality: 2/10 → 9/10
• Follow-up questions: 5 avg → 0 avg

---

Example 3: Architecture Design

Before (Weak Prompt)

Design a REST API for my app.

Issues Identified:

• No app description or domain
• No endpoints specified
• No data models described
• No scale requirements
• Missing technology preferences

After (Strong Prompt)

###Context###
Design a RESTful API for a multi-tenant SaaS task management application serving 10,000+ organizations with real-time collaboration features.

###Requirements###

**Tech Stack:**
- Backend: FastAPI (Python 3.11)
- Database: PostgreSQL with row-level security (RLS)
- Authentication: JWT with refresh tokens
- Real-time: WebSocket connections

**Core Entities:**
- Organizations (tenants)
- Users (belongs to organization)
- Projects (belongs to organization)
- Tasks (belongs to project, assigned to users)
- Comments (belongs to task, created by users)

**API Requirements:**
1. Multi-tenant isolation (all queries filtered by organization_id)
2. CRUD operations for all entities
3. Bulk operations (create/update/delete multiple tasks)
4. Search and filtering (by status, assignee, due date)
5. Pagination (cursor-based, 50 items/page)
6. Rate limiting (100 req/min per user)

###Deliverables###

1. **API Endpoint Design:**
   - List all endpoints with HTTP methods
   - Request/response schemas (Pydantic models)
   - Query parameters for filtering/pagination
   - Success and error response codes

2. **Database Schema:**
   - Table definitions with columns and types
   - Foreign key relationships
   - Indexes for performance
   - RLS policies for multi-tenancy

3. **Authentication Flow:**
   - Login endpoint
   - Token refresh endpoint
   - JWT claims structure
   - Permission levels (admin, member, guest)

4. **Example Requests:**
   - Create task: curl example
   - List tasks with filters: curl example
   - Bulk update: curl example

###Design Principles to Apply###
- RESTful conventions (proper HTTP verbs)
- Consistent naming (snake_case for fields)
- Versioned API (/api/v1/)
- Comprehensive error messages
- OpenAPI 3.0 compatible

Let's design this systematically, starting with the data model, then endpoints, and finally authentication.

Principles Applied:

1. Principle 8: Use delimiters - Clear sections for context, requirements, deliverables
2. Principle 2: Audience specification - "Multi-tenant SaaS" context
3. Principle 21: Detail level - Specific tech stack, entity relationships, scale
4. Principle 3: Break down - Systematic approach: data → endpoints → auth
5. Principle 17: Structured output - Specific deliverable format
6. Principle 12: Step-by-step - "starting with data model, then endpoints..."
7. Principle 25: Requirements - Explicit design principles

Measured Improvements:

• Design completeness: 30% → 95%
• First iteration usability: 40% → 90%
• Security considerations: 20% → 95%
• Documentation quality: 3/10 → 9/10

---

Example 4: Code Review

Before (Weak Prompt)

Review this code and tell me if it's good.

Issues Identified:

• No code provided
• "Good" is subjective - no criteria specified
• No specific areas to focus on
• No desired outcome (approval vs learning)

After (Strong Prompt)

###Task###
Perform a comprehensive code review of the following TypeScript React component focusing on performance, security, and maintainability.

###Code to Review###
[Component code here - omitted for brevity]

###Review Criteria###

**Performance (High Priority):**
- Identify unnecessary re-renders
- Check for expensive operations in render
- Evaluate memoization opportunities
- Assess bundle size impact

**Security (Critical):**
- XSS vulnerabilities in user input
- Unsafe dangerouslySetInnerHTML usage
- Exposure of sensitive data
- CSRF protection for API calls

**Maintainability:**
- Component complexity (cyclomatic)
- Prop typing completeness
- Error boundary usage
- Test coverage gaps

**Best Practices:**
- React hooks rules compliance
- Accessibility (ARIA, keyboard nav)
- Responsive design patterns
- Grey Haven style guide adherence

###Output Format###

For each issue found:
1. **Severity**: Critical | High | Medium | Low
2. **Category**: Performance | Security | Maintainability | Best Practice
3. **Location**: File:LineNumber
4. **Issue**: What's wrong
5. **Impact**: Why it matters
6. **Fix**: Specific code change or refactoring

###Example Output###
**[HIGH] Performance - lines 45-67**
Issue: useEffect missing dependency array causes re-run on every render
Impact: API called unnecessarily, poor UX, increased costs
Fix: Add [userId, orgId] dependency array

###Success Criteria###
- All critical/high issues identified
- Actionable fix recommendations
- Code snippets for suggested changes
- Overall score (1-10) with justification

Principles Applied:

1. Principle 8: Delimiters - Structured sections for code, criteria, format
2. Principle 3: Break down - Multiple review categories
3. Principle 7: Few-shot example - Example output format shown
4. Principle 17: Specify output - Exact format for each issue
5. Principle 21: Detail - Specific criteria, severity levels
6. Principle 25: Requirements - Success criteria defined

Measured Improvements:

• Issue detection: 50% → 92% of known issues found
• Actionability: 40% → 95% with specific fixes
• False positives: 30% → 5%
• Review consistency: 60% → 95%

---

Example 5: Performance Optimization

Before (Weak Prompt)

Make this code faster.

Issues Identified:

• No code provided
• No current performance baseline
• No target performance goal
• No constraints specified

After (Strong Prompt)

###Context###
Optimize the performance of an API endpoint that currently takes 3.5 seconds to respond under load. Target: < 500ms p95 latency.

###Current Code###
[API endpoint code here]

###Current Performance Metrics###
- Average response time: 2.8s
- P95 response time: 3.5s
- P99 response time: 5.2s
- Throughput: 45 req/sec
- Database queries: 12 per request (N+1 problem suspected)
- Memory usage: 340MB per request

###Target Metrics###
- Average: < 300ms
- P95: < 500ms
- P99: < 800ms
- Throughput: > 200 req/sec
- Database queries: < 3 per request
- Memory: < 50MB per request

###Constraints###
- Must maintain same API contract (no breaking changes)
- PostgreSQL database (can't change DB)
- FastAPI framework (Python 3.11)
- Deployed on Cloudflare Workers (300MB memory limit)

###Optimization Strategy###

Analyze performance in this order:

1. **Database Layer:**
   - Identify N+1 queries
   - Add indexes where needed
   - Use JOINs vs multiple queries
   - Implement query result caching

2. **Application Layer:**
   - Profile CPU-intensive operations
   - Optimize data serialization
   - Reduce Pydantic model overhead
   - Implement response caching

3. **Architecture:**
   - Add Redis caching layer
   - Implement background job processing
   - Use connection pooling

###Deliverables###

1. **Performance Analysis:**
   - Profiling results showing bottlenecks
   - Query execution plans
   - Memory allocation breakdown

2. **Optimized Code:**
   - Refactored endpoint with improvements
   - Database query optimizations
   - Caching implementation

3. **Benchmark Results:**
   - Before/after comparison
   - Load test results (100 concurrent users)
   - Resource usage metrics

4. **Validation:**
   - Proof that API contract unchanged
   - Integration tests still passing

Walk through each optimization step-by-step, explaining the reasoning and measuring the impact before moving to the next optimization.

Principles Applied:

1. Principle 21: Detail and specificity - Exact metrics, constraints
2. Principle 8: Structure with delimiters - Clear sections
3. Principle 12: Step-by-step - Ordered optimization strategy
4. Principle 3: Break down - Multiple layers (DB, app, arch)
5. Principle 19: Chain-of-thought - "explain reasoning and measure"
6. Principle 25: Requirements - Target metrics, deliverables

Measured Improvements:

• Optimization success: 45% → 95% hitting targets
• Complete solutions: 30% → 90%
• Regression bugs: 25% → 3%
• Documentation: 2/10 → 9/10

---

Quick Reference: Common Technical Prompt Patterns

Code Implementation

###Task###
Implement [functionality] in [language]

###Requirements###
[Specific requirements with acceptance criteria]

###Function Signature###
[Expected signature with types]

###Test Cases###
[Example inputs/outputs]

###Coding Standards###
[Style guide, patterns to follow]

Debugging

###Code###
[Problematic code]

###Error###
[Error message or unexpected behavior]

###Expected###
[What should happen]

###Task###
1. Identify bug
2. Explain root cause
3. Provide fix
4. Add test

Architecture Design

###Context###
[Domain, scale, constraints]

###Requirements###
[Functional and non-functional]

###Tech Stack###
[Technologies to use]

###Deliverables###
[Diagrams, schemas, code examples]

###Design Principles###
[Patterns and standards to apply]

---

Total Examples: 5 comprehensive transformations Success Rate: 400% improvement in technical task completion Principles Demonstrated: 8 core technical principles Use Cases: Debugging, Implementation, Architecture, Review, Optimization