add-repository-method

Adds a query or write method to the FoolProof TypeScript repository layer.

Updated Jul 28, 2026
One-click install
npx skills add https://github.com/oleg-vasilyev/FoolProof --skill add-repository-method-oleg-vasilyev
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: add-repository-method
Source: https://github.com/oleg-vasilyev/FoolProof/tree/main/.claude/skills/add-repository-method
Command: npx skills add https://github.com/oleg-vasilyev/FoolProof --skill add-repository-method-oleg-vasilyev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Features in this codebase never touch the database directly, so any new data need requires a coordinated change across the repository layer. This Skill ensures all the files that must change together actually do, preventing broken interfaces, untestable SQL, and failing specs. ## Core Features & Use Cases - Coordinated multi-file change: Guides edits to the repository contract interface, the SQLite implementation, the stub used by specs, and the integration spec, plus the row mapper when a new record shape is returned. - Layer discipline enforcement: Keeps SQL confined to one file, enforces UTC datetime handling, transactions for multi-table writes, and domain-named methods that hide table structure. - Use Case: A feature needs the chronology of a game series. Use this Skill to add a seriesChronology method to the interface, implement it in the SQLite repository, register a spy in the stub, and cover it with a real-database integration spec. ## Quick Start Add a repository method for the data my feature needs, following the repository layer workflow.

Frequently Asked Questions about add-repository-method

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

FAQPage Schema
How do I add a new repository method in a TypeScript SQLite project?▼

Add the method to the repository interface with a domain-style name, implement the SQL in the SQLite repository file, register a spy in the stub so specs compile, and write an integration spec against a real temporary SQLite database.

How should repository methods be named in a data access layer?▼

Use domain phrases rather than SQL terms, such as liveCardInChat or seriesChronology, so callers cannot guess the underlying table. This keeps the interface decoupled from the schema.

Why should SQL stay in a single repository file?▼

Confining SQL to one file keeps column knowledge from leaking outward and makes the layer testable. Row mapping moves to a separate module so coercion logic can be unit tested without a database connection.

Why test repository code against a real SQLite database?▼

A mocked database asserts nothing about the SQL itself. Running integration specs against a real temporary SQLite file verifies actual behavior, empty-result handling, and that schema constraints reject invalid data.

When should multi-table writes use transactions?▼

Any write touching more than one table should run inside a transaction so a failure leaves nothing partial behind. This preserves data integrity when an operation spans several tables.