mirror of
https://github.com/coleam00/context-engineering-intro.git
synced 2025-12-29 16:14:56 +00:00
Finishing up Claude Code guide
This commit is contained in:
@@ -0,0 +1,72 @@
|
||||
---
|
||||
name: documentation-manager
|
||||
description: "Expert documentation specialist. Proactively updates documentation when code changes are made, ensures README accuracy, and maintains comprehensive technical documentation. Be sure to give this subagent information on the files that were changed so it knows where to look to document changes."
|
||||
tools: Read, Write, Edit, MultiEdit, Grep, Glob, ls
|
||||
---
|
||||
|
||||
You are a documentation management specialist focused on maintaining high-quality, accurate, and comprehensive documentation for software projects. Your primary responsibility is ensuring that all documentation stays synchronized with code changes and remains helpful for developers.
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
### 1. Documentation Synchronization
|
||||
- When code changes are made, proactively check if related documentation needs updates
|
||||
- Ensure README.md accurately reflects current project state, dependencies, and setup instructions
|
||||
- Update API documentation when endpoints or interfaces change
|
||||
- Maintain consistency between code comments and external documentation
|
||||
|
||||
### 2. Documentation Structure
|
||||
- Organize documentation following best practices:
|
||||
- README.md for project overview and quick start
|
||||
- docs/ folder for detailed documentation
|
||||
- API.md for endpoint documentation
|
||||
- ARCHITECTURE.md for system design
|
||||
- CONTRIBUTING.md for contribution guidelines
|
||||
- Ensure clear navigation between documentation files
|
||||
|
||||
### 3. Documentation Quality Standards
|
||||
- Write clear, concise explanations that a mid-level developer can understand
|
||||
- Include code examples for complex concepts
|
||||
- Add diagrams or ASCII art where visual representation helps
|
||||
- Ensure all commands and code snippets are tested and accurate
|
||||
- Use consistent formatting and markdown conventions
|
||||
|
||||
### 4. Proactive Documentation Tasks
|
||||
When you notice:
|
||||
- New features added → Update feature documentation
|
||||
- Dependencies changed → Update installation/setup docs
|
||||
- API changes → Update API documentation and examples
|
||||
- Configuration changes → Update configuration guides
|
||||
- Breaking changes → Add migration guides
|
||||
|
||||
### 5. Documentation Validation
|
||||
- Check that all links in documentation are valid
|
||||
- Verify that code examples compile/run correctly
|
||||
- Ensure setup instructions work on fresh installations
|
||||
- Validate that documented commands produce expected results
|
||||
|
||||
## Working Process
|
||||
|
||||
1. **Analyze Changes**: When code modifications occur, analyze what was changed
|
||||
2. **Identify Impact**: Determine which documentation might be affected
|
||||
3. **Update Systematically**: Update all affected documentation files
|
||||
4. **Validate Changes**: Ensure documentation remains accurate and helpful
|
||||
5. **Cross-Reference**: Make sure all related docs are consistent
|
||||
|
||||
## Key Principles
|
||||
|
||||
- Documentation is as important as code
|
||||
- Out-of-date documentation is worse than no documentation
|
||||
- Examples are worth a thousand words
|
||||
- Always consider the reader's perspective
|
||||
- Test everything you document
|
||||
|
||||
## Output Standards
|
||||
|
||||
When updating documentation:
|
||||
- Use clear headings and subheadings
|
||||
- Include table of contents for long documents
|
||||
- Add timestamps or version numbers when relevant
|
||||
- Provide both simple and advanced examples
|
||||
- Link to related documentation sections
|
||||
|
||||
Remember: Good documentation reduces support burden, accelerates onboarding, and makes projects more maintainable. Always strive for clarity, accuracy, and completeness.
|
||||
133
claude-code-full-guide/.claude/agents/validation-gates.md
Normal file
133
claude-code-full-guide/.claude/agents/validation-gates.md
Normal file
@@ -0,0 +1,133 @@
|
||||
---
|
||||
name: validation-gates
|
||||
description: "Testing and validation specialist. Proactively runs tests, validates code changes, ensures quality gates are met, and iterates on fixes until all tests pass. Call this agent after you implement features and need to validate that they were implemented correctly. Be very specific with the features that were implemented and a general idea of what needs to be tested."
|
||||
tools: Bash, Read, Edit, MultiEdit, Grep, Glob, TodoWrite
|
||||
---
|
||||
|
||||
You are a validation and testing specialist responsible for ensuring code quality through comprehensive testing, validation, and iterative improvement. Your role is to act as a quality gatekeeper, ensuring that all code changes meet the project's standards before being considered complete.
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
### 1. Automated Testing Execution
|
||||
- Run all relevant tests after code changes
|
||||
- Execute linting and formatting checks
|
||||
- Run type checking where applicable
|
||||
- Perform build validation
|
||||
- Check for security vulnerabilities
|
||||
|
||||
### 2. Test Coverage Management
|
||||
- Ensure new code has appropriate test coverage
|
||||
- Write missing tests for uncovered code paths
|
||||
- Validate that tests actually test meaningful scenarios
|
||||
- Maintain or improve overall test coverage metrics
|
||||
|
||||
### 3. Iterative Fix Process
|
||||
When tests fail:
|
||||
1. Analyze the failure carefully
|
||||
2. Identify the root cause
|
||||
3. Implement a fix
|
||||
4. Re-run tests to verify the fix
|
||||
5. Continue iterating until all tests pass
|
||||
6. Document any non-obvious fixes
|
||||
|
||||
### 4. Validation Gates Checklist
|
||||
Before marking any task as complete, ensure:
|
||||
- [ ] All unit tests pass
|
||||
- [ ] Integration tests pass (if applicable)
|
||||
- [ ] Linting produces no errors
|
||||
- [ ] Type checking passes (for typed languages)
|
||||
- [ ] Code formatting is correct
|
||||
- [ ] Build succeeds without warnings
|
||||
- [ ] No security vulnerabilities detected
|
||||
- [ ] Performance benchmarks met (if applicable)
|
||||
|
||||
### 5. Test Writing Standards
|
||||
When creating new tests:
|
||||
- Write descriptive test names that explain what is being tested
|
||||
- Include at least:
|
||||
- Happy path test cases
|
||||
- Edge case scenarios
|
||||
- Error/failure cases
|
||||
- Boundary condition tests
|
||||
- Use appropriate testing patterns (AAA: Arrange, Act, Assert)
|
||||
- Mock external dependencies appropriately
|
||||
- Keep tests fast and deterministic
|
||||
|
||||
## Validation Process Workflow
|
||||
|
||||
1. **Initial Assessment**
|
||||
- Identify what type of validation is needed
|
||||
- Determine which tests should be run
|
||||
- Check for existing test suites
|
||||
|
||||
2. **Execute Validation**
|
||||
```bash
|
||||
# Example validation sequence (adapt based on project)
|
||||
npm run lint
|
||||
npm run typecheck
|
||||
npm run test
|
||||
npm run build
|
||||
```
|
||||
|
||||
3. **Handle Failures**
|
||||
- Read error messages carefully
|
||||
- Use grep/search to find related code
|
||||
- Fix issues one at a time
|
||||
- Re-run failed tests after each fix
|
||||
|
||||
4. **Iterate Until Success**
|
||||
- Continue fixing and testing
|
||||
- Don't give up after first attempt
|
||||
- Try different approaches if needed
|
||||
- Ask for help if truly blocked
|
||||
|
||||
5. **Final Verification**
|
||||
- Run complete test suite one final time
|
||||
- Verify no regressions were introduced
|
||||
- Ensure all validation gates pass
|
||||
|
||||
## Common Validation Commands by Language
|
||||
|
||||
### JavaScript/TypeScript
|
||||
```bash
|
||||
npm run lint # or: npx eslint .
|
||||
npm run typecheck # or: npx tsc --noEmit
|
||||
npm run test # or: npx jest
|
||||
npm run test:coverage # Check coverage
|
||||
npm run build # Verify build
|
||||
```
|
||||
|
||||
### Python
|
||||
```bash
|
||||
ruff check . # Linting
|
||||
mypy . # Type checking
|
||||
pytest # Run tests
|
||||
pytest --cov # With coverage
|
||||
python -m build # Build check
|
||||
```
|
||||
|
||||
### Go
|
||||
```bash
|
||||
go fmt ./... # Format
|
||||
go vet ./... # Linting
|
||||
go test ./... # Run tests
|
||||
go build . # Build validation
|
||||
```
|
||||
|
||||
## Quality Metrics to Track
|
||||
|
||||
- Test success rate (must be 100%)
|
||||
- Code coverage (aim for >80%)
|
||||
- Linting warnings/errors (should be 0)
|
||||
- Build time (shouldn't increase significantly)
|
||||
- Test execution time (keep under reasonable limits)
|
||||
|
||||
## Important Principles
|
||||
|
||||
1. **Never Skip Validation**: Even for "simple" changes
|
||||
2. **Fix, Don't Disable**: Fix failing tests rather than disabling them
|
||||
3. **Test Behavior, Not Implementation**: Focus on what code does, not how
|
||||
4. **Fast Feedback**: Run quick tests first, comprehensive tests after
|
||||
5. **Document Failures**: When tests reveal bugs, document the fix
|
||||
|
||||
Remember: Your role is to ensure that code not only works but is maintainable, reliable, and meets all quality standards. Be thorough, be persistent, and don't compromise on quality.
|
||||
16
claude-code-full-guide/.claude/commands/primer.md
Normal file
16
claude-code-full-guide/.claude/commands/primer.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# Prime Context for Claude Code
|
||||
|
||||
Use the command `tree` to get an understanding of the project structure.
|
||||
|
||||
Start with reading the CLAUDE.md file if it exists to get an understanding of the project.
|
||||
|
||||
Read the README.md file to get an understanding of the project.
|
||||
|
||||
Read key files in the src/ or root directory
|
||||
|
||||
Explain back to me:
|
||||
- Project structure
|
||||
- Project purpose and goals
|
||||
- Key files and their purposes
|
||||
- Any important dependencies
|
||||
- Any important configuration files
|
||||
109
claude-code-full-guide/.claude/hooks/README.md
Normal file
109
claude-code-full-guide/.claude/hooks/README.md
Normal file
@@ -0,0 +1,109 @@
|
||||
# Claude Code Hooks Examples
|
||||
|
||||
This directory contains example hooks for Claude Code that demonstrate how to add deterministic behavior to your AI coding workflow.
|
||||
|
||||
## What are Hooks?
|
||||
|
||||
Hooks are user-defined shell commands that execute at specific points in Claude Code's lifecycle. They provide control over Claude's behavior, ensuring certain actions always happen rather than relying on the AI to choose to run them.
|
||||
|
||||
## Files in this Directory
|
||||
|
||||
1. **format-after-edit.sh** - A PostToolUse hook that automatically formats code after file edits
|
||||
2. **example-hook-config.json** - Example configuration showing how to set up various hooks
|
||||
|
||||
## How to Use These Hooks
|
||||
|
||||
### Option 1: Copy to Your Settings File
|
||||
|
||||
Copy the hooks configuration from `example-hook-config.json` to your Claude Code settings:
|
||||
|
||||
**Project-specific** (`.claude/settings.json`):
|
||||
```bash
|
||||
# Create settings file if it doesn't exist
|
||||
touch .claude/settings.json
|
||||
|
||||
# Add hooks configuration from example-hook-config.json
|
||||
```
|
||||
|
||||
**User-wide** (`~/.claude/settings.json`):
|
||||
```bash
|
||||
# Apply hooks to all Claude Code sessions
|
||||
cp example-hook-config.json ~/.claude/settings.json
|
||||
```
|
||||
|
||||
### Option 2: Use Individual Hooks
|
||||
|
||||
1. Copy the hook script to your project:
|
||||
```bash
|
||||
cp format-after-edit.sh /your/project/.claude/hooks/
|
||||
chmod +x /your/project/.claude/hooks/format-after-edit.sh
|
||||
```
|
||||
|
||||
2. Add to your settings.json:
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"PostToolUse": [
|
||||
{
|
||||
"matcher": "Edit|Write|MultiEdit",
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": ".claude/hooks/format-after-edit.sh"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Available Hook Events
|
||||
|
||||
- **PreToolUse**: Before tool execution (can block tools)
|
||||
- **PostToolUse**: After successful tool completion
|
||||
- **UserPromptSubmit**: When user submits a prompt
|
||||
- **SubagentStop**: When a subagent completes
|
||||
- **Stop**: When main agent finishes responding
|
||||
- **Notification**: During system notifications
|
||||
- **PreCompact**: Before context compaction
|
||||
- **SessionStart**: At session initialization
|
||||
|
||||
## Creating Your Own Hooks
|
||||
|
||||
1. Write a shell script that:
|
||||
- Reads JSON input from stdin
|
||||
- Processes the input
|
||||
- Returns JSON output (empty `{}` for success)
|
||||
- Can return `{"action": "block", "message": "reason"}` to block operations
|
||||
|
||||
2. Make it executable:
|
||||
```bash
|
||||
chmod +x your-hook.sh
|
||||
```
|
||||
|
||||
3. Add to settings.json with appropriate matcher and event
|
||||
|
||||
## Security Considerations
|
||||
|
||||
- Hooks execute arbitrary shell commands
|
||||
- Always validate and sanitize inputs
|
||||
- Use full paths to avoid PATH manipulation
|
||||
- Be careful with file operations
|
||||
- Test hooks thoroughly before deployment
|
||||
|
||||
## Debugging Hooks
|
||||
|
||||
Run Claude Code with debug flag to see hook execution:
|
||||
```bash
|
||||
claude --debug
|
||||
```
|
||||
|
||||
This will show:
|
||||
- Which hooks are triggered
|
||||
- Input/output for each hook
|
||||
- Any errors or issues
|
||||
|
||||
## Integration with Subagents
|
||||
|
||||
The example configuration includes a hook that integrates with the validation-gates subagent, demonstrating how hooks and subagents can work together for a more robust development workflow.
|
||||
@@ -0,0 +1,50 @@
|
||||
{
|
||||
"hooks": {
|
||||
"PostToolUse": [
|
||||
{
|
||||
"matcher": "Edit|Write|MultiEdit",
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": ".claude/hooks/format-after-edit.sh",
|
||||
"description": "Automatically format code after file edits"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"PreToolUse": [
|
||||
{
|
||||
"matcher": "Bash",
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "bash -c 'input=$(cat); cmd=$(echo \"$input\" | jq -r \".tool_input.command // empty\"); if [[ \"$cmd\" =~ (rm|delete).*(\\*|\\.env|credentials|secret) ]]; then echo \"{\\\"action\\\": \\\"block\\\", \\\"message\\\": \\\"Dangerous command blocked: $cmd\\\"}\"; else echo \"{}\"; fi'",
|
||||
"description": "Block dangerous bash commands"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"SubagentStop": [
|
||||
{
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "bash -c 'input=$(cat); agent=$(echo \"$input\" | jq -r \".subagent_name // empty\"); if [[ \"$agent\" == \"validation-gates\" ]]; then echo \"Validation gates completed. Running final checks...\" >&2; fi; echo \"{}\"'",
|
||||
"description": "Log when validation-gates subagent completes"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"UserPromptSubmit": [
|
||||
{
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "bash -c 'input=$(cat); prompt=$(echo \"$input\" | jq -r \".prompt // empty\"); if [[ \"$prompt\" =~ (test|validate|check) ]] && [[ ! \"$prompt\" =~ (skip|no|without).*(test|validation) ]]; then echo \"Reminder: Use the validation-gates subagent to ensure comprehensive testing.\" >&2; fi; echo \"{}\"'",
|
||||
"description": "Remind about validation when testing is mentioned"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
70
claude-code-full-guide/.claude/hooks/format-after-edit.sh
Normal file
70
claude-code-full-guide/.claude/hooks/format-after-edit.sh
Normal file
@@ -0,0 +1,70 @@
|
||||
#!/bin/bash
|
||||
# PostToolUse hook: Automatically format code after file edits
|
||||
# This hook runs after Edit, Write, or MultiEdit tools to ensure consistent formatting
|
||||
|
||||
# Read the JSON input from stdin
|
||||
input=$(cat)
|
||||
|
||||
# Extract tool name and file path from the input
|
||||
tool_name=$(echo "$input" | jq -r '.tool_name // empty')
|
||||
file_path=$(echo "$input" | jq -r '.tool_input.file_path // empty')
|
||||
|
||||
# Only process if it's a file editing tool and we have a file path
|
||||
if [[ "$tool_name" =~ ^(Edit|Write|MultiEdit)$ ]] && [[ -n "$file_path" ]]; then
|
||||
# Determine file extension
|
||||
extension="${file_path##*.}"
|
||||
|
||||
# Format based on file type
|
||||
case "$extension" in
|
||||
js|jsx|ts|tsx)
|
||||
# JavaScript/TypeScript files
|
||||
if command -v prettier &> /dev/null; then
|
||||
echo "Formatting $file_path with Prettier..." >&2
|
||||
prettier --write "$file_path" 2>/dev/null || true
|
||||
elif command -v npx &> /dev/null; then
|
||||
echo "Formatting $file_path with npx prettier..." >&2
|
||||
npx prettier --write "$file_path" 2>/dev/null || true
|
||||
fi
|
||||
;;
|
||||
py)
|
||||
# Python files
|
||||
if command -v black &> /dev/null; then
|
||||
echo "Formatting $file_path with Black..." >&2
|
||||
black "$file_path" 2>/dev/null || true
|
||||
elif command -v ruff &> /dev/null; then
|
||||
echo "Formatting $file_path with Ruff..." >&2
|
||||
ruff format "$file_path" 2>/dev/null || true
|
||||
fi
|
||||
;;
|
||||
go)
|
||||
# Go files
|
||||
if command -v gofmt &> /dev/null; then
|
||||
echo "Formatting $file_path with gofmt..." >&2
|
||||
gofmt -w "$file_path" 2>/dev/null || true
|
||||
fi
|
||||
;;
|
||||
rs)
|
||||
# Rust files
|
||||
if command -v rustfmt &> /dev/null; then
|
||||
echo "Formatting $file_path with rustfmt..." >&2
|
||||
rustfmt "$file_path" 2>/dev/null || true
|
||||
fi
|
||||
;;
|
||||
json)
|
||||
# JSON files
|
||||
if command -v jq &> /dev/null; then
|
||||
echo "Formatting $file_path with jq..." >&2
|
||||
# Format JSON with jq (careful with large files)
|
||||
if [[ $(stat -f%z "$file_path" 2>/dev/null || stat -c%s "$file_path" 2>/dev/null) -lt 1048576 ]]; then
|
||||
jq . "$file_path" > "$file_path.tmp" && mv "$file_path.tmp" "$file_path" 2>/dev/null || true
|
||||
fi
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
|
||||
# Log formatting completion
|
||||
echo "Post-edit formatting completed for $file_path" >&2
|
||||
fi
|
||||
|
||||
# Always return success to avoid blocking the tool
|
||||
echo "{}"
|
||||
25
claude-code-full-guide/.claude/hooks/log-tool-usage.sh
Normal file
25
claude-code-full-guide/.claude/hooks/log-tool-usage.sh
Normal file
@@ -0,0 +1,25 @@
|
||||
#!/bin/bash
|
||||
# PostToolUse hook: Log all tool usage for tracking and debugging
|
||||
# This hook runs after any tool execution to maintain an audit log
|
||||
|
||||
# Read the JSON input from stdin
|
||||
input=$(cat)
|
||||
|
||||
# Extract tool name and basic info
|
||||
tool_name=$(echo "$input" | jq -r '.tool_name // "unknown"')
|
||||
timestamp=$(date '+%Y-%m-%d %H:%M:%S')
|
||||
|
||||
# Create logs directory if it doesn't exist
|
||||
mkdir -p .claude/logs
|
||||
|
||||
# Log the tool usage
|
||||
echo "[$timestamp] Tool used: $tool_name" >> .claude/logs/tool-usage.log
|
||||
|
||||
# Optionally, you can add more detailed logging
|
||||
if [[ "$tool_name" =~ ^(Edit|Write|MultiEdit)$ ]]; then
|
||||
file_path=$(echo "$input" | jq -r '.tool_input.file_path // "unknown"')
|
||||
echo "[$timestamp] File operation: $tool_name on $file_path" >> .claude/logs/file-operations.log
|
||||
fi
|
||||
|
||||
# Always return success to avoid blocking tools
|
||||
echo "{}"
|
||||
@@ -10,6 +10,7 @@
|
||||
"Bash(tree:*)",
|
||||
"Bash(ruff:*)",
|
||||
"Bash(touch:*)",
|
||||
"Bash(chmod:*)",
|
||||
"Bash(cat:*)",
|
||||
"Bash(ruff check:*)",
|
||||
"Bash(pytest:*)",
|
||||
@@ -18,9 +19,7 @@
|
||||
"Bash(python3 -m pytest:*)",
|
||||
"WebFetch(domain:*)",
|
||||
"Bash(gh issue view:*)",
|
||||
"mcp__puppeteer__puppeteer_navigate",
|
||||
"mcp__puppeteer__puppeteer_screenshot",
|
||||
"mcp__puppeteer__puppeteer_evaluate"
|
||||
"WebFetch(domain:docs.anthropic.com)"
|
||||
],
|
||||
"deny": []
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user