7.9 KiB
7.9 KiB
Technical Task Prompt Template
Reusable template for code, debugging, architecture, and technical tasks.
Principles Applied: 3, 7, 8, 12, 17, 19, 21, 25
Template: Code Implementation
###Task###
Implement [functionality description] in [language/framework]
###Requirements###
**Functional:**
- [Feature requirement 1]
- [Feature requirement 2]
- [Feature requirement 3]
**Technical:**
- Language: [version]
- Framework: [if applicable]
- Must support: [constraints]
- Must handle: [edge cases]
###Function Signature### (if applicable)
[Expected signature with types]
```[language]
[signature here]
###Examples### Input: [example input] Output: [expected output]
Input: [edge case] Output: [expected behavior]
###Test Cases### ✅ Valid cases:
- [case 1]
- [case 2]
❌ Invalid cases (should handle):
- [case 1]
- [case 2]
###Coding Standards###
- Style: [style guide to follow]
- Naming: [conventions]
- Comments: [documentation level]
- Error handling: [approach]
###Deliverables###
- [Specific output 1]
- [Specific output 2]
- [Specific output 3]
**Use When:**
- Implementing new features
- Creating utilities or helpers
- Building components
**Example Usage:**
```markdown
###Task###
Implement email validation function in TypeScript with comprehensive error messages
###Requirements###
**Functional:**
- Validate email format (RFC 5322)
- Return detailed validation result
- Support internationalized domains
**Technical:**
- Language: TypeScript 5.3
- Framework: None (pure function)
- Must support: Unicode characters in local part
- Must handle: null, undefined, empty string
###Function Signature###
```typescript
function validateEmail(email: string | null | undefined): {
isValid: boolean;
errors: string[];
}
###Examples### Input: "user@example.com" Output: { isValid: true, errors: [] }
Input: "invalid@" Output: { isValid: false, errors: ["Missing domain part"] }
###Test Cases### ✅ Valid cases:
❌ Invalid cases (should handle):
- "" (empty string) → "Email is required"
- null → "Email cannot be null"
- "@example.com" → "Missing local part"
- "user@" → "Missing domain part"
###Coding Standards###
- Style: Prettier (100 char line length)
- Naming: camelCase
- Comments: JSDoc for function
- Error handling: Collect all errors, don't fail fast
###Deliverables###
- TypeScript function with types
- JSDoc comment explaining parameters
- Unit tests (Vitest)
- Usage example
---
## Template: Debugging
```markdown
###Problem###
[One-line description of the issue]
###Code###
```[language]
[Paste problematic code]
###Error### [Exact error message or unexpected behavior]
###Expected Behavior### [What should happen instead]
###Environment###
- Language: [version]
- Framework: [if applicable]
- OS: [if relevant]
- Dependencies: [relevant packages with versions]
###What I've Tried###
- [Debugging step 1]
- [Debugging step 2]
- [Debugging step 3]
###Task###
- Identify the root cause
- Explain why the error occurs
- Provide the corrected code
- Explain why the fix works
- Add a test case to prevent regression
Think through this step-by-step.
**Use When:**
- Fixing bugs
- Understanding errors
- Investigating unexpected behavior
---
## Template: Architecture Design
```markdown
###Context###
Design [system component] for [use case/domain]
**Scale:**
- Users: [number]
- Requests: [volume]
- Data: [size]
- Uptime: [requirement]
**Constraints:**
- Budget: [if applicable]
- Technology: [must use / can't use]
- Time: [timeline]
###Requirements###
**Functional:**
- [Feature 1]
- [Feature 2]
- [Feature 3]
**Non-Functional:**
- Performance: [metrics]
- Scalability: [targets]
- Reliability: [SLA]
- Security: [requirements]
###Tech Stack###
**Preferred:**
- [Technology 1] (reason)
- [Technology 2] (reason)
**Open to:**
- Alternatives if better fit
###Deliverables###
1. **Architecture Diagram:**
- Component breakdown
- Data flow
- Integration points
2. **Technology Choices:**
- Specific tools/frameworks
- Rationale for each
- Tradeoffs considered
3. **Data Model:**
- Schema design
- Relationships
- Indexing strategy
4. **API Design:**
- Endpoints
- Request/response formats
- Authentication approach
5. **Deployment Strategy:**
- Infrastructure
- CI/CD pipeline
- Monitoring approach
###Design Principles###
- [Principle 1, e.g., "Microservices over monolith"]
- [Principle 2, e.g., "Event-driven architecture"]
- [Principle 3, e.g., "Database per service"]
Let's approach this systematically, starting with the data model, then services, then integration.
Use When:
- System design
- Technology selection
- Infrastructure planning
Template: Code Review
###Code to Review###
```[language]
[Paste code here]
###Review Criteria###
Performance (Priority: [High/Medium/Low])
- Unnecessary re-renders/re-computation
- Expensive operations in hot paths
- Memory leaks or excessive allocation
- Inefficient algorithms (O(n²) where O(n) possible)
Security (Priority: Critical)
- Input validation
- SQL injection / XSS vulnerabilities
- Authentication/Authorization gaps
- Secret exposure
- CSRF protection
Maintainability (Priority: High)
- Code complexity (cyclomatic < 10)
- Clear naming
- Proper abstraction
- DRY (Don't Repeat Yourself)
- Single Responsibility Principle
Best Practices (Priority: Medium)
- Framework patterns followed
- Error handling comprehensive
- Logging appropriate
- Type safety (TypeScript/type hints)
###Output Format###
For each issue: [SEVERITY] Category - Location
- Issue: [What's wrong]
- Impact: [Why it matters]
- Fix:
// Corrected code
###Summary###
- Overall Score: [X/10]
- Critical Issues: [count]
- Recommendation: [Deploy / Fix First / Refactor]
**Use When:**
- Reviewing pull requests
- Code quality checks
- Security audits
---
## Template: Performance Optimization
```markdown
###Current Performance###
[Describe current state with metrics]
**Baseline Metrics:**
- Response time: [P50, P95, P99]
- Throughput: [requests/sec]
- Resource usage: [CPU/Memory/Network]
###Target Performance###
- Response time: [targets]
- Throughput: [target]
- Resource usage: [constraints]
###Code/System to Optimize###
```[language]
[Paste relevant code]
###Constraints###
- Cannot change: [API contract, database, etc.]
- Must maintain: [backward compatibility, etc.]
- Budget: [infrastructure costs]
###Optimization Approach###
Analyze and optimize in this order:
-
Identify Bottlenecks:
- Profile the code
- Identify hot paths
- Measure database queries
- Check network calls
-
Algorithm Optimization:
- Improve time complexity
- Reduce unnecessary computation
- Cache expensive operations
-
Database Optimization:
- Eliminate N+1 queries
- Add indexes
- Optimize query structure
-
Infrastructure:
- Caching layers
- Connection pooling
- Async processing
###Deliverables###
- Performance analysis with bottlenecks identified
- Optimized code with explanations
- Before/after benchmark results
- Validation that functionality unchanged
**Use When:**
- Optimizing slow code
- Meeting performance SLAs
- Reducing resource costs
---
## Quick Selection Guide
| Task Type | Use Template | Key Sections |
|-----------|--------------|--------------|
| Build feature | Code Implementation | Requirements, Test Cases, Standards |
| Fix bug | Debugging | Error, Environment, What I've Tried |
| Design system | Architecture | Context, Scale, Deliverables |
| Review code | Code Review | Criteria, Output Format |
| Speed up | Performance | Metrics, Approach, Deliverables |
---
**Total Templates**: 5 core technical templates
**Avg Fill Time**: 2-5 minutes
**Success Rate**: 90%+ first-response quality