flashdb-integration
starsforks
How to install flashdb-integration?
easyzoom/aix-skills/flashdb-integration
$npx -y skills add easyzoom/aix-skills --skill flashdb-integrationUse when integrating, porting, configuring, or debugging FlashDB KVDB or TSDB on MCU flash, filesystems, RTOS, or bare-metal projects
SKILL.md
| 1 | # FlashDB Integration |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Use this skill to integrate FlashDB as an embedded key-value or time-series database. The agent should confirm storage mode, flash/file backend, sector geometry, erase policy, and data-retention requirements before formatting or deleting database sectors. |
| 6 | |
| 7 | ## When To Use |
| 8 | |
| 9 | Use this skill when: |
| 10 | |
| 11 | - The user wants to add FlashDB KVDB or TSDB for parameters, configuration, logs, events, or time-series records. |
| 12 | - The issue involves init failure, sector size, erase errors, lost keys, database full, migration, blob values, timestamps, or flash wear. |
| 13 | - The project mentions FlashDB, `fdb_kvdb`, `fdb_tsdb`, KVDB, TSDB, `fdb_cfg`, or `fdb_port`. |
| 14 | |
| 15 | Do not use this skill for raw filesystem work without FlashDB. Use `littlefs-integration` or storage-specific skills instead. |
| 16 | |
| 17 | ## First Questions |
| 18 | |
| 19 | Ask for: |
| 20 | |
| 21 | - Database type: KVDB, TSDB, or both. |
| 22 | - Backend: raw flash, FAL partition, filesystem, or vendor storage layer. |
| 23 | - Sector size, partition size, erase value, write alignment, and flash driver status. |
| 24 | - RTOS or bare-metal environment and locking requirements. |
| 25 | - Whether existing database data must be preserved. |
| 26 | - Current error log, assert, return code, or database output. |
| 27 | |
| 28 | ## Integration Checklist |
| 29 | |
| 30 | 1. Confirm database purpose. |
| 31 | Use KVDB for named settings and TSDB for append-style time records. Do not force both if one is enough. |
| 32 | |
| 33 | 1. Confirm storage backend. |
| 34 | Identify whether FlashDB talks to raw flash, FAL, filesystem, or a custom port. |
| 35 | |
| 36 | 1. Match sector geometry. |
| 37 | Sector size and partition boundaries must match the real erase granularity and FlashDB configuration. |
| 38 | |
| 39 | 1. Preserve data by default. |
| 40 | Do not format, clean, or recreate the database unless the user approves data loss or confirms it is a first-boot path. |
| 41 | |
| 42 | 1. Add locking when shared. |
| 43 | Protect database operations if multiple tasks, shell commands, logging callbacks, or ISRs can access it. |
| 44 | |
| 45 | 1. Verify both metadata and values. |
| 46 | Read back keys or TSDB records after reboot, not only immediately after write. |
| 47 | |
| 48 | ## Porting Checks |
| 49 | |
| 50 | - Flash read/write/erase operations return correct status. |
| 51 | - Write alignment and erased-state assumptions match the chip. |
| 52 | - Partition does not overlap firmware, bootloader, littlefs, logs, or calibration data. |
| 53 | - Default KV values and schema migration strategy are explicit. |
| 54 | - Blob size and RAM buffer requirements fit the target. |
| 55 | - TSDB timestamp source is monotonic enough for the product. |
| 56 | - Database full behavior is understood: rollover, cleanup, or failure. |
| 57 | |
| 58 | ## Common Failures |
| 59 | |
| 60 | - Database init formats existing production data unexpectedly. |
| 61 | - KV values disappear because default table reinitializes them incorrectly. |
| 62 | - TSDB records have bad order because timestamp source is wrong. |
| 63 | - Database full is handled as a generic write failure. |
| 64 | - Flash sector size in config differs from real erase size. |
| 65 | - Concurrent shell/log/task access corrupts records without locking. |
| 66 | |
| 67 | ## Verification |
| 68 | |
| 69 | Before claiming FlashDB works: |
| 70 | |
| 71 | - State database type, backend, partition, sector size, and preservation policy. |
| 72 | - Confirm init result without unapproved formatting. |
| 73 | - Confirm write/read/delete or append/query behavior for the target use case. |
| 74 | - Confirm data survives reset or remount. |
| 75 | - Confirm full-database and migration behavior is defined or explicitly deferred. |
| 76 | |
| 77 | ## Example |
| 78 | |
| 79 | User: |
| 80 | |
| 81 | ```text |
| 82 | 想用 FlashDB 存设备参数，重启后有时候读不到。 |
| 83 | ``` |
| 84 | |
| 85 | Agent: |
| 86 | |
| 87 | 1. Asks for KVDB config, backend, sector size, flash driver, default table, and data preservation requirement. |
| 88 | 1. Checks whether init path reformats or overwrites defaults. |
| 89 | 1. Verifies set/get after reboot and confirms locking if shell or tasks can modify parameters. |
People who liked this also viewed
6 picksType
- azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026
- systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026
- safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026
- explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026
- minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026
- insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 2026
