new-problemlisted

# Recording a solved problem Every problem lives in two places: a solution file at the repo root and a study issue. CI checks that they agree, and the README index is regenerated from the issues. This skill walks the routine that keeps all of it consistent. **Order matters: create the issue first, then the file.** `check_solutions.py` treats a solution file with no matching issue as an error, so pushing the file first makes CI fail. ## Input needed from the user - the problem, as a LeetCode URL or just its number - their solution code - their notes: what the problem asks, and how they solved it The notes are the point of this repo - they are the user's study record, so ask for them rather than inventing them. Offer to draft from the code if the user wants, but let the user own the final wording. ## The voice of a note All 154 existing notes share a voice. A drafted note that does not match it reads as written by someone else, which defeats the point of a study record. - Plain declarative Korean - `~된다`, `~하면 된다`, `~한다`. Counted across the existing notes: 된다 142, 있다 61, 한다 31. Not polite form, not casual speech. - One bolded sentence carrying the key idea, rarely more. - State definitions go in a fenced block of their own: `dp[i][j] = ...` - Short paragraphs, frequent line breaks. Most notes run 250-400 characters; a hard problem with several moving parts earns more, but not by much. ## What is worth recording, and what is not About one note in six records a mist