From 6603f0be753d3b7e77380890b75d6ceaa95c3f80 Mon Sep 17 00:00:00 2001 From: Harivansh Rathi Date: Sun, 14 Dec 2025 15:57:02 -0500 Subject: [PATCH] claude files and readme --- .claude/commands/add-tests.md | 40 ++++++++++ .claude/commands/explain.md | 47 +++++++++++ .claude/commands/generate.md | 146 ++++++++++++++++++++++++++++++++++ .claude/commands/hint.md | 42 ++++++++++ README.md | 10 +-- 5 files changed, 278 insertions(+), 7 deletions(-) create mode 100644 .claude/commands/add-tests.md create mode 100644 .claude/commands/explain.md create mode 100644 .claude/commands/generate.md create mode 100644 .claude/commands/hint.md diff --git a/.claude/commands/add-tests.md b/.claude/commands/add-tests.md new file mode 100644 index 0000000..d546e7a --- /dev/null +++ b/.claude/commands/add-tests.md @@ -0,0 +1,40 @@ +--- +description: Add more test cases to an existing problem +argument-hint: [problem-name] +allowed-tools: Read, Edit +--- + +# Add More Test Cases + +Add additional test cases to an existing problem to make it more challenging or cover more edge cases. + +## Problem +Problem name: $ARGUMENTS (if empty, ask which problem) + +## Process + +1. Read the existing solution.py and tests.py for the problem +2. Analyze what edge cases are NOT covered +3. Ask the user what kind of tests they want: + - Edge cases (empty, single element, boundaries) + - Performance tests (large inputs) + - Tricky cases (duplicates, negative numbers, special characters) + - Custom scenario they describe + +4. Add new test functions to tests.py using the Edit tool + +## Test naming convention +```python +def test_edge_case_{description}(): + """Clear description of what this tests.""" + ... + +def test_tricky_{description}(): + """Description of the tricky scenario.""" + ... +``` + +## Do NOT: +- Remove existing tests +- Modify the solution.py +- Add tests that are impossible given the constraints diff --git a/.claude/commands/explain.md b/.claude/commands/explain.md new file mode 100644 index 0000000..a2bac6e --- /dev/null +++ b/.claude/commands/explain.md @@ -0,0 +1,47 @@ +--- +description: Explain the solution approach for a completed problem +argument-hint: [problem-name] +--- + +# Explain Solution + +After the user has solved a problem (or given up), explain the optimal solution approach. + +## Problem +Problem name: $ARGUMENTS (if empty, ask which problem) + +## Process + +1. Read their solution.py to see their implementation +2. Provide explanation covering: + +### For a CORRECT solution: +- Confirm their approach works +- Explain time/space complexity +- Show alternative approaches if any exist +- Mention any optimizations they could make + +### For an INCORRECT or INCOMPLETE solution: +- Identify what's wrong without just giving the answer +- Explain the correct approach conceptually +- Walk through the algorithm step by step +- Show the optimal solution with detailed comments + +## Explanation Format + +``` +## Your Approach +{What they did and why it works/doesn't work} + +## Optimal Solution +{The best approach with complexity analysis} + +## Key Insight +{The "aha" moment or trick that makes this problem tractable} + +## Code Walkthrough +{Step-by-step explanation of the solution} + +## Similar Problems +{Related concepts to practice} +``` diff --git a/.claude/commands/generate.md b/.claude/commands/generate.md new file mode 100644 index 0000000..ea49dda --- /dev/null +++ b/.claude/commands/generate.md @@ -0,0 +1,146 @@ +--- +description: Generate a new practice problem with tests +argument-hint: [difficulty] [topic] +allowed-tools: Write, Bash(mkdir:*) +--- + +# Generate a New Practice Problem + +You are generating a practical implementation problem for veetcode - a terminal-based coding practice tool. + +## Arguments Provided +- Difficulty: $1 (if empty, ask user to choose: easy, medium, or hard) +- Topic: $2 (if empty, ask user what concept/topic they want to practice) + +## Problem Style Guide + +Generate **practical implementation** problems, NOT abstract LeetCode puzzles: + +### DO: +- Use real-world business context (e.g., "You are building a payment system...") +- Provide clear function signatures with type hints +- Include 2-3 concrete examples with explanations +- List explicit constraints +- Focus on practical skills: data transformation, validation, API-like operations + +### DON'T: +- Create pure algorithmic puzzles without context +- Use abstract mathematical framing +- Make problems that feel like textbook exercises + +## Difficulty Calibration + +**Easy** (15-25 min): +- Single data structure (list, dict, set) +- 1-2 core concepts +- 3-4 test cases +- ~20-30 lines solution + +**Medium** (30-40 min): +- Multiple data structures +- 3-4 concepts (sorting, hash maps, two pointers) +- 5-6 test cases including edge cases +- ~40-60 lines solution + +**Hard** (45-60 min): +- Custom classes or complex data structures +- 5+ concepts (DP, graphs, sliding window + state) +- 7-10 test cases with tricky edge cases +- ~80+ lines solution + +## Output Format + +### 1. First, confirm with the user: +- The difficulty level +- The topic/concept +- A one-line problem summary + +### 2. Generate the problem name +Create a kebab-case name (e.g., `validate-transactions`, `rate-limiter`, `word-frequency`) + +### 3. Create the directory +```bash +mkdir -p problems/{difficulty}/{problem-name} +``` + +### 4. Create solution.py + +Structure: +```python +""" +{Problem Title} + +{Story-based description in 2-3 sentences with real-world context} + +Example 1: + Input: {param1} = {value1}, {param2} = {value2} + Output: {expected} + Explanation: {why this is the answer} + +Example 2: + Input: {param1} = {value1}, {param2} = {value2} + Output: {expected} + +Constraints: + - {constraint 1} + - {constraint 2} + - {constraint 3} +""" + + +def {function_name}({params_with_types}) -> {return_type}: + """{One-line docstring describing what to return}.""" + pass # Your implementation here +``` + +### 5. Create tests.py + +Structure: +```python +import pytest +from solution import {function_name} + + +def test_basic_case(): + """Test the example from the problem description.""" + assert {function_name}(...) == ... + + +def test_another_case(): + """Test another typical case.""" + assert {function_name}(...) == ... + + +def test_edge_case_empty(): + """Test empty or minimal input.""" + assert {function_name}(...) == ... + + +def test_edge_case_boundary(): + """Test boundary conditions.""" + assert {function_name}(...) == ... + + +# Add more tests based on difficulty: +# Easy: 3-4 tests +# Medium: 5-6 tests +# Hard: 7-10 tests +``` + +## Example Problems by Topic + +**Arrays/Lists**: frequency counting, deduplication, sliding window, two pointers +**Strings**: parsing, validation, transformation, pattern matching +**Hash Maps**: grouping, caching, lookup optimization +**Trees/Graphs**: traversal, path finding, hierarchy operations +**OOP Design**: class design, state management, encapsulation +**Data Processing**: ETL operations, aggregation, filtering pipelines + +## After Generation + +Tell the user: +1. The path to their new problem: `problems/{difficulty}/{problem-name}/` +2. How to start practicing: `uv run veetcode` then select the problem +3. The file to edit: `solution.py` + +Now, let's generate a problem! If difficulty or topic weren't provided, ask the user to choose. diff --git a/.claude/commands/hint.md b/.claude/commands/hint.md new file mode 100644 index 0000000..5acfcfd --- /dev/null +++ b/.claude/commands/hint.md @@ -0,0 +1,42 @@ +--- +description: Get a hint for the current problem without spoiling the solution +argument-hint: [problem-name] +--- + +# Get a Hint + +The user needs a hint for a problem they're working on. + +## Problem to hint on +Problem name: $ARGUMENTS (if empty, ask which problem they need help with) + +## How to give hints + +1. First, read the problem's solution.py to understand what they're solving +2. Give hints in progressive levels - start vague, get more specific only if asked + +### Hint Levels: + +**Level 1 - Conceptual** (give first): +- What data structure would be useful here? +- What's the key insight or pattern? +- Example: "Think about how you could avoid checking every pair..." + +**Level 2 - Approach** (if they ask for more): +- General algorithm approach without code +- Time/space complexity target +- Example: "A hash map could let you check in O(1) if you've seen a complement..." + +**Level 3 - Pseudocode** (if still stuck): +- Step-by-step logic without actual code +- Key operations to perform +- Example: "For each element: calculate what you need, check if you've seen it, store current..." + +## Rules +- NEVER show the actual solution code +- NEVER give away the answer directly +- Ask if they want more specific hints after each level +- Encourage them to try implementing after each hint + +## Read the problem first +Read: problems/*/$ARGUMENTS/solution.py (find the matching problem directory) diff --git a/README.md b/README.md index d1bd972..7044932 100644 --- a/README.md +++ b/README.md @@ -5,9 +5,8 @@ Built for people who enjoy programming, vim, claude code, ghostty panes and TUIs ## Features - Browse problems by difficulty (easy/medium/hard) -- Auto-run tests when you save your solution -- Visual solved indicators -- Clean, minimal TUI +- Auto-run tests on file write +- Claude code slash command to generate problems, tests on demand ## Installation @@ -37,7 +36,4 @@ veetcode 3. Open `problems///solution.py` in your editor 4. Implement the solution 5. Write file - tests run automatically - -## Generating Problems - -Problems are generated via Claude Code slash commands \ No newline at end of file +6. Generate more problems :) \ No newline at end of file