mirror of
https://github.com/harivansh-afk/veet-code.git
synced 2026-04-17 12:04:16 +00:00
claude files and readme
This commit is contained in:
parent
10d6c16285
commit
6603f0be75
5 changed files with 278 additions and 7 deletions
40
.claude/commands/add-tests.md
Normal file
40
.claude/commands/add-tests.md
Normal file
|
|
@ -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
|
||||||
47
.claude/commands/explain.md
Normal file
47
.claude/commands/explain.md
Normal file
|
|
@ -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}
|
||||||
|
```
|
||||||
146
.claude/commands/generate.md
Normal file
146
.claude/commands/generate.md
Normal file
|
|
@ -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.
|
||||||
42
.claude/commands/hint.md
Normal file
42
.claude/commands/hint.md
Normal file
|
|
@ -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)
|
||||||
10
README.md
10
README.md
|
|
@ -5,9 +5,8 @@ Built for people who enjoy programming, vim, claude code, ghostty panes and TUIs
|
||||||
## Features
|
## Features
|
||||||
|
|
||||||
- Browse problems by difficulty (easy/medium/hard)
|
- Browse problems by difficulty (easy/medium/hard)
|
||||||
- Auto-run tests when you save your solution
|
- Auto-run tests on file write
|
||||||
- Visual solved indicators
|
- Claude code slash command to generate problems, tests on demand
|
||||||
- Clean, minimal TUI
|
|
||||||
|
|
||||||
## Installation
|
## Installation
|
||||||
|
|
||||||
|
|
@ -37,7 +36,4 @@ veetcode
|
||||||
3. Open `problems/<difficulty>/<name>/solution.py` in your editor
|
3. Open `problems/<difficulty>/<name>/solution.py` in your editor
|
||||||
4. Implement the solution
|
4. Implement the solution
|
||||||
5. Write file - tests run automatically
|
5. Write file - tests run automatically
|
||||||
|
6. Generate more problems :)
|
||||||
## Generating Problems
|
|
||||||
|
|
||||||
Problems are generated via Claude Code slash commands
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue