@dtt_siye/atool 1.1.0

package/templates/CLAUDE.md.go

@@ -0,0 +1,67 @@
+# Project Configuration
+
+## Project Type
+Go application / library
+
+## Build & Run
+- Build: `go build ./...`
+- Run: `go run ./cmd/myapp`
+- Test: `go test ./...`
+- Vet: `go vet ./...`
+- Lint: `golangci-lint run`
+- Format: `gofmt -w .`
+- Tidy: `go mod tidy`
+
+## Code Style
+- Follow Effective Go guidelines
+- Use `gofmt`/`goimports` for formatting
+- Use meaningful package names (lowercase, no underscores)
+- Keep functions small and focused
+- Handle errors explicitly (no silent drops)
+- Use interfaces for abstraction
+- Prefer composition over inheritance
+- Use table-driven tests
+
+## Architecture
+- Standard Go project layout (cmd/, internal/, pkg/)
+- Interface definitions for abstractions
+- Dependency injection via interfaces
+- Use context for cancellation and timeouts
+- Structured logging (slog or zerolog)
+- Configuration via environment variables or config files
+
+## Error Handling
+- Always check returned errors
+- Wrap errors with context (fmt.Errorf with %w)
+- Define sentinel errors with var
+- Custom error types for domain errors
+- Use errors.Is and errors.As for error inspection
+
+## Testing
+- Table-driven tests for comprehensive coverage
+- Use testing package (no external frameworks required)
+- Use testify/assert for assertions (if desired)
+- Mock interfaces with mockgen
+- Benchmark tests with `go test -bench`
+- Race detection with `go test -race`
+
+## Common Commands
+```bash
+# Build
+go build ./...
+
+# Run tests
+go test ./...
+
+# Run with race detection
+go test -race ./...
+
+# Lint
+golangci-lint run
+
+# Format
+gofmt -w .
+
+# Tidy dependencies
+go mod tidy
+```

package/templates/CLAUDE.md.harmony

@@ -0,0 +1,54 @@
+# Project Configuration
+
+## Project Type
+HarmonyOS / ArkTS application
+
+## Build & Run
+- Build: `hvigorw assembleHap` or use DevEco Studio
+- Run: Use DevEco Studio or `hdc install` for device deployment
+- Test: `hvigorw test`
+- Preview: Use DevEco Studio Previewer
+
+## Code Style
+- Follow ArkTS coding conventions
+- Use declarative UI paradigm (ArkUI)
+- Prefer @Component decorator for UI components
+- Use ETS (Extended TypeScript) syntax
+- Follow HarmonyOS design guidelines (consistent with device design language)
+- Use modular architecture (feature modules)
+
+## Architecture
+- MVVM pattern recommended
+- Use @State, @Prop, @Link for state management
+- Use AppStorage and LocalStorage for shared state
+- Use @Provide and @Consume for cross-component state
+- Repository pattern for data access
+- Emitters for event handling
+
+## Resource Management
+- Use `resources` directory for all resources (string, media, profile)
+- Follow resource qualifiers (en_US, zh_CN, etc.)
+- Use `$r('app.string.xxx')` for string references
+- Use `$r('app.media.xxx')` for media references
+
+## Navigation
+- Use Navigation component for page routing
+- Define routes in `main_pages.json`
+- Use NavPathStack for programmatic navigation
+
+## Testing
+- Unit tests with standard test framework
+- UI tests with UiTest framework
+- Mock external dependencies
+
+## Common Commands
+```bash
+# Build HAP package
+hvigorw assembleHap
+
+# Clean build
+hvigorw clean
+
+# Run tests
+hvigorw test
+```

package/templates/CLAUDE.md.java

@@ -0,0 +1,56 @@
+# Project Configuration
+
+## Project Type
+Java / Spring Boot project
+
+## Build & Run
+- Build: `./mvnw clean package` or `./gradlew build`
+- Run: `./mvnw spring-boot:run` or `./gradlew bootRun`
+- Test: `./mvnw test` or `./gradlew test`
+
+## Code Style
+- Follow standard Java conventions (JLS)
+- Use Spring Boot best practices and auto-configuration
+- Prefer constructor injection over field injection
+- Use `@RequiredArgsConstructor` from Lombok where appropriate
+- Follow the package-by-feature convention
+- Keep controllers thin - business logic in services
+- Use DTOs for API request/response, map with MapStruct
+
+## Architecture
+- Layered architecture: Controller → Service → Repository
+- Use Spring Data JPA for data access
+- Define proper exception handlers with `@ControllerAdvice`
+- Use `@ConfigurationProperties` for externalized configuration
+- Follow SOLID principles
+
+## Testing
+- Unit tests with JUnit 5 and Mockito
+- Integration tests with Spring Boot Test
+- Test coverage minimum: 70% for business logic
+- Use `@SpringBootTest` sparingly - prefer slice tests
+
+## Dependencies
+- Add new dependencies via `./mvnw dependency:add` or edit `pom.xml`/`build.gradle`
+- Run `./mvnw dependency:tree` to check for conflicts
+
+## API Design
+- Follow RESTful conventions
+- Use proper HTTP status codes
+- Version APIs with `/api/v1/` prefix
+- Document with Springdoc/OpenAPI
+
+## Common Commands
+```bash
+# Create a new entity
+# 1. Create entity class in model package
+# 2. Create repository interface extending JpaRepository
+# 3. Create service class with @Service
+# 4. Create REST controller with @RestController
+
+# Run tests
+./mvnw test
+
+# Check for dependency updates
+./mvnw versions:display-dependency-updates
+```

package/templates/CLAUDE.md.mobile-flutter

@@ -0,0 +1,38 @@
+---
+description: Flutter/Dart mobile development conventions
+globs: "*.dart", "pubspec.yaml"
+alwaysApply: true
+---
+# Flutter / Dart Conventions
+
+Follow Flutter and Dart best practices.
+
+## Architecture
+- Feature-first folder structure
+- BLoC / Riverpod for state management
+- Repository pattern for data access
+- Freezed for immutable models
+
+## Code Style
+- Follow Dart style guide (`dart format`, `dart analyze`)
+- Use `const` constructors where possible
+- Prefer `final` over `var`
+- Use extension methods for utilities
+- Avoid `print()` — use `logger` package
+
+## State Management
+- Riverpod (recommended): Type-safe, compile-time checked
+- BLoC: Event-driven, good for complex flows
+- Provider: Simpler, for smaller apps
+
+## Navigation
+- GoRouter for declarative routing
+- Deep linking support
+- Type-safe route parameters
+- Bottom sheets and dialogs
+
+## Testing
+- Unit tests with `test` package
+- Widget tests with `flutter_test`
+- Integration tests with `integration_test`
+- Mocktail for mocking

package/templates/CLAUDE.md.mobile-react-native

@@ -0,0 +1,37 @@
+---
+description: React Native mobile development conventions
+globs: "*.tsx", "*.ts", "package.json"
+alwaysApply: true
+---
+# React Native Conventions
+
+Follow React Native and TypeScript best practices.
+
+## Architecture
+- Feature-first folder structure
+- Screen components in `screens/`
+- Reusable components in `components/`
+- Services/API in `services/`
+
+## Code Style
+- TypeScript for all new files
+- Functional components with hooks
+- Use `expo` when possible for faster development
+- Follow React conventions
+
+## State Management
+- Zustand for simple to moderate state
+- Redux Toolkit for complex state
+- React Query / SWR for server state
+- AsyncStorage / MMKV for persistence
+
+## Navigation
+- React Navigation for routing
+- Type-safe navigation params
+- Deep linking support
+- Tab and stack navigators
+
+## Testing
+- Jest + React Native Testing Library
+- Detox for E2E tests
+- Mock native modules

package/templates/CLAUDE.md.mobile-swift

@@ -0,0 +1,40 @@
+---
+description: Swift/iOS development conventions
+globs: "*.swift", "Package.swift", "*.xcodeproj"
+alwaysApply: true
+---
+# Swift / iOS Conventions
+
+Follow Swift and iOS development best practices.
+
+## Architecture
+- MVVM with SwiftUI
+- The Composable Architecture (TCA) for complex state
+- Clean Architecture for large apps
+- Protocol-oriented design
+
+## Code Style
+- Follow Swift API Design Guidelines
+- SwiftUI for UI (modern projects)
+- Value types over reference types
+- `guard` for early returns
+- `final` classes by default
+
+## SwiftUI Patterns
+- `@StateObject` for owned observable objects
+- `@ObservedObject` for observed objects from parent
+- `@EnvironmentObject` for shared state
+- `@AppStorage` for user preferences
+- `@Observable` macro (Observation framework)
+
+## Navigation
+- SwiftUI NavigationStack / NavigationSplitView
+- Type-safe routing with enums
+- Deep linking support
+- Sheet and fullScreenCover for modals
+
+## Testing
+- XCTest for unit and UI tests
+- Swift Testing framework (new)
+- Mock with protocols
+- Preview-based development

package/templates/CLAUDE.md.python

@@ -0,0 +1,65 @@
+# Project Configuration
+
+## Project Type
+Python application (Django / FastAPI / Flask / CLI)
+
+## Build & Run
+- Install: `pip install -e ".[dev]"` or `poetry install`
+- Run: `python -m myapp` or `uvicorn myapp.main:app --reload`
+- Test: `pytest` or `python -m pytest`
+- Lint: `ruff check .` or `flake8`
+- Format: `ruff format .` or `black .`
+- Type check: `mypy .`
+
+## Code Style
+- Follow PEP 8 conventions
+- Use type hints for all function signatures
+- Use docstrings (Google or NumPy style)
+- Prefer pathlib over os.path
+- Use f-strings for string formatting
+- Maximum line length: 88 (Black default) or 120 (per project)
+- Use virtual environments (venv, poetry, uv)
+
+## Architecture
+- Separate concerns: routes, services, models, schemas
+- Use Pydantic models for data validation
+- Dependency injection for testability
+- Use environment variables for configuration (python-dotenv or pydantic-settings)
+- Follow the repository pattern for data access
+
+## Testing
+- pytest for all testing
+- Use fixtures for setup/teardown
+- Mock external dependencies with pytest-mock
+- Test coverage: aim for 80%+
+- Use hypothesis for property-based testing where appropriate
+
+## Dependencies
+- Pin dependencies in requirements.txt or pyproject.toml
+- Use `pip-compile` or `poetry lock` for reproducible builds
+- Separate dev dependencies
+
+## API Design
+- Use REST conventions for API endpoints (resource-oriented URLs, correct HTTP methods)
+- Version APIs when breaking changes are needed (/api/v1/, /api/v2/)
+- Use Pydantic schemas for request/response validation
+- Document APIs with OpenAPI/Swagger (FastAPI auto-generates, Django via drf-spectacular)
+- Return consistent error response format with error codes and messages
+
+## Common Commands
+```bash
+# Run tests
+pytest
+
+# Run with coverage
+pytest --cov=myapp --cov-report=term-missing
+
+# Lint
+ruff check .
+
+# Format
+ruff format .
+
+# Type check
+mypy .
+```

package/templates/CLAUDE.md.rust

@@ -0,0 +1,68 @@
+# Project Configuration
+
+## Project Type
+Rust application / library
+
+## Build & Run
+- Build: `cargo build`
+- Run: `cargo run`
+- Test: `cargo test`
+- Check: `cargo check`
+- Clippy: `cargo clippy`
+- Format: `cargo fmt`
+- Release: `cargo build --release`
+
+## Code Style
+- Follow Rust API Guidelines
+- Use `rustfmt` for formatting
+- Use `clippy` for linting (deny warnings)
+- Prefer `Result` over panic/unwrap in library code
+- Use meaningful error types (thiserror for custom errors)
+- Prefer ownership over borrowing when it simplifies code
+- Use iterators and functional patterns
+- Document public APIs with `///` doc comments
+
+## Architecture
+- Module system for organization (lib.rs / main.rs)
+- Trait definitions for abstractions
+- Error handling with Result and custom error types
+- Use `async/await` for I/O-bound operations
+- Feature flags for optional functionality
+
+## Testing
+- Unit tests in the same module (`#[cfg(test)]` mod)
+- Integration tests in `tests/` directory
+- Use `#[should_panic]` for panic tests
+- Property-based testing with `proptest`
+- Mock external dependencies with `mockall`
+
+## Dependencies
+- Declare dependencies in Cargo.toml with version constraints
+- Use `cargo update` to update lock file, review changes before committing
+- Prefer workspace inheritance for shared dependency versions in multi-crate projects
+- Audit dependencies with `cargo audit` for known vulnerabilities
+
+## API Design
+- Design public APIs with Rust API Guidelines in mind
+- Use builder pattern for complex configuration
+- Return `Result<T, E>` for fallible operations (avoid panics in library code)
+- Implement `From` for error type conversions
+- Document public API with `///` doc comments including examples
+
+## Common Commands
+```bash
+# Build
+cargo build
+
+# Run tests
+cargo test
+
+# Check + Clippy
+cargo clippy -- -D warnings
+
+# Format
+cargo fmt
+
+# Run with release optimizations
+cargo run --release
+```

package/templates/CLAUDE.md.rust-tauri

@@ -0,0 +1,120 @@
+# {{PROJECT_NAME}}
+
+{{PROJECT_DESCRIPTION}}
+
+## 项目架构
+
+本项目基于 **Tauri 2** 桌面应用框架，采用 Rust + Web 前端双架构设计：
+
+```
+{{PROJECT_NAME}}/
+├── src/                    # 前端代码（Web UI）
+│   ├── App.tsx             # 应用入口
+│   ├── main.tsx            # 渲染进程入口
+│   ├── components/         # UI 组件
+│   ├── hooks/              # 自定义 Hooks
+│   ├── stores/             # 状态管理
+│   ├── services/           # API/Tauri IPC 调用层
+│   ├── styles/             # 样式文件
+│   └── utils/              # 工具函数
+├── src-tauri/              # Rust 后端代码
+│   ├── Cargo.toml          # Rust 依赖
+│   ├── tauri.conf.json     # Tauri 配置
+│   ├── src/
+│   │   ├── main.rs         # 主入口
+│   │   ├── lib.rs          # 库入口（注册命令）
+│   │   ├── commands/       # Tauri 命令模块
+│   │   ├── state.rs        # 应用状态管理
+│   │   └── utils/          # Rust 工具模块
+│   ├── capabilities/       # 权限配置
+│   └── icons/              # 应用图标
+├── package.json            # 前端依赖
+├── vite.config.ts          # Vite 构建配置
+└── tsconfig.json           # TypeScript 配置
+```
+
+## 技术栈
+
+| 层 | 技术 | 说明 |
+|---|------|------|
+| 桌面框架 | Tauri 2 | Rust 后端 + Web 前端 |
+| 后端语言 | Rust | 系统级操作、IPC 命令 |
+| 前端框架 | React + TypeScript | UI 渲染 |
+| 构建工具 | Vite | 前端构建 |
+| 包管理 | pnpm / npm | 前端依赖管理 |
+| Rust 包管理 | Cargo | 后端依赖管理 |
+
+## 核心设计模式
+
+### IPC 通信模式
+
+前端通过 `@tauri-apps/api` 的 `invoke()` 调用 Rust 命令：
+
+```typescript
+// 前端调用
+import { invoke } from '@tauri-apps/api/core';
+const result = await invoke('my_command', { arg1: 'value' });
+```
+
+```rust
+// Rust 端定义
+#[tauri::command]
+async fn my_command(arg1: String) -> Result<String, String> {
+    Ok(format!("Received: {}", arg1))
+}
+```
+
+### 状态管理
+
+- **前端状态**: React 状态管理（Zustand/Context）
+- **后端状态**: `tauri::State` 管理应用全局状态
+- **跨层通信**: 仅通过 IPC 命令传递，不共享内存
+
+### 安全模型
+
+- 所有系统 API 访问必须在 `capabilities/` 中声明权限
+- 文件系统访问通过作用域（scope）限制路径
+- 窗口操作受权限控制
+
+## 开发规范
+
+### Rust 端
+
+- 遵循 Rust 官方编码规范（`rustfmt` + `clippy`）
+- 错误处理使用 `Result<T, E>`，禁止 `unwrap()` 在生产代码中
+- 命令函数必须标注 `#[tauri::command]`
+- 异步操作使用 `async fn` + Tokio
+- 共享状态使用 `tauri::State` 注入
+
+### 前端
+
+- TypeScript strict 模式
+- 函数式组件 + Hooks
+- IPC 调用统一封装在 `services/` 层
+- 组件文件与样式文件就近放置
+- 使用 CSS Modules 或 Tailwind CSS
+
+## 常用命令
+
+```bash
+# 前端开发
+pnpm install          # 安装前端依赖
+pnpm dev              # 启动前端开发服务器
+
+# Tauri 开发（同时启动前后端）
+pnpm tauri dev        # 开发模式（热重载）
+pnpm tauri build      # 构建发布版本
+
+# Rust 检查
+cd src-tauri && cargo check    # 快速检查
+cd src-tauri && cargo clippy   # Lint 检查
+cd src-tauri && cargo test     # 运行测试
+```
+
+## 文档同步规则
+
+修改 `src/` 下的前端代码或 `src-tauri/src/` 下的 Rust 代码后，必须同步更新：
+1. `README.md` — 架构、目录结构、技术栈
+2. `COMPONENT.md` — 组件/命令 API 和使用示例
+3. `UI_STYLE.md` — 涉及的样式变更
+4. `docs/` — 对应的模块文档

package/templates/CLAUDE.md.web

@@ -0,0 +1,63 @@
+# Project Configuration
+
+## Project Type
+Web application (React / Next.js / Vue / Svelte)
+
+## Build & Run
+- Install: `npm install` or `pnpm install` or `yarn install`
+- Dev: `npm run dev` or `pnpm dev`
+- Build: `npm run build` or `pnpm build`
+- Test: `npm test` or `pnpm test`
+- Lint: `npm run lint` or `pnpm lint`
+
+## Code Style
+- Use TypeScript for all new files
+- Use functional components and hooks (no class components)
+- Follow the framework's official style guide
+- Use CSS Modules, Tailwind CSS, or styled-components (per project convention)
+- Prefer composition over inheritance
+- Keep components small and focused (single responsibility)
+
+## Component Architecture
+- Co-locate related files (component, styles, tests)
+- Use barrel exports (index.ts) for public APIs
+- Prefer custom hooks for reusable logic
+- Use proper prop typing with TypeScript interfaces
+- Implement proper error boundaries
+
+## State Management
+- Use framework-provided state (useState, useReducer, Zustand, Pinia, etc.)
+- Keep server state separate from client state
+- Use optimistic updates for better UX
+
+## API Integration
+- Use established patterns (React Query, SWR, asyncData, etc.)
+- Proper error handling and loading states
+- Type API responses with TypeScript
+
+## Dependencies
+- Pin dependency versions in package.json (use exact versions or lock file)
+- Use `npm audit` or `pnpm audit` to check for vulnerabilities
+- Keep dev dependencies separate from production dependencies
+- Review and update dependencies regularly
+
+## Testing
+- Unit tests for utilities and custom hooks
+- Component tests with Testing Library
+- E2E tests for critical flows
+- Mock external dependencies
+
+## Common Commands
+```bash
+# Install dependencies
+npm install
+
+# Run development server
+npm run dev
+
+# Run tests
+npm test
+
+# Build for production
+npm run build
+```

package/templates/COMPONENT.md.android

@@ -0,0 +1,58 @@
+# {{PROJECT_NAME}} - 组件文档
+
+> 本文档由 `project-analyze` skill 自动生成，也可手动维护。
+
+## Feature 模块
+
+> 由 `project-analyze` skill 自动填充
+
+| 模块 | 包路径 | 描述 |
+|------|--------|------|
+| | | |
+
+## UI 层 (Screens / Composables)
+
+> 由 `project-analyze` skill 自动填充
+
+| 页面/组件 | 文件路径 | 描述 |
+|-----------|----------|------|
+| | | |
+
+## ViewModel 层
+
+> 由 `project-analyze` skill 自动填充
+
+| ViewModel | 关联 UI | State | Actions |
+|-----------|---------|-------|---------|
+| | | | |
+
+## Model 层
+
+> 由 `project-analyze` skill 自动填充
+
+| 模型 | 类型 | 描述 |
+|------|------|------|
+| | Entity | |
+| | DTO | |
+| | UI State | |
+
+## Repository 层
+
+> 由 `project-analyze` skill 自动填充
+
+| Repository | 数据源 | 描述 |
+|------------|--------|------|
+| | Remote | |
+| | Local | |
+
+## 依赖注入 (DI)
+
+> 由 `project-analyze` skill 自动填充
+
+| Module | 提供的依赖 | 描述 |
+|--------|-----------|------|
+| | | |
+
+## 跨模块导航
+
+> 由 `project-analyze` skill 自动填充