Agent Skills
› muratgur/ordinus
› sqlite-minimal-persistence
sqlite-minimal-persistence
GitHub保守扩展 SQLite 持久化,仅在产品行为明确需要时添加表。避免推测性设计,保持最小 schema,通过 IPC 隔离访问,确保数据安全与架构清晰。
Trigger Scenarios
修改 better-sqlite3 或 Drizzle schema
涉及数据库引导、迁移或持久化边界变更
提议新增产品数据表
Install
npx skills add muratgur/ordinus --skill sqlite-minimal-persistence -g -y
SKILL.md
Frontmatter
{
"name": "sqlite-minimal-persistence",
"description": "Extend Ordinus SQLite persistence conservatively. Use when touching better-sqlite3, Drizzle schema, database bootstrap, app_meta, migrations, durable state, persistence boundaries, or proposals to add new product tables."
}
SQLite Minimal Persistence
Objective
Use SQLite as durable local app state without designing product tables before the workflow model is clear.
Current Policy
- The minimum database starts with
app_meta. - Add new tables only when the product behavior needs durable state now.
- Avoid adding agent, task, provider, schedule, inbox, or run schemas speculatively.
- Keep secrets out of ordinary product tables unless a secure storage decision has been made.
- Treat SQLite as main-process owned. Renderer must access state only through typed IPC.
Workflow
- Confirm the requested behavior truly needs persistence.
- Check whether existing
app_metaor settings-level storage is sufficient. - If a table is necessary, define the smallest schema that supports the current behavior.
- Add Drizzle schema and bootstrap/migration logic together.
- Keep data access behind main-process services.
- Update
db.getStatusonly if the status surface needs to show new bootstrap information. - Run typecheck, lint, build, and a runtime smoke test that opens the app.
Design Guidance
- Prefer durable state for user-visible history, resumable work, and app configuration.
- Prefer filesystem storage for large artifacts and generated files, with database metadata later when needed.
- Prefer explicit timestamps and schema versioning for local migrations.
- Keep schema names product-oriented and stable.
Red Flags
- A table is added because a future module might need it.
- Renderer imports database code.
- Database writes are mixed into UI event handlers.
- Migration behavior is not exercised by opening the app.
Version History
- f507122 Current 2026-07-05 18:19


