moai-adk 0.4.4__py3-none-any.whl → 0.4.7__py3-none-any.whl

moai_adk/templates/.claude/skills/moai-essentials-review/SKILL.md

@@ -1,112 +1,113 @@
 ---
-
 name: moai-essentials-review
-description: Automated code review with SOLID principles, code smells, and language-specific best practices. Use when preparing concise review checklists for code changes.
+version: 2.0.0
+created: 2025-10-22
+updated: 2025-10-22
+status: active
+description: Automated code review with SOLID principles, code smells, and language-specific best practices.
+keywords: ['code-review', 'solid', 'best-practices', 'quality']
 allowed-tools:
   - Read
   - Bash
-  - Write
-  - Edit
-  - TodoWrite
 ---
 
-# Alfred Code Reviewer
+# Essentials Review Skill
 
 ## Skill Metadata
+
 | Field | Value |
 | ----- | ----- |
-| Allowed tools | Read (read_file), Write (write_file), Edit (edit_file), Bash (terminal), TodoWrite (todo_write) |
-| Auto-load | On demand during Sync stage (review gate) |
-| Trigger cues | Code review requests, quality checklist preparation, merge readiness checks. |
-
-## What it does
-
-Automated code review with language-specific best practices, SOLID principles verification, and code smell detection.
-
-## When to use
-
-- Loads when someone asks for a code review or a pre-merge quality assessment.
-- “Please review the code”, “How can this code be improved?”, “Check the code quality”
-- Optionally invoked after `/alfred:3-sync`
-- Before merging PR
-
-## How it works
-
-**Code Constraints Check**:
-- File ≤300 LOC
-- Function ≤50 LOC
-- Parameters ≤5
-- Cyclomatic complexity ≤10
-
-**SOLID Principles**:
-- Single Responsibility
-- Open/Closed
-- Liskov Substitution
-- Interface Segregation
-- Dependency Inversion
-
-**Code Smell Detection**:
-- Long Method
-- Large Class
-- Duplicate Code
-- Dead Code
-- Magic Numbers
-
-**Language-specific Best Practices**:
-- Python: List comprehension, type hints, PEP 8
-- TypeScript: Strict typing, async/await, error handling
-- Java: Streams API, Optional, Design patterns
-
-**Review Report**:
-```markdown
-## Code Review Report
-
-### 🔴 Critical Issues (3)
-1. **src/auth/service.py:45** - Function too long (85 > 50 LOC)
-2. **src/api/handler.ts:120** - Missing error handling
-3. **src/db/repository.java:200** - Magic number
-
-### ⚠️ Warnings (5)
-1. **src/utils/helper.py:30** - Unused import
-
-### ✅ Good Practices Found
-- Test coverage: 92%
-- Consistent naming
-```
-
-## Examples
-```markdown
-- Checks the current diff and lists items that can be modified immediately.
-- Schedule follow-up tasks with TodoWrite.
-```
+| **Skill Name** | moai-essentials-review |
+| **Version** | 2.0.0 (2025-10-22) |
+| **Allowed tools** | Read (read_file), Bash (terminal) |
+| **Auto-load** | On demand when keywords detected |
+| **Tier** | Essentials |
+
+---
+
+## What It Does
+
+Automated code review with SOLID principles, code smells, and language-specific best practices.
+
+**Key capabilities**:
+- ✅ Best practices enforcement for essentials domain
+- ✅ TRUST 5 principles integration
+- ✅ Latest tool versions (2025-10-22)
+- ✅ TDD workflow support
+
+---
+
+## When to Use
+
+**Automatic triggers**:
+- Related code discussions and file patterns
+- SPEC implementation (`/alfred:2-run`)
+- Code review requests
+
+**Manual invocation**:
+- Review code for TRUST 5 compliance
+- Design new features
+- Troubleshoot issues
+
+---
 
 ## Inputs
-- A snapshot of the code/tests/documentation you are currently working on.
-- Ongoing agent status information.
+
+- Language-specific source directories
+- Configuration files
+- Test suites and sample data
 
 ## Outputs
-- Immediately actionable checklists or improvement suggestions.
-- Recommendations on whether to take next steps or not.
+
+- Test/lint execution plan
+- TRUST 5 review checkpoints
+- Migration guidance
 
 ## Failure Modes
-- If you cannot find the required files or test results.
-- When the scope of work is excessively large and cannot be resolved with simple support.
+
+- When required tools are not installed
+- When dependencies are missing
+- When test coverage falls below 85%
 
 ## Dependencies
-- Mainly used in conjunction with `tdd-implementer`, `quality-gate`, etc.
 
-## References
-- IEEE. "Recommended Practice for Software Reviews." IEEE 1028-2008.
-- Cisco. "Peer Review Best Practices." https://www.cisco.com/c/en/us/support/docs/optical/ons-15454-esc/15114-peer-review.html (accessed 2025-03-29).
+- Access to project files via Read/Bash tools
+- Integration with `moai-foundation-langs` for language detection
+- Integration with `moai-foundation-trust` for quality gates
+
+---
+
+## References (Latest Documentation)
+
+_Documentation links updated 2025-10-22_
+
+---
 
 ## Changelog
-- 2025-03-29: Overhauled input/output definitions for Essentials skills.
 
-## Works well with
+- **v2.0.0** (2025-10-22): Major update with latest tool versions, comprehensive best practices, TRUST 5 integration
+- **v1.0.0** (2025-03-29): Initial Skill release
+
+---
+
+## Works Well With
 
-- moai-foundation-specs
-- moai-essentials-refactor
+- `moai-foundation-trust` (quality gates)
+- `moai-alfred-code-reviewer` (code review)
+- `moai-essentials-debug` (debugging support)
+
+---
 
 ## Best Practices
-- Record results, even for simple improvements, to increase traceability.
-- Clearly mark items that require human review to distinguish them from automation.
+
+✅ **DO**:
+- Follow essentials best practices
+- Use latest stable tool versions
+- Maintain test coverage ≥85%
+- Document all public APIs
+
+❌ **DON'T**:
+- Skip quality gates
+- Use deprecated tools
+- Ignore security warnings
+- Mix testing frameworks

moai_adk/templates/.claude/skills/moai-essentials-review/examples.md

@@ -0,0 +1,29 @@
+# moai-essentials-review - Working Examples
+
+_Last updated: 2025-10-22_
+
+## Example 1: Basic Setup
+
+```bash
+# Setup commands
+# ...
+```
+
+## Example 2: TDD Workflow
+
+```bash
+# RED: Write failing test
+# GREEN: Implement feature
+# REFACTOR: Improve code
+```
+
+## Example 3: Quality Gate
+
+```bash
+# Run quality checks
+# Verify coverage ≥85%
+```
+
+---
+
+_For more examples, see SKILL.md reference section_

moai_adk/templates/.claude/skills/moai-essentials-review/reference.md

@@ -0,0 +1,28 @@
+# moai-essentials-review - CLI Reference
+
+_Last updated: 2025-10-22_
+
+## Quick Reference
+
+### Installation
+
+```bash
+# Installation commands
+```
+
+### Common Commands
+
+```bash
+# Test
+# Lint
+# Format
+# Build
+```
+
+## Tool Versions (2025-10-22)
+
+_No specific tool versions (workflow/process Skill)_
+
+---
+
+_For detailed usage, see SKILL.md_

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

@@ -1,98 +1,113 @@
 ---
-
 name: moai-foundation-ears
-description: EARS requirement authoring guide (Ubiquitous/Event/State/Optional/Constraints). Use when teams need guidance on EARS requirements structure.
+version: 2.0.0
+created: 2025-10-22
+updated: 2025-10-22
+status: active
+description: EARS requirement authoring guide (Ubiquitous/Event/State/Optional/Constraints).
+keywords: ['ears', 'requirements', 'authoring', 'syntax']
 allowed-tools:
   - Read
   - Bash
-  - Write
-  - Edit
-  - TodoWrite
 ---
 
-# Alfred EARS Authoring Guide
+# Foundation Ears Skill
 
 ## 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 | Requests to draft or refine EARS-style requirements, “write spec”, or “requirements format” cues. |
+| **Skill Name** | moai-foundation-ears |
+| **Version** | 2.0.0 (2025-10-22) |
+| **Allowed tools** | Read (read_file), Bash (terminal) |
+| **Auto-load** | On demand when keywords detected |
+| **Tier** | Foundation |
 
-## What it does
+---
 
-EARS (Easy Approach to Requirements Syntax) authoring guide for writing clear, testable requirements using 5 statement patterns.
+## What It Does
 
-## When to use
+EARS requirement authoring guide (Ubiquitous/Event/State/Optional/Constraints).
 
-- Activates whenever the user asks to draft structured requirements or mentions EARS syntax.
-- “Writing SPEC”, “Requirements summary”, “EARS syntax”
-- Automatically invoked by `/alfred:1-plan`
-- When writing or refining SPEC documents
+**Key capabilities**:
+- ✅ Best practices enforcement for foundation domain
+- ✅ TRUST 5 principles integration
+- ✅ Latest tool versions (2025-10-22)
+- ✅ TDD workflow support
 
-## How it works
+---
 
-EARS provides 5 statement patterns for structured requirements:
+## When to Use
 
-### 1. Ubiquitous (Basic Requirements)
-**Format**: The system must provide [function]
-**Example**: The system must provide user authentication function
+**Automatic triggers**:
+- Related code discussions and file patterns
+- SPEC implementation (`/alfred:2-run`)
+- Code review requests
 
-### 2. Event-driven (event-based)
-**Format**: WHEN If [condition], the system must [operate]
-**Example**: WHEN When the user logs in, the system must issue a JWT token
+**Manual invocation**:
+- Review code for TRUST 5 compliance
+- Design new features
+- Troubleshoot issues
 
-### 3. State-driven
-**Format**: WHILE When in [state], the system must [operate]
-**Example**: WHILE When the user is authenticated, the system must allow access to protected resources
+---
 
-### 4. Optional (Optional function)
-**Format**: If WHERE [condition], the system can [operate]
-**Example**: If WHERE refresh token is provided, the system can issue a new access token
+## Inputs
 
-### 5. Constraints
-**Format**: IF [condition], the system SHOULD [constrain]
-**Example**: IF an invalid token is provided, the system SHOULD deny access
+- Language-specific source directories
+- Configuration files
+- Test suites and sample data
 
-## Writing Tips
+## Outputs
 
-✅ Be specific and measurable
-✅ Avoid vague terms (“adequate”, “sufficient”, “fast”)
-✅ One requirement per statement
-✅ Make it testable
+- Test/lint execution plan
+- TRUST 5 review checkpoints
+- Migration guidance
 
-## Examples
-```markdown
-- Scan standard documents and report missing sections.
-- Changed regulations are reflected in CLAUDE.md.
-```
+## Failure Modes
 
-## Inputs
-- Project standard documents (e.g. `CLAUDE.md`, `.moai/config.json`).
-- Latest printouts from relevant sub-agents.
+- When required tools are not installed
+- When dependencies are missing
+- When test coverage falls below 85%
 
-## Outputs
-- Templates or policy summaries conforming to the MoAI-ADK standard.
-- Reusable rules/checklists.
+## Dependencies
 
-## Failure Modes
-- When required standard files are missing or have limited access rights.
-- When conflicting policies are detected and coordination is required.
+- Access to project files via Read/Bash tools
+- Integration with `moai-foundation-langs` for language detection
+- Integration with `moai-foundation-trust` for quality gates
 
-## Dependencies
-- There is great synergy when called together with cc-manager.
+---
+
+## References (Latest Documentation)
 
-## References
-- Mavin, A., et al. "Easy Approach to Requirements Syntax (EARS)." IEEE RE, 2009.
-- INCOSE. "Guide for Writing Requirements." INCOSE-TP-2010-006-02 (accessed 2025-03-29).
+_Documentation links updated 2025-10-22_
+
+---
 
 ## Changelog
-- 2025-03-29: Foundation skill templates have been enhanced to align with best practice structures.
 
-## Works well with
+- **v2.0.0** (2025-10-22): Major update with latest tool versions, comprehensive best practices, TRUST 5 integration
+- **v1.0.0** (2025-03-29): Initial Skill release
 
-- moai-foundation-specs
+---
+
+## Works Well With
+
+- `moai-foundation-trust` (quality gates)
+- `moai-alfred-code-reviewer` (code review)
+- `moai-essentials-debug` (debugging support)
+
+---
 
 ## 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.
+
+✅ **DO**:
+- Follow foundation best practices
+- Use latest stable tool versions
+- Maintain test coverage ≥85%
+- Document all public APIs
+
+❌ **DON'T**:
+- Skip quality gates
+- Use deprecated tools
+- Ignore security warnings
+- Mix testing frameworks

moai_adk/templates/.claude/skills/moai-foundation-ears/examples.md

@@ -0,0 +1,29 @@
+# moai-foundation-ears - Working Examples
+
+_Last updated: 2025-10-22_
+
+## Example 1: Basic Setup
+
+```bash
+# Setup commands
+# ...
+```
+
+## Example 2: TDD Workflow
+
+```bash
+# RED: Write failing test
+# GREEN: Implement feature
+# REFACTOR: Improve code
+```
+
+## Example 3: Quality Gate
+
+```bash
+# Run quality checks
+# Verify coverage ≥85%
+```
+
+---
+
+_For more examples, see SKILL.md reference section_

moai_adk/templates/.claude/skills/moai-foundation-ears/reference.md

@@ -0,0 +1,28 @@
+# moai-foundation-ears - CLI Reference
+
+_Last updated: 2025-10-22_
+
+## Quick Reference
+
+### Installation
+
+```bash
+# Installation commands
+```
+
+### Common Commands
+
+```bash
+# Test
+# Lint
+# Format
+# Build
+```
+
+## Tool Versions (2025-10-22)
+
+_No specific tool versions (workflow/process Skill)_
+
+---
+
+_For detailed usage, see SKILL.md_

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

@@ -1,90 +1,122 @@
 ---
-
 name: moai-foundation-git
-description: Git workflow automation (branching, TDD commits, PR management). Use when standardizing Git practices across the project.
+version: 2.0.0
+created: 2025-10-22
+updated: 2025-10-22
+status: active
+description: GitFlow automation and PR policy enforcement for MoAI-ADK workflows.
+keywords: ['git', 'gitflow', 'pr', 'automation']
 allowed-tools:
   - Read
   - Bash
-  - Write
-  - Edit
-  - TodoWrite
 ---
 
-# Alfred Git Workflow
+# Foundation Git Skill
 
 ## 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 | Branch creation, commit convention, PR readiness, and release gating requests. |
+| **Skill Name** | moai-foundation-git |
+| **Version** | 2.0.0 (2025-10-22) |
+| **Allowed tools** | Read (read_file), Bash (terminal) |
+| **Auto-load** | On demand when keywords detected |
+| **Tier** | Foundation |
 
-## What it does
+---
 
-Automates Git operations following MoAI-ADK conventions: branch creation, locale-based TDD commits, Draft PR creation, and PR Ready transition.
+## What It Does
 
-## When to use
+GitFlow automation and PR policy enforcement for MoAI-ADK workflows.
 
-- Activates when Git workflow automation is needed for branching, commits, or PR promotion.
-- “Create branch”, “Create PR”, “Create commit”
-- Automatically invoked by `/alfred:1-plan`, `/alfred:2-run`, `/alfred:3-sync`
-- Git workflow automation needed
+**Key capabilities**:
+- ✅ Best practices enforcement for foundation domain
+- ✅ TRUST 5 principles integration
+- ✅ Latest tool versions (2025-10-22)
+- ✅ TDD workflow support
 
-## How it works
+---
 
-**1. Branch Creation**:
-```bash
-git checkout develop
-git checkout -b feature/SPEC-AUTH-001
-```
+## When to Use
 
-**2. Locale-based TDD Commits**:
-- **Korean (ko)**: 🔴 RED: [Test Description]
-- **English (en)**: 🔴 RED: [Test description]
-- **Japanese (ja)**: 🔴 RED: [テスト説明]
-- **Chinese (zh)**: 🔴 RED: [测试说明]
+**Automatic triggers**:
+- Related code discussions and file patterns
+- SPEC implementation (`/alfred:2-run`)
+- Code review requests
 
-Configured via `.moai/config.json`:
-```json
-{"project": {"locale": "ko"}}
-```
+**Manual invocation**:
+- Review code for TRUST 5 compliance
+- Design new features
+- Troubleshoot issues
 
-**3. Draft PR Creation**:
-Creates Draft PR with SPEC reference and test checklist.
+---
 
-**4. PR Ready Transition** (via `/alfred:3-sync`):
-- Updates PR from Draft → Ready
-- Adds quality gate checklist
-- Verifies TRUST 5-principles
+## Tool Version Matrix (2025-10-22)
 
-## Examples
-```markdown
-- Scan standard documents and report missing sections.
-- Changed regulations are reflected in CLAUDE.md.
-```
+| Tool | Version | Purpose | Status |
+|------|---------|---------|--------|
+| **Git** | 2.47.0 | Primary | ✅ Current |
+| **GitHub CLI** | 2.63.0 | Primary | ✅ Current |
 
-## 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.
+
+- Language-specific source directories
+- Configuration files
+- Test suites and sample data
 
 ## Outputs
-- Templates or policy summaries conforming to the MoAI-ADK standard.
-- Reusable rules/checklists.
+
+- Test/lint execution plan
+- TRUST 5 review checkpoints
+- Migration guidance
 
 ## Failure Modes
-- When required standard files are missing or have limited access rights.
-- When conflicting policies are detected and coordination is required.
+
+- When required tools are not installed
+- When dependencies are missing
+- When test coverage falls below 85%
 
 ## Dependencies
-- There is great synergy when called together with cc-manager.
 
-## References
-- Vincent Driessen. "A successful Git branching model." https://nvie.com/posts/a-successful-git-branching-model/ (accessed 2025-03-29).
-- GitHub Docs. "GitHub Flow." https://docs.github.com/en/get-started/using-github/github-flow (accessed 2025-03-29).
+- Access to project files via Read/Bash tools
+- Integration with `moai-foundation-langs` for language detection
+- Integration with `moai-foundation-trust` for quality gates
+
+---
+
+## References (Latest Documentation)
+
+_Documentation links updated 2025-10-22_
+
+---
 
 ## Changelog
-- 2025-03-29: Foundation skill templates have been enhanced to align with best practice structures.
+
+- **v2.0.0** (2025-10-22): Major update with latest tool versions, comprehensive best practices, TRUST 5 integration
+- **v1.0.0** (2025-03-29): Initial Skill release
+
+---
+
+## Works Well With
+
+- `moai-foundation-trust` (quality gates)
+- `moai-alfred-code-reviewer` (code review)
+- `moai-essentials-debug` (debugging support)
+
+---
+
+## Best Practices
+
+✅ **DO**:
+- Follow foundation best practices
+- Use latest stable tool versions
+- Maintain test coverage ≥85%
+- Document all public APIs
+
+❌ **DON'T**:
+- Skip quality gates
+- Use deprecated tools
+- Ignore security warnings
+- Mix testing frameworks