├── assistants ├── copilot │ └── .gitkeep ├── cursor │ └── .gitkeep ├── junie │ └── .gitkeep ├── windsurf │ └── .gitkeep └── claude │ ├── claude-general-coding.md │ ├── claude-frontend.md │ └── claude-spring-boot.md ├── .gitignore ├── LICENSE └── README.md /assistants/copilot/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /assistants/cursor/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /assistants/junie/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /assistants/windsurf/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # macOS 2 | .DS_Store 3 | .DS_Store? 4 | ._* 5 | .Spotlight-V100 6 | .Trashes 7 | ehthumbs.db 8 | Thumbs.db 9 | 10 | # Editor files 11 | .vscode/ 12 | .idea/ 13 | *.swp 14 | *.swo 15 | *~ 16 | 17 | # Logs 18 | logs 19 | *.log 20 | 21 | # Temporary files 22 | *.tmp 23 | *.temp -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2025 AI Dot Files Contributors 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. -------------------------------------------------------------------------------- /assistants/claude/claude-general-coding.md: -------------------------------------------------------------------------------- 1 | # Claude Code Guidelines for General Software Development 2 | 3 | This file contains general coding guidelines for Claude Code to follow across all programming languages and frameworks. 4 | 5 | ## General Principles 6 | 7 | * **Code Quality:** Write clean, readable, and maintainable code 8 | * **Documentation:** Document complex logic and non-obvious decisions 9 | * **Testing:** Include appropriate unit and integration tests 10 | * **Security:** Follow security best practices and never expose secrets 11 | * **Performance:** Consider performance implications of design decisions 12 | 13 | ## Code Style 14 | 15 | * **Consistency:** Follow existing project conventions and patterns 16 | * **Naming:** Use clear, descriptive names for variables, functions, and classes 17 | * **Functions:** Keep functions focused and reasonably sized 18 | * **Comments:** Write comments that explain "why" rather than "what" 19 | 20 | ## Architecture Patterns 21 | 22 | * **Separation of Concerns:** Keep different responsibilities in separate modules 23 | * **DRY Principle:** Don't repeat yourself - extract common functionality 24 | * **SOLID Principles:** Follow SOLID design principles where applicable 25 | * **Error Handling:** Implement consistent error handling strategies 26 | 27 | ## Version Control 28 | 29 | * **Commit Messages:** Write clear, descriptive commit messages 30 | * **Branch Strategy:** Follow the project's branching conventions 31 | * **Code Reviews:** Structure code for easy review and understanding 32 | 33 | ## Dependencies 34 | 35 | * **Minimal Dependencies:** Only add dependencies that provide clear value 36 | * **Security Updates:** Keep dependencies up to date for security 37 | * **License Compatibility:** Ensure dependency licenses are compatible -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # AI Dot Files 2 | 3 | A curated collection of configuration files and guidelines to help developers optimize their AI coding tools for maximum productivity. 4 | 5 | ## Overview 6 | 7 | This repository contains best practices, configuration files, and setup guides for popular AI coding assistants. Whether you're using Claude Code, GitHub Copilot, Cursor, or other AI tools, these dot files will help you get the most out of your AI-powered development workflow. 8 | 9 | ## Supported AI Tools 10 | 11 | ### 🤖 Claude Code 12 | - **General Coding Guidelines** - Core principles for clean, maintainable code 13 | - **Frontend Development** - TypeScript, React, Vue, and modern web development patterns 14 | - **Spring Boot** - Java enterprise application development with modern practices 15 | 16 | ### 🐙 GitHub Copilot 17 | Configuration and best practices coming soon. 18 | 19 | ### 💡 Cursor 20 | Configuration and best practices coming soon. 21 | 22 | ### 🌊 Windsurf 23 | Configuration and best practices coming soon. 24 | 25 | ### 🔮 Junie 26 | Configuration and best practices coming soon. 27 | 28 | ## Getting Started 29 | 30 | 1. **Choose your AI tool** - Navigate to the appropriate directory under `assistants/` 31 | 2. **Review the guidelines** - Each tool has specific configuration files and best practices 32 | 3. **Apply the configurations** - Follow the setup instructions for your chosen tool 33 | 4. **Customize as needed** - Adapt the guidelines to match your project's specific requirements 34 | 35 | ## Directory Structure 36 | 37 | ``` 38 | assistants/ 39 | ├── claude/ # Claude Code configurations 40 | │ ├── claude-frontend.md 41 | │ ├── claude-general-coding.md 42 | │ └── claude-spring-boot.md 43 | ├── copilot/ # GitHub Copilot configurations 44 | ├── cursor/ # Cursor configurations 45 | ├── junie/ # Junie configurations 46 | └── windsurf/ # Windsurf configurations 47 | ``` 48 | 49 | ## Contributing 50 | 51 | We welcome contributions to improve these AI tool configurations! Please: 52 | 53 | 1. Fork this repository 54 | 2. Create a feature branch for your improvements 55 | 3. Add or update configuration files following the existing patterns 56 | 4. Submit a pull request with a clear description of your changes 57 | 58 | ## Philosophy 59 | 60 | These configurations are designed with the following principles: 61 | 62 | - **Productivity First** - Optimize for developer speed and efficiency 63 | - **Code Quality** - Maintain high standards for maintainability and readability 64 | - **Best Practices** - Follow industry-standard conventions and patterns 65 | - **Flexibility** - Provide guidelines that can be adapted to different projects 66 | 67 | ## License 68 | 69 | This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details. 70 | 71 | ## Community 72 | 73 | Share your experiences and improvements with AI coding tools. Together, we can build better development workflows that leverage the power of AI while maintaining code quality and best practices. -------------------------------------------------------------------------------- /assistants/claude/claude-frontend.md: -------------------------------------------------------------------------------- 1 | # Claude Code Guidelines for Frontend Development 2 | 3 | This file contains guidelines for Claude Code to follow when working on frontend projects, focusing on modern JavaScript/TypeScript development with Tailwind CSS. 4 | 5 | ## Core Technologies 6 | 7 | * **Language:** Prefer TypeScript to JavaScript for better type safety and developer experience 8 | * **Framework:** Follow the established framework patterns (Vue, Angular, Svelte, etc.) - avoid React/JSX 9 | * **Styling:** Use Tailwind CSS as the primary styling solution with utility-first approach 10 | * **Build Tools:** Use modern build tools like Vite, Webpack, or the framework's recommended tooling 11 | * **Package Manager:** Use the project's existing package manager (npm, yarn, pnpm) 12 | 13 | ## Component Architecture 14 | 15 | * **Component Design:** Create reusable, single-responsibility components 16 | * **Props/API Design:** Design clear, minimal component APIs 17 | * **State Management:** Use appropriate state management patterns (local state, context, external stores) 18 | * **Component Structure:** Organize components logically with clear naming conventions 19 | 20 | ## Styling Approach 21 | 22 | * **Tailwind CSS First:** Use Tailwind utility classes as the primary styling method 23 | * **Tailwind CSS Plus:** Leverage Tailwind CSS Plus templates and components when available for faster development 24 | * **Utility Composition:** Compose complex designs using Tailwind utilities rather than custom CSS 25 | * **Component Extraction:** Extract repeated utility patterns into reusable components 26 | * **Custom Utilities:** Create custom utilities in tailwind.config.js when needed 27 | * **Responsive Design:** Use Tailwind's responsive prefixes (sm:, md:, lg:, xl:, 2xl:) for mobile-first design 28 | * **Design Tokens:** Utilize Tailwind's design system (spacing, colors, typography) for consistency 29 | * **Accessibility:** Use Tailwind's accessibility utilities and include proper ARIA labels with semantic HTML 30 | 31 | ## Performance 32 | 33 | * **Bundle Size:** Be mindful of bundle size when adding dependencies 34 | * **Tailwind Optimization:** Ensure Tailwind's purge/content configuration removes unused styles 35 | * **JIT Compilation:** Use Tailwind's Just-in-Time compiler for faster builds and smaller CSS 36 | * **Lazy Loading:** Implement code splitting and lazy loading where appropriate 37 | * **Component Optimization:** Use framework-specific optimization patterns (memoization, computed properties) 38 | * **Asset Optimization:** Optimize images and other assets using modern formats (WebP, AVIF) 39 | 40 | ## Type Safety (TypeScript) 41 | 42 | * **Strict Types:** Use strict TypeScript configuration 43 | * **API Types:** Define proper types for API responses and component props 44 | * **Generic Types:** Use generics appropriately for reusable components 45 | * **Type Guards:** Implement type guards for runtime type safety 46 | 47 | ## Testing 48 | 49 | * **Unit Tests:** Test component logic and behavior 50 | * **Integration Tests:** Test component interactions and user workflows 51 | * **Testing Library:** Use appropriate testing libraries for your framework (Vue Test Utils, Svelte Testing Library, etc.) 52 | * **Visual Testing:** Consider visual regression testing for Tailwind-styled components 53 | * **E2E Tests:** Include end-to-end tests for critical user paths 54 | 55 | ## Development Experience 56 | 57 | * **Hot Reload:** Ensure development server supports fast refresh 58 | * **Linting:** Use ESLint with appropriate rules for the project 59 | * **Formatting:** Use Prettier for consistent code formatting 60 | * **Dev Tools:** Leverage framework-specific dev tools and browser extensions -------------------------------------------------------------------------------- /assistants/claude/claude-spring-boot.md: -------------------------------------------------------------------------------- 1 | # Claude Code Guidelines for Spring Boot Development 2 | 3 | This file contains guidelines for Claude Code to follow when working on this Spring Boot project. Adhering to these standards ensures consistency, maintainability, and leverages modern practices. 4 | 5 | ## Core Technologies & Versions 6 | 7 | * **Java:** Use the latest Long-Term Support (LTS) version of Java (e.g., Java 21 or later) unless project constraints dictate otherwise. 8 | * **Spring Boot:** Always use the latest stable release of Spring Boot 3.x (or the latest major stable version available) for new features or projects. 9 | * **Build Tool:** Use Maven as the build tool. Ensure the `pom.xml` uses the latest stable Spring Boot parent POM and compatible plugin versions. 10 | 11 | ## Project Structure 12 | 13 | * **Packaging:** Strongly prefer a **package-by-feature** structure over package-by-layer. This means grouping all code related to a specific feature or domain concept (like "posts", "users", or "orders") together in the same package hierarchy. Avoid structuring packages based solely on technical layers (like "controllers", "services", "repositories"). 14 | 15 | * **Why Package-by-Feature?** It improves modularity, makes navigating code related to a single feature easier, reduces coupling between features, and simplifies refactoring or potentially extracting the feature into a microservice later. 16 | 17 | * **Example:** 18 | 19 | **PREFER THIS (Package-by-Feature):** 20 | ``` 21 | com.example.application 22 | ├── posts # Feature: Posts 23 | │ ├── PostController.java # Controller for Posts 24 | │ ├── PostService.java # Service logic for Posts 25 | │ ├── PostRepository.java # Data access for Posts 26 | │ ├── Post.java # Domain/Entity for Posts 27 | │ └── dto # Data Transfer Objects specific to Posts 28 | │ ├── PostCreateRequest.java 29 | │ └── PostSummaryResponse.java 30 | │ 31 | ├── users # Feature: Users 32 | │ ├── UserController.java 33 | │ ├── UserService.java 34 | │ ├── UserRepository.java 35 | │ └── User.java 36 | │ 37 | └── common # Optional: Truly shared utilities/config 38 | └── exception 39 | └── ResourceNotFoundException.java 40 | ``` 41 | 42 | **AVOID THIS (Package-by-Layer):** 43 | ``` 44 | com.example.application 45 | ├── controller 46 | │ ├── PostController.java 47 | │ └── UserController.java 48 | │ 49 | ├── service 50 | │ ├── PostService.java 51 | │ └── UserService.java 52 | │ 53 | ├── repository 54 | │ ├── PostRepository.java 55 | │ └── UserRepository.java 56 | │ 57 | └── model (or domain/entity) 58 | ├── Post.java 59 | └── User.java 60 | ``` 61 | 62 | 63 | ## Data Access 64 | 65 | * **No Persistence Required:** For applications that don't need data persistence across restarts (prototypes, demos, simple services with temporary data), use **in-memory data structures** like `Map`, `List`, or `Set` within your service classes. Don't introduce database complexity unless you specifically need persistent storage. 66 | 67 | * **Simple Applications/Queries:** For applications primarily dealing with straightforward, single-table CRUD operations or when direct SQL control is beneficial *without complex object mapping*, prefer using the Spring Framework **`JdbcClient`**. Avoid the older `JdbcTemplate`. 68 | 69 | * **Standard/Complex Applications:** For applications with domain models involving relationships, complex queries, or where JPA features (caching, dirty checking, repository abstractions) provide significant benefits, use **Spring Data JPA**. 70 | 71 | * **Default Decision Tree:** 72 | 1. If data doesn't need to persist across application restarts → Use in-memory collections 73 | 2. If unsure about persistence needs → Start with in-memory, migrate to database when needed 74 | 3. If persistence is required but queries are simple → Use `JdbcClient` 75 | 4. If persistence is required with complex domain models → Use Spring Data JPA 76 | 77 | * **In-Memory Best Practices:** 78 | - Use `ConcurrentHashMap` instead of `HashMap` for thread-safe operations in multi-threaded environments 79 | - Consider using `@PostConstruct` to initialize sample data for development/testing 80 | - Document clearly that data is not persistent to avoid confusion 81 | - For more sophisticated in-memory needs, consider using an embedded H2 database in memory mode (`jdbc:h2:mem:testdb`) 82 | 83 | ## HTTP Clients 84 | 85 | * **Outgoing HTTP Requests:** Use the Spring Framework 6+ **`RestClient`** for making synchronous or asynchronous HTTP calls. Avoid using the legacy `RestTemplate` in new code. 86 | 87 | ## Java Language Features 88 | 89 | * **Data Carriers:** Use Java **Records** (`record`) for immutable data transfer objects (DTOs), value objects, or simple data aggregates whenever possible. Prefer records over traditional classes with getters, setters, `equals()`, `hashCode()`, and `toString()` for these use cases. 90 | * **Immutability:** Favor immutability for objects where appropriate, especially for DTOs and configuration properties. 91 | 92 | ## Spring Framework Best Practices 93 | 94 | * **Dependency Injection:** Use **constructor injection** for mandatory dependencies. Avoid field injection. 95 | * **Configuration:** Use `application.properties` or `application.yml` for application configuration. Leverage Spring Boot's externalized configuration mechanisms (profiles, environment variables, etc.). Use `@ConfigurationProperties` for type-safe configuration binding. 96 | * **Error Handling:** Implement consistent exception handling, potentially using `@ControllerAdvice` and custom exception classes. Provide meaningful error responses. 97 | * **Logging:** Use SLF4j with a suitable backend (like Logback, included by default in Spring Boot starters) for logging. Write clear and informative log messages. 98 | 99 | ## Testing 100 | 101 | * **Unit Tests:** Write unit tests for services and components using JUnit 5 and Mockito. 102 | * **Integration Tests:** Write integration tests using `@SpringBootTest`. For database interactions, consider using Testcontainers or an in-memory database (like H2) configured only for the test profile. Ensure integration tests cover the controller layer and key application flows. 103 | * **Test Location:** Place tests in the standard `src/test/java` directory, mirroring the source package structure. 104 | 105 | ## General Code Quality 106 | 107 | * **Readability:** Write clean, readable, and maintainable code. 108 | * **Comments:** Add comments only where necessary to explain complex logic or non-obvious decisions. Code should be self-documenting where possible. 109 | * **API Design:** Design RESTful APIs with clear resource naming, proper HTTP methods, and consistent request/response formats. --------------------------------------------------------------------------------