Create or review dygo Fixtures and explicit Patches for reference data, setup Records, backfills, renames, and unsafe lifecycle transitions. Use when metadata sync alone cannot express the required data change.
Installs into .claude/skills of the current project.
Are you the author of Dygo Fixtures And Patches?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/hapyco-dygo-fixtures-and-patches)
---
name: dygo-fixtures-and-patches
description: Create or review dygo Fixtures and explicit Patches for reference data, setup Records, backfills, renames, and unsafe lifecycle transitions. Use when metadata sync alone cannot express the required data change.
---
# dygo Fixtures And Patches
Choose the mechanism by intent.
- Use a Fixture for repeatable reference, setup, or demo Records.
- Use a Patch for a one-time ordered lifecycle transition.
- Use metadata sync for additive schema changes that metadata can infer safely.
## Source Contracts
Read `docs/fixtures.md`, `docs/patches.md`, and the database lifecycle in `docs/database.md`.
## Rules
- Keep Fixtures app-owned and Entity-local.
- Use stable match fields and explicit dependencies.
- Do not use Fixtures as an uncontrolled production data migration system.
- Prefer structured Patch operations.
- Use the SQL escape hatch only when structured operations cannot express a safe transition.
- Place a Patch in the correct pre-sync or post-sync phase.
- Make Patch execution transactional and ledgered according to the runtime contract.
- Never hide destructive cleanup inside additive migration. Use explicit prune or a reviewed Patch.
- Preview writes before application when a dry-run path exists.
## Check
Use fixture validation and dry-run plans. For a Patch, verify the intended before and after state, failure rollback, and repeat-run ledger behavior.
