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

description

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:

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

<the solution function, verbatim — including any existing beginner comments>

**Time:** O(n log n) — **Space:** O(n) ```

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:

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