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

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

@@ -0,0 +1,100 @@
+---
+
+name: moai-lang-csharp
+description: C# best practices with xUnit, .NET tooling, LINQ, and async/await patterns. Use when writing or reviewing C# code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# C# Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | C# code discussions, framework guidance, or file extensions such as .cs. |
+| Tier | 3 |
+
+## What it does
+
+Provides C#-specific expertise for TDD development, including xUnit testing, .NET CLI tooling, LINQ query expressions, and async/await patterns.
+
+## When to use
+
+- Engages when the conversation references C# work, frameworks, or files like .cs.
+- "Writing C# tests", "How to use xUnit", "LINQ queries"
+- Automatically invoked when working with .NET projects
+- C# SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **xUnit**: Modern .NET testing framework
+- **Moq**: Mocking library for interfaces
+- **FluentAssertions**: Expressive assertions
+- Test coverage ≥85% with Coverlet
+
+**Build Tools**:
+- **.NET CLI**: dotnet build, test, run
+- **NuGet**: Package management
+- **MSBuild**: Build system
+
+**Code Quality**:
+- **StyleCop**: C# style checker
+- **SonarAnalyzer**: Static code analysis
+- **EditorConfig**: Code formatting rules
+
+**C# Patterns**:
+- **LINQ**: Query expressions for collections
+- **Async/await**: Asynchronous programming
+- **Properties**: Get/set accessors
+- **Extension methods**: Add methods to existing types
+- **Nullable reference types**: Null safety (C# 8+)
+
+**Best Practices**:
+- File ≤300 LOC, method ≤50 LOC
+- Use PascalCase for public members
+- Prefer `var` for local variables when type is obvious
+- Async methods should end with "Async" suffix
+- Use string interpolation ($"") over concatenation
+
+## Examples
+```bash
+dotnet test && dotnet format --verify-no-changes
+```
+
+## 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. "C# Programming Guide." https://learn.microsoft.com/dotnet/csharp/ (accessed 2025-03-29).
+- Microsoft. ".NET Testing with dotnet test." https://learn.microsoft.com/dotnet/core/testing/ (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 (C#-specific review)
+- web-api-expert (ASP.NET Core 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-dart/SKILL.md

@@ -0,0 +1,98 @@
+---
+
+name: moai-lang-dart
+description: Dart best practices with flutter test, dart analyze, and Flutter widget patterns. Use when writing or reviewing Dart/Flutter code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Dart Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Dart code discussions, framework guidance, or file extensions such as .dart. |
+| Tier | 3 |
+
+## What it does
+
+Provides Dart-specific expertise for TDD development, including flutter test framework, dart analyze linting, and Flutter widget patterns for cross-platform app development.
+
+## When to use
+
+- Engages when the conversation references Dart work, frameworks, or files like .dart.
+- “Writing Dart tests”, “Flutter widget patterns”, “How to use flutter tests”
+- Automatically invoked when working with Dart/Flutter projects
+- Dart SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **flutter test**: Built-in test framework
+- **mockito**: Mocking library for Dart
+- **Widget testing**: Test Flutter widgets
+- Test coverage with `flutter test --coverage`
+
+**Code Quality**:
+- **dart analyze**: Static analysis tool
+- **dart format**: Code formatting
+- **very_good_analysis**: Strict lint rules
+
+**Package Management**:
+- **pub**: Package manager (pub.dev)
+- **pubspec.yaml**: Dependency configuration
+- Flutter SDK version management
+
+**Flutter Patterns**:
+- **StatelessWidget/StatefulWidget**: UI components
+- **Provider/Riverpod**: State management
+- **BLoC**: Business logic separation
+- **Navigator**: Routing and navigation
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Prefer `const` constructors for immutable widgets
+- Use `final` for immutable fields
+- Widget composition over inheritance
+
+## Examples
+```bash
+dart test && dart analyze
+```
+
+## 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
+- Google. "Dart Language Tour." https://dart.dev/guides/language/language-tour (accessed 2025-03-29).
+- Flutter. "Testing." https://docs.flutter.dev/testing (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 (Dart-specific review)
+- mobile-app-expert (Flutter 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-elixir/SKILL.md

@@ -0,0 +1,99 @@
+---
+
+name: moai-lang-elixir
+description: Elixir best practices with ExUnit, Mix, and OTP patterns. Use when writing or reviewing Elixir code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Elixir Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Elixir code discussions, framework guidance, or file extensions such as .ex/.exs. |
+| Tier | 3 |
+
+## What it does
+
+Provides Elixir-specific expertise for TDD development, including ExUnit testing, Mix build tool, and OTP (Open Telecom Platform) patterns for concurrent systems.
+
+## When to use
+
+- Engages when the conversation references Elixir work, frameworks, or files like .ex/.exs.
+- "Writing Elixir tests", "How to use ExUnit", "OTP patterns"
+- Automatically invoked when working with Elixir/Phoenix projects
+- Elixir SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **ExUnit**: Built-in test framework
+- **Mox**: Mocking library
+- **StreamData**: Property-based testing
+- Test coverage with `mix test --cover`
+
+**Build Tools**:
+- **Mix**: Build tool and project manager
+- **mix.exs**: Project configuration
+- **Hex**: Package manager
+
+**Code Quality**:
+- **Credo**: Static code analysis
+- **Dialyzer**: Type checking
+- **mix format**: Code formatting
+
+**OTP Patterns**:
+- **GenServer**: Generic server behavior
+- **Supervisor**: Process supervision
+- **Application**: Application behavior
+- **Task**: Async/await operations
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Pattern matching over conditionals
+- Pipe operator (|>) for data transformations
+- Immutable data structures
+- "Let it crash" philosophy with supervisors
+
+## Examples
+```bash
+mix test && mix credo --strict
+```
+
+## 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
+- Elixir Lang. "Getting Started." https://elixir-lang.org/getting-started/introduction.html (accessed 2025-03-29).
+- Credo. "Credo — The Elixir Linter." https://hexdocs.pm/credo/ (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 (Elixir-specific review)
+- web-api-expert (Phoenix 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-go/SKILL.md

@@ -0,0 +1,100 @@
+---
+
+name: moai-lang-go
+description: Go best practices with go test, golint, gofmt, and standard library utilization. Use when writing or reviewing Go code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Go Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Go code discussions, framework guidance, or file extensions such as .go. |
+| Tier | 3 |
+
+## What it does
+
+Provides Go-specific expertise for TDD development, including go test framework, golint/staticcheck, gofmt formatting, and effective standard library usage.
+
+## When to use
+
+- Engages when the conversation references Go work, frameworks, or files like .go.
+- “Writing Go tests”, “How to use go tests”, “Go standard library”
+- Automatically invoked when working with Go projects
+- Go SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **go test**: Built-in testing framework
+- **Table-driven tests**: Structured test cases
+- **testify/assert**: Optional assertion library
+- Test coverage ≥85% with `go test -cover`
+
+**Code Quality**:
+- **gofmt**: Automatic code formatting
+- **golint**: Go linter (deprecated, use staticcheck)
+- **staticcheck**: Advanced static analysis
+- **go vet**: Built-in error detection
+
+**Standard Library**:
+- Use standard library first before external dependencies
+- **net/http**: HTTP server/client
+- **encoding/json**: JSON marshaling
+- **context**: Context propagation
+
+**Go Patterns**:
+- Interfaces for abstraction (small interfaces)
+- Error handling with explicit returns
+- Defer for cleanup
+- Goroutines and channels for concurrency
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Exported names start with capital letters
+- Error handling: `if err != nil { return err }`
+- Avoid naked returns in large functions
+
+## Examples
+```bash
+go test ./... && golangci-lint run
+```
+
+## 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
+- The Go Authors. "Effective Go." https://go.dev/doc/effective_go (accessed 2025-03-29).
+- GolangCI. "golangci-lint Documentation." https://golangci-lint.run/usage/quick-start/ (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 (Go-specific review)
+- alfred-performance-optimizer (Go 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-haskell/SKILL.md

@@ -0,0 +1,100 @@
+---
+
+name: moai-lang-haskell
+description: Haskell best practices with HUnit, Stack/Cabal, and pure functional programming. Use when writing or reviewing Haskell code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Haskell Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Haskell code discussions, framework guidance, or file extensions such as .hs. |
+| Tier | 3 |
+
+## What it does
+
+Provides Haskell-specific expertise for TDD development, including HUnit testing, Stack/Cabal build tools, and pure functional programming with strong type safety.
+
+## When to use
+
+- Engages when the conversation references Haskell work, frameworks, or files like .hs.
+- “Writing Haskell tests”, “How to use HUnit”, “Pure functional programming”
+- Automatically invoked when working with Haskell projects
+- Haskell SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **HUnit**: Unit testing framework
+- **QuickCheck**: Property-based testing
+- **Hspec**: BDD-style testing
+- Test coverage with hpc
+
+**Build Tools**:
+- **Stack**: Reproducible builds, dependency resolution
+- **Cabal**: Haskell package system
+- **hpack**: Alternative package description
+
+**Code Quality**:
+- **hlint**: Haskell linter
+- **stylish-haskell**: Code formatting
+- **GHC warnings**: Compiler-level checks
+
+**Functional Programming**:
+- **Pure functions**: No side effects
+- **Monads**: IO, Maybe, Either, State
+- **Functors/Applicatives**: Abstraction patterns
+- **Type classes**: Polymorphism
+- **Lazy evaluation**: Infinite data structures
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Prefer total functions (avoid partial)
+- Type-driven development
+- Point-free style (when readable)
+- Avoid do-notation overuse
+
+## Examples
+```bash
+cabal test && hlint src
+```
+
+## 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
+- Haskell.org. "Haskell Language Documentation." https://www.haskell.org/documentation/ (accessed 2025-03-29).
+- GitHub. "HLint." https://github.com/ndmitchell/hlint (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 (Haskell-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-java/SKILL.md

@@ -0,0 +1,98 @@
+---
+
+name: moai-lang-java
+description: Java best practices with JUnit, Maven/Gradle, Checkstyle, and Spring Boot patterns. Use when writing or reviewing Java code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Java Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Java code discussions, framework guidance, or file extensions such as .java. |
+| Tier | 3 |
+
+## What it does
+
+Provides Java-specific expertise for TDD development, including JUnit testing, Maven/Gradle build tools, Checkstyle linting, and Spring Boot patterns.
+
+## When to use
+
+- Engages when the conversation references Java work, frameworks, or files like .java.
+- “Writing Java tests”, “How to use JUnit”, “Spring Boot patterns”
+- Automatically invoked when working with Java projects
+- Java SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **JUnit 5**: Unit testing with annotations (@Test, @BeforeEach)
+- **Mockito**: Mocking framework for dependencies
+- **AssertJ**: Fluent assertion library
+- Test coverage ≥85% with JaCoCo
+
+**Build Tools**:
+- **Maven**: pom.xml, dependency management
+- **Gradle**: build.gradle, Kotlin DSL support
+- Multi-module project structures
+
+**Code Quality**:
+- **Checkstyle**: Java style checker (Google/Sun conventions)
+- **PMD**: Static code analysis
+- **SpotBugs**: Bug detection
+
+**Spring Boot Patterns**:
+- Dependency Injection (@Autowired, @Component)
+- REST controllers (@RestController, @RequestMapping)
+- Service layer separation (@Service, @Repository)
+- Configuration properties (@ConfigurationProperties)
+
+**Best Practices**:
+- File ≤300 LOC, method ≤50 LOC
+- Interfaces for abstraction
+- Builder pattern for complex objects
+- Exception handling with custom exceptions
+
+## Examples
+```bash
+./mvnw test && ./mvnw checkstyle: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
+- Oracle. "Java Language Specification." https://docs.oracle.com/javase/specs/ (accessed 2025-03-29).
+- JUnit. "JUnit 5 User Guide." https://junit.org/junit5/docs/current/user-guide/ (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 (Java-specific review)
+- database-expert (JPA/Hibernate patterns)
+
+## 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-javascript/SKILL.md

@@ -0,0 +1,96 @@
+---
+
+name: moai-lang-javascript
+description: JavaScript best practices with Jest, ESLint, Prettier, and npm package management. Use when writing or reviewing JavaScript code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# JavaScript Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | JavaScript code discussions, framework guidance, or file extensions such as .js. |
+| Tier | 3 |
+
+## What it does
+
+Provides JavaScript-specific expertise for TDD development, including Jest testing, ESLint linting, Prettier formatting, and npm package management.
+
+## When to use
+
+- Engages when the conversation references JavaScript work, frameworks, or files like .js.
+- "Writing JavaScript tests", "How to use Jest", "ES6+ grammar"
+- Automatically invoked when working with JavaScript projects
+- JavaScript SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **Jest**: Unit testing with mocking, snapshots
+- **@testing-library**: DOM/React testing
+- Test coverage ≥85% enforcement
+
+**Code Quality**:
+- **ESLint**: JavaScript linting with recommended rules
+- **Prettier**: Code formatting (opinionated)
+- **JSDoc**: Type hints via comments (for type safety)
+
+**Package Management**:
+- **npm**: Standard package manager
+- **package.json** for dependencies and scripts
+- Semantic versioning
+
+**Modern JavaScript**:
+- ES6+ features (arrow functions, destructuring, spread/rest)
+- Async/await over callbacks
+- Module imports (ESM) over CommonJS
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Prefer `const` over `let`, avoid `var`
+- Guard clauses for early returns
+- Meaningful names, avoid abbreviations
+
+## Examples
+```bash
+npm run test && npm run lint
+```
+
+## 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
+- MDN Web Docs. "JavaScript Guide." https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide (accessed 2025-03-29).
+- Jest. "Getting Started." https://jestjs.io/docs/getting-started (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 (JavaScript-specific review)
+- alfred-debugger-pro (JavaScript 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.