leetcode/.omp/commands/sync-solutions.md

---
description: Sync work/ leetcode solutions into docs/solutions/ pages (gold standard format)
---

Sync every leetcode solution under `work/` into a docs page under `docs/reference/`, formatted exactly like the gold standard `docs/solutions/01-reverse-string.mdx`. Extra focus (optional): $@

## Inventory

1. Glob `work/**/*.js`. Each filename is `<number>.<kebab-slug>.js`; the directory path is `work/<Difficulty>/<Category>/`.
2. Glob `docs/solutions/*.mdx`. A solution is already ported when a page's frontmatter title starts with the same leetcode number (`title: '<number>. …'`). Numeric filename prefixes (`01-`, `02-`, …) define sidebar order — never renumber existing pages.
3. Build the todo list: one task per unported solution, plus one task per already-ported page whose `## Answer` code block no longer matches its `work/` source verbatim (update just the code block in that case).

## Target path

`docs/solutions/<NN>-<kebab-slug>.mdx` where `<NN>` is the next unused two-digit prefix (continue from the highest existing one, in ascending leetcode-number order for the new batch) and `<kebab-slug>` is the slug from the work filename.

## Page format — copy the gold standard exactly

Every work file has a header comment block containing the problem statement, examples, constraints, and any follow-up. Transform it into:

````mdx
---
title: '<number>. <Problem Name>'
description: <first sentence of the problem statement, no trailing period>
sidebar:
  badge: '<Difficulty>'
---

<Badge variant="accent"><Topic></Badge>

::::warning
<the follow-up or special requirement, verbatim>
::::

### Example 1:
- Input: `<input>`
- Output: `<output>`
- Explanation: <explanation with array/value literals wrapped in backticks>

### Constraints:

- `<constraint>` (inline code; keep plain prose like "nums is sorted…" with only identifiers in backticks)

## Answer

```js
<the JSDoc comment and function from the work file, byte-for-byte verbatim — do not reformat, rename, or "improve" the code>
```
````

Rules:

- `<Topic>`: the problem's pattern category from the curriculum tables in `README.md` (e.g. "Two Pointers", "Hash-Based Lookup" → use "Hash Table", "Sliding Window", "Prefix Sum"). Fall back to the `work/` subdirectory name if the problem isn't in the README.
- `::::warning`: only when the statement has a follow-up, in-place requirement, or similar special constraint. Omit the block entirely otherwise.
- One `### Example N:` section per example in the header comment; include the Explanation bullet only when the source has one.
- Exponents stay caret-style in inline code (`10^4`), matching the source comments.
- Do NOT copy the header comment block into the page — only the JSDoc + function go in the code fence.

## Verify

1. `bunx blume build --isolated` must succeed with no new warnings; confirm each new route generated (`/solutions/<slug>`).
2. Spot-check one new page's built HTML for the badge, callout (when present), and solution code.
3. `rm -rf .blume-verify` when done.

Report a table: work file → docs page → created / updated / skipped (already in sync).