leetcode-init

name	leetcode-init
description	Use when initializing a LeetCode Python problem from a same-name `.txt` prompt dump and `.py` stub, especially when the goal is to scaffold a local runner and unittest coverage without generating the solution itself.

LeetCode Init

Purpose

Turn a copied LeetCode prompt text file plus its matching Python stub into a runnable local scaffold that stays solution-free.

The scaffold should help the user test their own implementation later, not solve the algorithm for them.

Required Workflow

1. Resolve the target problem pair.
   • Prefer an explicitly named slug or file path.
   • Otherwise work from the current directory only when there is exactly one same-name .txt and .py pair.
2. Run the bundled initializer script:
   • python3 ~/linux-config/dot_agents/skills/leetcode-init/scripts/init_leetcode_problem.py <slug-or-path>
3. Review the script output diff before moving on.
4. Confirm the generated Python file still leaves the Solution method unimplemented.
5. Tell the user what was scaffolded and point them at the generated runner:
   • python3 <problem>.py
   • python3 <problem>.py --test

What The Script Generates

• A self-contained problem file with a __main__ example runner
• Inline unittest coverage generated from the prompt examples
• Runtime actual-vs-expected diff output when examples do not match
• Full Python stack traces with line numbers when the current solution raises at runtime
• Inline TreeNode and ListNode helpers only when the method signature needs them

Guardrails

• Do not generate the actual algorithmic solution.
• Do not overwrite a Python file that already contains substantive user implementation unless it was previously generated by this skill.
• Use the examples from the .txt file as the source of truth for the scaffolded test cases.
• Keep the generated harness self-contained in the problem file instead of introducing a shared helper module for LeetCode structures.

Notes

• The script currently targets common LeetCode prompt shapes where examples are written as Example N: blocks with Input: and Output: lines.
• Tree and linked-list examples are handled from the method signature type hints, so keep those hints intact in the stub before running the initializer.