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

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

@@ -0,0 +1,98 @@
+---
+
+name: moai-lang-julia
+description: Julia best practices with Test stdlib, Pkg manager, and scientific computing patterns. Use when writing or reviewing Julia code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Julia Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Julia code discussions, framework guidance, or file extensions such as .jl. |
+| Tier | 3 |
+
+## What it does
+
+Provides Julia-specific expertise for TDD development, including Test standard library, Pkg package manager, and high-performance scientific computing patterns.
+
+## When to use
+
+- Engages when the conversation references Julia work, frameworks, or files like .jl.
+- "Writing Julia tests", "How to use Test stdlib", "Scientific computing"
+- Automatically invoked when working with Julia projects
+- Julia SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **Test**: Built-in testing library (@test, @testset)
+- **Coverage.jl**: Test coverage analysis
+- **BenchmarkTools.jl**: Performance benchmarking
+
+**Package Management**:
+- **Pkg**: Built-in package manager
+- **Project.toml**: Package configuration
+- **Manifest.toml**: Dependency lock file
+
+**Code Quality**:
+- **JuliaFormatter.jl**: Code formatting
+- **Lint.jl**: Static analysis
+- **JET.jl**: Type inference analysis
+
+**Scientific Computing**:
+- **Multiple dispatch**: Method specialization on argument types
+- **Type stability**: Performance optimization
+- **Broadcasting**: Element-wise operations (. syntax)
+- **Linear algebra**: Built-in BLAS/LAPACK
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Type annotations for performance-critical code
+- Prefer abstract types for function arguments
+- Use @inbounds for performance (after bounds checking)
+- Profile before optimizing
+
+## Examples
+```bash
+julia --project -e 'using Pkg; Pkg.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
+- Julia Language. "Documentation." https://docs.julialang.org/en/v1/ (accessed 2025-03-29).
+- JuliaFormatter.jl. "JuliaFormatter Documentation." https://domluna.github.io/JuliaFormatter.jl/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 (coverage verification)
+- alfred-code-reviewer (Julia-specific review)
+- alfred-performance-optimizer (Julia profiling)
+
+## 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-kotlin/SKILL.md

@@ -0,0 +1,99 @@
+---
+
+name: moai-lang-kotlin
+description: Kotlin best practices with JUnit, Gradle, ktlint, coroutines, and extension functions. Use when writing or reviewing Kotlin code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Kotlin Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Kotlin code discussions, framework guidance, or file extensions such as .kt/.kts. |
+| Tier | 3 |
+
+## What it does
+
+Provides Kotlin-specific expertise for TDD development, including JUnit testing, Gradle build system, ktlint linting, coroutines for concurrency, and extension functions.
+
+## When to use
+
+- Engages when the conversation references Kotlin work, frameworks, or files like .kt/.kts.
+- “Writing Kotlin tests”, “How to use coroutines”, “Android patterns”
+- Automatically invoked when working with Kotlin/Android projects
+- Kotlin SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **JUnit 5**: Unit testing with Kotlin extensions
+- **MockK**: Kotlin-friendly mocking library
+- **Kotest**: Kotlin-native testing framework
+- Test coverage ≥85% with JaCoCo
+
+**Build Tools**:
+- **Gradle**: build.gradle.kts with Kotlin DSL
+- **Maven**: pom.xml alternative
+- Multi-platform support (JVM, Native, JS)
+
+**Code Quality**:
+- **ktlint**: Kotlin linter with formatting
+- **detekt**: Static code analysis
+- **Android Lint**: Android-specific checks
+
+**Kotlin Features**:
+- **Coroutines**: Async programming with suspend functions
+- **Extension functions**: Add methods to existing classes
+- **Data classes**: Automatic equals/hashCode/toString
+- **Null safety**: Non-nullable types by default
+- **Smart casts**: Automatic type casting after checks
+
+**Android Patterns**:
+- **Jetpack Compose**: Declarative UI
+- **ViewModel**: UI state management
+- **Room**: Database abstraction
+- **Retrofit**: Network requests
+
+## Examples
+```bash
+./gradlew test && ./gradlew ktlintCheck
+```
+
+## 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
+- JetBrains. "Kotlin Language Documentation." https://kotlinlang.org/docs/home.html (accessed 2025-03-29).
+- Pinterest. "ktlint." https://pinterest.github.io/ktlint/ (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 (Kotlin-specific review)
+- mobile-app-expert (Android 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-lua/SKILL.md

@@ -0,0 +1,98 @@
+---
+
+name: moai-lang-lua
+description: Lua best practices with busted, luacheck, and embedded scripting patterns. Use when writing or reviewing Lua code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Lua Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Lua code discussions, framework guidance, or file extensions such as .lua. |
+| Tier | 3 |
+
+## What it does
+
+Provides Lua-specific expertise for TDD development, including busted testing framework, luacheck linting, and embedded scripting patterns for game development and system configuration.
+
+## When to use
+
+- Engages when the conversation references Lua work, frameworks, or files like .lua.
+- "Writing Lua tests", "How to use busted", "Embedded scripting"
+- Automatically invoked when working with Lua projects
+- Lua SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **busted**: Elegant Lua testing framework
+- **luassert**: Assertion library
+- **lua-coveralls**: Coverage reporting
+- BDD-style test writing
+
+**Code Quality**:
+- **luacheck**: Lua linter and static analyzer
+- **StyLua**: Code formatting
+- **luadoc**: Documentation generation
+
+**Package Management**:
+- **LuaRocks**: Package manager
+- **rockspec**: Package specification
+
+**Lua Patterns**:
+- **Tables**: Versatile data structure
+- **Metatables**: Operator overloading
+- **Closures**: Function factories
+- **Coroutines**: Cooperative multitasking
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Use `local` for all variables
+- Prefer tables over multiple return values
+- Document public APIs
+- Avoid global variables
+
+## Examples
+```bash
+luacheck src && busted
+```
+
+## 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
+- Lua.org. "Programming in Lua." https://www.lua.org/pil/contents.html (accessed 2025-03-29).
+- Olivine Labs. "busted." https://olivinelabs.com/busted/ (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 (Lua-specific review)
+- cli-tool-expert (Lua scripting utilities)
+
+## 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-php/SKILL.md

@@ -0,0 +1,98 @@
+---
+
+name: moai-lang-php
+description: PHP best practices with PHPUnit, Composer, and PSR standards. Use when writing or reviewing PHP code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# PHP Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | PHP code discussions, framework guidance, or file extensions such as .php. |
+| Tier | 3 |
+
+## What it does
+
+Provides PHP-specific expertise for TDD development, including PHPUnit testing, Composer package management, and PSR (PHP Standards Recommendations) compliance.
+
+## When to use
+
+- Engages when the conversation references PHP work, frameworks, or files like .php.
+- "Writing PHP tests", "How to use PHPUnit", "PSR standard"
+- Automatically invoked when working with PHP projects
+- PHP SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **PHPUnit**: PHP testing framework
+- **Mockery**: Mocking library
+- **PHPSpec**: BDD-style testing (alternative)
+- Test coverage with `phpunit --coverage-html`
+
+**Code Quality**:
+- **PHP_CodeSniffer**: PSR compliance checker
+- **PHPStan**: Static analysis tool
+- **PHP CS Fixer**: Code formatting
+
+**Package Management**:
+- **Composer**: Dependency management
+- **composer.json**: Package configuration
+- **Packagist**: Public package registry
+
+**PSR Standards**:
+- **PSR-1**: Basic coding standard
+- **PSR-2/PSR-12**: Coding style guide
+- **PSR-4**: Autoloading standard
+- **PSR-7**: HTTP message interfaces
+
+**Best Practices**:
+- File ≤300 LOC, method ≤50 LOC
+- Type declarations (PHP 7.4+)
+- Namespaces for organization
+- Dependency injection over global state
+
+## Examples
+```bash
+vendor/bin/phpunit && vendor/bin/phpstan analyse
+```
+
+## 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
+- PHP Manual. "PHP Documentation." https://www.php.net/manual/en/ (accessed 2025-03-29).
+- PHPUnit. "PHPUnit Manual." https://phpunit.de/documentation.html (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 (PHP-specific review)
+- web-api-expert (Laravel/Symfony API 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-python/SKILL.md

@@ -0,0 +1,96 @@
+---
+
+name: moai-lang-python
+description: Python best practices with pytest, mypy, ruff, black, and uv package management. Use when writing or reviewing Python code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Python Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Python code discussions, framework guidance, or file extensions such as .py. |
+| Tier | 3 |
+
+## What it does
+
+Provides Python-specific expertise for TDD development, including pytest testing, mypy type checking, ruff linting, black formatting, and modern uv package management.
+
+## When to use
+
+- Engages when the conversation references Python work, frameworks, or files like .py.
+- “Writing Python tests”, “How to use pytest”, “Python type hints”
+- Automatically invoked when working with Python projects
+- Python SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **pytest**: Test discovery, fixtures, parametrize, markers
+- **coverage.py**: Test coverage ≥85% enforcement
+- **pytest-mock**: Mocking and patching
+
+**Type Safety**:
+- **mypy**: Static type checking with strict mode
+- Type hints for function signatures, return types
+- Generic types, Protocols, TypedDict
+
+**Code Quality**:
+- **ruff**: Fast Python linter (replaces flake8, isort, pylint)
+- **black**: Opinionated code formatter
+- Complexity checks (≤10), line length (≤88)
+
+**Package Management**:
+- **uv**: Modern, fast package installer
+- `pyproject.toml` for project configuration
+- Virtual environment management
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Meaningful variable names (no single letters except loops)
+- Guard clauses over nested conditions
+- Docstrings for public APIs
+
+## Examples
+```bash
+python -m pytest && ruff check . && black --check .
+```
+
+## 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
+- Python Software Foundation. "Python Developer's Guide." https://docs.python.org/3/ (accessed 2025-03-29).
+- Pytest. "pytest Documentation." https://docs.pytest.org/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 (coverage verification)
+- alfred-code-reviewer (Python-specific review)
+- alfred-debugger-pro (Python debugging)
+
+## 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-r/SKILL.md

@@ -0,0 +1,99 @@
+---
+
+name: moai-lang-r
+description: R best practices with testthat, lintr, and data analysis patterns. Use when writing or reviewing R code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# R Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | R code discussions, framework guidance, or file extensions such as .r. |
+| Tier | 3 |
+
+## What it does
+
+Provides R-specific expertise for TDD development, including testthat testing framework, lintr code linting, and statistical data analysis patterns.
+
+## When to use
+
+- Engages when the conversation references R work, frameworks, or files like .r.
+- “Writing R tests”, “How to use testthat”, “Data analysis patterns”
+- Automatically invoked when working with R projects
+- R SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **testthat**: Unit testing framework
+- **covr**: Test coverage tool
+- **mockery**: Mocking library
+- Test coverage ≥85% enforcement
+
+**Code Quality**:
+- **lintr**: Static code analysis
+- **styler**: Code formatting
+- **goodpractice**: R package best practices
+
+**Package Management**:
+- **devtools**: Package development tools
+- **usethis**: Workflow automation
+- **CRAN**: Official package repository
+
+**Data Analysis Patterns**:
+- **tidyverse**: Data manipulation (dplyr, ggplot2)
+- **data.table**: High-performance data manipulation
+- **Vectorization** over loops
+- **Pipes** (%>%) for readable code
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Document functions with roxygen2
+- Use meaningful variable names
+- Avoid global variables
+- Prefer functional programming
+
+## Examples
+```bash
+Rscript -e 'devtools::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
+- R Core Team. "R Language Definition." https://cran.r-project.org/manuals.html (accessed 2025-03-29).
+- RStudio. "testthat Reference." https://testthat.r-lib.org/ (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 (R-specific review)
+- data-science-expert (statistical analysis)
+
+## 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-ruby/SKILL.md

@@ -0,0 +1,99 @@
+---
+
+name: moai-lang-ruby
+description: Ruby best practices with RSpec, RuboCop, Bundler, and Rails patterns. Use when writing or reviewing Ruby code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Ruby Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Ruby code discussions, framework guidance, or file extensions such as .rb. |
+| Tier | 3 |
+
+## What it does
+
+Provides Ruby-specific expertise for TDD development, including RSpec BDD testing, RuboCop linting, Bundler package management, and Rails framework patterns.
+
+## When to use
+
+- Engages when the conversation references Ruby work, frameworks, or files like .rb.
+- “Writing Ruby tests”, “How to use RSpec”, “Rails patterns”
+- Automatically invoked when working with Ruby/Rails projects
+- Ruby SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **RSpec**: Behavior-driven development (describe, context, it)
+- **FactoryBot**: Test data factories
+- **Capybara**: Integration testing for web apps
+- Test coverage ≥85% with SimpleCov
+
+**Code Quality**:
+- **RuboCop**: Ruby linter and formatter
+- **Reek**: Code smell detection
+- **Brakeman**: Security vulnerability scanner (Rails)
+
+**Package Management**:
+- **Bundler**: Dependency management with Gemfile
+- **RubyGems**: Package distribution
+- Semantic versioning in gemspec
+
+**Rails Patterns**:
+- MVC architecture (Model-View-Controller)
+- ActiveRecord for database interactions
+- RESTful routing conventions
+- Service objects for business logic
+- Strong parameters for security
+
+**Best Practices**:
+- File ≤300 LOC, method ≤50 LOC
+- Prefer symbols over strings for hash keys
+- Use blocks and yielding for abstraction
+- Duck typing over explicit type checking
+
+## Examples
+```bash
+bundle exec rubocop && bundle exec rspec
+```
+
+## 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
+- Ruby Lang. "Ruby Programming Language." https://www.ruby-lang.org/en/documentation/ (accessed 2025-03-29).
+- RuboCop. "RuboCop Documentation." https://docs.rubocop.org/rubocop/ (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 (Ruby-specific review)
+- web-api-expert (Rails API 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.