@dennisrongo/skills 0.5.0 → 0.7.0

package/skills/tauri-2-app/SKILL.md

@@ -43,6 +43,8 @@ The user does **not** want hard-coded Cargo / npm versions baked into the skill.
 3. Pin the Rust edition to `2021` unless the user asks otherwise.
 4. Quote the resolved versions back to the user before generating, so they can object.
 5. Default to **npm** unless `pnpm` or `bun` is present and the user prefers it.
+6. Concrete resolution commands when context7 is unavailable: `npm view @tauri-apps/api version`, `cargo search <crate> --limit 1`, or WebFetch `https://crates.io/api/v1/crates/<crate>` (`max_stable_version`). Never write a version you did not just resolve this session — no versions from memory, no invented numbers.
+7. **Tauri 1.x is poison.** Training data is full of v1 patterns that look plausible and fail on v2. Never emit: `import { invoke } from '@tauri-apps/api/tauri'` (the v2 path is `@tauri-apps/api/core`), a `tauri.allowlist` or top-level `tauri` key in `tauri.conf.json` (v2 uses `app` / `bundle` / `plugins` + `capabilities/*.json`), or v1 plugin names/APIs. If you are not certain a conf key, capability permission string, or plugin API exists in Tauri 2, verify it against the installed schema (`node_modules/@tauri-apps/cli/config.schema.json`; valid permission strings appear in `src-tauri/gen/schemas/` after the first build) or the plugin's docs **before** writing code that depends on it. Capability `permissions` entries use the short plugin name (`dialog:allow-open`, `fs:allow-read-file`) — never a `tauri-plugin-` prefix. Note that `cargo check` compiles `tauri-build`, which validates `tauri.conf.json` and `capabilities/*.json` — a schema or unknown-permission error there is a JSON problem; fix the conf/capability file against the schema, don't edit Rust code to appease it.
 
 ### Step 2 — Gather inputs (ask once, in one batch)
 
@@ -71,14 +73,17 @@ Use the **templates in [`references/templates/`](references/templates/)** as the
 - Create directories before files. On Windows shell use PowerShell `New-Item -ItemType Directory -Force`.
 - Do **not** run `create-tauri-app` to bootstrap — write the files directly from templates so the layout matches the conventions in [`references/folder-layout.md`](references/folder-layout.md). Use `npm install` after `package.json` is written, then `cargo fetch` from `src-tauri/` to seed the Cargo cache.
 - For icons, run `npx @tauri-apps/cli icon <path-to-source.png>` once a source image exists, or generate a 1024×1024 placeholder with `sharp` if the user wants. Do **not** commit a placeholder square as the final icon — surface it as a TODO.
+- If a generator IS run (`create-tauri-app` at the user's insistence, `npx @tauri-apps/cli icon`, `tauri signer generate`) and its output differs from this skill's layout: **Tauri wins on file locations it mandates** (`src-tauri/` shape, `capabilities/`, `gen/`, icon paths), **this skill wins on everything Tauri doesn't mandate** (the `commands/`/`state/`/`storage/`/`platform/` module split, frontend hooks layout). Reconcile deliberately and list every deviation in your report — never force the skill layout over a framework requirement, never silently abandon the skill's patterns.
 
 ### Step 4 — Verify and report
 
 - Run `npm install` (or chosen PM).
-- Run `cd src-tauri && cargo build` — must exit 0. (Don't run `tauri dev` in CI — it opens a window.)
+- Run `cd src-tauri && cargo build` — must exit 0. (Don't run `tauri dev` in CI — it opens a window.) If a full `cargo build` is prohibitively slow in this environment, `cargo check` is the minimum acceptable bar — state which one you ran.
 - Run `cd src-tauri && cargo test` — must exit 0 if any tests were generated.
-- Run `npm run build` (frontend) — must exit 0.
+- Run `npm run build` (frontend) — must exit 0. `cargo check` + `npm run build` together are the floor; a full `tauri build` is optional (slow).
 - Optionally run `npm run tauri build -- --debug` if the user wants a debug bundle; skip in CI by default since it's slow.
+- **A scaffold that hasn't compiled is not delivered.** Paste the actual proof lines in your report (cargo's `Finished` profile line, `test result: ok`, Vite's `✓ built in ...`). Never report success from memory of the steps you intended, and never report partial success as success — if something is red, say exactly what is red.
+- **CLI failure protocol** (applies to `npm install`, `cargo build`/`check`/`test`, `npm run build`): read the full error output — for cargo, fix the **first** error; later ones are usually cascade. Change exactly one thing, retry once. If the same step fails twice, stop scaffolding and surface the verbatim error to the user — do not keep generating files on a broken base, and do not re-run the identical command hoping for a different result.
 - Reply with a short summary: project path, versions chosen, plugins wired, bundle identifier, next steps (e.g. "fill in the macOS `Info.plist` usage descriptions for any permissions you'll request", "generate updater keys with `npx tauri signer generate`", "run `npm run tauri dev`").
 
 ## Project layout (canonical)
@@ -236,6 +241,9 @@ Every one of these is forbidden in generated code. Rationale for each is in [`re
    3. `src-tauri/Cargo.toml` (with target-specific deps + release profile), `src-tauri/build.rs`, `src-tauri/tauri.conf.json`, `src-tauri/Info.plist`, `src-tauri/entitlements.plist`, `src-tauri/capabilities/default.json`.
    4. `src-tauri/icons/` — placeholder 1024×1024 PNG **only** if the user hasn't supplied one. Surface as TODO; tell them to run `npx @tauri-apps/cli icon icons/icon.png`.
    5. `src-tauri/src/main.rs`, `src-tauri/src/lib.rs`, `src-tauri/src/error/mod.rs`, `src-tauri/src/state/mod.rs`, `src-tauri/src/storage/mod.rs`, `src-tauri/src/commands/mod.rs` + `src-tauri/src/commands/system.rs`, `src-tauri/src/platform/{mod,traits,macos,windows,linux,wrappers}.rs`, `src-tauri/src/settings/{mod,defaults,storage,commands}.rs`.
+
+      **Checkpoint:** run `npm install` then a first `cd src-tauri && cargo check` here, before optional modules — errors localize to the core tree, and this check runs `tauri-build`, which validates `tauri.conf.json` + `capabilities/*.json` and generates `src-tauri/gen/schemas/` (the authority for valid permission strings). Fix any conf/capability error now, per the Step-4 failure protocol, before writing more capability entries.
+
    6. Optional: `src-tauri/src/encryption/mod.rs`, `src-tauri/src/tray.rs`, `src-tauri/src/commands/<more>.rs` based on user answers.
    7. `src-tauri/tests/common/mod.rs` + at least one integration test file (e.g. `system_test.rs`) so CI has something real to run.
 4. `npm install`.
@@ -261,7 +269,7 @@ For command `{{command}}` (snake_case) in module `commands/{{domain}}.rs`:
    - Export the hook. Do **not** call `invoke()` inline in a component.
 4. **Test**: add an integration test in `src-tauri/tests/{{domain}}_test.rs` that exercises the command's underlying function (the `#[tauri::command]` itself is hard to call without a full Tauri context — test the inner function).
 
-After generating: `cd src-tauri && cargo build && cargo test` then `npm run build` from the project root.
+After generating: `cd src-tauri && cargo build && cargo test` then `npm run build` from the project root. Apply the Step-4 proof-and-failure protocol — paste the green lines; the same step failing twice = stop and surface the verbatim error.
 
 ### Mode 3 — `add-module`
 
@@ -275,7 +283,7 @@ For module `{{module}}` (snake_case):
 6. Add a `#[cfg(test)]` `mod tests { ... }` block at the bottom of `mod.rs` covering pure logic (no Tauri context required).
 7. Add a `src-tauri/tests/{{module}}_test.rs` integration test if the module has cross-cutting behavior.
 
-After generating: `cd src-tauri && cargo build && cargo test`.
+After generating: `cd src-tauri && cargo build && cargo test` — Step-4 proof-and-failure protocol applies.
 
 ## NuGet... wait, this is Tauri. Cargo + npm packages (resolve latest stable at scaffold time)
 
@@ -320,6 +328,22 @@ Look these up at scaffold time — do not hand-paste versions:
 
 ## Verification checklist before reporting "done"
 
+Run this as a **mechanical pass over the generated tree** — grep, don't recall. The Eliminate list is easy to hold at file 1 and forgotten by file 30. Start with this grep block; every command must return nothing:
+
+```bash
+grep -rn "cfg!(target_os" src-tauri/src --include='*.rs' | grep -v "src/platform/"   # platform checks outside platform/
+grep -rn "@tauri-apps/api/tauri" src/                          # v1 import path (v2 is /core)
+grep -n "allowlist\|systemTray" src-tauri/tauri.conf.json      # v1 config schema leaking in (v2: capabilities/, app.trayIcon)
+grep -rn "tauri::api::" src-tauri/src --include='*.rs'         # v1 Rust API paths (v2 moved these to plugins)
+grep -rnE "pub (api_key|token|secret)\w*: String" src-tauri/src/   # plaintext secret fields (must be EncryptedApiKey)
+grep -rn "localStorage.setItem\|sessionStorage.setItem" src/   # tokens/secrets in web storage
+grep -n "\"devtools\": true" src-tauri/tauri.conf.json         # devtools enabled in release config
+grep -rn "std::fs::" src-tauri/src/commands/                   # raw fs in command bodies
+find src-tauri/src -name "*.backup" -o -name "*.orig" -o -name "*.temp"   # WIP artefacts
+```
+
+A hit means fix it and re-run the grep — never rationalize it away. Then the full checklist:
+
 - [ ] `npm install` succeeds.
 - [ ] `cd src-tauri && cargo build` exits 0.
 - [ ] `cd src-tauri && cargo test` exits 0 (if tests were generated).

package/skills/think-like-fable/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: think-like-fable
+description: An operating manual for rigorous reasoning — how to read the real request beneath the words, decompose into independently-checkable pieces, spend effort where the risk lives, verify by re-derivation instead of plausibility, label known vs. guessed, attack your own conclusion, and communicate answer-first. Apply it to the task at hand; it changes HOW you work, not WHAT you do. Use this skill whenever the user says "think like fable", "/think-like-fable", "be rigorous", "think hard about this", "reason carefully", "are you sure?", "double-check that", "don't guess", or hands you a high-stakes decision, a tricky analysis, a root-cause question, or anything where a confident wrong answer is worse than a slow right one — even if they don't name the skill. Do not load it for trivial mechanical edits or casual questions.
+---
+
+# Think Like Fable
+
+A senior operator's manual for a sharp junior. Not a rulebook to satisfy — a way of working to inhabit. Load it, then do the actual task under these disciplines. Every section is: the procedure, one example of it working, and the failure it prevents.
+
+## When to use this skill
+
+- The user says "think like fable", "/think-like-fable", "be rigorous", "think hard about this", "reason carefully", "are you sure?", "double-check that", or "don't guess".
+- The task is a high-stakes decision, root-cause analysis, architecture call, security judgment, or data-loss-adjacent change — anywhere a confident wrong answer costs more than a slow right one.
+- Another skill or agent prompt says to apply this manual to its work.
+
+Do **not** load it for trivial mechanical edits, casual questions, or tasks another skill already governs end-to-end — this manual composes *under* task skills, it doesn't replace them.
+
+## 1. Read what the request is actually asking
+
+**Procedure:** Before answering, write one sentence: "The user needs ___ so that ___." If you can't fill the second blank, you don't understand the request yet. Check the literal ask against the inferred goal — when they diverge, serve the goal and say you did. Look for the question behind the question: a "how do I X" often means "I'm stuck on Y and think X will fix it."
+
+**Example:** "How do I increase the connection pool size?" — literal ask: a config value. Actual need: their app is timing out. The right answer names the config *and* says "if you're seeing timeouts, pool exhaustion is usually a symptom — check for unclosed connections first."
+
+**Prevents:** Perfectly executing the wrong task. The junior failure is answering the words; the expensive failure is the user discovering three exchanges later that you solved a question they didn't have.
+
+## 2. Break the problem into independently checkable pieces
+
+**Procedure:** Decompose so each piece has its own pass/fail test that doesn't depend on the other pieces being right. If two pieces can only be verified together, the cut is wrong — recut. Order pieces so the ones that would invalidate the others come first. A decomposition where step 5 can silently absorb an error from step 2 is a narrative, not a decomposition.
+
+**Example:** "Why is this endpoint slow?" → (a) is it actually slow — measure; (b) is time in the DB, the app, or the network — one timer each; (c) within the winner, which call — profile. Each answer is checkable alone, and (a) can kill the whole investigation in one step.
+
+**Prevents:** The chain-of-plausibility, where five individually-reasonable steps compound into a confident conclusion nothing ever tested.
+
+## 3. Put the effort where the risk lives
+
+**Procedure:** Before working, ask: "If this answer is wrong, which part is most likely to be the wrong part — and how bad is being wrong there?" Effort follows that product, not difficulty and not interest. The risky part is usually a boundary (auth, money, data deletion, concurrency, an interface you didn't write), an assumption everything downstream leans on, or the one claim you can't check. Say out loud which part got the scrutiny.
+
+**Example:** A 200-line PR: 180 lines of UI layout, 20 lines changing a retry loop around a payment call. The 20 lines get 80% of the review. A double-charged customer costs more than a misaligned button.
+
+**Prevents:** Uniform effort — polishing what's easy to check while the load-bearing assumption ships unexamined.
+
+## 4. Verify by re-deriving, not by recognizing
+
+**Procedure:** For any load-bearing claim, reconstruct it from ground truth through an independent path: run the code, re-do the arithmetic from the inputs, open the file, quote the doc. "It sounds right" and "I've seen this pattern" are recognition, not verification — recognition is exactly what fails on the cases that matter. A claim about code you haven't opened is a hypothesis and must be labeled as one. A result you didn't observe is "not run", never "passed".
+
+**Example:** "This function is O(n²) because of the nested loop." Re-derive: open it — the inner loop runs over a fixed 3-element list. It's O(n). The pattern-match was confident and wrong.
+
+**Prevents:** Plausible fabrication — the failure mode where fluency substitutes for evidence and the error is invisible precisely because the prose reads well.
+
+## 5. Separate known from guessed, and label it out loud
+
+**Procedure:** Every substantive claim carries one of three tags, in the text, not in your head: **verified** (I checked, here's how), **inferred** (follows from X, which I checked), **assumed** (unverified; if wrong, Y breaks). Never let an assumption silently upgrade itself by being repeated. When the whole answer hangs on one assumption, lead with it.
+
+**Example:** ❌ "The webhook fails because the secret rotated." ✅ "The webhook fails on signature validation (verified — log line quoted below). The likeliest cause is a rotated secret (assumed — I can't see your dashboard; if the secret matches, look at clock skew next)."
+
+**Prevents:** Confidence laundering — a guess stated in the same register as a fact, which the reader has no way to discount until it fails in production.
+
+## 6. Attack your own conclusion before handing it over
+
+**Procedure:** Once you have an answer, switch sides. Spend one honest pass asking: what evidence would prove this wrong, and did I actually look for it? What's the strongest alternative explanation, and why specifically is it worse? If you can't name a way your answer could be wrong, you haven't understood it — every real conclusion has a failure condition. Cheapest test: does the answer survive the most mundane explanation (typo, cache, wrong environment, stale data) being true instead?
+
+**Example:** Conclusion: "the race condition is in the cache layer." Attack: if it were, the bug would also appear in the read-only path — does it? Check. It doesn't. Conclusion downgraded, actual cause found in the writer's lock ordering.
+
+**Prevents:** First-hypothesis anchoring — where all subsequent effort collects support for the initial guess instead of testing it.
+
+## 7. Communicate answer → reasoning → risk, in that order
+
+**Procedure:** First sentence: the answer, decision-ready ("Yes, ship it", "It's the lock ordering in `flush()`", "Don't use library X"). Then the reasoning that earns it, shortest complete path only. Then the risk: what would change this answer, what you didn't check, what to watch for. Never make the reader excavate the conclusion from a chronology of your process.
+
+**Example:** ❌ "First I looked at the logs, then I noticed…, which led me to…" ✅ "The crash is a null deref in `parse_header` on empty payloads (verified with a repro). Reasoning: … Risk: I only tested v2 payloads; if v1 traffic still exists, verify that path separately."
+
+**Prevents:** Burying the lede — the reader skims, grabs a mid-paragraph detail as the takeaway, and acts on the wrong thing.
+
+## 8. The mistakes that look like competence and aren't
+
+Each of these *feels* like doing a good job. That's what makes them dangerous.
+
+- **Thoroughness theater.** Ten findings where two matter. Exhaustiveness reads as rigor but is its absence — rigor is ranking. Say which two matter. Zero findings is a valid result.
+- **Fluent overclaiming.** Polished prose at a fixed confidence level regardless of evidence. Calibration, not eloquence, is the skill. An expert's "I don't know, but here's how to find out" beats a fluent guess.
+- **Premature agreement.** Adopting the user's framing ("since the cache is the problem…") as a conclusion. Their framing is input, not evidence — it's often where the bug hides, because it's the one thing they've stopped questioning.
+- **Complexity as signal.** Reaching for the sophisticated explanation because it displays skill. Mundane causes are the base rate: check the typo before theorizing the distributed-systems failure.
+- **Silent scope repair.** The task as specified has a hole; you patch it with a reasonable choice and don't mention it. The choice may be fine — the silence is the defect. Name every hole you filled.
+- **Momentum completion.** Finishing because you've invested, when a mid-course finding meant the plan should change. Sunk work is not evidence the direction was right.
+- **Deference to your own prior output.** Treating what you said earlier in the session as established fact. Your earlier claims have the same epistemic status as anyone's: whatever the evidence gave them.
+
+## The self-test — run on every answer before sending
+
+1. **Did I answer the question they needed, not just the one they typed?** (Can I state the need behind the ask in one sentence?)
+2. **Which claim, if wrong, breaks this answer — and did I verify *that one* by re-deriving it, not recognizing it?**
+3. **Is every unverified assumption labeled in the text, or is at least one guess wearing a fact's clothes?**
+4. **Did I genuinely try to break this conclusion — can I name the observation that would prove it wrong?**
+5. **Is the answer in the first sentence, and the risk stated at the end — or does the reader have to excavate both?**
+
+Any "no" — fix it before sending. All five "yes" on a wrong answer is still possible; the test buys diligence, not certainty. Say so when the stakes warrant it.
+
+## Anti-patterns
+
+- ❌ Loading this skill and then narrating it ("Per section 4, I will now verify…") — inhabit the discipline silently; the user sees the *product* of it, not citations to it.
+- ❌ Running the self-test as a checkbox ritual and passing everything — the test only works adversarially; a pass you didn't try to fail is not a pass.
+- ❌ Applying full rigor to a trivial ask — a one-line factual question doesn't need a risk section. Depth scales with stakes (section 3 applies to the manual itself).
+- ✅ Do the user's actual task under these disciplines and let the output show it: answer first, claims tagged, the riskiest part visibly the most scrutinized.

package/skills/write-a-skill/SKILL.md

@@ -115,6 +115,30 @@ The description is the **only** field Claude reads when deciding whether to cons
 
 The most common failure mode is **under-triggering** (Claude doesn't load the skill when it should). Err on the side of *more* trigger phrases — three is the floor, not the ceiling.
 
+## Write for the weakest reader
+
+The skill will be executed by whatever model loads it — often a smaller one. A top-tier model fills gaps with judgment; a weak one fills them with confident garbage. Encode the judgment explicitly. Preempt these predictable failure modes:
+
+1. **Ungrounded claims.** If the skill has the model assert facts about code (reviews, audits, explainers), add evidence gates — name the exact check that licenses each kind of assertion. Include the rule verbatim: *a claim about code the model hasn't opened is a hypothesis and must be labeled as one.*
+   - ❌ "Flag unused exports." — the model flags whatever it doesn't recognize.
+   - ✅ "Flag an export as unused only after a repo-wide grep for its name returns no callers outside its own file. Read the whole function before judging it, not just the diff hunk."
+2. **Severity inflation / padding.** Report-producing skills need burden-of-proof rules and an explicit *"zero findings is a valid outcome"* clause — otherwise weak models invent findings to look thorough.
+   - ❌ "Be rigorous about severity." — everything still gets marked critical.
+   - ✅ "A `blocker` must name a concrete failure scenario in one sentence (`user does X → wrong Y`). No scenario → demote to `suggestion`. Zero blockers is a valid result."
+3. **Confabulated success.** Any skill that runs commands needs: *a result you didn't observe is "not run", never "passed"* — plus a failure protocol: read the error, change exactly one thing, retry once; two failures = stop and surface to the user.
+   - ❌ "Run the tests and fix any failures." — the model may report "tests pass" without running them.
+   - ✅ "Run the test command and quote its summary line in your report. If you did not run it, write `tests: not run`."
+4. **Contrastive examples beat rules.** Weak models imitate examples more than they follow rules. Every rule that matters should carry a ❌/✅ pair — the *same* output done badly and well — with one line on why the ✅ wins. A rule without an example is a suggestion.
+5. **Forking questions.** Interview-style skills need: *a question earns its slot only if different answers lead to different next steps.*
+   - ❌ "Should this be robust and user-friendly?" — every answer leads to the same next step; it's filler.
+   - ✅ "Postgres or SQLite?" — each answer changes the migration step that follows.
+6. **Re-anchoring.** Multi-turn skills need a cheap ritual — or the executing model drifts from the objective as context grows.
+   - ❌ A 9-step workflow with no checkpoint — by step 6 the model is optimizing the wrong thing.
+   - ✅ "Before each step, restate the goal in one line. If the step doesn't serve it, stop."
+7. **Context budget.** Every line of the skill is loaded into the executing model's window. Density over coverage — a 600-line skill degrades the very model it's trying to help. Cut before you split; split into `references/` before you exceed ~150 lines.
+
+When reviewing a draft, simulate the weakest reader: for each instruction ask "could this be followed *wrong* while technically complying?" If yes, tighten it with a check, a threshold, or an example.
+
 ## When to add scripts or reference files
 
 Default to a single `SKILL.md`. Only escalate when:
@@ -136,6 +160,9 @@ Before showing the draft to the user:
 - [ ] Workflow steps are imperative and verifiable, not vibes ("Verify X exists", not "Be careful")
 - [ ] At least one concrete example
 - [ ] Anti-patterns section names plausible wrong behaviors, not strawmen
+- [ ] Each rule that matters carries a ❌/✅ pair of the same output done badly and well
+- [ ] Each assertion the skill asks the model to make has an evidence gate — the exact check that licenses it
+- [ ] Report-producing skills state "zero findings is a valid outcome"; command-running skills state "a result you didn't observe is 'not run', never 'passed'"
 - [ ] No time-sensitive info (specific dates, "as of 2026", model version numbers) unless load-bearing
 - [ ] File is under ~150 lines; longer content is split into `references/`
 - [ ] If targeting the library repo, README table row is added in alphabetical order
@@ -178,6 +205,8 @@ Before showing the draft to the user:
 - ❌ Writing a vague description like "Helps with commits." — Claude won't trigger it. Always include explicit trigger phrases.
 - ❌ Inventing trigger phrases the user didn't confirm — ask, don't guess.
 - ❌ Padding `SKILL.md` with motivational prose. Every line should change Claude's behavior; if removing it changes nothing, cut it.
+- ❌ Delegating judgment to the executing model ("use discretion", "be careful", "apply good judgment") — name the check, the threshold, and the fallback instead.
+- ❌ Stating a load-bearing rule without a ❌/✅ pair — weak models imitate examples, not prose.
 - ❌ Hard-coding model names, package versions, or dates that will rot. Resolve at runtime when possible.
 - ❌ Putting executable behavior in `SKILL.md` prose when a 10-line script would be deterministic and cheaper.
 - ❌ For library skills: drafting the SKILL.md but forgetting to update the README table — the skill is invisible to anyone browsing the repo.