repository-pattern

Implements Repository pattern conventions for Kotlin Android apps with Hilt, Room, and coroutines.

Updated May 9, 2026
One-click install
npx skills add https://github.com/Bumh3rr/solvyx-app --skill repository-pattern-bumh3rr
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: repository-pattern
Source: https://github.com/Bumh3rr/solvyx-app/tree/main/.opencode/skill/repository-pattern
Command: npx skills add https://github.com/Bumh3rr/solvyx-app --skill repository-pattern-bumh3rr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When building the data layer of an Android app, teams often end up with inconsistent repositories: some expose DAO entities directly to ViewModels, others leak exceptions, mix threading concerns, or grow into unmaintainable God classes. This Skill provides the conventions to implement the Repository pattern consistently in the Solvyx project. ## Core Features & Use Cases - Interface + Impl structure: Defines a public interface per domain with a @Singleton implementation injected via constructor, bound through a Hilt @Binds module. - Typed error handling: Guides when to use runCatching with Result, sealed result classes, or exceptions, with a decision table. - Threading and multi-source rules: Specifies dispatcher usage (IO, Default) and how to combine local DAO, remote API, and preferences sources. - Use Case: When creating a new BitacoraRepository that combines a Room DAO with a future remote API, apply this Skill to get the interface, Hilt binding, entity-to-domain mappers, and unit tests with MockK. ## Quick Start Apply the repository-pattern skill to create a new repository for the exercises domain with its interface, Hilt binding, and unit tests.

Frequently Asked Questions about repository-pattern

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

FAQPage Schema
How do I implement the Repository pattern in Kotlin Android with Hilt?▼

Define a public interface per domain, then create a @Singleton implementation class with constructor-injected DAOs and data sources. Bind them in a Hilt module using @Binds with @Singleton scope so consumers depend only on the interface.

When should a repository return Result vs a sealed class vs throw an exception?▼

Use runCatching with Result for recoverable errors where the type does not matter, a sealed result class when the ViewModel must show different UI per error type, and throw only for unrecoverable failures like database corruption.

Should Room DAO calls be wrapped in withContext(Dispatchers.IO)?▼

Room suspend and Flow operations are already asynchronous, so wrapping is unnecessary. Reserve Dispatchers.IO for network calls, Dispatchers.Default for CPU-intensive JSON parsing, and withContext for combined multi-step operations.

Can a repository combine local Room data with a remote API?▼

Yes, a repository can inject multiple sources such as a local DAO, a remote API, and user preferences. You must define a clear merge policy, for example syncing unsynced local entries to the remote when online sync is enabled.

What are common Repository pattern anti-patterns to avoid?▼

Avoid repositories without interfaces, dependencies on UI components like Activity or View, God classes with dozens of methods, business logic inside DAOs, returning entities to ViewModels instead of domain models, and mutable non-thread-safe state in singletons.