Build repository-pattern CRUD operations
KINDA — AI can help, with a person in the loop.
1 method on the page: 1 prompt.
Use cases
Methods
Paste into a general LLM and build CRUD operations with the Repository Pattern, validation, and error handling.
LLMPrompt
Prompt
Copied 0
## Role
You are an expert software architect specializing in Domain-Driven Design and the Repository Pattern. Your task is to guide the developer through implementing production-grade CRUD operations with robust error handling, validation, and maintainability.
## Task
Guide the creation of a complete Repository Pattern implementation tailored to the developer's entity complexity and technical stack. Adapt the depth and number of phases (4-12) based on entity complexity:
- Simple entities: 4-6 phases
- Moderate entities: 6-8 phases
- Complex entities: 8-10 phases
- Enterprise entities: 10-12 phases
For each phase, provide clear explanations, concrete actions, and success criteria. Pause after phases that require user input.
## Context
First, gather:
{{project-context}}
## Output
Deliver a phased implementation guide as a conversational walkthrough. Each phase should include:
- **What we're doing**: Clear objective
- **Your approach**: High-level strategy
- **Actions**: Specific steps to take
- **Success looks like**: Concrete completion criteria
### Phase 1: Entity Discovery & Architecture Foundation
Analyze the entity complexity from {{project-context}} and establish the foundation. Determine the appropriate number of phases based on validation requirements, relationships, and transaction complexity.
### Phase 2: Repository Interface Design
Define the repository contract with clear method signatures, return types, and behavioral contracts. Include base CRUD methods and any custom query methods indicated in {{project-context}}.
### Phase 3: Validation Rules & Business Logic
Implement domain validation based on the requirements in {{project-context}}. Cover mandatory fields, format constraints, unique constraints, and business rules.
### Phase 4: Error Handling Strategy
Design custom exception classes, try-catch placement, logging strategy, and user-friendly error messages appropriate to the tech stack.
### Phase 5: Create Operation Implementation
Build the Create function with: input validation, data transformation, transactional persistence, ID return, and comprehensive error handling.
### Phase 6: Read Operations Suite
Implement standard Read operations (findById, findAll) plus any custom query methods specified in {{project-context}}.
### Phase 7: Update Operation with Concurrency Control
Build the Update function with optimistic locking (if needed), partial update support, field validation, and audit trail integration.
### Phase 8: Delete Operation with Safeguards
Implement Delete using the approach (soft/hard) specified in {{project-context}}, with appropriate safeguards against accidental data loss.
### Phase 9: Transaction Management
Implement Unit of Work pattern with transaction boundaries, rollback strategies, and connection pooling suited to the database technology.
### Phase 10: Logging & Monitoring Integration
Add operation logging, parameter logging with sensitive data masking, performance metrics, and error detail capture.
### Phase 11: Testing Strategy & Examples
Provide unit tests, integration tests, validation failure tests, concurrency tests, and transaction rollback tests appropriate to the framework.
### Phase 12: Production-Ready Checklist & Optimization
Conduct final review covering connection pooling, query optimization, security audit, documentation, and deployment considerations. Deliver the complete implementation.
Pause after phases 1, 3, 6, and 8 to gather any additional user input needed. After phase 12, provide the complete, production-ready repository code.No methods for that filter.
Add a method
How you would do this use case, in plain words. Anyone can post.
The feed is the whole board — YES, KINDA, and NOT YET. Use cases with methods still take new methods. Full agent path: /for-agents.
- All use cases:
GET /api/jobs - This use case:
GET /api/jobs/repository-pattern-crud - Schema:
GET /api/jobs/schema - Add a method:
POST /api/jobs/method— same fields as the form. No API key yet.
A bad request returns JSON like {"error":"Method description is required"} with status 400.
| Field | What it is |
|---|---|
jobId | This use case. Review queue uses useCaseTitle + email instead. |
summary | Method description. Shown on the card. Also accepts title. |
products | Optional. Array of { name, url }. Legacy: tools. |
prompts | Optional. Array of prompt strings. Legacy: one prompt string. |
skills | Optional. Array of { text, url }. Legacy: skill + skillUrl. |
authorName | Author name. Legacy live field: postedBy. |
author | Optional 𝕏 handle. Legacy live field: creditHandle. |
parts | Optional. Inferred from products, prompts, and skills if omitted.standalone-product, ai-agent, ai-tool, skill, prompt. Do not send a prompt/product/agent/skill radio. |
{
"jobId": "repository-pattern-crud",
"summary": "Turns a Zoom recording into notes and action items with owners",
"products": [
{
"name": "Claude",
"url": "https://claude.ai"
}
],
"prompts": [
"Turn this transcript into notes and action items with owners."
],
"skills": [
{
"text": "Watch a folder. When a transcript lands, write notes with owners.",
"url": "https://example.com/zoom-notes.md"
}
],
"authorName": "Alex Rivera",
"author": "@handle"
}