Pitfalls in Using Claude Code

Directory Navigation Problems (My Main Concern):

Claude Code frequently has trouble maintaining the correct working directory, often resetting to previous project directories or failing to change directories properly [BUG] wrong working directory · Issue #5038 · anthropics/claude-code +2. This is one of the most reported issues:

Wrong Working Directory: Users report Claude Code starting in the wrong directory even when launched from a different location, and continuing to reset back to incorrect directories even after correction [BUG] wrong working directory · Issue #5038 · anthropics/claude-code

from Perplexity, the key points are

  • Regularly use /clear or reset commands to refresh context and prevent drift.
  • Problems with Windows Subsystem for Linux (WSL) and global npm prefix permissions can block updates or cause errors—Linux users should prefer distro-managed packages.

Other than keep prompting it to stay in the right directory, I intend to improve the claud.md file, here are some sample md files.

And lastly and foremost importantly, always review AI’s work and don’t let AI to do git operation, which can be fatal!

# Python Data Science Project

## Environment Setup
- Python version: 3.11 (managed with pyenv)
- Virtual environment: `.venv/`
- Activate: `source .venv/bin/activate`
- Package manager: pip with requirements.txt

## Project Structure
## Key Libraries
- pandas for data manipulation
- scikit-learn for ML
- pytest for testing
- black for formatting
- mypy for type checking

## Commands
- `python -m pytest`: Run all tests
- `black .`: Format code
- `mypy src/`: Type check
- `python scripts/train.py`: Train model
- `jupyter lab`: Start Jupyter

## Data Handling
- Raw data in `data/raw/` - DO NOT MODIFY
- Processed data in `data/processed/`
- Use pandas for all CSV operations
- Always validate data types after loading

## Testing Requirements
- Write tests for all functions in src/
- Use pytest fixtures for test data
- Mock external API calls
- Minimum 80% code coverage

## Documentation
- Use Google-style docstrings
- Update README.md for any API changes
- Document all data transformations

Another example

# Advanced Full-Stack Project

## 🚨 CRITICAL RULES
- NEVER expose API keys in frontend code
- ALWAYS validate user input on backend
- USE rate limiting on all API endpoints
- CHECK authentication before any data access

## Tech Stack
- Frontend: React 18, TypeScript, MUI v5
- Backend: Node.js, Express, TypeScript
- Database: MongoDB with Mongoose
- Auth: JWT with refresh tokens
- Testing: Jest, Cypress for E2E

## Development Workflow
1. Pull latest from main
2. Create feature branch
3. Write tests first (TDD)
4. Implement feature
5. Run full test suite
6. Create PR with description

## Custom Shortcuts
When I type these commands, follow the specified workflow:

### QPLAN
- Analyze similar code in the codebase
- Determine if plan is consistent with existing patterns
- Identify reusable components/functions
- Create step-by-step implementation plan

### QCODE  
- Implement the plan
- Run tests after each major change
- Format code with Prettier
- Run TypeScript compiler
- Verify no linting errors

### QCHECK
Act as a skeptical senior engineer and:
1. Review all code changes
2. Check for security vulnerabilities
3. Verify error handling
4. Assess performance implications
5. Ensure tests cover edge cases

### QTEST
Create comprehensive tests for: $ARGUMENTS
- Unit tests with Jest
- Mock all external dependencies
- Test error scenarios
- Verify state changes
- Check accessibility

## API Development
- Use RESTful conventions
- Version APIs (/api/v1/)
- Return consistent error formats
- Include request ID in responses
- Log all API calls

## Database Guidelines
- Use transactions for multi-document operations
- Create indexes for frequently queried fields
- Soft delete (set deleted flag) instead of hard delete
- Always use parameterized queries

## Performance Rules
- Lazy load components when possible
- Implement pagination for lists > 20 items
- Cache API responses appropriately
- Optimize images before upload
- Use debouncing for search inputs

## Security Checklist
- [ ] Input validation
- [ ] SQL injection prevention
- [ ] XSS protection
- [ ] CSRF tokens
- [ ] Rate limiting
- [ ] Secure headers

A minimal and concise example

## Best Practices for CLAUDE.md Files

Keep CLAUDE.md files concise - you're writing for Claude, not onboarding a junior developer. Here are the key principles:

### 1. **Be Concise**
- Use bullet points, not paragraphs
- Remove redundant information
- Focus on what's unique to your project

### 2. **Structure Clearly**
- Start with critical rules/warnings
- Group related information
- Use consistent formatting

### 3. **Include Essential Commands**
- List all frequently used commands
- Explain any custom scripts
- Document build/test processes

### 4. **Define Code Style**
- Specify formatting preferences
- List coding patterns to follow
- Clarify what NOT to do

### 5. **Project-Specific Context**
Use CLAUDE.md to demystify your project's unique landscape:
- Unusual folder structures
- Custom conventions
- Domain-specific requirements

### 6. **Hierarchical Organization**
CLAUDE.md files can be hierarchical - place them at project root and in nested directories for more specific contexts

### 7. **Dynamic Updates**
When Claude makes mistakes, ask it to update CLAUDE.md to not make them again

### 8. **Custom Commands**
Create .claude/commands/ folder with markdown files for custom slash commands:

```markdown
# .claude/commands/fix-github-issue.md
Please analyze and fix GitHub issue: $ARGUMENTS

1. Use `gh issue view` to get details
2. Search codebase for relevant files
3. Implement necessary changes
4. Write and run tests
5. Create descriptive commit
6. Push and create PR

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.