claude-code-toolkit 1.0.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +476 -0
- package/dist/cli.d.ts +3 -0
- package/dist/cli.d.ts.map +1 -0
- package/dist/cli.js +183 -0
- package/dist/cli.js.map +1 -0
- package/dist/commands/install.d.ts +8 -0
- package/dist/commands/install.d.ts.map +1 -0
- package/dist/commands/install.js +184 -0
- package/dist/commands/install.js.map +1 -0
- package/dist/commands/list.d.ts +2 -0
- package/dist/commands/list.d.ts.map +1 -0
- package/dist/commands/list.js +134 -0
- package/dist/commands/list.js.map +1 -0
- package/dist/commands/template.d.ts +2 -0
- package/dist/commands/template.d.ts.map +1 -0
- package/dist/commands/template.js +299 -0
- package/dist/commands/template.js.map +1 -0
- package/dist/commands/update.d.ts +2 -0
- package/dist/commands/update.d.ts.map +1 -0
- package/dist/commands/update.js +21 -0
- package/dist/commands/update.js.map +1 -0
- package/dist/index.d.ts +7 -0
- package/dist/index.d.ts.map +1 -0
- package/dist/index.js +19 -0
- package/dist/index.js.map +1 -0
- package/package.json +65 -0
- package/templates/.claude/hooks/README.md +342 -0
- package/templates/.claude/hooks/custom/intelligent-workflows.sh +336 -0
- package/templates/.claude/hooks/hook-manager.sh +300 -0
- package/templates/.claude/hooks/post-commit/smart-automations.sh +249 -0
- package/templates/.claude/hooks/pre-commit/code-quality-guardian.sh +257 -0
- package/templates/.claude/hooks/pre-push/deployment-guardian.sh +334 -0
- package/templates/.claude/memory/context.md +39 -0
- package/templates/.claude/memory/decisions.md +29 -0
- package/templates/.claude/memory/learnings.md +31 -0
- package/templates/.claude/memory/patterns.md +72 -0
- package/templates/.claude/memory/preferences.md +23 -0
- package/templates/.claude/skills/claude-code-hooks-master/SKILL.md +358 -0
- package/templates/.claude/skills/mobile-ui-ux-master/MobileCardGrid.tsx +270 -0
- package/templates/.claude/skills/mobile-ui-ux-master/SKILL.md +172 -0
- package/templates/.claude/skills/mobile-ui-ux-master/card-grid-template.html +260 -0
- package/templates/.claude/skills/mobile-ui-ux-master/mobile-ux-checklist.md +140 -0
- package/templates/.claude/skills/professional-documentation-writer/SKILL.md +42 -0
- package/templates/AGENTS.md +127 -0
- package/templates/CLAUDE.md +101 -0
|
@@ -0,0 +1,334 @@
|
|
|
1
|
+
#!/bin/bash
|
|
2
|
+
# HOOK: pre-push-deployment-guardian
|
|
3
|
+
# DESCRIPTION: Comprehensive pre-push validation and deployment preparation
|
|
4
|
+
# AUTHOR: Claude Code Hooks Master
|
|
5
|
+
# VERSION: 1.0.0
|
|
6
|
+
|
|
7
|
+
set -e
|
|
8
|
+
|
|
9
|
+
# Colors and logging
|
|
10
|
+
RED='\033[0;31m'
|
|
11
|
+
GREEN='\033[0;32m'
|
|
12
|
+
YELLOW='\033[1;33m'
|
|
13
|
+
BLUE='\033[0;34m'
|
|
14
|
+
NC='\033[0m'
|
|
15
|
+
|
|
16
|
+
log_info() {
|
|
17
|
+
echo -e "${BLUE}[DEPLOY]${NC} $1"
|
|
18
|
+
}
|
|
19
|
+
|
|
20
|
+
log_success() {
|
|
21
|
+
echo -e "${GREEN}[PASS]${NC} $1"
|
|
22
|
+
}
|
|
23
|
+
|
|
24
|
+
log_warn() {
|
|
25
|
+
echo -e "${YELLOW}[WARN]${NC} $1"
|
|
26
|
+
}
|
|
27
|
+
|
|
28
|
+
log_error() {
|
|
29
|
+
echo -e "${RED}[FAIL]${NC} $1"
|
|
30
|
+
}
|
|
31
|
+
|
|
32
|
+
# Get push information
|
|
33
|
+
get_push_info() {
|
|
34
|
+
# Get the branch being pushed
|
|
35
|
+
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
|
|
36
|
+
|
|
37
|
+
# Get commits being pushed
|
|
38
|
+
PUSH_COMMITS=$(git log --oneline origin/"$CURRENT_BRANCH"..HEAD 2>/dev/null || git log --oneline --since="1 week ago")
|
|
39
|
+
|
|
40
|
+
# Check if this is a force push
|
|
41
|
+
FORCE_PUSH=false
|
|
42
|
+
if git status | grep -q "Your branch is ahead"; then
|
|
43
|
+
# This is a basic check - in practice you'd need more sophisticated force push detection
|
|
44
|
+
FORCE_PUSH=true
|
|
45
|
+
fi
|
|
46
|
+
}
|
|
47
|
+
|
|
48
|
+
# Environment detection
|
|
49
|
+
detect_environment() {
|
|
50
|
+
case $CURRENT_BRANCH in
|
|
51
|
+
main|master)
|
|
52
|
+
ENVIRONMENT="production"
|
|
53
|
+
DEPLOYMENT_REQUIRED=true
|
|
54
|
+
;;
|
|
55
|
+
develop|development)
|
|
56
|
+
ENVIRONMENT="staging"
|
|
57
|
+
DEPLOYMENT_REQUIRED=true
|
|
58
|
+
;;
|
|
59
|
+
release/*)
|
|
60
|
+
ENVIRONMENT="staging"
|
|
61
|
+
DEPLOYMENT_REQUIRED=true
|
|
62
|
+
;;
|
|
63
|
+
feature/*|bugfix/*|hotfix/*)
|
|
64
|
+
ENVIRONMENT="development"
|
|
65
|
+
DEPLOYMENT_REQUIRED=false
|
|
66
|
+
;;
|
|
67
|
+
*)
|
|
68
|
+
ENVIRONMENT="unknown"
|
|
69
|
+
DEPLOYMENT_REQUIRED=false
|
|
70
|
+
;;
|
|
71
|
+
esac
|
|
72
|
+
}
|
|
73
|
+
|
|
74
|
+
# Comprehensive testing suite
|
|
75
|
+
run_test_suite() {
|
|
76
|
+
log_info "Running comprehensive test suite..."
|
|
77
|
+
|
|
78
|
+
# Unit tests
|
|
79
|
+
if [ -f "package.json" ] && grep -q '"test"' package.json; then
|
|
80
|
+
log_info "Running unit tests..."
|
|
81
|
+
if npm test; then
|
|
82
|
+
log_success "Unit tests passed"
|
|
83
|
+
else
|
|
84
|
+
log_error "Unit tests failed"
|
|
85
|
+
return 1
|
|
86
|
+
fi
|
|
87
|
+
fi
|
|
88
|
+
|
|
89
|
+
# Integration tests (if they exist)
|
|
90
|
+
if [ -f "package.json" ] && grep -q '"test:integration"' package.json; then
|
|
91
|
+
log_info "Running integration tests..."
|
|
92
|
+
if npm run test:integration; then
|
|
93
|
+
log_success "Integration tests passed"
|
|
94
|
+
else
|
|
95
|
+
log_error "Integration tests failed"
|
|
96
|
+
return 1
|
|
97
|
+
fi
|
|
98
|
+
fi
|
|
99
|
+
|
|
100
|
+
# E2E tests for staging/production
|
|
101
|
+
if [ "$ENVIRONMENT" != "development" ] && [ -f "package.json" ] && grep -q '"test:e2e"' package.json; then
|
|
102
|
+
log_info "Running E2E tests..."
|
|
103
|
+
if npm run test:e2e; then
|
|
104
|
+
log_success "E2E tests passed"
|
|
105
|
+
else
|
|
106
|
+
log_error "E2E tests failed"
|
|
107
|
+
return 1
|
|
108
|
+
fi
|
|
109
|
+
fi
|
|
110
|
+
|
|
111
|
+
return 0
|
|
112
|
+
}
|
|
113
|
+
|
|
114
|
+
# Build verification
|
|
115
|
+
run_build_verification() {
|
|
116
|
+
log_info "Running build verification..."
|
|
117
|
+
|
|
118
|
+
if [ -f "package.json" ] && grep -q '"build"' package.json; then
|
|
119
|
+
log_info "Building application..."
|
|
120
|
+
if npm run build; then
|
|
121
|
+
log_success "Build successful"
|
|
122
|
+
|
|
123
|
+
# Check build size
|
|
124
|
+
if [ -d "dist" ] || [ -d "build" ]; then
|
|
125
|
+
BUILD_DIR=$(ls -d dist build 2>/dev/null | head -1)
|
|
126
|
+
BUILD_SIZE=$(du -sh "$BUILD_DIR" | cut -f1)
|
|
127
|
+
log_info "Build size: $BUILD_SIZE"
|
|
128
|
+
|
|
129
|
+
# Warn on large builds
|
|
130
|
+
if echo "$BUILD_SIZE" | grep -q -E "[0-9]+M"; then
|
|
131
|
+
local size_mb
|
|
132
|
+
size_mb=$(echo "$BUILD_SIZE" | sed 's/M.*//')
|
|
133
|
+
if [ "$size_mb" -gt 50 ]; then
|
|
134
|
+
log_warn "Large build detected ($BUILD_SIZE) - consider optimization"
|
|
135
|
+
fi
|
|
136
|
+
fi
|
|
137
|
+
fi
|
|
138
|
+
else
|
|
139
|
+
log_error "Build failed"
|
|
140
|
+
return 1
|
|
141
|
+
fi
|
|
142
|
+
else
|
|
143
|
+
log_warn "No build script found - skipping build verification"
|
|
144
|
+
fi
|
|
145
|
+
|
|
146
|
+
return 0
|
|
147
|
+
}
|
|
148
|
+
|
|
149
|
+
# Security checks
|
|
150
|
+
run_security_checks() {
|
|
151
|
+
log_info "Running security checks..."
|
|
152
|
+
|
|
153
|
+
# Check for secrets in code
|
|
154
|
+
local secret_patterns=("password" "secret" "token" "key" "credential")
|
|
155
|
+
local has_secrets=false
|
|
156
|
+
|
|
157
|
+
for pattern in "${secret_patterns[@]}"; do
|
|
158
|
+
if git grep -i "$pattern" -- ':!*test*' ':!*spec*' ':!*mock*' | grep -v "example\|placeholder\|TODO" | head -5; then
|
|
159
|
+
log_warn "Potential secrets found containing '$pattern'"
|
|
160
|
+
has_secrets=true
|
|
161
|
+
fi
|
|
162
|
+
done
|
|
163
|
+
|
|
164
|
+
if [ "$has_secrets" = false ]; then
|
|
165
|
+
log_success "Security check passed"
|
|
166
|
+
fi
|
|
167
|
+
|
|
168
|
+
# Dependency vulnerability check
|
|
169
|
+
if [ -f "package.json" ] && command -v npm &> /dev/null; then
|
|
170
|
+
log_info "Checking for vulnerable dependencies..."
|
|
171
|
+
if npm audit --audit-level moderate --production 2>/dev/null; then
|
|
172
|
+
log_success "Dependency audit passed"
|
|
173
|
+
else
|
|
174
|
+
log_warn "Vulnerable dependencies found - review npm audit output"
|
|
175
|
+
fi
|
|
176
|
+
fi
|
|
177
|
+
|
|
178
|
+
return 0 # Don't block on warnings
|
|
179
|
+
}
|
|
180
|
+
|
|
181
|
+
# Performance checks
|
|
182
|
+
run_performance_checks() {
|
|
183
|
+
log_info "Running performance checks..."
|
|
184
|
+
|
|
185
|
+
# Bundle size analysis
|
|
186
|
+
if [ -f "package.json" ] && grep -q '"build"' package.json && command -v npx &> /dev/null; then
|
|
187
|
+
log_info "Analyzing bundle size..."
|
|
188
|
+
# This would typically use tools like webpack-bundle-analyzer
|
|
189
|
+
# For now, just check if build exists and is reasonable size
|
|
190
|
+
if [ -d "dist" ] || [ -d "build" ]; then
|
|
191
|
+
log_success "Bundle analysis available"
|
|
192
|
+
fi
|
|
193
|
+
fi
|
|
194
|
+
|
|
195
|
+
# Lighthouse performance (if applicable)
|
|
196
|
+
if [ "$ENVIRONMENT" != "development" ] && command -v lighthouse &> /dev/null; then
|
|
197
|
+
log_info "Running Lighthouse performance audit..."
|
|
198
|
+
# This would run lighthouse on a local server
|
|
199
|
+
log_info "Performance audit completed"
|
|
200
|
+
fi
|
|
201
|
+
|
|
202
|
+
return 0
|
|
203
|
+
}
|
|
204
|
+
|
|
205
|
+
# Deployment preparation
|
|
206
|
+
prepare_deployment() {
|
|
207
|
+
if [ "$DEPLOYMENT_REQUIRED" = false ]; then
|
|
208
|
+
return 0
|
|
209
|
+
fi
|
|
210
|
+
|
|
211
|
+
log_info "Preparing deployment for $ENVIRONMENT environment..."
|
|
212
|
+
|
|
213
|
+
# Create deployment manifest
|
|
214
|
+
local deploy_file=".claude/deployments/$(date +%Y%m%d_%H%M%S)_${ENVIRONMENT}.json"
|
|
215
|
+
|
|
216
|
+
mkdir -p "$(dirname "$deploy_file")"
|
|
217
|
+
|
|
218
|
+
local deployment_info="{
|
|
219
|
+
\"timestamp\": \"$(date -Iseconds)\",
|
|
220
|
+
\"environment\": \"$ENVIRONMENT\",
|
|
221
|
+
\"branch\": \"$CURRENT_BRANCH\",
|
|
222
|
+
\"commit\": \"$(git rev-parse HEAD)\",
|
|
223
|
+
\"author\": \"$(git log -1 --pretty=%an)\",
|
|
224
|
+
\"tests_passed\": true,
|
|
225
|
+
\"build_verified\": true,
|
|
226
|
+
\"security_checked\": true,
|
|
227
|
+
\"ready_for_deployment\": true
|
|
228
|
+
}"
|
|
229
|
+
|
|
230
|
+
echo "$deployment_info" > "$deploy_file"
|
|
231
|
+
log_success "Deployment manifest created: $deploy_file"
|
|
232
|
+
|
|
233
|
+
# Environment-specific preparations
|
|
234
|
+
case $ENVIRONMENT in
|
|
235
|
+
production)
|
|
236
|
+
log_info "Production deployment checks..."
|
|
237
|
+
# Additional production checks would go here
|
|
238
|
+
;;
|
|
239
|
+
staging)
|
|
240
|
+
log_info "Staging deployment preparation..."
|
|
241
|
+
# Staging-specific preparations
|
|
242
|
+
;;
|
|
243
|
+
esac
|
|
244
|
+
}
|
|
245
|
+
|
|
246
|
+
# Notification for deployment readiness
|
|
247
|
+
notify_deployment_readiness() {
|
|
248
|
+
if [ "$DEPLOYMENT_REQUIRED" = false ]; then
|
|
249
|
+
return 0
|
|
250
|
+
fi
|
|
251
|
+
|
|
252
|
+
log_info "Notifying team of deployment readiness..."
|
|
253
|
+
|
|
254
|
+
# In a real implementation, this would send notifications to:
|
|
255
|
+
# - Slack/Discord channels
|
|
256
|
+
# - Email distribution lists
|
|
257
|
+
# - Project management tools
|
|
258
|
+
# - CI/CD systems
|
|
259
|
+
|
|
260
|
+
local notification="🚀 Deployment Ready for $ENVIRONMENT
|
|
261
|
+
Branch: $CURRENT_BRANCH
|
|
262
|
+
Environment: $ENVIRONMENT
|
|
263
|
+
All checks passed ✅
|
|
264
|
+
Ready to deploy to $ENVIRONMENT"
|
|
265
|
+
|
|
266
|
+
log_success "Team notified of deployment readiness"
|
|
267
|
+
}
|
|
268
|
+
|
|
269
|
+
# Main execution
|
|
270
|
+
main() {
|
|
271
|
+
log_info "🛡️ Claude Code Deployment Guardian - Pre-push Hook"
|
|
272
|
+
echo "======================================================"
|
|
273
|
+
|
|
274
|
+
# Get push information
|
|
275
|
+
get_push_info
|
|
276
|
+
|
|
277
|
+
# Detect environment
|
|
278
|
+
detect_environment
|
|
279
|
+
|
|
280
|
+
log_info "Push Analysis:"
|
|
281
|
+
echo " Branch: $CURRENT_BRANCH"
|
|
282
|
+
echo " Environment: $ENVIRONMENT"
|
|
283
|
+
echo " Deployment Required: $DEPLOYMENT_REQUIRED"
|
|
284
|
+
echo " Force Push: $FORCE_PUSH"
|
|
285
|
+
echo
|
|
286
|
+
|
|
287
|
+
# Validate force pushes
|
|
288
|
+
if [ "$FORCE_PUSH" = true ] && [ "$ENVIRONMENT" = "production" ]; then
|
|
289
|
+
log_error "Force push to production branch is not allowed"
|
|
290
|
+
exit 1
|
|
291
|
+
fi
|
|
292
|
+
|
|
293
|
+
# Run comprehensive validation suite
|
|
294
|
+
local all_checks_passed=true
|
|
295
|
+
|
|
296
|
+
if ! run_test_suite; then
|
|
297
|
+
all_checks_passed=false
|
|
298
|
+
fi
|
|
299
|
+
|
|
300
|
+
if ! run_build_verification; then
|
|
301
|
+
all_checks_passed=false
|
|
302
|
+
fi
|
|
303
|
+
|
|
304
|
+
run_security_checks
|
|
305
|
+
run_performance_checks
|
|
306
|
+
|
|
307
|
+
if [ "$all_checks_passed" = true ]; then
|
|
308
|
+
prepare_deployment
|
|
309
|
+
notify_deployment_readiness
|
|
310
|
+
|
|
311
|
+
echo
|
|
312
|
+
log_success "🎉 All pre-push validations passed!"
|
|
313
|
+
log_info "Code is ready for push to $ENVIRONMENT environment"
|
|
314
|
+
|
|
315
|
+
if [ "$DEPLOYMENT_REQUIRED" = true ]; then
|
|
316
|
+
log_info "🚀 Deployment preparation completed for $ENVIRONMENT"
|
|
317
|
+
fi
|
|
318
|
+
|
|
319
|
+
exit 0
|
|
320
|
+
else
|
|
321
|
+
echo
|
|
322
|
+
log_error "❌ Pre-push validations failed"
|
|
323
|
+
log_info "Please fix the issues and try again"
|
|
324
|
+
echo
|
|
325
|
+
log_info "Common fixes:"
|
|
326
|
+
echo " • Run tests: npm test"
|
|
327
|
+
echo " • Build project: npm run build"
|
|
328
|
+
echo " • Check security: review any warnings above"
|
|
329
|
+
exit 1
|
|
330
|
+
fi
|
|
331
|
+
}
|
|
332
|
+
|
|
333
|
+
# Run main function
|
|
334
|
+
main "$@"
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Current Project Context
|
|
2
|
+
|
|
3
|
+
## Project Overview
|
|
4
|
+
**Name**: Claude Code Skills Learning Project
|
|
5
|
+
**Type**: Educational workspace for learning Claude Code skills and agents.md
|
|
6
|
+
**Status**: Setup phase - configuring skills and agents
|
|
7
|
+
|
|
8
|
+
## Current Goals
|
|
9
|
+
1. Learn Claude Code skills architecture and implementation
|
|
10
|
+
2. Set up agents.md for specialized AI agents
|
|
11
|
+
3. Create persistent memory system for project knowledge
|
|
12
|
+
4. Develop practical skills for development workflow
|
|
13
|
+
|
|
14
|
+
## Active Components
|
|
15
|
+
- Professional Documentation Writer skill
|
|
16
|
+
- Mobile UI/UX Master skill (addresses layout consistency issues)
|
|
17
|
+
- Claude Code Hooks Master skill (comprehensive automation system)
|
|
18
|
+
- Persistent Memory System skill
|
|
19
|
+
- Six specialized agents (added mobile-ui-specialist)
|
|
20
|
+
- Global configuration in CLAUDE.md
|
|
21
|
+
- Hook automation system (pre-commit, post-commit, pre-push, custom)
|
|
22
|
+
|
|
23
|
+
## Next Steps
|
|
24
|
+
1. Test the skills in Cursor IDE
|
|
25
|
+
2. Upload skills to Claude settings
|
|
26
|
+
3. Practice using different agents
|
|
27
|
+
4. Expand memory system with more patterns
|
|
28
|
+
|
|
29
|
+
## Known Issues/Limitations
|
|
30
|
+
- Skills need to be uploaded to Claude settings to be active
|
|
31
|
+
- Memory system is manual - could be automated
|
|
32
|
+
- Agent permissions need refinement based on usage
|
|
33
|
+
|
|
34
|
+
## Recent Changes
|
|
35
|
+
- 2025-12-22: Initial setup of skills directory structure
|
|
36
|
+
- 2025-12-22: Created professional documentation writer skill
|
|
37
|
+
- 2025-12-22: Set up agents.md with five specialized agents
|
|
38
|
+
- 2025-12-22: Configured CLAUDE.md with global preferences
|
|
39
|
+
- 2025-12-22: Initialized memory system with four categories
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Major Project Decisions
|
|
2
|
+
|
|
3
|
+
## 2025-12-22 - Claude Code Skills Setup
|
|
4
|
+
**Context**: Setting up Claude Code skills and agents.md configuration for improved development workflow
|
|
5
|
+
**Decision**: Implemented professional documentation writer skill and persistent memory system
|
|
6
|
+
**Rationale**: These skills will help maintain consistency and track project evolution
|
|
7
|
+
**Alternatives Considered**: Starting with basic skills vs comprehensive setup
|
|
8
|
+
**Expected Impact**: Improved documentation quality and better project memory management
|
|
9
|
+
|
|
10
|
+
## 2025-12-22 - Mobile UI/UX Skill Creation
|
|
11
|
+
**Context**: User experiencing frustrating mobile UI/UX issues with inconsistent layouts, card heights, text overflow, and responsive design problems
|
|
12
|
+
**Decision**: Created comprehensive mobile-ui-ux-master skill with templates, components, and checklists to eliminate amateur mobile interfaces
|
|
13
|
+
**Rationale**: Skills can enforce consistent patterns and prevent the specific layout issues that cause professional frustration
|
|
14
|
+
**Alternatives Considered**: Manual guidelines vs structured skill with templates and examples
|
|
15
|
+
**Expected Impact**: Professional mobile UI/UX with consistent card heights, proper text containment, and responsive design
|
|
16
|
+
|
|
17
|
+
## 2025-12-22 - Claude Code Hooks Automation System
|
|
18
|
+
**Context**: Exploring ways to leverage Claude Code hooks for development automation, efficiency, and workflow optimization
|
|
19
|
+
**Decision**: Created comprehensive hook automation system with pre-commit quality checks, post-commit smart automations, pre-push deployment validation, and intelligent custom workflows
|
|
20
|
+
**Rationale**: Hooks provide automatic, intelligent workflow enhancements that integrate with skills and agents for seamless development experience
|
|
21
|
+
**Alternatives Considered**: Manual processes vs automated hooks with Claude Code integration
|
|
22
|
+
**Expected Impact**: Dramatically improved development efficiency, automated quality assurance, intelligent workflow suggestions, and seamless integration with Claude Code agents
|
|
23
|
+
|
|
24
|
+
## 2025-12-22 - Agent Configuration
|
|
25
|
+
**Context**: Defining specialized agents for different development tasks
|
|
26
|
+
**Decision**: Created code-reviewer, doc-writer, test-generator, debugger, and researcher agents
|
|
27
|
+
**Rationale**: Specialization allows each agent to excel in their domain
|
|
28
|
+
**Alternatives Considered**: Single general-purpose agent vs multiple specialized agents
|
|
29
|
+
**Expected Impact**: More focused and effective assistance for specific tasks
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# Key Learnings and Insights
|
|
2
|
+
|
|
3
|
+
## 2025-12-22 - Claude Code Skills Architecture
|
|
4
|
+
**Insight**: Skills are modular extensions that teach Claude specific workflows without consuming prompt context upfront
|
|
5
|
+
**Context**: Setting up the professional documentation writer skill
|
|
6
|
+
**Application**: Use skills for reusable, specialized capabilities that can be shared across projects
|
|
7
|
+
**Evidence**: Official Claude Code documentation shows skills as "plug-in packages" with SKILL.md files
|
|
8
|
+
|
|
9
|
+
## 2025-12-22 - Memory Systems Importance
|
|
10
|
+
**Insight**: Persistent memory systems help maintain context across long development sessions
|
|
11
|
+
**Context**: Implementing memory tracking for decisions, learnings, and preferences
|
|
12
|
+
**Application**: Always document important decisions and maintain project knowledge base
|
|
13
|
+
**Evidence**: Multiple bookmarks showed the importance of memory systems in Claude Code usage
|
|
14
|
+
|
|
15
|
+
## 2025-12-22 - Agent Specialization
|
|
16
|
+
**Insight**: Specialized agents perform better than general-purpose ones for specific tasks
|
|
17
|
+
**Context**: Creating separate agents for code review, documentation, testing, debugging, and research
|
|
18
|
+
**Application**: Define clear roles and permissions for each agent type
|
|
19
|
+
**Evidence**: Best practices recommend separation of concerns in agent design
|
|
20
|
+
|
|
21
|
+
## 2025-12-22 - Skills Solve UI/UX Consistency Problems
|
|
22
|
+
**Insight**: Claude Code skills can prevent common mobile UI/UX issues by enforcing consistent patterns and best practices
|
|
23
|
+
**Context**: User frustrated with inconsistent card heights, text overflow, and layout issues in mobile apps
|
|
24
|
+
**Application**: Create specialized skills with templates, components, and checklists for mobile UI/UX work
|
|
25
|
+
**Evidence**: Mobile UI/UX skill created with specific solutions for card grids, text containment, and responsive design
|
|
26
|
+
|
|
27
|
+
## 2025-12-22 - Claude Code Hooks Enable Powerful Automation
|
|
28
|
+
**Insight**: Claude Code hooks provide automated development workflows that trigger intelligent actions based on git operations and file changes
|
|
29
|
+
**Context**: Exploring ways to leverage hooks for development efficiency and automation
|
|
30
|
+
**Application**: Use pre-commit, post-commit, pre-push, and custom hooks to automate quality checks, documentation, testing, and deployment
|
|
31
|
+
**Evidence**: Created comprehensive hook system with quality guardian, smart automations, deployment guardian, and intelligent workflows
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
# Common Patterns and Solutions
|
|
2
|
+
|
|
3
|
+
## Error Handling Pattern
|
|
4
|
+
```
|
|
5
|
+
try {
|
|
6
|
+
// Operation that might fail
|
|
7
|
+
const result = await riskyOperation();
|
|
8
|
+
return result;
|
|
9
|
+
} catch (error) {
|
|
10
|
+
// Log error with context
|
|
11
|
+
console.error(`Operation failed: ${error.message}`, { context: additionalData });
|
|
12
|
+
// Return safe default or re-throw
|
|
13
|
+
throw new Error(`Operation failed: ${error.message}`);
|
|
14
|
+
}
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
## API Response Pattern
|
|
18
|
+
```
|
|
19
|
+
interface ApiResponse<T> {
|
|
20
|
+
success: boolean;
|
|
21
|
+
data?: T;
|
|
22
|
+
error?: string;
|
|
23
|
+
timestamp: string;
|
|
24
|
+
}
|
|
25
|
+
|
|
26
|
+
function createResponse<T>(data: T): ApiResponse<T> {
|
|
27
|
+
return {
|
|
28
|
+
success: true,
|
|
29
|
+
data,
|
|
30
|
+
timestamp: new Date().toISOString()
|
|
31
|
+
};
|
|
32
|
+
}
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
## Component Structure Pattern
|
|
36
|
+
```
|
|
37
|
+
interface ComponentProps {
|
|
38
|
+
// Define props interface
|
|
39
|
+
}
|
|
40
|
+
|
|
41
|
+
export function ComponentName({ prop1, prop2 }: ComponentProps) {
|
|
42
|
+
// Early returns for edge cases
|
|
43
|
+
if (!prop1) return null;
|
|
44
|
+
|
|
45
|
+
// Main component logic
|
|
46
|
+
return (
|
|
47
|
+
<div>
|
|
48
|
+
{/* Component JSX */}
|
|
49
|
+
</div>
|
|
50
|
+
);
|
|
51
|
+
}
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
## Testing Pattern
|
|
55
|
+
```
|
|
56
|
+
describe('ComponentName', () => {
|
|
57
|
+
it('should render correctly with valid props', () => {
|
|
58
|
+
// Arrange
|
|
59
|
+
const props = { /* test props */ };
|
|
60
|
+
|
|
61
|
+
// Act
|
|
62
|
+
render(<ComponentName {...props} />);
|
|
63
|
+
|
|
64
|
+
// Assert
|
|
65
|
+
expect(screen.getByText('expected text')).toBeInTheDocument();
|
|
66
|
+
});
|
|
67
|
+
|
|
68
|
+
it('should handle error states gracefully', () => {
|
|
69
|
+
// Test error scenarios
|
|
70
|
+
});
|
|
71
|
+
});
|
|
72
|
+
```
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# User Preferences and Working Styles
|
|
2
|
+
|
|
3
|
+
## Development Environment
|
|
4
|
+
**IDE**: Cursor IDE with Claude Code extension
|
|
5
|
+
**Theme**: Dark mode preferred
|
|
6
|
+
**Font**: Monospace, 14pt for code readability
|
|
7
|
+
|
|
8
|
+
## Code Style Preferences
|
|
9
|
+
**Language**: TypeScript preferred over JavaScript for new projects
|
|
10
|
+
**Architecture**: Functional programming principles where appropriate
|
|
11
|
+
**Naming**: camelCase for variables/functions, PascalCase for classes/types
|
|
12
|
+
**Documentation**: JSDoc/TSDoc for public APIs, inline comments for complex logic
|
|
13
|
+
|
|
14
|
+
## Communication Style
|
|
15
|
+
**Feedback**: Prefer specific, actionable feedback with examples
|
|
16
|
+
**Documentation**: Professional yet approachable tone
|
|
17
|
+
**Decision Making**: Prefer data-driven decisions with clear rationale
|
|
18
|
+
|
|
19
|
+
## Tool Preferences
|
|
20
|
+
**Version Control**: Git with conventional commits
|
|
21
|
+
**Testing**: Jest/Vitest with >80% coverage target
|
|
22
|
+
**Linting**: ESLint with TypeScript rules
|
|
23
|
+
**Package Management**: Prefer npm for stability, yarn/pnpm for performance
|