Clarify FULL synchronous is rarely needed in sqlite skill

claude/CLAUDE.md

@@ -25,6 +25,11 @@ When asked to respond to reviews in a PR, check the PR description and all comme
 ## Commits
 Commit often. It's better to commit things than to leave changes hanging for a long time. You don't have to commit after every change, but once you're done working just go ahead and commit. 
 
+## Comments in code
+Only comment what is necessary to explain **why** the code is doing something. Do not write comments for **what** the code is doing, that should be obvious from the code itself.
+Do not write comments for anything obvious, anything that an expert can be expected to know, or anything already documented elsewhere.
+Comments are permanent part of the code! Only comment what should be permanently stored along with the code, moment to moment coding decisions, what old versions of the code were before refactors etc. do not belong in comments.
+
 ## Writing Style
 
 Following rules are for your writing. Follow these when responding to the user, when writing documentation and code comments, and when writing commit messages or PR descriptions.
@@ -40,11 +45,13 @@ Following rules are for your writing. Follow these when responding to the user,
 - Do not use em-dashes. No "It's not X, it's Y". Avoid overusing intricate, underscore, highlight, showcase, journey to, step into. Do not use "You're absolutely right!".
 - Avoid sentence fragments for emphasis. Bad: "Not X. Not Y. Just Z."
 - Do use emphasis when necessary: "This is a destructive operation. All data will be lost. Should I proceed?"
+- Avoid flowery language like "no ceremony", "this is more than X", "you're right to poke it", "this is load bearing", "dissolves your original concern"
 
 Examples:
 - Bad: Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by a problem with the authentication middleware. I will investigate this problem now.
 - Bad: Not a bug. Not a feature. A fundamental design flaw.
 - Bad: It's worth noting that this approach has limitations.
+- Bad: Just implementation, no ceremony.
 - Good: Sure. Bug may be in auth middleware. I'll check.
 - Good: This is a design flaw.
 - Good: This approach has limitations.

claude/settings.json

@@ -1,8 +1,8 @@
 {
-  "includeCoAuthoredBy": false,
   "attribution": {
     "sessionUrl": false
   },
+  "includeCoAuthoredBy": false,
   "permissions": {
     "allow": [
       "mcp__claude_ai_Willet__list_organizations",

claude/skills/sqlite/SKILL.md

@@ -28,5 +28,5 @@ CREATE TABLE user (id INTEGER PRIMARY KEY, name TEXT NOT NULL) STRICT;
 
 - **`foreign_keys`, `busy_timeout`, `synchronous` reset per connection.** Missing them on any connection silently drops the behavior (e.g. FK constraints stop being enforced). Set them on connection open.
 - **`journal_mode = WAL` is different**: it persists in the DB file, so set it once. WAL needs the DB on **local disk** (breaks on network filesystems) and adds `-wal` and `-shm` sidecar files next to the DB.
-- **`synchronous = NORMAL` durability**: an OS crash or power loss can lose the last few committed transactions. The DB stays consistent (no corruption) — only the tail is lost. Use `FULL` if you cannot tolerate losing any committed write.
+- **`synchronous = NORMAL` durability**: an OS crash or power loss can lose the last few committed transactions. The DB stays consistent (no corruption) — only the tail is lost. `NORMAL` is almost always the right choice; `FULL` is rarely needed. If you genuinely cannot afford to lose any committed write, you shouldn't be on SQLite at all — use a DB replicated across regions.
 - **STRICT allows only `INT`, `INTEGER`, `REAL`, `TEXT`, `BLOB`, `ANY`.** No `VARCHAR`, `DATETIME`, `BOOLEAN`, etc. Use `ANY` for a column that needs to hold mixed types.

git/gitignore

@@ -1,2 +1,6 @@
 .history/
 
+
+## Panda
+styled-system
+styled-system-studio