claude-git-hooks 2.0.0 → 2.3.0

package/templates/presets/fullstack/CONSISTENCY_CHECKS.md

@@ -0,0 +1,147 @@
+# Full-Stack Consistency Checks
+
+This template provides specific checks for cross-layer consistency in full-stack applications.
+
+## API Contract Consistency
+
+### DTO ↔ TypeScript Interface Matching
+
+**Backend DTO Example:**
+```java
+public class UserDTO {
+    private Long id;
+    private String email;
+    private String firstName;
+    private String lastName;
+}
+```
+
+**Frontend Interface Should Match:**
+```typescript
+interface User {
+    id: number;
+    email: string;
+    firstName: string;
+    lastName: string;
+}
+```
+
+**Check for:**
+- ✅ All fields present in both
+- ✅ Same field names (exact match, including casing)
+- ✅ Compatible types (Long↔number, String↔string, etc.)
+- ✅ Optional fields marked consistently
+
+## Error Response Consistency
+
+**Backend Error Response:**
+```java
+{
+    "timestamp": "2024-01-01T12:00:00",
+    "status": 400,
+    "error": "Bad Request",
+    "message": "Validation failed",
+    "path": "/api/users"
+}
+```
+
+**Frontend Should Handle:**
+```javascript
+catch (error) {
+    if (error.response.status === 400) {
+        // Handle validation error
+    } else if (error.response.status === 401) {
+        // Handle unauthorized
+    }
+    // etc.
+}
+```
+
+**Check for:**
+- ✅ Frontend handles all status codes backend returns
+- ✅ Error messages displayed to user are user-friendly
+- ✅ No sensitive info exposed in errors
+
+## Authentication Flow Consistency
+
+**Check for:**
+- ✅ Token format matches between backend generation and frontend consumption
+- ✅ Token expiration handled on both sides
+- ✅ Refresh token logic works end-to-end
+- ✅ Secure token storage (httpOnly cookies > localStorage)
+- ✅ Authorization headers formatted correctly
+
+## Validation Consistency
+
+**Backend:**
+```java
+@NotNull
+@Email
+private String email;
+
+@Size(min = 8, max = 100)
+private String password;
+```
+
+**Frontend Should Match:**
+```javascript
+const validationSchema = {
+    email: yup.string().email().required(),
+    password: yup.string().min(8).max(100).required()
+};
+```
+
+**Check for:**
+- ✅ Same validation rules on both sides
+- ✅ Clear error messages match
+- ✅ Required fields consistent
+- ✅ Length/format constraints match
+
+## Data Flow Checks
+
+**When Backend Changes:**
+- ✅ Check if frontend needs updates
+- ✅ Verify API contract compatibility
+- ✅ Check for breaking changes
+
+**When Frontend Changes:**
+- ✅ Verify API calls still match backend
+- ✅ Check error handling is complete
+- ✅ Ensure all backend responses handled
+
+## Common Consistency Issues
+
+### Type Mismatches
+❌ Backend: `Long`, Frontend: `string` (should be `number`)
+❌ Backend: `LocalDateTime`, Frontend: not parsing as Date
+❌ Backend: enum values, Frontend: magic strings
+
+### Naming Mismatches
+❌ Backend: `user_id`, Frontend: `userId`
+❌ Backend: `firstName`, Frontend: `first_name`
+❌ Inconsistent pluralization
+
+### Missing Fields
+❌ Backend returns field frontend doesn't expect
+❌ Frontend expects field backend doesn't send
+❌ Optional fields treated as required
+
+### Status Code Issues
+❌ Backend returns 500, frontend only handles 4xx
+❌ Backend returns 204, frontend expects JSON
+❌ Backend changes status code, frontend not updated
+
+## Verification Checklist
+
+When analyzing commits that touch both backend and frontend:
+
+- [ ] API endpoint paths match
+- [ ] HTTP methods correct
+- [ ] Request/response DTOs match TypeScript types
+- [ ] All status codes handled
+- [ ] Error responses properly handled
+- [ ] Authentication/authorization consistent
+- [ ] Validation rules match
+- [ ] Data transformations are inverse operations
+- [ ] Breaking changes documented
+- [ ] Tests cover the integration

package/templates/presets/fullstack/PRE_COMMIT_GUIDELINES.md

@@ -0,0 +1,125 @@
+# Fullstack Code Quality Guidelines
+
+## Cross-Layer Consistency (PRIORITY)
+
+### API Contracts
+✅ DTOs (backend) match TypeScript interfaces (frontend)
+✅ Field names use same casing (camelCase recommended)
+✅ Required/optional fields consistent
+✅ Data types match (String↔string, Integer↔number, etc.)
+
+### Error Handling
+✅ Backend returns consistent error format
+✅ Frontend handles all backend error codes
+✅ User-friendly error messages in frontend
+✅ No sensitive info in error messages
+
+### Authentication Flow
+✅ JWT token format consistent
+✅ Token storage secure (httpOnly cookies preferred)
+✅ Token expiration handled properly
+✅ Refresh token logic works end-to-end
+
+### Validation
+✅ Server-side validation always present
+✅ Client-side validation matches server rules
+✅ Clear validation error messages
+✅ Never trust client validation alone
+
+## Backend Standards (Spring Boot)
+
+### Controllers
+- Proper HTTP methods and status codes
+- Input validation with `@Valid`
+- Exception handling with `@ExceptionHandler`
+- Use DTOs, never expose entities
+- Return consistent response format
+
+### Services
+- Use `@Transactional` appropriately
+- Handle exceptions properly
+- Keep business logic here (not in controllers)
+- Avoid N+1 queries
+
+### Security
+- Never hardcode credentials
+- Use parameterized queries
+- Validate all input
+- Implement proper authorization checks
+
+## Frontend Standards (React)
+
+### Components
+- Keep components small and focused
+- Use proper hooks (useState, useEffect, etc.)
+- Implement error boundaries
+- Handle loading and error states
+- Ensure accessibility
+
+### API Integration
+- Validate API responses
+- Handle all error scenarios
+- Show appropriate loading states
+- Implement proper error recovery
+
+### Security
+- Never use `dangerouslySetInnerHTML` without sanitization
+- Store tokens securely
+- Validate user input
+- Don't expose API keys
+
+## Common Full-Stack Issues
+
+### Backend-Frontend Mismatches
+❌ DTOs don't match frontend types
+❌ Different field names or casing
+❌ Frontend expects fields backend doesn't send
+❌ Error responses not handled in frontend
+
+### Security Issues
+❌ SQL injection vulnerabilities (backend)
+❌ XSS vulnerabilities (frontend)
+❌ Exposed secrets or credentials
+❌ Missing authentication/authorization
+❌ Insecure token storage
+
+### Data Flow Problems
+❌ Missing validation on either layer
+❌ Inconsistent error handling
+❌ Breaking API changes without frontend update
+❌ Frontend not handling all backend states
+
+### Performance Issues
+❌ N+1 queries (backend)
+❌ Unnecessary re-renders (frontend)
+❌ Large API payloads
+❌ Missing pagination
+❌ Unoptimized database queries
+
+## Testing
+
+### Backend
+- Unit tests for services
+- Integration tests for repositories
+- API endpoint tests
+- Security tests
+
+### Frontend
+- Component unit tests
+- Integration tests for API calls
+- User interaction tests
+- Error scenario tests
+
+### End-to-End
+- Critical user flows
+- Authentication flows
+- Error handling
+- Edge cases
+
+## Commit Best Practices
+
+When modifying both backend and frontend:
+1. Ensure API contract changes are compatible
+2. Update both layers together if breaking change
+3. Test the complete flow locally
+4. Document any API changes in commit message

package/templates/presets/fullstack/config.json

@@ -0,0 +1,12 @@
+{
+  "analysis": {
+    "maxFileSize": 100000,
+    "maxFiles": 15,
+    "timeout": 180000
+  },
+  "subagents": {
+    "enabled": true,
+    "model": "sonnet",
+    "batchSize": 4
+  }
+}

package/templates/presets/fullstack/preset.json

@@ -0,0 +1,55 @@
+{
+  "name": "fullstack",
+  "displayName": "Fullstack (Spring Boot + React)",
+  "description": "Full-stack application with Spring Boot backend and React frontend",
+  "version": "1.0.0",
+
+  "techStack": [
+    "Spring Boot 2.6+",
+    "JPA",
+    "SQL Server",
+    "Spring Security",
+    "JWT",
+    "React 18+",
+    "Material-UI v5",
+    "Redux",
+    "Maven",
+    "Jest",
+    "JUnit"
+  ],
+
+  "fileExtensions": [
+    ".java",
+    ".xml",
+    ".yml",
+    ".yaml",
+    ".js",
+    ".jsx",
+    ".ts",
+    ".tsx",
+    ".css",
+    ".scss",
+    ".html",
+    ".sql"
+  ],
+
+  "focusAreas": [
+    "API contract consistency between backend and frontend",
+    "Data flow from database through API to UI",
+    "Authentication and authorization across layers",
+    "Error handling consistency",
+    "Security vulnerabilities (OWASP, XSS)",
+    "Performance optimization (backend queries, frontend rendering)",
+    "Type safety (DTOs match API contracts)",
+    "Cross-layer testing"
+  ],
+
+  "templates": {
+    "analysis": "ANALYSIS_PROMPT.md",
+    "guidelines": "PRE_COMMIT_GUIDELINES.md",
+    "consistency": "CONSISTENCY_CHECKS.md",
+    "commitMessage": "../shared/COMMIT_MESSAGE.md",
+    "analyzeDiff": "../shared/ANALYZE_DIFF.md",
+    "resolution": "../shared/RESOLUTION_PROMPT.md"
+  }
+}

package/templates/shared/ANALYSIS_PROMPT.md

@@ -0,0 +1,103 @@
+You are analyzing a **{{PRESET_NAME}}** project with the following technology stack:
+
+**Tech Stack:** {{TECH_STACK}}
+
+**Analyzing files matching:** {{FILE_EXTENSIONS}}
+
+## Your Task
+
+Perform a comprehensive code quality analysis focusing on these areas:
+
+{{FOCUS_AREAS}}
+
+## Analysis Guidelines
+
+Evaluate the code changes across these dimensions:
+
+### 1. **Security**
+- Check for common vulnerabilities (injection, XSS, authentication issues)
+- Look for exposed credentials or sensitive data
+- Verify input validation
+- Check for insecure configurations
+
+### 2. **Reliability**
+- Identify potential bugs or runtime errors
+- Check error handling completeness
+- Look for null pointer risks
+- Verify exception handling
+
+### 3. **Maintainability**
+- Assess code clarity and organization
+- Check for code duplication
+- Evaluate naming conventions
+- Review documentation quality
+
+### 4. **Performance**
+- Identify potential performance bottlenecks
+- Check for inefficient algorithms
+- Look for resource leaks
+- Verify proper cleanup
+
+### 5. **Best Practices**
+- Language-specific idioms and patterns
+- Framework best practices
+- Design patterns usage
+- Code organization
+
+## Output Format
+
+Respond with a valid JSON following the SonarQube format:
+
+```json
+{
+  "QUALITY_GATE": "PASSED|FAILED",
+  "approved": true|false,
+  "metrics": {
+    "reliability": "A|B|C|D|E",
+    "security": "A|B|C|D|E",
+    "maintainability": "A|B|C|D|E",
+    "coverage": 0-100,
+    "duplications": 0-100,
+    "complexity": "number"
+  },
+  "issues": {
+    "blocker": 0,
+    "critical": 0,
+    "major": 0,
+    "minor": 0,
+    "info": 0
+  },
+  "details": [
+    {
+      "severity": "BLOCKER|CRITICAL|MAJOR|MINOR|INFO",
+      "type": "BUG|VULNERABILITY|CODE_SMELL",
+      "file": "path/to/file",
+      "line": 123,
+      "message": "Clear description of the issue"
+    }
+  ],
+  "securityHotspots": 0,
+  "blockingIssues": ["List of critical issues that must be fixed"]
+}
+```
+
+## Severity Guidelines
+
+- **BLOCKER**: Critical security vulnerabilities, data loss risks, critical bugs
+- **CRITICAL**: Major security issues, significant bugs, critical performance problems
+- **MAJOR**: Important issues that should be fixed soon
+- **MINOR**: Minor issues, suggestions for improvement
+- **INFO**: Informational notes, optional improvements
+
+## Quality Gate Rules
+
+- **FAILED**: If blocker >= 1 OR critical > 1 OR security hotspots > 0
+- **PASSED**: Otherwise
+
+## Analysis Rules
+
+- Be strict but fair - focus on real problems, not style preferences
+- Provide actionable, specific feedback with line numbers
+- Consider the context and purpose of the code
+- Prioritize security and reliability over style
+- Be constructive in your feedback

package/templates/shared/ANALYZE_DIFF.md

@@ -0,0 +1,33 @@
+Analyze the following changes. CONTEXT: {{CONTEXT_DESCRIPTION}}
+{{SUBAGENT_INSTRUCTION}}
+Please generate:
+1. A concise and descriptive PR title (maximum 72 characters)
+2. A detailed PR description that includes:
+   - Summary of changes
+   - Motivation/context
+   - Type of change (feature/fix/refactor/docs/etc)
+   - Recommended testing
+3. A suggested branch name following the format: type/short-description (example: feature/add-user-auth, fix/memory-leak)
+
+IMPORTANT: If these are local changes without push, the suggested branch name should be for creating a new branch from the current one.
+
+Respond EXCLUSIVELY with a valid JSON with this structure:
+```json
+{
+  "prTitle": "Interesting PR title",
+  "prDescription": "detailed PR description with markdown",
+  "suggestedBranchName": "type/suggested-branch-name",
+  "changeType": "feature|fix|refactor|docs|test|chore",
+  "breakingChanges": false,
+  "testingNotes": "notes on necessary testing or 'None'"
+}
+```
+
+## COMMITS
+{{COMMITS}}
+
+## CHANGED FILES
+{{DIFF_FILES}}
+
+## FULL DIFF
+{{FULL_DIFF}}

package/templates/shared/COMMIT_MESSAGE.md

@@ -0,0 +1,24 @@
+Analyze the following changes and generate a commit message following the Conventional Commits format.
+
+Respond ONLY with a valid JSON:
+
+```json
+{
+  "type": "feat|fix|docs|style|refactor|test|chore|ci|perf",
+  "scope": "optional scope (e.g.: api, frontend, db)",
+  "title": "short description in present tense (max 50 chars)",
+  "body": "optional detailed description"
+}
+```
+
+## CHANGES TO ANALYZE
+
+### Modified files:
+{{FILE_LIST}}
+
+### Summary of changes:
+Files changed: {{FILE_COUNT}}
+Insertions: {{INSERTIONS}}, Deletions: {{DELETIONS}}
+
+### Detailed diffs:
+{{FILE_DIFFS}}

package/templates/shared/PRE_COMMIT_GUIDELINES.md

@@ -0,0 +1,145 @@
+# General Code Quality Guidelines
+
+## Security Fundamentals
+
+### Input Validation
+✅ Validate all user input
+✅ Sanitize data before use
+✅ Use parameterized queries
+✅ Escape output properly
+✅ Validate file paths
+
+### Credentials and Secrets
+✅ Never hardcode credentials
+✅ Use environment variables or secure vaults
+✅ Don't log sensitive data
+✅ Rotate keys regularly
+✅ Use secure random generators
+
+### Authentication & Authorization
+✅ Implement proper authentication
+✅ Check permissions before operations
+✅ Use secure session management
+✅ Implement rate limiting
+✅ Log security events
+
+## Reliability
+
+### Error Handling
+✅ Handle all error cases
+✅ Provide meaningful error messages
+✅ Clean up resources in finally blocks
+✅ Don't swallow exceptions silently
+✅ Log errors appropriately
+
+### Null Safety
+✅ Check for null/undefined values
+✅ Use optional chaining where supported
+✅ Provide default values
+✅ Document when null is valid
+✅ Avoid null pointer exceptions
+
+### Resource Management
+✅ Close files and connections
+✅ Free allocated memory
+✅ Use try-with-resources patterns
+✅ Implement proper cleanup
+✅ Avoid resource leaks
+
+## Maintainability
+
+### Code Organization
+✅ Keep functions small and focused
+✅ Use descriptive names
+✅ Follow consistent naming conventions
+✅ Organize code logically
+✅ Limit nesting depth
+
+### Documentation
+✅ Document complex logic
+✅ Explain non-obvious decisions
+✅ Keep comments up to date
+✅ Use inline documentation
+✅ Document public APIs
+
+### Code Duplication
+✅ Extract common code into functions
+✅ Use appropriate design patterns
+✅ Don't copy-paste code
+✅ Refactor when you see duplication
+✅ Keep DRY (Don't Repeat Yourself)
+
+## Performance
+
+### General Guidelines
+✅ Choose appropriate data structures
+✅ Avoid unnecessary loops
+✅ Cache expensive computations
+✅ Use lazy loading when appropriate
+✅ Profile before optimizing
+
+### Resource Usage
+✅ Limit memory allocations
+✅ Use streaming for large data
+✅ Implement pagination
+✅ Clean up resources promptly
+✅ Avoid memory leaks
+
+## Common Issues to Avoid
+
+### Critical Issues (BLOCKER)
+❌ Security vulnerabilities (SQL injection, XSS, etc.)
+❌ Exposed credentials or secrets
+❌ Data loss risks
+❌ Critical bugs that crash the application
+
+### Major Issues (CRITICAL/MAJOR)
+❌ Unhandled exceptions
+❌ Resource leaks
+❌ Missing input validation
+❌ Poor error handling
+❌ Performance bottlenecks
+
+### Minor Issues (MINOR/INFO)
+❌ Code duplication
+❌ Poor naming
+❌ Missing documentation
+❌ Style inconsistencies
+❌ Unused code
+
+## Testing
+
+✅ Write tests for new functionality
+✅ Test error scenarios
+✅ Test edge cases
+✅ Mock external dependencies
+✅ Aim for reasonable coverage
+
+## Version Control
+
+✅ Write clear commit messages
+✅ Keep commits focused and atomic
+✅ Don't commit sensitive data
+✅ Review your own changes first
+✅ Rebase/clean up before pushing
+
+## Language-Specific
+
+Different languages have specific best practices:
+
+- **JavaScript/Node.js**: Use strict mode, handle promises, avoid callback hell
+- **Python**: Follow PEP 8, use virtual environments, handle exceptions
+- **Java**: Follow naming conventions, use proper access modifiers, handle checked exceptions
+- **SQL**: Use parameterized queries, optimize for performance, maintain data integrity
+- **Shell scripts**: Quote variables, check exit codes, handle errors
+
+## Quality Standards
+
+Strive for:
+- **Reliability**: A or B
+- **Security**: A or B
+- **Maintainability**: A or B
+- **Coverage**: 70%+ for new code
+- **Complexity**: Keep cyclomatic complexity low
+
+Remember: The goal is to write code that is secure, reliable, maintainable, and performs well.

package/templates/shared/RESOLUTION_PROMPT.md

@@ -0,0 +1,32 @@
+# FIX_CRITICAL_ISSUES
+
+CONTEXT:
+repo:{{REPO_NAME}}
+branch:{{BRANCH_NAME}}
+commit:{{COMMIT_SHA}}
+files:{{FILE_COUNT}}
+
+CRITICAL_ISSUES:
+{{BLOCKING_ISSUES}}
+
+AFFECTED_FILES:
+{{FILE_CONTENTS}}
+
+INSTRUCTIONS:
+1.Navigate→exact_file:line
+2.Apply_minimal_fix
+3.Maintain_style/conventions
+4.No_unrelated_refactoring
+
+OUTPUT:
+- diff_format
+- one_line_explanation_max
+
+PRIORITY:
+1.security_vulns
+2.null_ptr/runtime
+3.logic_errors
+4.performance
+5.code_quality
+
+START_FIXING: