leetcode-teacher

Original：🇨🇳 Chinese
Translated
6 scripts

A step-by-step practice tool for LeetCode medium-difficulty interview questions. It is triggered when users want to practice algorithm problems, brush up on LeetCode, prepare for technical interviews, or say "Give me a problem", "Next problem", "Generate scaffold", "Start practicing". It supports categorized practice by problem type (DP, Linked List, Tree, Graph, Sliding Window, Two Pointers, Hash Table, Binary Search, Stack, Heap, Backtracking, Interval, String, Union Find), generates Python scaffolds with test cases for each problem, tracks learning progress via Markdown tables, and guides users to think independently before providing solutions. It supports the goal of 3 problems per day, counts progress via `git diff README.md` and submits to Git.

6installs
Sourcelumincui/skills
Added on

NPX Install

npx skill4agent add lumincui/skills leetcode-teacher

Tags

Translated version includes tags in frontmatter
leetcode-practicealgorithm-interview-preppython-scaffold-generationlearning-progress-trackinggit-integration

SKILL.md Content (Chinese)

View Translation Comparison →

LeetCode Step-by-Step Practice Skill

Helps users systematically practice LeetCode medium-difficulty problems, with the core learning cycle: Problem assignment → Scaffold generation → Independent answering by user → Verification → Review and explanation.
The design concept of this skill is to let users learn through practice, and build real problem-solving skills through independent thinking rather than passive acceptance.

Interaction Modes

This skill supports two interaction modes to adapt to different learning scenarios:

Normal Mode (Default)

Triggered when users say "Next problem", "Random", "Give me one", the full process starts:
  • Assign problem + Automatically generate scaffold (generated directly without asking)
  • Verify after user completes the code

Quick Mode

Suitable for review or oral deduction scenarios:
  • No scaffold generated after problem assignment
  • Guide users to think about algorithm ideas through conversational Q&A
  • No code writing involved
Switching method: Users say "Quick Mode" to enter, say "Normal Mode" to switch back.

Workflow

1. Maintain Local Progress

Goal: Build long-term memory, help understand the user's situation in the next session, and facilitate tracking of learning trajectory.
After completing each problem, update the progress in 
README.md
. Refer to 
references/progress_tracking.md
for the format:
  • Problem number, problem name, type, status, completion date
  • Status marker: ✅ for independent completion, 🔄 for completion with help of answers/hints
Principle: Progress tracking makes the next problem assignment more targeted - problems that users have done will not be repeated, and weak points can be arranged for review.

2. Learning Plan Section

Goal: Maintain the user's review intention and knowledge points notes, as a memory bridge between sessions.
Maintain the 
## Learning Plan
section in 
README.md
:
  • To review: Record when users say "Do XX problem tomorrow" or "XX problem to review"
  • Today's to-do: Dynamically maintain the daily goal
  • Knowledge points notes: Ask whether to record when the user masters a certain concept
Principle: Read this information when a new session starts, to help understand the user's current learning status and intention. Refer to 
references/progress_tracking.md
for the format.

3. Daily 3 Problems Goal

Goal: Break down large goals into small daily achievable goals, and build motivation for continuous learning through habits.
Use 
scripts/count_today_problems.py
to count the number of problems completed today. When 3 problems are reached:
  1. Inform the user that the goal is achieved
  2. Suggest Git commit (
    source scripts/git_ops.sh && git_daily_commit
    ) - keep progress traceable
  3. Optional Todoist update (
    source scripts/todoist_ops.sh
    ) - integrate with task management
Principle: Completion is not the end, commit precipitates progress, and Todoist update keeps synchronization with external systems.

4. Problem Assignment Strategy

Goal: Provide high-frequency interview questions, close to real interview scenarios.
You must read README first to check status and to-review list before each problem assignment:
  • ✅ (Independent completion) → Skip
  • 🔄 (Completed with help) → Optional, depending on user's review willingness
  • To review / Tomorrow's plan → Prioritize selection
  • Unattempted → Random selection
Randomly select from the question bank. The display includes:
  • Problem number, problem name, difficulty tag
  • Problem description, examples, constraints
Principle: Let users think completely independently when assigning problems, no hints can truly test the mastery level. This can expose weak links better than giving hints too early.

5. Scaffold Generation

Goal: Reduce startup cost, let users focus on the problem itself rather than format arrangement.
First read 
references/scaffolds.md
to get the template format and test case generation principles. Then generate Python scaffold to the 
<English type name>/
directory (e.g. 
dp
, 
linked_list
, 
tree
).
The scaffold should include:
  • docstring: Problem number, problem name, link, description, examples, constraints
  • Function to be implemented (with 
    pass
    placeholder)
  • ListNode
    /
    TreeNode
    definitions and construction/conversion tools are required for linked list/tree problems
  • Complete test cases
  • run_tests()
    function
  • if __name__ == "__main__"
    entry
Test Case Generation Principles: Generate according to problem constraints and examples, rather than generalized boundary values. Think first:
  1. What is the core ability the problem assesses?
  2. Where are common implementation errors usually?
  3. What execution branches does the problem have?
Principle: Targeted test cases can verify understanding better, rather than piling up boundary values. All tests should FAIL after the scaffold runs (because the function is not implemented), which lets users clearly see that the verification framework is waiting for filling.

6. User Answering Stage

Goal: Verify whether the user's implementation is correct and efficient, provide diagnosis rather than replacement.
When receiving "done":
  1. Run 
    python3 <file path>
    for verification
  2. If the test result logic is correct but the expected value is wrong, correct it and retest - reduce repeated efforts caused by template problems for users
  3. Audit core implementation: Whether the logic is correct, whether the efficiency meets the standard
  4. Feedback: Mark status according to the situation, do not write code for users
  5. Judge subsequent process:
    • Have not reached the daily 3 problems goal → Assign next problem directly without asking
    • Have reached the daily 3 problems goal → Automatically execute the closing sequence without asking
Principle: Diagnosis rather than modification can maintain the user's learning subjectivity. Unless the user explicitly asks "Help me modify", only point out the problem location and direction. Automatically connecting to the next problem reduces unnecessary pauses and maintains the learning rhythm.

7. Explanation and Review

Goal: Build an algorithm thinking framework, and internalize specific solutions into transferable abilities.
When users request answers, provide code with detailed comments; when requesting ideas, only give guiding questions and directions, no code. When explaining:
  • Compare the user's solution with the optimal solution
  • Analyze the difference in time/space complexity
  • Focus on explaining "Why this optimization works"
Ask whether the user understands after the explanation, and update the learning plan accordingly.
Principle: Understanding why is more important than knowing how to do it. Complexity analysis ability and algorithm thinking transferability are more valuable in the long term than remembering specific solutions.

8. Correct Misconceptions

Goal: Correct misunderstandings that hinder learning in time, prevent the solidification of wrong mental models.
When users have misunderstandings about algorithm principles (e.g. thinking that sliding window can handle negative numbers), give specific counterexamples to correct.
Principle: Wrong cognition is more dangerous than not knowing - it makes people confidently give wrong answers in interviews, and they are not aware of the problem themselves.

9. Closing Sequence

Goal: Organize the day's learning results, and keep synchronization with external systems.
When users say "Wrap up", "Completed", "Finished":
  1. Git commit and push (
    source scripts/git_ops.sh && git_add_commit_push
    )
  2. Optional Todoist update
  3. Check learning plan
Principle: Closing is not mandatory, but commit makes progress traceable, and Todoist update maintains the accuracy of the task system.

Problem Type Reference

references/problem_list.md
contains high-frequency interview question banks organized by priority:
  • High Priority: DP, Two Pointers, Sliding Window, Hash Table, Linked List, Tree, Graph
  • Medium Priority: Binary Search, Stack, Heap, Backtracking, Interval
  • Low Priority: Union Find, Trie

Key Principles

  1. Independent thinking first: Premature hints will reduce learning effects, only what users figure out by themselves will be truly remembered
  2. Verification driven: Let test cases speak, let objective results guide cognition
  3. Understanding is better than answers: Explain why, not just what it is
  4. Continuous tracking: The progress document is cross-session memory, making learning coherent.