create-repository

Generate repository implementations for Domain interfaces using EF Core or Dapper.

Updated Feb 20, 2026
One-click install
npx skills add https://github.com/yeeehaooo/WorkSpace --skill create-repository-yeeehaooo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: create-repository
Source: https://github.com/yeeehaooo/WorkSpace/tree/main/skills/dotnet/generators/create-repository
Command: npx skills add https://github.com/yeeehaooo/WorkSpace --skill create-repository-yeeehaooo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Generate repository implementations for Domain interfaces using EF Core or Dapper in the Infrastructure layer.

Core Features & Use Cases

  • Supports both EF Core and Dapper backends to implement I{Entity}Repository for Domain entities.
  • Enforces a strict separation where the repository handles only data operations and relies on a UnitOfWork for transactions.
  • Produces scaffolding for read/write data access patterns and aligns with the Repository pattern in Domain-Driven Design.

Quick Start

Create a repository class named {Entity}Repository implementing I{Entity}Repository in the Infrastructure layer using EF Core or Dapper.

Frequently Asked Questions about create-repository

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate repository implementations for Domain interfaces using EF Core?

To generate repository implementations using EF Core, you create a class named {Entity}Repository implementing I{Entity}Repository in the Infrastructure layer. This scaffolds read, add, update, and delete data operations while enforcing that repositories perform only data operations.

Can I use Dapper instead of EF Core for Domain repository pattern scaffolding?

Yes, Dapper is supported as an alternative backend for Domain repository pattern scaffolding. You can generate repository implementations for Domain interfaces using Dapper in the Infrastructure layer, covering read, add, update, and delete data operations.

What is the role of UnitOfWork when generating repositories for Domain-Driven Design?

When generating repositories for Domain-Driven Design, UnitOfWork handles transaction delegation. The generated repository implementations enforce a strict separation where repositories perform only data operations and rely on UnitOfWork for transaction management.

Does the generated repository scaffolding support both read and write data operations?

Yes, the generated repository scaffolding supports both read and write data operations. It produces scaffolding for read/write data access patterns, specifically covering read, add, update, and delete operations aligned with the Repository pattern.

When do I need to generate repository implementations for the Infrastructure layer?

You need to generate repository implementations for the Infrastructure layer when adopting the Repository pattern in Domain-Driven Design. It applies to projects requiring data access scaffolding that separates data operations from transaction management.

Why does the repository pattern delegate transactions to UnitOfWork instead of handling them directly?

The repository pattern delegates transactions to UnitOfWork to enforce a strict separation of concerns. Repositories perform only data operations like read, add, update, and delete, while UnitOfWork manages transaction boundaries in the Infrastructure layer.