Add ~/.omp config; nvim git-repo external; ya pkg install hook

- dot_omp: agent config/keybindings/mcp/themes/commands + loop defs,
  goals, run-loop.sh; dotstate config.yml symlink materialized; dbs,
  logs, sessions, memories, blobs, caches, .env (secret), and
  managed-skills excluded
- .chezmoiexternal.toml: prdlk/nvim as git-repo external — no
  refreshPeriod + ff-only pull, local checkout wins over remote
- yazi plugins: vendored source copies dropped (target-ignored already);
  package.toml is the manifest, installed via run_onchange ya pkg
  install hook; stale piper/easyjump pins bumped to match live content
- herdr: plugins/github checkout, logs, session.json, .bak,
  release-notes dropped from sync (herdr-managed machine state)

dot_omp/private_agent/commands/leetcode-docs.md

@@ -0,0 +1,84 @@
+---
+description: Convert a LeetCode solution file into a Fumadocs MDX docs page
+---
+
+Convert the LeetCode solution file at `$1` into a Fumadocs-formatted MDX page.
+
+Extra instructions (optional, may include output dir override): $@
+
+## Input format
+
+The source file follows the standard on-disk format:
+- A `/* ... */` header block: problem number, title, difficulty, LeetCode URL, problem description, examples, constraints
+- A JSDoc `@param`/`@return` block
+- One or more solution functions (possibly with line-by-line beginner comments and `// ====` banners)
+
+## Output location
+
+Default: write next to the content root at `content/docs/leetcode/<difficulty>/<category>/<number>-<slug>.mdx`, mirroring the source tree (e.g. `Easy/Array/1365.how-many-numbers.js` → `content/docs/leetcode/easy/array/1365-how-many-numbers.mdx`). Lowercase all path segments. If the extra instructions specify a different output path or content root, use that instead. Create directories as needed.
+
+## Page structure
+
+Produce exactly this shape:
+
+```mdx
+---
+title: 1365. How Many Numbers Are Smaller Than the Current Number
+description: <one-sentence summary of the technique, e.g. "Frequency map + prefix count — the counting hammer.">
+---
+
+<Callout title="Easy · Array · Hash Table">
+  [View on LeetCode](https://leetcode.com/problems/how-many-numbers-are-smaller-than-the-current-number/)
+</Callout>
+
+## Problem
+
+<problem description from the header block, reflowed into clean Markdown prose — no hard-wrapped 70-char lines>
+
+## Examples
+
+<each example as a fenced code block:>
+
+```txt title="Example 1"
+Input: nums = [8,1,2,2,3]
+Output: [4,0,1,1,3]
+```
+
+<if an example has an Explanation, put it as plain prose under its code block>
+
+## Constraints
+
+<bulleted list from the header block, with values in inline code: `2 <= nums.length <= 500`>
+
+## Solution
+
+<one-paragraph intuition: name the pattern (frequency map, prefix sum, two pointers, etc.) and the key insight in 2–3 sentences. Derive this from the code itself.>
+
+```js title="solution.js" lineNumbers
+<the solution function, verbatim — including any existing beginner comments>
+```
+
+<Callout type="idea" title="Complexity">
+  **Time:** O(n log n) — **Space:** O(n)
+</Callout>
+```
+
+## Rules
+
+1. **Frontmatter `title` carries the h1** — Fumadocs renders it as the page title, so never emit a `# heading` in the body.
+2. **Escape MDX hazards.** The header text may contain `<`, `>`, `{`, `}` (e.g. `j != i and nums[j] < nums[i]`, `2 <= nums.length <= 500`). Anything with these characters must be wrapped in inline code or fenced blocks, or the MDX compile will fail. When in doubt, inline-code it.
+3. **Code is verbatim.** Copy the solution function(s) exactly — do not rewrite, reformat, or strip existing comments. The docs page documents the code as it exists.
+4. **Multiple approaches → tab group:**
+   ````mdx
+   ```js tab="Frequency Map" tab-group="approach"
+   ...
+   ```
+
+   ```js tab="Sort + Map"
+   ...
+   ```
+   ````
+5. **Complexity callout is derived, not guessed blindly.** Read the code: nested loop → O(n²), sort → O(n log n), single pass + map → O(n). If genuinely ambiguous, state the dominant term and why in one clause.
+6. **Callout header line** = `<Difficulty> · <topic tags>`. Difficulty comes from the header block; infer 1–2 topic tags from the directory path and the technique used.
+7. **No invented content.** Problem statement, examples, and constraints come only from the header block. The intuition paragraph and complexity are the only sections you author.
+8. **After writing**, print one line: the output path. Nothing else.

dot_omp/private_agent/commands/leetcode-eli5.md

@@ -0,0 +1,74 @@
+---
+description: Add super-simple line-by-line comments to a LeetCode solution file
+---
+
+Add beginner-level line-by-line comments to the LeetCode solution file at: $1
+
+## Rules
+
+1. **Read the file first.** It follows the standard on-disk format:
+   - A `/* ... */` header block containing problem number, title, difficulty, URL, description, examples, and constraints
+   - A JSDoc `@param`/`@return` block
+   - The solution function(s)
+
+2. **Never touch the header block or JSDoc block.** Preserve them byte-for-byte.
+
+3. **Never change the code.** Do not rename variables, reformat logic, alter whitespace inside expressions, or "improve" anything. Comments only. The file must produce an identical AST after your edit.
+
+4. **Comment style — explain as if to a complete beginner who has never programmed:**
+   - One comment line (or short block) ABOVE each meaningful line/statement
+   - Use plain everyday language and physical metaphors:
+     - object/map → "box" ("Create an empty box to count how many times each number appears")
+     - increment → "add 1 to its count"
+     - `(freq[x] || 0) + 1` → "If we already saw this number, add 1 to its count. If we never saw it before, start counting from 1"
+     - sort comparator → spell out the rule in words ("put the letter that appears MORE times first; if tied, alphabetical order")
+     - return → say WHAT is being returned and WHY in plain words
+   - Explain the WHY, not just the WHAT ("so the next bigger numbers know there are more smaller ones")
+   - Inline comments (`// ...` at end of line) are fine for short trailing clarifications like `.join('')` → "glue the sorted letters back into a string"
+   - No jargon without immediate translation: if you must say "index", follow with "(its position)"
+
+5. **Add a section banner** above the solution function in this exact style:
+   ```js
+   // ============================================
+   // <problem number>. <problem title>
+   // ============================================
+   ```
+   Pull the number and title from the header block.
+
+6. **Multiple solutions in one file:** comment every one of them, each with its own banner (append "– Approach 2" etc. to the banner title).
+
+7. **Extra instructions** (if provided after the file path): $@
+
+8. **After editing**, print a one-line confirmation: file path + number of comment lines added. Nothing else.
+
+## Example transformation
+
+Input body:
+```js
+var smallerNumbersThanCurrent = function (nums) {
+  const freq = {};
+  for (let x of nums) freq[x] = (freq[x] || 0) + 1;
+  return nums.map((x) => smaller[x]);
+};
+```
+
+Output body:
+```js
+// ============================================
+// 1365. How Many Numbers Are Smaller Than the Current Number
+// ============================================
+
+var smallerNumbersThanCurrent = function (nums) {
+  // Create an empty box to store how many times each number appears
+  const freq = {};
+
+  // Go through every number in the list one by one
+  // If we already saw this number, add 1 to its count
+  // If we never saw it before, start counting from 1
+  for (let x of nums) freq[x] = (freq[x] || 0) + 1;
+
+  // Go through the original list and replace each number
+  // with "how many numbers are smaller than it"
+  return nums.map((x) => smaller[x]);
+};
+```