dotfiles/dot_omp/private_agent/commands/leetcode-docs.md

---
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.