Audit SQLite persistence code for consistent locking and idempotent schema changes.
npx skills add https://github.com/ElPoot/contabilidad --skill audit-sqlite
Please help me install this Agent Skill. Skill: audit-sqlite Source: https://github.com/ElPoot/contabilidad/tree/main/.agents/skills/audit-sqlite Command: npx skills add https://github.com/ElPoot/contabilidad --skill audit-sqlite
Prevents database corruption and runtime failures by ensuring every SQLite access follows a consistent locking and idempotent schema pattern across the backend persistence layer.
threading.Lock() consistently (including proper with self._lock: usage) to avoid “database is locked” and race conditions.CREATE TABLE ... IF NOT EXISTS, ALTER TABLE patterns) are repeatable and safe.ClassificationDB reference pattern.Use case: When refactoring or adding features to the contabilidad classifier workflow, audit gestor_contable/core/* SQLite modules to confirm they match the locking strategy used by ClassificationDB.
Ask the AI to run an audit of the SQLite modules in gestor_contable/core/ against the ClassificationDB locking and schema/idempotency pattern and produce the required “AUDITORIA: PERSISTENCIA SQLITE Y LOCKING” report with any real code findings.
High-intent search queries and answers about installing and using this skill.
Preventing SQLite race conditions requires consistent threading lock usage across all database access. By wrapping sqlite3.connect operations with a threading.Lock and enforcing `with self._lock:` for reads and writes, you eliminate concurrent database locked errors and data corruption.
Making SQLite schema changes idempotent requires using repeatable operations such as `CREATE TABLE IF NOT EXISTS` and safe ALTER TABLE patterns. Verifying schema idempotency ensures database migrations can execute multiple times without failing or duplicating table structures.
Auditing SQLite persistence code for concurrency bugs involves scanning modules for sqlite3.connect calls and comparing reads and writes against consistent `with self._lock:` threading lock usage. The audit reports only actual locking inconsistencies evidenced by the current code.
Avoiding direct GUI-driven SQLite writes prevents concurrency bugs by isolating database access in the backend persistence layer. Comparing modules against a reference pattern ensures all writes follow consistent locking strategies rather than uncontrolled GUI paths.
A limitation of using threading locks for SQLite database concurrency is that it requires scanning every sqlite3.connect call to ensure strict `with self._lock:` enforcement. The audit reports only differences evidenced by current code, meaning gaps outside scanned modules remain vulnerable to race conditions.
jvalinskyAudit Objective-C source files for lock and dispatch-queue concurrency issues.
penwypGenerate a code-grounded refactor design report with implementation order and acceptance criteria.
somachakIdentify race conditions, deadlocks, and concurrency bugs in backend code.
jvalinskyAudit Objective-C SQLite code for transaction atomicity and statement lifecycle invariants.