moai-adk 0.3.13__py3-none-any.whl → 0.4.1__py3-none-any.whl

moai_adk/templates/.claude/skills/moai-lang-rust/SKILL.md

@@ -0,0 +1,100 @@
+---
+
+name: moai-lang-rust
+description: Rust best practices with cargo test, clippy, rustfmt, and ownership/borrow checker mastery. Use when writing or reviewing Rust code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Rust Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Rust code discussions, framework guidance, or file extensions such as .rs. |
+| Tier | 3 |
+
+## What it does
+
+Provides Rust-specific expertise for TDD development, including cargo test, clippy linting, rustfmt formatting, and ownership/borrow checker compliance.
+
+## When to use
+
+- Engages when the conversation references Rust work, frameworks, or files like .rs.
+- “Writing Rust tests”, “How to use cargo tests”, “Ownership rules”
+- Automatically invoked when working with Rust projects
+- Rust SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **cargo test**: Built-in test framework
+- **proptest**: Property-based testing
+- **criterion**: Benchmarking
+- Test coverage with `cargo tarpaulin` or `cargo llvm-cov`
+
+**Code Quality**:
+- **clippy**: Rust linter with 500+ lint rules
+- **rustfmt**: Automatic code formatting
+- **cargo check**: Fast compilation check
+- **cargo audit**: Security vulnerability scanning
+
+**Memory Safety**:
+- **Ownership**: One owner per value
+- **Borrowing**: Immutable (&T) or mutable (&mut T) references
+- **Lifetimes**: Explicit lifetime annotations when needed
+- **Move semantics**: Understanding Copy vs Clone
+
+**Rust Patterns**:
+- Result<T, E> for error handling (no exceptions)
+- Option<T> for nullable values
+- Traits for polymorphism
+- Match expressions for exhaustive handling
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Prefer immutable bindings (let vs let mut)
+- Use iterators over manual loops
+- Avoid `unwrap()` in production code, use proper error handling
+
+## Examples
+```bash
+cargo test && cargo clippy -- -D warnings
+```
+
+## Inputs
+- Language-specific source directories (e.g. `src/`, `app/`).
+- Language-specific build/test configuration files (e.g. `package.json`, `pyproject.toml`, `go.mod`).
+- Relevant test suites and sample data.
+
+## Outputs
+- Test/lint execution plan tailored to the selected language.
+- List of key language idioms and review checkpoints.
+
+## Failure Modes
+- When the language runtime or package manager is not installed.
+- When the main language cannot be determined in a multilingual project.
+
+## Dependencies
+- Access to the project file is required using the Read/Grep tool.
+- When used with `Skill("moai-foundation-langs")`, it is easy to share cross-language conventions.
+
+## References
+- Rust Project Developers. "The Rust Programming Language." https://doc.rust-lang.org/book/ (accessed 2025-03-29).
+- Rust Project Developers. "Clippy." https://doc.rust-lang.org/clippy/ (accessed 2025-03-29).
+
+## Changelog
+- 2025-03-29: Input/output/failure response/reference information for each language has been specified.
+
+## Works well with
+
+- alfred-trust-validation (coverage verification)
+- alfred-code-reviewer (Rust-specific review)
+- alfred-performance-optimizer (Rust benchmarking)
+
+## Best Practices
+- Enable automatic validation by matching your linter with the language's official style guide.
+- Fix test/build pipelines with reproducible commands in CI.

moai_adk/templates/.claude/skills/moai-lang-scala/SKILL.md

@@ -0,0 +1,100 @@
+---
+
+name: moai-lang-scala
+description: Scala best practices with ScalaTest, sbt, and functional programming patterns. Use when writing or reviewing Scala code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Scala Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Scala code discussions, framework guidance, or file extensions such as .scala. |
+| Tier | 3 |
+
+## What it does
+
+Provides Scala-specific expertise for TDD development, including ScalaTest framework, sbt build tool, and functional programming patterns.
+
+## When to use
+
+- Engages when the conversation references Scala work, frameworks, or files like .scala.
+- “Writing Scala tests”, “How to use ScalaTest”, “Functional programming”
+- Automatically invoked when working with Scala projects
+- Scala SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **ScalaTest**: Flexible testing framework
+- **specs2**: BDD-style testing
+- **ScalaCheck**: Property-based testing
+- Test coverage with sbt-scoverage
+
+**Build Tools**:
+- **sbt**: Scala build tool
+- **build.sbt**: Build configuration
+- Multi-project builds
+
+**Code Quality**:
+- **Scalafmt**: Code formatting
+- **Scalafix**: Linting and refactoring
+- **WartRemover**: Code linting
+
+**Functional Programming**:
+- **Immutable data structures**
+- **Higher-order functions**
+- **Pattern matching**
+- **For-comprehensions**
+- **Monads (Option, Either, Try)**
+
+**Best Practices**:
+- File ≤300 LOC, method ≤50 LOC
+- Prefer immutable vals over mutable vars
+- Case classes for data modeling
+- Tail recursion for loops
+- Avoid null, use Option
+
+## Examples
+```bash
+sbt test && sbt scalafmtCheck
+```
+
+## Inputs
+- Language-specific source directories (e.g. `src/`, `app/`).
+- Language-specific build/test configuration files (e.g. `package.json`, `pyproject.toml`, `go.mod`).
+- Relevant test suites and sample data.
+
+## Outputs
+- Test/lint execution plan tailored to the selected language.
+- List of key language idioms and review checkpoints.
+
+## Failure Modes
+- When the language runtime or package manager is not installed.
+- When the main language cannot be determined in a multilingual project.
+
+## Dependencies
+- Access to the project file is required using the Read/Grep tool.
+- When used with `Skill("moai-foundation-langs")`, it is easy to share cross-language conventions.
+
+## References
+- Lightbend. "Scala Documentation." https://docs.scala-lang.org/ (accessed 2025-03-29).
+- Scalameta. "scalafmt." https://scalameta.org/scalafmt/ (accessed 2025-03-29).
+
+## Changelog
+- 2025-03-29: Input/output/failure response/reference information for each language has been specified.
+
+## Works well with
+
+- alfred-trust-validation (coverage verification)
+- alfred-code-reviewer (Scala-specific review)
+- alfred-refactoring-coach (functional refactoring)
+
+## Best Practices
+- Enable automatic validation by matching your linter with the language's official style guide.
+- Fix test/build pipelines with reproducible commands in CI.

moai_adk/templates/.claude/skills/moai-lang-shell/SKILL.md

@@ -0,0 +1,100 @@
+---
+
+name: moai-lang-shell
+description: Shell scripting best practices with bats, shellcheck, and POSIX compliance. Use when writing or reviewing Shell scripts code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Shell Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Shell code discussions, framework guidance, or file extensions such as .sh/.bash. |
+| Tier | 3 |
+
+## What it does
+
+Provides shell scripting expertise for TDD development, including bats testing framework, shellcheck linting, and POSIX compliance for portable scripts.
+
+## When to use
+
+- Engages when the conversation references Shell work, frameworks, or files like .sh/.bash.
+- "Writing shell scripts", "bats testing", "POSIX compatibility"
+- Automatically invoked when working with shell script projects
+- Shell SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **bats**: Bash Automated Testing System
+- **shunit2**: xUnit-style shell testing
+- **assert.sh**: Shell assertion library
+- Test-driven shell development
+
+**Code Quality**:
+- **shellcheck**: Static analysis for shell scripts
+- **shfmt**: Shell script formatting
+- **bashate**: Style checker
+
+**POSIX Compliance**:
+- Portable shell features (sh vs bash)
+- Avoid bashisms for portability
+- Use `[ ]` instead of `[[ ]]` for POSIX
+- Standard utilities (no GNU extensions)
+
+**Shell Patterns**:
+- **Error handling**: set -e, set -u, set -o pipefail
+- **Exit codes**: Proper use of 0 (success) and non-zero
+- **Quoting**: Always quote variables ("$var")
+- **Functions**: Modular script organization
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Use `#!/bin/sh` for POSIX, `#!/bin/bash` for Bash
+- Check command existence with `command -v`
+- Use `$()` over backticks
+- Validate input arguments
+
+## Examples
+```bash
+bats tests && shellcheck scripts/*.sh
+```
+
+## Inputs
+- Language-specific source directories (e.g. `src/`, `app/`).
+- Language-specific build/test configuration files (e.g. `package.json`, `pyproject.toml`, `go.mod`).
+- Relevant test suites and sample data.
+
+## Outputs
+- Test/lint execution plan tailored to the selected language.
+- List of key language idioms and review checkpoints.
+
+## Failure Modes
+- When the language runtime or package manager is not installed.
+- When the main language cannot be determined in a multilingual project.
+
+## Dependencies
+- Access to the project file is required using the Read/Grep tool.
+- When used with `Skill("moai-foundation-langs")`, it is easy to share cross-language conventions.
+
+## References
+- GNU. "Bash Reference Manual." https://www.gnu.org/software/bash/manual/bash.html (accessed 2025-03-29).
+- koalaman. "ShellCheck." https://www.shellcheck.net/ (accessed 2025-03-29).
+
+## Changelog
+- 2025-03-29: Input/output/failure response/reference information for each language has been specified.
+
+## Works well with
+
+- alfred-trust-validation (coverage verification)
+- alfred-code-reviewer (Shell-specific review)
+- devops-expert (Deployment scripts)
+
+## Best Practices
+- Enable automatic validation by matching your linter with the language's official style guide.
+- Fix test/build pipelines with reproducible commands in CI.

moai_adk/templates/.claude/skills/moai-lang-sql/SKILL.md

@@ -0,0 +1,100 @@
+---
+
+name: moai-lang-sql
+description: SQL best practices with testing frameworks, query optimization, and migration management. Use when writing or reviewing SQL code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# SQL Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | SQL code discussions, framework guidance, or file extensions such as .sql. |
+| Tier | 3 |
+
+## What it does
+
+Provides SQL-specific expertise for database development, including SQL testing strategies, query optimization techniques, and migration management best practices.
+
+## When to use
+
+- Engages when the conversation references SQL work, frameworks, or files like .sql.
+- “Writing SQL tests”, “Query optimization”, “Migration management”
+- Automatically invoked when working with database projects
+- SQL SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**Testing Strategies**:
+- **pgTAP**: PostgreSQL testing framework
+- **DbUnit**: Database testing for JVM
+- **SQLTest**: SQL unit testing
+- Integration tests with test databases
+
+**Query Optimization**:
+- **EXPLAIN/EXPLAIN ANALYZE**: Execution plan analysis
+- **Index optimization**: B-tree, Hash, GiST indices
+- **Query rewriting**: JOIN optimization
+- **Avoiding N+1 queries**: Eager loading
+
+**Migration Management**:
+- **Flyway**: Version-based migrations
+- **Liquibase**: Changelog-based migrations
+- **Alembic**: Python database migrations
+- **Rails migrations**: Ruby on Rails approach
+
+**SQL Best Practices**:
+- **Normalization**: 3NF compliance
+- **Constraints**: Foreign keys, NOT NULL, CHECK
+- **Transactions**: ACID properties
+- **Prepared statements**: SQL injection prevention
+
+**Database Patterns**:
+- Use CTEs (Common Table Expressions) for readability
+- Window functions over self-joins
+- Avoid SELECT * in production code
+- Use parameterized queries
+
+## Examples
+```bash
+sqlfluff lint sql/ && sqlfluff fix sql/
+```
+
+## Inputs
+- Language-specific source directories (e.g. `src/`, `app/`).
+- Language-specific build/test configuration files (e.g. `package.json`, `pyproject.toml`, `go.mod`).
+- Relevant test suites and sample data.
+
+## Outputs
+- Test/lint execution plan tailored to the selected language.
+- List of key language idioms and review checkpoints.
+
+## Failure Modes
+- When the language runtime or package manager is not installed.
+- When the main language cannot be determined in a multilingual project.
+
+## Dependencies
+- Access to the project file is required using the Read/Grep tool.
+- When used with `Skill("moai-foundation-langs")`, it is easy to share cross-language conventions.
+
+## References
+- PostgreSQL Global Development Group. "PostgreSQL Documentation." https://www.postgresql.org/docs/ (accessed 2025-03-29).
+- SQLFluff. "SQLFluff Documentation." https://docs.sqlfluff.com/en/stable/ (accessed 2025-03-29).
+
+## Changelog
+- 2025-03-29: Input/output/failure response/reference information for each language has been specified.
+
+## Works well with
+
+- alfred-trust-validation (migration validation)
+- alfred-code-reviewer (SQL review)
+- database-expert (database design)
+
+## Best Practices
+- Enable automatic validation by matching your linter with the language's official style guide.
+- Fix test/build pipelines with reproducible commands in CI.

moai_adk/templates/.claude/skills/moai-lang-swift/SKILL.md

@@ -0,0 +1,99 @@
+---
+
+name: moai-lang-swift
+description: Swift best practices with XCTest, SwiftLint, and iOS/macOS development patterns. Use when writing or reviewing Swift code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Swift Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Swift code discussions, framework guidance, or file extensions such as .swift. |
+| Tier | 3 |
+
+## What it does
+
+Provides Swift-specific expertise for TDD development, including XCTest framework, SwiftLint linting, Swift Package Manager, and iOS/macOS platform patterns.
+
+## When to use
+
+- Engages when the conversation references Swift work, frameworks, or files like .swift.
+- “Writing Swift tests”, “How to use XCTest”, “iOS patterns”
+- Automatically invoked when working with Swift/iOS projects
+- Swift SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **XCTest**: Apple's native testing framework
+- **Quick/Nimble**: BDD-style testing (alternative)
+- **XCUITest**: UI testing for iOS/macOS apps
+- Test coverage with Xcode Code Coverage
+
+**Code Quality**:
+- **SwiftLint**: Swift linter and style checker
+- **SwiftFormat**: Code formatting tool
+- **Xcode Analyzer**: Static code analysis
+
+**Package Management**:
+- **Swift Package Manager (SPM)**: Dependency management
+- **CocoaPods**: Alternative package manager (legacy)
+- **Carthage**: Decentralized dependency manager
+
+**Swift Patterns**:
+- **Optionals**: Safe handling of nil values (?, !)
+- **Guard statements**: Early exit patterns
+- **Protocol-oriented programming**: Protocols over inheritance
+- **Value types**: Prefer structs over classes
+- **Closures**: First-class functions
+
+**iOS/macOS Patterns**:
+- **SwiftUI**: Declarative UI framework
+- **Combine**: Reactive programming
+- **UIKit/AppKit**: Traditional UI frameworks
+- **MVVM/MVC**: Architecture patterns
+
+## Examples
+```bash
+swift test && swift-format --lint --recursive Sources
+```
+
+## Inputs
+- Language-specific source directories (e.g. `src/`, `app/`).
+- Language-specific build/test configuration files (e.g. `package.json`, `pyproject.toml`, `go.mod`).
+- Relevant test suites and sample data.
+
+## Outputs
+- Test/lint execution plan tailored to the selected language.
+- List of key language idioms and review checkpoints.
+
+## Failure Modes
+- When the language runtime or package manager is not installed.
+- When the main language cannot be determined in a multilingual project.
+
+## Dependencies
+- Access to the project file is required using the Read/Grep tool.
+- When used with `Skill("moai-foundation-langs")`, it is easy to share cross-language conventions.
+
+## References
+- Apple. "Swift Programming Language Guide." https://docs.swift.org/swift-book/ (accessed 2025-03-29).
+- Apple. "Swift Package Manager." https://developer.apple.com/documentation/swift_packages (accessed 2025-03-29).
+
+## Changelog
+- 2025-03-29: Input/output/failure response/reference information for each language has been specified.
+
+## Works well with
+
+- alfred-trust-validation (coverage verification)
+- alfred-code-reviewer (Swift-specific review)
+- mobile-app-expert (iOS app development)
+
+## Best Practices
+- Enable automatic validation by matching your linter with the language's official style guide.
+- Fix test/build pipelines with reproducible commands in CI.

moai_adk/templates/.claude/skills/moai-lang-typescript/SKILL.md

@@ -0,0 +1,96 @@
+---
+
+name: moai-lang-typescript
+description: TypeScript best practices with Vitest, Biome, strict typing, and npm/pnpm package management. Use when writing or reviewing TypeScript code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# TypeScript Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | TypeScript code discussions, framework guidance, or file extensions such as .ts/.tsx. |
+| Tier | 3 |
+
+## What it does
+
+Provides TypeScript-specific expertise for TDD development, including Vitest testing, Biome linting/formatting, strict type checking, and modern npm/pnpm package management.
+
+## When to use
+
+- Engages when the conversation references TypeScript work, frameworks, or files like .ts/.tsx.
+- "Writing TypeScript tests", "How to use Vitest", "Type safety"
+- Automatically invoked when working with TypeScript projects
+- TypeScript SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **Vitest**: Fast unit testing (Jest-compatible API)
+- **@testing-library**: Component testing for React/Vue
+- Test coverage ≥85% with c8/istanbul
+
+**Type Safety**:
+- **strict: true** in tsconfig.json
+- **noImplicitAny**, **strictNullChecks**, **strictFunctionTypes**
+- Interface definitions, Generics, Type guards
+
+**Code Quality**:
+- **Biome**: Fast linter + formatter (replaces ESLint + Prettier)
+- Type-safe configurations
+- Import organization, unused variable detection
+
+**Package Management**:
+- **pnpm**: Fast, disk-efficient package manager (preferred)
+- **npm**: Fallback option
+- `package.json` + `tsconfig.json` configuration
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Prefer interfaces over types for public APIs
+- Use const assertions for literal types
+- Avoid `any`, prefer `unknown` or proper types
+
+## Examples
+```bash
+npm run lint && npm test
+```
+
+## Inputs
+- Language-specific source directories (e.g. `src/`, `app/`).
+- Language-specific build/test configuration files (e.g. `package.json`, `pyproject.toml`, `go.mod`).
+- Relevant test suites and sample data.
+
+## Outputs
+- Test/lint execution plan tailored to the selected language.
+- List of key language idioms and review checkpoints.
+
+## Failure Modes
+- When the language runtime or package manager is not installed.
+- When the main language cannot be determined in a multilingual project.
+
+## Dependencies
+- Access to the project file is required using the Read/Grep tool.
+- When used with `Skill("moai-foundation-langs")`, it is easy to share cross-language conventions.
+
+## References
+- Microsoft. "TypeScript Handbook." https://www.typescriptlang.org/docs/ (accessed 2025-03-29).
+- OpenJS Foundation. "ESLint User Guide." https://eslint.org/docs/latest/ (accessed 2025-03-29).
+
+## Changelog
+- 2025-03-29: Input/output/failure response/reference information for each language has been specified.
+
+## Works well with
+
+- alfred-trust-validation (coverage verification)
+- alfred-code-reviewer (TypeScript-specific review)
+- alfred-refactoring-coach (type-safe refactoring)
+
+## Best Practices
+- Enable automatic validation by matching your linter with the language's official style guide.
+- Fix test/build pipelines with reproducible commands in CI.