@dtt_siye/atool 1.1.0

package/templates/cursor-rules.harmony.mdc

@@ -0,0 +1,30 @@
+---
+description: HarmonyOS/ArkTS development conventions
+globs: "*.ets", "*.ts", "oh-package.json5", "build-profile.json5"
+alwaysApply: true
+---
+# HarmonyOS/ArkTS Conventions
+
+Follow HarmonyOS and ArkTS best practices.
+
+## Architecture
+- MVVM pattern
+- @Component decorator for UI
+- @State/@Prop/@Link for state management
+- Repository pattern for data access
+
+## Code Style
+- ArkTS conventions
+- Declarative UI paradigm (ArkUI)
+- Modular architecture (feature modules)
+- Emitters for event handling
+
+## Resources
+- Use resources directory for strings and media
+- Use $r() references for resources
+- Follow resource qualifiers
+
+## Navigation
+- Navigation component for routing
+- Define routes in main_pages.json
+- NavPathStack for programmatic navigation

package/templates/cursor-rules.java.mdc

@@ -0,0 +1,30 @@
+---
+description: Java/Spring Boot development conventions
+globs: "*.java", "pom.xml", "build.gradle"
+alwaysApply: true
+---
+# Java/Spring Boot Conventions
+
+Follow standard Java conventions and Spring Boot best practices.
+
+## Architecture
+- Layered: Controller → Service → Repository
+- Prefer constructor injection
+- Keep controllers thin, business logic in services
+- Use DTOs for API request/response
+
+## Code Style
+- Package-by-feature convention
+- Use Lombok `@RequiredArgsConstructor` for injection
+- Follow SOLID principles
+- Proper exception handling with `@ControllerAdvice`
+
+## Testing
+- JUnit 5 + Mockito for unit tests
+- Spring Boot Test for integration tests
+- Minimum 70% coverage for business logic
+
+## API Design
+- RESTful conventions
+- Proper HTTP status codes
+- Version with `/api/v1/` prefix

package/templates/cursor-rules.mobile-flutter.mdc

@@ -0,0 +1,42 @@
+---
+name: atool-flutter-conventions
+description: Flutter/Dart mobile development conventions
+mode: agent
+instructions: |
+  You are working on a Flutter/Dart project. Follow these conventions:
+
+  ## 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
+
+  ## Testing
+  - Unit tests with `test` package
+  - Widget tests with `flutter_test`
+  - Integration tests with `integration_test`
+  - Mocktail for mocking
+
+  ## Build Commands
+  - Run: flutter run
+  - Build APK: flutter build apk
+  - Build iOS: flutter build ios
+  - Test: flutter test
+  - Analyze: flutter analyze

package/templates/cursor-rules.mobile-react-native.mdc

@@ -0,0 +1,43 @@
+---
+name: atool-react-native-conventions
+description: React Native mobile development conventions
+mode: agent
+instructions: |
+  You are working on a React Native project. Follow these conventions:
+
+  ## Architecture
+  - Feature-first folder structure
+  - Screen components in `screens/`
+  - Reusable components in `components/`
+  - Services/API in `services/`
+  - Hooks in `hooks/`
+  - Navigation in `navigation/`
+
+  ## 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
+
+  ## Build Commands
+  - Run Android: npm run android
+  - Run iOS: npm run ios
+  - Test: npm test
+  - Start Metro: npm start

package/templates/cursor-rules.mobile-swift.mdc

@@ -0,0 +1,42 @@
+---
+name: atool-swift-conventions
+description: Swift/iOS development conventions
+mode: agent
+instructions: |
+  You are working on a Swift/iOS project. Follow these conventions:
+
+  ## Architecture
+  - MVVM architecture with SwiftUI
+  - The Composable Architecture (TCA) for complex state
+  - Clean Architecture for large apps
+  - Protocol-oriented design
+
+  ## Code Style
+  - Follow Swift API Design Guidelines
+  - Use SwiftUI for UI (modern projects)
+  - Prefer value types over reference types
+  - Use `guard` for early returns
+  - Use `final` classes by default
+  - Use `async/await` for concurrency
+
+  ## 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
+
+  ## Testing
+  - XCTest for unit and UI tests
+  - Swift Testing framework (new)
+  - Mock with protocols (no frameworks needed)
+
+  ## Build Commands
+  - Build: xcodebuild build -scheme MyApp
+  - Test: xcodebuild test -scheme MyApp
+  - Run: open in Xcode and run

package/templates/cursor-rules.python.mdc

@@ -0,0 +1,33 @@
+---
+description: Python development conventions
+globs: "*.py", "pyproject.toml", "requirements.txt", "setup.py"
+alwaysApply: true
+---
+# Python Conventions
+
+Follow Python best practices.
+
+## Code Style
+- PEP 8 conventions
+- Type hints for all function signatures
+- Docstrings (Google or NumPy style)
+- Prefer pathlib over os.path
+- f-strings for formatting
+- Max line length: 88 or 120
+
+## Architecture
+- Separate routes, services, models, schemas
+- Pydantic models for validation
+- Dependency injection for testability
+- Environment variables for config
+
+## Testing
+- pytest for all testing
+- Fixtures for setup/teardown
+- Mock external dependencies
+- Aim for 80%+ coverage
+
+## Tools
+- Ruff for linting and formatting
+- mypy for type checking
+- pytest for testing

package/templates/cursor-rules.rust-tauri.mdc

@@ -0,0 +1,67 @@
+---
+description: Tauri 2 desktop app conventions (Rust + Web frontend)
+globs: "*.rs", "*.tsx", "*.ts", "*.vue", "*.svelte", "Cargo.toml", "tauri.conf.json", "package.json"
+alwaysApply: true
+---
+# Tauri 2 Desktop App Conventions
+
+Follow Tauri 2 best practices for Rust + Web desktop applications.
+
+## Architecture
+
+This is a dual-architecture project:
+- **Frontend** (`src/`): Web UI (React/Vue/Svelte + TypeScript + Vite)
+- **Backend** (`src-tauri/`): Rust (Tauri commands, system APIs)
+- **Communication**: IPC via `invoke()` / `#[tauri::command]`
+
+## Code Style
+
+### Rust (src-tauri/)
+- Follow Rust official style guide (`rustfmt` + `clippy`)
+- Error handling: use `Result<T, E>`, no `unwrap()` in production
+- Async: use `async fn` + Tokio runtime
+- All commands: `#[tauri::command]` annotation
+- State: inject via `tauri::State`
+
+### Frontend (src/)
+- TypeScript strict mode for all new files
+- Functional components and hooks only
+- IPC calls encapsulated in `services/` layer
+- Component files co-located with styles
+
+## IPC Pattern
+
+```rust
+// Rust side
+#[tauri::command]
+async fn my_command(arg: String) -> Result<String, String> {
+    Ok(format!("Received: {}", arg))
+}
+```
+
+```typescript
+// Frontend side
+import { invoke } from '@tauri-apps/api/core';
+const result = await invoke<string>('my_command', { arg: 'value' });
+```
+
+## Security
+
+- All system API access must be declared in `capabilities/`
+- File system access scoped via `scope` configuration
+- Window operations require proper permissions
+- Never disable security features for convenience
+
+## Testing
+
+- Rust: `cargo test` in src-tauri/
+- Frontend: `pnpm test` or `npm test`
+- E2E: Use WebDriver or Tauri's testing utilities
+
+## Build Commands
+
+- Install: `pnpm install` or `npm install`
+- Dev: `pnpm tauri dev` (hot reload for both layers)
+- Build: `pnpm tauri build`
+- Rust check: `cd src-tauri && cargo check`
+- Rust lint: `cd src-tauri && cargo clippy`

package/templates/cursor-rules.rust.mdc

@@ -0,0 +1,30 @@
+---
+description: Rust/Cargo development conventions
+globs: "*.rs", "Cargo.toml"
+alwaysApply: true
+---
+# Rust Conventions
+
+Follow Rust best practices and idioms.
+
+## Code Style
+- Rust API Guidelines
+- rustfmt for formatting
+- clippy for linting (deny warnings)
+- Result over panic/unwrap in libraries
+- Meaningful error types (thiserror)
+- Iterators and functional patterns
+- Doc comments for public APIs
+
+## Architecture
+- Module system for organization
+- Trait definitions for abstractions
+- Custom error types with thiserror
+- async/await for I/O operations
+- Feature flags for optional functionality
+
+## Testing
+- Unit tests in-module with #[cfg(test)]
+- Integration tests in tests/
+- proptest for property-based testing
+- mockall for mocking

package/templates/cursor-rules.web.mdc

@@ -0,0 +1,30 @@
+---
+description: Web development conventions (React/Next.js/Vue/Svelte)
+globs: "*.tsx", "*.ts", "*.vue", "*.svelte", "package.json"
+alwaysApply: true
+---
+# Web Development Conventions
+
+Follow modern web development best practices.
+
+## Code Style
+- TypeScript for all new files
+- Functional components and hooks only
+- Follow the framework's official style guide
+- Keep components small and focused
+
+## Architecture
+- Co-locate related files
+- Use barrel exports for public APIs
+- Prefer custom hooks/composables for reusable logic
+- Proper prop typing with TypeScript interfaces
+
+## State Management
+- Framework-provided state as primary
+- Separate server state from client state
+- Optimistic updates for better UX
+
+## Testing
+- Testing Library for component tests
+- Unit tests for utilities and hooks
+- E2E tests for critical flows

package/templates/kiro-steering.android.md

@@ -0,0 +1,39 @@
+---
+inclusion: always
+name: atool-android-conventions
+description: Android/Kotlin development conventions
+---
+
+You are working on an Android/Kotlin project. Follow these conventions:
+
+## Architecture
+- MVVM architecture with Repository pattern
+- Jetpack Compose for UI (modern projects)
+- Hilt for dependency injection
+- Room for local database
+- Retrofit + OkHttp for networking
+
+## Code Style
+- Follow Kotlin coding conventions
+- Use Android KTX extensions
+- Coroutines and Flow over callbacks
+- ViewModels with proper lifecycle management
+- Sealed classes for state representation
+- Data classes for data holders
+
+## Resource Management
+- snake_case naming conventions
+- String resources for all user-facing text
+- Vector drawables over PNG
+- Material Design 3 guidelines
+
+## Testing
+- JUnit 5 + MockK for unit tests
+- Turbine for Flow testing
+- Compose Test Rule for UI tests
+
+## Build Commands
+- Build: ./gradlew assembleDebug
+- Test: ./gradlew test
+- Run: ./gradlew installDebug
+

package/templates/kiro-steering.devops.md

@@ -0,0 +1,32 @@
+---
+inclusion: always
+name: atool-devops-conventions
+description: DevOps/Infrastructure conventions
+---
+
+You are working on a DevOps/Infrastructure project. Follow these conventions:
+
+## Docker
+- Multi-stage builds for minimal image size
+- Pin base image versions (never use latest)
+- Use .dockerignore
+- Run as non-root user
+
+## Kubernetes
+- Declarative YAML manifests
+- Resource limits and requests
+- ConfigMaps and Secrets for configuration
+- Liveness and readiness probes
+
+## Terraform
+- Modules for reusable infrastructure
+- Pin provider versions
+- Remote state with locking
+- Separate environments (dev/staging/prod)
+
+## CI/CD
+- Pipeline as code
+- Test before deploy
+- Immutable artifacts
+- Rollback strategy
+

package/templates/kiro-steering.generic.md

@@ -0,0 +1,28 @@
+---
+inclusion: always
+name: atool-generic-conventions
+description: Generic development conventions
+---
+
+You are working on a generic project. Follow these conventions:
+
+## Guidelines
+- Follow the language's standard conventions and style guide
+- Write clear, self-documenting code
+- Handle errors gracefully
+- Use version control with meaningful commit messages
+
+## Code Quality
+- Run linters and formatters appropriate for the language
+- Use static analysis tools when available
+- Write meaningful commit messages
+
+## Testing
+- Write tests for critical functionality
+- Use the language's standard testing framework
+- Mock external dependencies
+
+## Tips
+- aTool can auto-detect your stack once you add config files
+- Run /atool-init to re-run initialization after project setup
+

package/templates/kiro-steering.go.md

@@ -0,0 +1,41 @@
+---
+inclusion: always
+name: atool-go-conventions
+description: Go development conventions
+---
+
+You are working on a Go project. Follow these conventions:
+
+## Code Style
+- Follow Effective Go guidelines
+- Use gofmt/goimports for formatting
+- Keep functions small and focused
+- Handle errors explicitly
+- Use interfaces for abstraction
+- Prefer composition over inheritance
+
+## 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)
+
+## Error Handling
+- Always check returned errors
+- Wrap errors with context (fmt.Errorf %w)
+- Use errors.Is and errors.As for error inspection
+
+## Testing
+- Table-driven tests
+- testing package + testify/assert
+- mockgen for interface mocking
+- go test -race for race detection
+
+## Build Commands
+- Build: go build ./...
+- Test: go test ./...
+- Lint: golangci-lint run
+- Format: gofmt -w .
+- Tidy: go mod tidy
+

package/templates/kiro-steering.harmony.md

@@ -0,0 +1,36 @@
+---
+inclusion: always
+name: atool-harmony-conventions
+description: HarmonyOS/ArkTS development conventions
+---
+
+You are working on a HarmonyOS/ArkTS project. Follow these conventions:
+
+## Architecture
+- MVVM pattern recommended
+- @Component decorator for UI components
+- @State, @Prop, @Link for state management
+- AppStorage and LocalStorage for shared state
+- Repository pattern for data access
+
+## Code Style
+- Follow ArkTS coding conventions
+- Declarative UI paradigm (ArkUI)
+- ETS (Extended TypeScript) syntax
+- Modular architecture (feature modules)
+
+## Resource Management
+- Use resources directory for all resources
+- Follow resource qualifiers (en_US, zh_CN, etc.)
+- Use $r() for resource references
+
+## Navigation
+- Navigation component for page routing
+- Define routes in main_pages.json
+- NavPathStack for programmatic navigation
+
+## Build Commands
+- Build: hvigorw assembleHap
+- Clean: hvigorw clean
+- Test: hvigorw test
+

package/templates/kiro-steering.java.md

@@ -0,0 +1,37 @@
+---
+inclusion: always
+name: atool-java-conventions
+description: Java/Spring Boot development conventions
+---
+
+You are working on a Java/Spring Boot project. Follow these conventions:
+
+## Architecture
+- Layered architecture: Controller → Service → Repository
+- Prefer constructor injection over field injection
+- Keep controllers thin, business logic in services
+- Use DTOs for API request/response, map with MapStruct
+
+## Code Style
+- Follow standard Java conventions (JLS)
+- Package-by-feature convention
+- Use Lombok where appropriate
+- Follow SOLID principles
+
+## Testing
+- JUnit 5 + Mockito for unit tests
+- Spring Boot Test for integration tests
+- Minimum 70% coverage for business logic
+
+## API Design
+- Follow RESTful conventions with proper HTTP status codes
+- Version APIs with /api/v1/ prefix
+- Document with Springdoc/OpenAPI
+- Use DTOs for API request/response, map with MapStruct
+- Centralized exception handling with @ControllerAdvice
+
+## Build Commands
+- Build: ./mvnw clean package or ./gradlew build
+- Test: ./mvnw test or ./gradlew test
+- Run: ./mvnw spring-boot:run or ./gradlew bootRun
+

package/templates/kiro-steering.mobile-flutter.md

@@ -0,0 +1,73 @@
+---
+inclusion: always
+name: atool-flutter-conventions
+description: Flutter/Dart mobile development conventions
+---
+
+You are working on a Flutter/Dart project. Follow these conventions:
+
+## Project Type
+Flutter / Dart mobile application
+
+## Build & Run
+- Run: `flutter run`
+- Build APK: `flutter build apk`
+- Build iOS: `flutter build ios`
+- Test: `flutter test`
+- Analyze: `flutter analyze`
+- Clean: `flutter clean`
+
+## 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
+- Use Freezed for immutable model classes
+
+## Architecture
+- Feature-first folder structure
+- BLoC / Riverpod for state management
+- Repository pattern for data access
+- Freezed for immutable models
+- Clean Architecture layers
+
+## 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
+- Golden tests for UI snapshots
+
+## Common Commands
+```bash
+# Run on connected device/emulator
+flutter run
+
+# Run tests
+flutter test
+
+# Analyze code
+flutter analyze
+
+# Build Android APK
+flutter build apk
+
+# Build iOS
+flutter build ios
+
+# Clean build artifacts
+flutter clean
+```
+