diff --git a/.claude/commands/commit.md b/.claude/commands/commit.md new file mode 100644 index 0000000..a1a7fb6 --- /dev/null +++ b/.claude/commands/commit.md @@ -0,0 +1,166 @@ +--- +allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git log:*) +argument-hint: [message] | --no-verify | --amend +description: Create well-formatted commits with conventional commit format and emoji +--- + +# Smart Git Commit + +Create well-formatted commit: $ARGUMENTS + +## Current Repository State + +- Git status: !`git status --porcelain` +- Current branch: !`git branch --show-current` +- Staged changes: !`git diff --cached --stat` +- Unstaged changes: !`git diff --stat` +- Recent commits: !`git log --oneline -5` + +## What This Command Does + +1. Unless specified with `--no-verify`, automatically runs pre-commit checks: + - `pnpm lint` to ensure code quality + - `pnpm build` to verify the build succeeds + - `pnpm generate:docs` to update documentation +2. Checks which files are staged with `git status` +3. If 0 files are staged, automatically adds all modified and new files with `git add` +4. Performs a `git diff` to understand what changes are being committed +5. Analyzes the diff to determine if multiple distinct logical changes are present +6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits +7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format + +## Best Practices for Commits + +- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated +- **Atomic commits**: Each commit should contain related changes that serve a single purpose +- **Split large changes**: If changes touch multiple concerns, split them into separate commits +- **Conventional commit format**: Use the format `: ` where type is one of: + - `feat`: A new feature + - `fix`: A bug fix + - `docs`: Documentation changes + - `style`: Code style changes (formatting, etc) + - `refactor`: Code changes that neither fix bugs nor add features + - `perf`: Performance improvements + - `test`: Adding or fixing tests + - `chore`: Changes to the build process, tools, etc. +- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature") +- **Concise first line**: Keep the first line under 72 characters +- **Emoji**: Each commit type is paired with an appropriate emoji: + - โœจ `feat`: New feature + - ๐Ÿ› `fix`: Bug fix + - ๐Ÿ“ `docs`: Documentation + - ๐Ÿ’„ `style`: Formatting/style + - โ™ป๏ธ `refactor`: Code refactoring + - โšก๏ธ `perf`: Performance improvements + - โœ… `test`: Tests + - ๐Ÿ”ง `chore`: Tooling, configuration + - ๐Ÿš€ `ci`: CI/CD improvements + - ๐Ÿ—‘๏ธ `revert`: Reverting changes + - ๐Ÿงช `test`: Add a failing test + - ๐Ÿšจ `fix`: Fix compiler/linter warnings + - ๐Ÿ”’๏ธ `fix`: Fix security issues + - ๐Ÿ‘ฅ `chore`: Add or update contributors + - ๐Ÿšš `refactor`: Move or rename resources + - ๐Ÿ—๏ธ `refactor`: Make architectural changes + - ๐Ÿ”€ `chore`: Merge branches + - ๐Ÿ“ฆ๏ธ `chore`: Add or update compiled files or packages + - โž• `chore`: Add a dependency + - โž– `chore`: Remove a dependency + - ๐ŸŒฑ `chore`: Add or update seed files + - ๐Ÿง‘โ€๐Ÿ’ป `chore`: Improve developer experience + - ๐Ÿงต `feat`: Add or update code related to multithreading or concurrency + - ๐Ÿ”๏ธ `feat`: Improve SEO + - ๐Ÿท๏ธ `feat`: Add or update types + - ๐Ÿ’ฌ `feat`: Add or update text and literals + - ๐ŸŒ `feat`: Internationalization and localization + - ๐Ÿ‘” `feat`: Add or update business logic + - ๐Ÿ“ฑ `feat`: Work on responsive design + - ๐Ÿšธ `feat`: Improve user experience / usability + - ๐Ÿฉน `fix`: Simple fix for a non-critical issue + - ๐Ÿฅ… `fix`: Catch errors + - ๐Ÿ‘ฝ๏ธ `fix`: Update code due to external API changes + - ๐Ÿ”ฅ `fix`: Remove code or files + - ๐ŸŽจ `style`: Improve structure/format of the code + - ๐Ÿš‘๏ธ `fix`: Critical hotfix + - ๐ŸŽ‰ `chore`: Begin a project + - ๐Ÿ”– `chore`: Release/Version tags + - ๐Ÿšง `wip`: Work in progress + - ๐Ÿ’š `fix`: Fix CI build + - ๐Ÿ“Œ `chore`: Pin dependencies to specific versions + - ๐Ÿ‘ท `ci`: Add or update CI build system + - ๐Ÿ“ˆ `feat`: Add or update analytics or tracking code + - โœ๏ธ `fix`: Fix typos + - โช๏ธ `revert`: Revert changes + - ๐Ÿ“„ `chore`: Add or update license + - ๐Ÿ’ฅ `feat`: Introduce breaking changes + - ๐Ÿฑ `assets`: Add or update assets + - โ™ฟ๏ธ `feat`: Improve accessibility + - ๐Ÿ’ก `docs`: Add or update comments in source code + - ๐Ÿ—ƒ๏ธ `db`: Perform database related changes + - ๐Ÿ”Š `feat`: Add or update logs + - ๐Ÿ”‡ `fix`: Remove logs + - ๐Ÿคก `test`: Mock things + - ๐Ÿฅš `feat`: Add or update an easter egg + - ๐Ÿ™ˆ `chore`: Add or update .gitignore file + - ๐Ÿ“ธ `test`: Add or update snapshots + - โš—๏ธ `experiment`: Perform experiments + - ๐Ÿšฉ `feat`: Add, update, or remove feature flags + - ๐Ÿ’ซ `ui`: Add or update animations and transitions + - โšฐ๏ธ `refactor`: Remove dead code + - ๐Ÿฆบ `feat`: Add or update code related to validation + - โœˆ๏ธ `feat`: Improve offline support + +## Guidelines for Splitting Commits + +When analyzing the diff, consider splitting commits based on these criteria: + +1. **Different concerns**: Changes to unrelated parts of the codebase +2. **Different types of changes**: Mixing features, fixes, refactoring, etc. +3. **File patterns**: Changes to different types of files (e.g., source code vs documentation) +4. **Logical grouping**: Changes that would be easier to understand or review separately +5. **Size**: Very large changes that would be clearer if broken down + +## Examples + +Good commit messages: +- โœจ feat: add user authentication system +- ๐Ÿ› fix: resolve memory leak in rendering process +- ๐Ÿ“ docs: update API documentation with new endpoints +- โ™ป๏ธ refactor: simplify error handling logic in parser +- ๐Ÿšจ fix: resolve linter warnings in component files +- ๐Ÿง‘โ€๐Ÿ’ป chore: improve developer tooling setup process +- ๐Ÿ‘” feat: implement business logic for transaction validation +- ๐Ÿฉน fix: address minor styling inconsistency in header +- ๐Ÿš‘๏ธ fix: patch critical security vulnerability in auth flow +- ๐ŸŽจ style: reorganize component structure for better readability +- ๐Ÿ”ฅ fix: remove deprecated legacy code +- ๐Ÿฆบ feat: add input validation for user registration form +- ๐Ÿ’š fix: resolve failing CI pipeline tests +- ๐Ÿ“ˆ feat: implement analytics tracking for user engagement +- ๐Ÿ”’๏ธ fix: strengthen authentication password requirements +- โ™ฟ๏ธ feat: improve form accessibility for screen readers + +Example of splitting commits: +- First commit: โœจ feat: add new solc version type definitions +- Second commit: ๐Ÿ“ docs: update documentation for new solc versions +- Third commit: ๐Ÿ”ง chore: update package.json dependencies +- Fourth commit: ๐Ÿท๏ธ feat: add type definitions for new API endpoints +- Fifth commit: ๐Ÿงต feat: improve concurrency handling in worker threads +- Sixth commit: ๐Ÿšจ fix: resolve linting issues in new code +- Seventh commit: โœ… test: add unit tests for new solc version features +- Eighth commit: ๐Ÿ”’๏ธ fix: update dependencies with security vulnerabilities + +## Command Options + +- `--no-verify`: Skip running the pre-commit checks (lint, build, generate:docs) + +## Important Notes + +- By default, pre-commit checks (`pnpm lint`, `pnpm build`, `pnpm generate:docs`) will run to ensure code quality +- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first +- If specific files are already staged, the command will only commit those files +- If no files are staged, it will automatically stage all modified and new files +- The commit message will be constructed based on the changes detected +- Before committing, the command will review the diff to identify if multiple commits would be more appropriate +- If suggesting multiple commits, it will help you stage and commit the changes separately +- Always reviews the commit diff to ensure the message matches the changes \ No newline at end of file diff --git a/.claude/commands/create-architecture-documentation.md b/.claude/commands/create-architecture-documentation.md new file mode 100644 index 0000000..0c5aebf --- /dev/null +++ b/.claude/commands/create-architecture-documentation.md @@ -0,0 +1,94 @@ +--- +allowed-tools: Read, Write, Edit, Bash +argument-hint: "[framework] | --c4-model | --arc42 | --adr | --plantuml | --full-suite" +description: Generate comprehensive architecture documentation with diagrams, ADRs, and interactive visualization +--- + +# Architecture Documentation Generator + +Generate comprehensive architecture documentation: $ARGUMENTS + +## Current Architecture Context + +- Project structure: !`find . -type f -name "*.json" -o -name "*.yaml" -o -name "*.toml" | head -5` +- Documentation exists: @docs/ or @README.md (if exists) +- Architecture files: !`find . -name "*architecture*" -o -name "*design*" -o -name "*.puml" | head -3` +- Services/containers: @docker-compose.yml or @k8s/ (if exists) +- API definitions: !`find . -name "*api*" -o -name "*openapi*" -o -name "*swagger*" | head -3` + +## Task + +Generate comprehensive architecture documentation with modern tooling and best practices: + +1. **Architecture Analysis and Discovery** + - Analyze current system architecture and component relationships + - Identify key architectural patterns and design decisions + - Document system boundaries, interfaces, and dependencies + - Assess data flow and communication patterns + - Identify architectural debt and improvement opportunities + +2. **Architecture Documentation Framework** + - Choose appropriate documentation framework and tools: + - **C4 Model**: Context, Containers, Components, Code diagrams + - **Arc42**: Comprehensive architecture documentation template + - **Architecture Decision Records (ADRs)**: Decision documentation + - **PlantUML/Mermaid**: Diagram-as-code documentation + - **Structurizr**: C4 model tooling and visualization + - **Draw.io/Lucidchart**: Visual diagramming tools + +3. **System Context Documentation** + - Create high-level system context diagrams + - Document external systems and integrations + - Define system boundaries and responsibilities + - Document user personas and stakeholders + - Create system landscape and ecosystem overview + +4. **Container and Service Architecture** + - Document container/service architecture and deployment view + - Create service dependency maps and communication patterns + - Document deployment architecture and infrastructure + - Define service boundaries and API contracts + - Document data persistence and storage architecture + +5. **Component and Module Documentation** + - Create detailed component architecture diagrams + - Document internal module structure and relationships + - Define component responsibilities and interfaces + - Document design patterns and architectural styles + - Create code organization and package structure documentation + +6. **Data Architecture Documentation** + - Document data models and database schemas + - Create data flow diagrams and processing pipelines + - Document data storage strategies and technologies + - Define data governance and lifecycle management + - Create data integration and synchronization documentation + +7. **Security and Compliance Architecture** + - Document security architecture and threat model + - Create authentication and authorization flow diagrams + - Document compliance requirements and controls + - Define security boundaries and trust zones + - Create incident response and security monitoring documentation + +8. **Quality Attributes and Cross-Cutting Concerns** + - Document performance characteristics and scalability patterns + - Create reliability and availability architecture documentation + - Document monitoring and observability architecture + - Define maintainability and evolution strategies + - Create disaster recovery and business continuity documentation + +9. **Architecture Decision Records (ADRs)** + - Create comprehensive ADR template and process + - Document historical architectural decisions and rationale + - Create decision tracking and review process + - Document trade-offs and alternatives considered + - Set up ADR maintenance and evolution procedures + +10. **Documentation Automation and Maintenance** + - Set up automated diagram generation from code annotations + - Configure documentation pipeline and publishing automation + - Set up documentation validation and consistency checking + - Create documentation review and approval process + - Train team on architecture documentation practices and tools + - Set up documentation versioning and change management \ No newline at end of file diff --git a/.claude/commands/ultra-think.md b/.claude/commands/ultra-think.md new file mode 100644 index 0000000..da21c0e --- /dev/null +++ b/.claude/commands/ultra-think.md @@ -0,0 +1,158 @@ +--- +description: Deep analysis and problem solving with multi-dimensional thinking +argument-hint: [problem or question to analyze] +--- + +# Deep Analysis and Problem Solving Mode + +Deep analysis and problem solving mode + +## Instructions + +1. **Initialize Ultra Think Mode** + - Acknowledge the request for enhanced analytical thinking + - Set context for deep, systematic reasoning + - Prepare to explore the problem space comprehensively + +2. **Parse the Problem or Question** + - Extract the core challenge from: $ARGUMENTS + - Identify all stakeholders and constraints + - Recognize implicit requirements and hidden complexities + - Question assumptions and surface unknowns + +3. **Multi-Dimensional Analysis** + Approach the problem from multiple angles: + + ### Technical Perspective + - Analyze technical feasibility and constraints + - Consider scalability, performance, and maintainability + - Evaluate security implications + - Assess technical debt and future-proofing + + ### Business Perspective + - Understand business value and ROI + - Consider time-to-market pressures + - Evaluate competitive advantages + - Assess risk vs. reward trade-offs + + ### User Perspective + - Analyze user needs and pain points + - Consider usability and accessibility + - Evaluate user experience implications + - Think about edge cases and user journeys + + ### System Perspective + - Consider system-wide impacts + - Analyze integration points + - Evaluate dependencies and coupling + - Think about emergent behaviors + +4. **Generate Multiple Solutions** + - Brainstorm at least 3-5 different approaches + - For each approach, consider: + - Pros and cons + - Implementation complexity + - Resource requirements + - Potential risks + - Long-term implications + - Include both conventional and creative solutions + - Consider hybrid approaches + +5. **Deep Dive Analysis** + For the most promising solutions: + - Create detailed implementation plans + - Identify potential pitfalls and mitigation strategies + - Consider phased approaches and MVPs + - Analyze second and third-order effects + - Think through failure modes and recovery + +6. **Cross-Domain Thinking** + - Draw parallels from other industries or domains + - Apply design patterns from different contexts + - Consider biological or natural system analogies + - Look for innovative combinations of existing solutions + +7. **Challenge and Refine** + - Play devil's advocate with each solution + - Identify weaknesses and blind spots + - Consider "what if" scenarios + - Stress-test assumptions + - Look for unintended consequences + +8. **Synthesize Insights** + - Combine insights from all perspectives + - Identify key decision factors + - Highlight critical trade-offs + - Summarize innovative discoveries + - Present a nuanced view of the problem space + +9. **Provide Structured Recommendations** + Present findings in a clear structure: + ``` + ## Problem Analysis + - Core challenge + - Key constraints + - Critical success factors + + ## Solution Options + ### Option 1: [Name] + - Description + - Pros/Cons + - Implementation approach + - Risk assessment + + ### Option 2: [Name] + [Similar structure] + + ## Recommendation + - Recommended approach + - Rationale + - Implementation roadmap + - Success metrics + - Risk mitigation plan + + ## Alternative Perspectives + - Contrarian view + - Future considerations + - Areas for further research + ``` + +10. **Meta-Analysis** + - Reflect on the thinking process itself + - Identify areas of uncertainty + - Acknowledge biases or limitations + - Suggest additional expertise needed + - Provide confidence levels for recommendations + +## Usage Examples + +```bash +# Architectural decision +/ultra-think Should we migrate to microservices or improve our monolith? + +# Complex problem solving +/ultra-think How do we scale our system to handle 10x traffic while reducing costs? + +# Strategic planning +/ultra-think What technology stack should we choose for our next-gen platform? + +# Design challenge +/ultra-think How can we improve our API to be more developer-friendly while maintaining backward compatibility? +``` + +## Key Principles + +- **First Principles Thinking**: Break down to fundamental truths +- **Systems Thinking**: Consider interconnections and feedback loops +- **Probabilistic Thinking**: Work with uncertainties and ranges +- **Inversion**: Consider what to avoid, not just what to do +- **Second-Order Thinking**: Consider consequences of consequences + +## Output Expectations + +- Comprehensive analysis (typically 2-4 pages of insights) +- Multiple viable solutions with trade-offs +- Clear reasoning chains +- Acknowledgment of uncertainties +- Actionable recommendations +- Novel insights or perspectives \ No newline at end of file