persistence-adapters

Review and modify PromptRepository filesystem and Firestore adapters while preserving contracts and migration safety.

1|Updated Aug 24, 2026
One-click install
npx skills add https://github.com/danilonovaisv/DAN-IMAGES-PROMPTS-2 --skill persistence-adapters-danilonovaisv
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: persistence-adapters
Source: https://github.com/danilonovaisv/DAN-IMAGES-PROMPTS-2/tree/main/.agents/skills/persistence-adapters
Command: npx skills add https://github.com/danilonovaisv/DAN-IMAGES-PROMPTS-2 --skill persistence-adapters-danilonovaisv

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Changing or reviewing persistence code is risky: filesystem and Firestore adapters can silently diverge, IDs and timestamps can be corrupted, and provider migrations can lose data. This Skill enforces the invariants that keep both storage backends behaviorally identical and migration-safe. ## Core Features & Use Cases - Contract Preservation: Ensures PromptRepository behavior stays consistent across filesystem and Firestore implementations, including IDs, creation timestamps, counters, category protections, and duplicate semantics. - Security & Integrity Guardrails: Validates PERSISTENCE_PROVIDER server-side only, prevents path traversal and partial writes in the filesystem adapter, and requires Firestore transactions for atomic read-modify-write operations. - Migration Safety: Requires documented migration, backup, rollback, indexes, credentials, and data ownership before changing providers, and forbids presenting local uploads as durable Cloud Run storage. - Use Case: When adding a new field to prompt records, use this Skill to update both adapters, verify shared contract behavior with tests, and document the Firestore index and rollback plan. ## Quick Start Review the changes to server/repositories and confirm both the filesystem and Firestore adapters still satisfy the PromptRepository contract.

Frequently Asked Questions about persistence-adapters

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

FAQPage Schema
How do I change the PromptRepository without breaking the filesystem and Firestore adapters?▼

Update both adapters so the shared repository contract stays identical, then test both implementations whenever contract behavior changes. Preserve IDs, creation timestamps, counters, category protections, and duplicate semantics across backends.

How should the persistence provider be selected between filesystem and Firestore?▼

Validate the PERSISTENCE_PROVIDER value on the server only. Request data must never select the backend, since client-controlled provider selection would let callers choose where their data is stored.

When are Firestore transactions required in the repository adapter?▼

Use Firestore transactions for any read-modify-write operation that requires atomicity, such as counter updates. Without transactions, concurrent writes can silently corrupt shared state.

Can local filesystem uploads be used as durable storage on Cloud Run?▼

No. Local filesystem uploads must never be presented as durable Cloud Run storage, because container instances are ephemeral. Treat Firestore records and local uploads as separate durability boundaries.

What must be documented before migrating persistence providers?▼

Document the migration plan, backup strategy, rollback procedure, required Firestore indexes, credentials handling, and data ownership before changing providers. This ensures the migration is reversible and auditable.

What if Firestore credentials or an emulator are unavailable for testing?▼

Test the filesystem adapter as usual, but explicitly report the Firestore verification as not executed. Do not claim both adapters were validated when only one was actually exercised.