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

moai_adk/templates/.claude/skills/moai-foundation-langs/SKILL.md

@@ -0,0 +1,94 @@
+---
+
+name: moai-foundation-langs
+description: Auto-detects project language and framework (package.json, pyproject.toml, etc). Use when referencing multi-language conventions.
+allowed-tools:
+  - Read
+  - Bash
+  - Write
+  - Edit
+  - TodoWrite
+---
+
+# Alfred Language Detection
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Write (write_file), Edit (edit_file), Bash (terminal), TodoWrite (todo_write) |
+| Auto-load | SessionStart (foundation bootstrap) |
+| Trigger cues | Project language detection, toolchain hints, multi-language repository setup questions. |
+
+## What it does
+
+Automatically detects project's primary language and framework by scanning configuration files, then recommends appropriate testing tools and linters.
+
+## When to use
+
+- Activates when the conversation needs to detect project languages or recommend toolchains.
+- "Detect language", "Check project language", "Recommend testing tools"
+- Automatically invoked by `/alfred:0-project`, `/alfred:2-run`
+- Setting up new project
+
+## How it works
+
+**Configuration File Scanning**:
+- `package.json` → TypeScript/JavaScript (Jest/Vitest, ESLint/Biome)
+- `pyproject.toml` → Python (pytest, ruff, black)
+- `Cargo.toml` → Rust (cargo test, clippy, rustfmt)
+- `go.mod` → Go (go test, golint, gofmt)
+- `Gemfile` → Ruby (RSpec, RuboCop)
+- `pubspec.yaml` → Dart/Flutter (flutter test, dart analyze)
+- `build.gradle` → Java/Kotlin (JUnit, Checkstyle)
+- `Package.swift` → Swift (XCTest, SwiftLint)
+
+**Toolchain Recommendation**:
+```json
+{
+  "language": "Python",
+  "test_framework": "pytest",
+  "linter": "ruff",
+  "formatter": "black",
+  "type_checker": "mypy",
+  "package_manager": "uv"
+}
+```
+
+**Framework Detection**:
+- **Python**: FastAPI, Django, Flask
+- **TypeScript**: React, Next.js, Vue
+- **Java**: Spring Boot, Quarkus
+
+**Supported Languages**: Python, TypeScript, Java, Go, Rust, Ruby, Dart, Swift, Kotlin, PHP, C#, C++, Elixir, Scala, Clojure (20+ languages)
+
+## Examples
+```markdown
+- Scan standard documents and report missing sections.
+- Changed regulations are reflected in CLAUDE.md.
+```
+
+## Best Practices
+- When changing standards, the reason for change and supporting documents are recorded.
+- Follow the single source principle and avoid modifying the same item in multiple places.
+
+## Inputs
+- Project standard documents (e.g. `CLAUDE.md`, `.moai/config.json`).
+- Latest printouts from relevant sub-agents.
+
+## Outputs
+- Templates or policy summaries conforming to the MoAI-ADK standard.
+- Reusable rules/checklists.
+
+## Failure Modes
+- When required standard files are missing or have limited access rights.
+- When conflicting policies are detected and coordination is required.
+
+## Dependencies
+- There is great synergy when called together with cc-manager.
+
+## References
+- JetBrains. "Multi-language project organization." https://www.jetbrains.com/help/idea/project-tool-window.html (accessed 2025-03-29).
+- Stack Overflow. "Multi-language repository patterns." https://stackoverflow.blog/2020/04/20/the-developer's-guide-to-multi-language-repos/ (accessed 2025-03-29).
+
+## Changelog
+- 2025-03-29: Foundation skill templates have been enhanced to align with best practice structures.

moai_adk/templates/.claude/skills/moai-foundation-specs/SKILL.md

@@ -0,0 +1,93 @@
+---
+
+name: moai-foundation-specs
+description: Validates SPEC YAML frontmatter (7 required fields) and HISTORY section. Use when enforcing SPEC documentation standards.
+allowed-tools:
+  - Read
+  - Bash
+  - Write
+  - Edit
+  - TodoWrite
+---
+
+# Alfred SPEC Metadata Validation
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Write (write_file), Edit (edit_file), Bash (terminal), TodoWrite (todo_write) |
+| Auto-load | SessionStart (foundation bootstrap) |
+| Trigger cues | SPEC metadata validation, frontmatter completeness, specification readiness checks. |
+
+## What it does
+
+Validates SPEC document structure including YAML frontmatter (7 required fields) and HISTORY section compliance.
+
+## When to use
+
+- Activates when verifying SPEC frontmatter or preparing new specification templates.
+- "SPEC verification", "Metadata check", "SPEC structure check"
+- Automatically invoked by `/alfred:1-plan`
+- Before creating SPEC document
+
+## How it works
+
+**YAML Frontmatter Validation (7 required fields)**:
+- `id`: SPEC ID (e.g., AUTH-001)
+- `version`: Semantic Version (e.g., 0.0.1)
+- `status`: draft|active|completed|deprecated
+- `created`: YYYY-MM-DD format
+- `updated`: YYYY-MM-DD format
+- `author`: @{GitHub ID} format
+- `priority`: low|medium|high|critical
+
+**HISTORY Section Validation**:
+- Checks existence of HISTORY section
+- Verifies version history (INITIAL/ADDED/CHANGED/FIXED tags)
+- Validates author and date consistency
+
+**Format Validation**:
+```bash
+# Check required fields
+rg "^(id|version|status|created|updated|author|priority):" .moai/specs/SPEC-*/spec.md
+
+# Verify HISTORY section
+rg "^## HISTORY" .moai/specs/SPEC-*/spec.md
+```
+
+## Examples
+```markdown
+- Scan standard documents and report missing sections.
+- Changed regulations are reflected in CLAUDE.md.
+```
+
+## Inputs
+- Project standard documents (e.g. `CLAUDE.md`, `.moai/config.json`).
+- Latest printouts from relevant sub-agents.
+
+## Outputs
+- Templates or policy summaries conforming to the MoAI-ADK standard.
+- Reusable rules/checklists.
+
+## Failure Modes
+- When required standard files are missing or have limited access rights.
+- When conflicting policies are detected and coordination is required.
+
+## Dependencies
+- There is great synergy when called together with cc-manager.
+
+## References
+- INCOSE. "Guide for Writing Requirements." INCOSE-TP-2010-006-02 (accessed 2025-03-29).
+- IEEE. "Software Requirements Specification Standard." IEEE 830-1998.
+
+## Changelog
+- 2025-03-29: Foundation skill templates have been enhanced to align with best practice structures.
+
+## Works well with
+
+- moai-foundation-ears
+- moai-foundation-tags
+
+## Best Practices
+- When changing standards, the reason for change and supporting documents are recorded.
+- Follow the single source principle and avoid modifying the same item in multiple places.

moai_adk/templates/.claude/skills/moai-foundation-tags/SKILL.md

@@ -0,0 +1,86 @@
+---
+
+name: moai-foundation-tags
+description: Scans @TAG markers directly from code and generates inventory (CODE-FIRST). Use when establishing or auditing TAG conventions.
+allowed-tools:
+  - Read
+  - Bash
+  - Write
+  - Edit
+  - TodoWrite
+---
+
+# Alfred TAG Scanning
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Write (write_file), Edit (edit_file), Bash (terminal), TodoWrite (todo_write) |
+| Auto-load | SessionStart (foundation bootstrap) |
+| Trigger cues | TAG scanning, traceability audits, orphan TAG remediation requests. |
+
+## What it does
+
+Scans all @TAG markers (SPEC/TEST/CODE/DOC) directly from codebase and generates TAG inventory without intermediate caching (CODE-FIRST principle).
+
+## When to use
+
+- Activates when scanning or auditing TAG chains or locating orphaned tags.
+- "TAG Scan", "TAG List", "TAG Inventory"
+- Automatically invoked by `/alfred:3-sync`
+- “Find orphan TAG”, “Check TAG chain”
+
+## How it works
+
+**CODE-FIRST Scanning**:
+```bash
+# Direct code scan without intermediate cache
+rg '@(SPEC|TEST|CODE|DOC):' -n .moai/specs/ tests/ src/ docs/
+```
+
+**TAG Inventory Generation**:
+- Lists all TAGs with file locations
+- Detects orphaned TAGs (no corresponding SPEC/TEST/CODE)
+- Identifies broken links in TAG chain
+- Reports duplicate IDs
+
+**TAG Chain Verification**:
+- @SPEC → @TEST → @CODE → @DOC connection check
+- Ensures traceability across all artifacts
+
+## Examples
+```markdown
+- Scan standard documents and report missing sections.
+- Changed regulations are reflected in CLAUDE.md.
+```
+
+## Inputs
+- Project standard documents (e.g. `CLAUDE.md`, `.moai/config.json`).
+- Latest printouts from relevant sub-agents.
+
+## Outputs
+- Templates or policy summaries conforming to the MoAI-ADK standard.
+- Reusable rules/checklists.
+
+## Failure Modes
+- When required standard files are missing or have limited access rights.
+- When conflicting policies are detected and coordination is required.
+
+## Dependencies
+- There is great synergy when called together with cc-manager.
+
+## References
+- BurntSushi. "ripgrep User Guide." https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md (accessed 2025-03-29).
+- ReqView. "Requirements Traceability Matrix Guide." https://www.reqview.com/doc/requirements-traceability-matrix/ (accessed 2025-03-29).
+
+## Changelog
+- 2025-03-29: Foundation skill templates have been enhanced to align with best practice structures.
+
+## Works well with
+
+- moai-foundation-trust
+- moai-foundation-specs
+
+## Best Practices
+- When changing standards, the reason for change and supporting documents are recorded.
+- Follow the single source principle and avoid modifying the same item in multiple places.

moai_adk/templates/.claude/skills/moai-foundation-trust/SKILL.md

@@ -0,0 +1,86 @@
+---
+
+name: moai-foundation-trust
+description: Validates TRUST 5-principles (Test 85%+, Readable, Unified, Secured, Trackable). Use when aligning with TRUST governance.
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - TodoWrite
+---
+
+# Foundation: TRUST Validation
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Write (write_file), Edit (edit_file), Bash (terminal), TodoWrite (todo_write) |
+| Auto-load | SessionStart (foundation bootstrap) |
+| Trigger cues | TRUST compliance checks, release readiness reviews, quality gate enforcement. |
+
+## What it does
+
+Validates MoAI-ADK's TRUST 5-principles compliance to ensure code quality, testability, security, and traceability.
+
+## When to use
+
+- Activates when TRUST compliance or release readiness needs to be evaluated.
+- "Check the TRUST principle", "Quality verification", "Check code quality"
+- Automatically invoked by `/alfred:3-sync`
+- Before merging PR or releasing
+
+## How it works
+
+**T - Test First**:
+- Checks test coverage ≥85% (pytest, vitest, go test, cargo test, etc.)
+- Verifies TDD cycle compliance (RED → GREEN → REFACTOR)
+
+**R - Readable**:
+- File ≤300 LOC, Function ≤50 LOC, Parameters ≤5, Complexity ≤10
+
+**U - Unified**:
+- SPEC-driven architecture consistency, Clear module boundaries
+
+**S - Secured**:
+- Input validation, No hardcoded secrets, Access control
+
+**T - Trackable**:
+- TAG chain integrity (@SPEC → @TEST → @CODE → @DOC)
+
+## Inputs
+- Project standard documents (e.g. `CLAUDE.md`, `.moai/config.json`).
+- Latest printouts from relevant sub-agents.
+
+## Outputs
+- Templates or policy summaries conforming to the MoAI-ADK standard.
+- Reusable rules/checklists.
+
+## Failure Modes
+- When required standard files are missing or have limited access rights.
+- When conflicting policies are detected and coordination is required.
+
+## Dependencies
+- There is great synergy when called together with cc-manager.
+
+## References
+- SonarSource. "Quality Gate: Developer's Guide." https://www.sonarsource.com/company/newsroom/white-papers/quality-gate/ (accessed 2025-03-29).
+- ISO/IEC 25010. "Systems and software quality models." (accessed 2025-03-29).
+
+## Changelog
+- 2025-03-29: Foundation skill templates have been enhanced to align with best practice structures.
+
+## Works well with
+
+- moai-foundation-tags (TAG traceability)
+- moai-foundation-specs (SPEC validation)
+
+## Examples
+```markdown
+- Scan standard documents and report missing sections.
+- Changed regulations are reflected in CLAUDE.md.
+```
+
+## Best Practices
+- When changing standards, the reason for change and supporting documents are recorded.
+- Follow the single source principle and avoid modifying the same item in multiple places.

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

@@ -0,0 +1,100 @@
+---
+
+name: moai-lang-c
+description: C best practices with Unity test framework, cppcheck, and Make build system. 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 .c/.h. |
+| Tier | 3 |
+
+## What it does
+
+Provides C-specific expertise for TDD development, including Unity test framework, cppcheck static analysis, and Make build system for system programming.
+
+## When to use
+
+- Engages when the conversation references C work, frameworks, or files like .c/.h.
+- "Writing C tests", "Unity test framework", "Embedded C"
+- Automatically invoked when working with C projects
+- C SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **Unity**: Lightweight C test framework
+- **CMock**: Mocking framework for C
+- **Ceedling**: Build automation for C
+- Test coverage with gcov
+
+**Build Tools**:
+- **Make**: Standard build automation
+- **CMake**: Modern build system
+- **GCC/Clang**: C compilers
+
+**Code Quality**:
+- **cppcheck**: Static code analysis
+- **Valgrind**: Memory leak detection
+- **splint**: Secure programming lint
+
+**C Patterns**:
+- **Opaque pointers**: Information hiding
+- **Function pointers**: Callback mechanisms
+- **Error codes**: Integer return values
+- **Manual memory management**: malloc/free discipline
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Always check malloc return values
+- Free every malloc
+- Avoid buffer overflows (use strncpy, snprintf)
+- Use const for read-only parameters
+- Initialize all variables
+
+## Examples
+```bash
+make test && cppcheck 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
+- ISO. "ISO/IEC 9899:2018 Programming Languages — C." (accessed 2025-03-29).
+- Cppcheck. "Cppcheck Manual." http://cppcheck.sourceforge.net/manual.pdf (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)
+- alfred-debugger-pro (C 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-clojure/SKILL.md

@@ -0,0 +1,100 @@
+---
+
+name: moai-lang-clojure
+description: Clojure best practices with clojure.test, Leiningen, and immutable data structures. Use when writing or reviewing Clojure code in project workflows.
+allowed-tools:
+  - Read
+  - Bash
+---
+
+# Clojure Expert
+
+## Skill Metadata
+| Field | Value |
+| ----- | ----- |
+| Allowed tools | Read (read_file), Bash (terminal) |
+| Auto-load | On demand when language keywords are detected |
+| Trigger cues | Clojure code discussions, framework guidance, or file extensions such as .clj/.cljc. |
+| Tier | 3 |
+
+## What it does
+
+Provides Clojure-specific expertise for TDD development, including clojure.test framework, Leiningen build tool, and immutable data structures with functional programming.
+
+## When to use
+
+- Engages when the conversation references Clojure work, frameworks, or files like .clj/.cljc.
+- "Writing Clojure tests", "How to use clojure.test", "Immutable data structures"
+- Automatically invoked when working with Clojure projects
+- Clojure SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **clojure.test**: Built-in testing library
+- **midje**: BDD-style testing
+- **test.check**: Property-based testing
+- Test coverage with cloverage
+
+**Build Tools**:
+- **Leiningen**: Project automation, dependency management
+- **deps.edn**: Official dependency tool
+- **Boot**: Alternative build tool
+
+**Code Quality**:
+- **clj-kondo**: Linter for Clojure
+- **cljfmt**: Code formatting
+- **eastwood**: Additional linting
+
+**Clojure Patterns**:
+- **Immutable data structures**: Persistent collections
+- **Pure functions**: Functional core, imperative shell
+- **Threading macros**: -> and ->> for readability
+- **Lazy sequences**: Infinite data processing
+- **Transducers**: Composable transformations
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- Prefer let bindings over def
+- Use namespaces for organization
+- Destructuring for data access
+- Avoid mutable state
+
+## Examples
+```bash
+lein test && clj-kondo --lint 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
+- Clojure.org. "Clojure Documentation." https://clojure.org/guides/getting_started (accessed 2025-03-29).
+- clj-kondo. "User Guide." https://github.com/clj-kondo/clj-kondo/blob/master/doc/usage.md (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 (Clojure-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-cpp/SKILL.md

@@ -0,0 +1,102 @@
+---
+
+name: moai-lang-cpp
+description: C++ best practices with Google Test, clang-format, and modern C++ (C++17/20). 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 .cpp/.hpp. |
+| Tier | 3 |
+
+## What it does
+
+Provides C++-specific expertise for TDD development, including Google Test framework, clang-format formatting, and modern C++ (C++17/20) features.
+
+## When to use
+
+- Engages when the conversation references C++ work, frameworks, or files like .cpp/.hpp.
+- "Writing C++ tests", "How to use Google Test", "Modern C++"
+- Automatically invoked when working with C++ projects
+- C++ SPEC implementation (`/alfred:2-run`)
+
+## How it works
+
+**TDD Framework**:
+- **Google Test (gtest)**: Unit testing framework
+- **Google Mock (gmock)**: Mocking framework
+- **Catch2**: Alternative testing framework
+- Test coverage with gcov/lcov
+
+**Build Tools**:
+- **CMake**: Cross-platform build system
+- **Make**: Traditional build tool
+- **Conan/vcpkg**: Package managers
+
+**Code Quality**:
+- **clang-format**: Code formatting
+- **clang-tidy**: Static analysis
+- **cppcheck**: Additional static analysis
+
+**Modern C++ Features**:
+- **Smart pointers**: unique_ptr, shared_ptr, weak_ptr
+- **Move semantics**: std::move, rvalue references
+- **Lambda expressions**: Inline functions
+- **auto keyword**: Type inference
+- **constexpr**: Compile-time evaluation
+- **std::optional**: Nullable types (C++17)
+- **Concepts**: Type constraints (C++20)
+
+**Best Practices**:
+- File ≤300 LOC, function ≤50 LOC
+- RAII (Resource Acquisition Is Initialization)
+- Rule of Five (destructor, copy/move constructors/assignments)
+- Prefer stack allocation over heap
+- Const correctness
+
+## Examples
+```bash
+cmake --build build --target test && clang-tidy src/*.cpp
+```
+
+## 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
+- ISO. "ISO/IEC 14882:2020(E) Programming Language C++." (accessed 2025-03-29).
+- LLVM Project. "clang-tidy Documentation." https://clang.llvm.org/extra/clang-tidy/ (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)
+- alfred-performance-optimizer (C++ 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.