ma-agents 3.4.7 → 3.4.8

package/.roo/skills/auto-bug-detection/SKILL.md

@@ -1,169 +0,0 @@
----
-name: auto-bug-detection
-description: Instructs agents to identify and report defects in already-delivered code
----
-# Auto Bug Detection
-
-Proactively identify and report defects found in already-delivered code during all agent sessions.
-
-## Purpose
-
-When you encounter code that has already been delivered (story/task marked done), you must scan for defects
-and report them using the structured format below. Do not silently ignore bugs in delivered code.
-
-## Detection Scope
-
-### Delivered Code (MUST scan and report bugs)
-
-- Code whose associated story/task is marked **done** or **completed**, regardless of branch.
-- Committed code on `main` or release branches.
-- Committed code on feature branches whose **parent story is completed**.
-
-### Work-in-Progress (DO NOT flag as bugs)
-
-- Uncommitted changes in the working tree.
-- Committed code on a branch whose associated story is still **in-progress** or **not-started**.
-- `TODO` / `FIXME` markers in code added as part of the **current story under review**.
-- Incomplete implementations explicitly tied to an active story.
-
-### Ambiguous Boundary — Feature Branches
-
-Committed code on a feature branch where the story status is **unknown** must be treated as WIP.
-
-To resolve the status, use the `story-status-lookup` skill — it defines how to identify the story slug,
-which file to read, and how to map status values to delivered vs WIP. Follow its fallback rule:
-when status cannot be determined, **default to WIP and do NOT flag as a bug**.
-
----
-
-## Detection Criteria
-
-Scan delivered code for the following categories of defects. Each category includes examples of what qualifies.
-
-### 1. Logic Errors
-
-Incorrect computational logic, wrong conditionals, or inverted boolean expressions that cause the code
-to produce incorrect results.
-
-**Examples:**
-- Using `>` instead of `>=` in a boundary check, silently excluding a valid edge value.
-- An accumulator initialized to `1` instead of `0`, skewing totals.
-- A loop that iterates one too many or one too few times (off-by-one error).
-
-### 2. Unhandled Edge Cases
-
-Inputs or states that the code does not handle, leading to incorrect behavior or crashes.
-
-**Examples:**
-- A function that accepts a list but does not handle an empty list, throwing an index error.
-- A parser that crashes on a valid but empty string input.
-- Division without a zero-check on the divisor.
-
-### 3. Missing Error Handling
-
-Absence of error handling for operations that can fail, causing unhandled exceptions or silent failures.
-
-**Examples:**
-- File I/O calls with no try/catch, crashing the process on a missing file.
-- Network requests with no timeout or error callback.
-- A database query whose rejection is swallowed without logging or recovery.
-
-### 4. Broken Contracts
-
-Code that violates the API contract it published: wrong return types, missing required fields in
-responses, or side effects not documented in the interface.
-
-**Examples:**
-- A function documented to return `string | null` but sometimes returns `undefined`.
-- A REST endpoint returning HTTP 200 for a failed operation instead of the correct 4xx/5xx code.
-- A class method mutating shared state that is not documented as a side effect.
-
-### 5. Regressions
-
-Previously working behavior that is now broken, typically introduced by a change in a related component.
-
-**Examples:**
-- A utility function refactored to accept a new parameter that broke all existing callers that pass no argument.
-- A config key renamed in one place but not updated in all consumers, causing silent runtime failures.
-- A test that was green before a dependency upgrade and now fails due to an incompatible API change.
-
-### 6. Security Vulnerabilities
-
-Code patterns that introduce exploitable security weaknesses in existing, delivered functionality.
-
-**Examples:**
-- User-supplied input passed directly into a shell command without sanitization (command injection).
-- Secrets or API keys hard-coded in source files committed to the repository.
-- SQL queries constructed via string concatenation with unsanitized user input (SQL injection).
-- Sensitive data (passwords, tokens) logged at INFO level in production code.
-
----
-
-## Reporting Format
-
-When a defect is detected in delivered code, report it using this structured template:
-
-```
-## Bug Report
-
-**Title:** [Short, descriptive title]
-**Severity:** [critical | high | medium | low]
-**Category:** [logic-error | unhandled-edge-case | missing-error-handling | broken-contract | regression | security-vulnerability]
-**Affected Component:** [Module, file, or system area]
-
-**Reproduction Steps:**
-1. [Step 1]
-2. [Step 2]
-
-**Expected Behavior:**
-[What should happen]
-
-**Actual Behavior:**
-[What actually happens]
-
-**Affected Files:**
-- path/to/file.ext (line N)
-```
-
-**Severity Guidelines:**
-- `critical` — Data loss, security breach, or system crash in normal usage.
-- `high` — Core feature broken or serious security risk; blocks users.
-- `medium` — Feature partially broken or degraded; workaround exists.
-- `low` — Minor issue, cosmetic defect, or edge case with minimal user impact.
-
----
-
-## What NOT to Flag
-
-Do **not** report the following as bugs:
-
-- **Work-in-progress code** — Uncommitted changes or code on a branch with an active story.
-- **TODO / FIXME comments** in code added as part of the **current story** being reviewed.
-- **Incomplete implementations** explicitly tied to an active or not-yet-started story.
-- **Style preferences** — Naming conventions, formatting, or architectural opinions not related to correctness.
-- **Speculative issues** — Theoretical attack scenarios or failure modes with no demonstrable code path in the current codebase (e.g., an attack vector that requires filesystem access the process can never obtain).
-
----
-
-## Required Action on Detection
-
-The required action depends on severity:
-
-### critical or high severity
-
-**Immediately run `/create-bug-story`** without waiting for user confirmation. These defects represent
-broken core functionality or security risks that must not be left untracked. Inform the user as you act:
-
-> "I found a **[severity]** bug in delivered code — running `create-bug-story` now to ensure it is tracked."
-
-Do not ask permission. Do not proceed with other tasks until the bug story is created.
-
-### medium or low severity
-
-**Recommend** that the user create a formal bug story, but do not act without their confirmation:
-
-> "I found a **[severity]** bug in delivered code. Would you like me to run `create-bug-story` to log it
-> formally so it can be scheduled in the sprint?"
-
-If the user declines or does not respond, note the finding in your response and continue. The bug report
-remains visible in the conversation but is not written to a file.

package/.roo/skills/cmake-best-practices/SKILL.md

@@ -1,64 +0,0 @@
----
-name: Modern CMake Best Practices
-description: Enforce target-based, property-oriented CMake patterns (CMake 3.0+).
----
-# Modern CMake Best Practices (Target-Based Approach)
-
-This skill ensures that CMake definitions follow the "Modern CMake" philosophy (3.0+), focusing on targets and properties rather than global variables.
-
-## Policies
-
-### 1. Target-Centric Philosophy
-*   **Rule**: Treat targets as objects. Use `target_*` commands instead of global commands.
-*   **Action**: 
-    - **Forbidden**: `include_directories()`, `link_libraries()`, `add_definitions()`.
-    - **Mandatory**: `target_include_directories()`, `target_link_libraries()`, `target_compile_definitions()`.
-*   **Rationale**: Encapsulates requirements and prevents property leakage to unrelated targets.
-
-### 2. Visibility Hygiene (`PUBLIC`, `PRIVATE`, `INTERFACE`)
-*   **Rule**: Always specify the scope of target properties.
-*   **Action**:
-    - `PRIVATE`: Requirement only for building the target.
-    - `INTERFACE`: Requirement only for consumers of the target.
-    - `PUBLIC`: Requirement for both.
-*   **Rationale**: Ensures that internal dependencies (like a private logging library) don't bleed into the usage requirements of your high-level API.
-
-### 3. Feature-Based C++ Standards
-*   **Rule**: Do not manually set `CMAKE_CXX_STANDARD` or `-std=c++XX` flags.
-*   **Action**: Use `target_compile_features(my_target PUBLIC cxx_std_17)`.
-*   **Rationale**: Allows CMake to handle compiler-specific flags and ensures the compiler actually supports the requested features.
-
-### 4. No Global Variable Manipulation
-*   **Rule**: Ban direct modification of `CMAKE_CXX_FLAGS` or `CMAKE_EXE_LINKER_FLAGS`.
-*   **Action**: Use `target_compile_options()` for specific compiler warnings or flags.
-*   **Rationale**: Global flags make it impossible to have different settings for different targets in the same project.
-
-### 5. Namespaced Alias Targets
-*   **Rule**: Always provide an alias for library targets using a namespace.
-*   **Action**: `add_library(MyLib::MyLib ALIAS my_lib_target)`.
-*   **Rationale**: Makes exported targets look consistent with external dependencies (like those found via `find_package`).
-
-## Examples
-
-### Before (Legacy Procedural CMake)
-```cmake
-include_directories(${PROJECT_SOURCE_DIR}/include)
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17 -Wall")
-add_library(mylib mylib.cpp)
-```
-
-### After (Modern Target-Based CMake)
-```cmake
-add_library(mylib mylib.cpp)
-
-target_compile_features(mylib PUBLIC cxx_std_17)
-target_compile_options(mylib PRIVATE -Wall)
-
-target_include_directories(mylib 
-    PUBLIC 
-        $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
-        $<INSTALL_INTERFACE:include>
-)
-
-add_library(MyProject::MyLib ALIAS mylib)
-```

package/.roo/skills/cmake-best-practices/examples/cmake.md

@@ -1,59 +0,0 @@
-# Modern CMake Examples
-
-### 1. Project Structure and App
-```cmake
-cmake_minimum_required(VERSION 3.14)
-project(MyAwesomeApp VERSION 1.0 LANGUAGES CXX)
-
-# Use target_compile_features for the whole project standard if needed
-# but target-specific is better.
-add_executable(app main.cpp)
-
-target_compile_features(app PRIVATE cxx_std_17)
-target_link_libraries(app PRIVATE MyProject::Core)
-```
-
-### 2. Library with Internal/External Dependencies
-```cmake
-add_library(core src/core.cpp)
-
-# Internal include dir
-target_include_directories(core 
-    PUBLIC  include
-    PRIVATE src
-)
-
-# Link against a 3rd party library found via find_package
-find_package(fmt REQUIRED)
-target_link_libraries(core 
-    PUBLIC  fmt::fmt
-    PRIVATE Threads::Threads
-)
-
-add_library(MyProject::Core ALIAS core)
-```
-
-### 3. Proper Header-Only Library
-```cmake
-add_library(utils INTERFACE)
-
-target_include_directories(utils 
-    INTERFACE 
-        $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
-        $<INSTALL_INTERFACE:include>
-)
-
-# Requirement: anyone using utils MUST have C++14
-target_compile_features(utils INTERFACE cxx_std_14)
-
-add_library(MyProject::Utils ALIAS utils)
-```
-
-### 4. Compiler-Specific Options Safely
-```cmake
-if(MSVC)
-    target_compile_options(core PRIVATE /W4 /WX)
-else()
-    target_compile_options(core PRIVATE -Wall -Wextra -Werror)
-endif()
-```

package/.roo/skills/code-documentation/SKILL.md

@@ -1,57 +0,0 @@
----
-name: Code Documentation Best Practices
-description: Standardize file headers and method documentation across C++, C#, JS, TS, and Python.
----
-# Code Documentation Best Practices
-
-This skill enforces high-quality, standardized documentation for source code files and methods. It ensures consistent metadata and clear explanations of intent across different programming languages.
-
-## Policies
-
-### 1. Mandatory File Headers
-*   **Rule**: Every source file must begin with a standardized header block.
-*   **Contents**:
-    - **Purpose**: A brief description of what the file contains/solves.
-    - **Author/Project**: Project name or author information.
-    - **Metadata**: Date created/modified and version if applicable.
-
-### 2. Mandatory Method Documentation
-*   **Rule**: Every public or non-trivial internal function/method must have a documentation block immediately preceding it.
-*   **Standards**:
-    - **C++**: Use Doxygen style (`/** ... */`).
-    - **C#**: Use XML Documentation style (`/// <summary> ...`).
-    - **JS/TS**: Use JSDoc style (`/** ... */`).
-    - **Python**: Use PEP 257 Docstrings (`""" ... """`).
-*   **Required Fields**:
-    - **Summary**: Concise description of what the method does.
-    - **Parameters**: Name and purpose of each argument.
-    - **Return Value**: Description of the output.
-    - **Exceptions/Errors**: Document significant error states or exceptions thrown.
-
-### 3. Focus on "Why" and "What"
-*   **Rule**: Do not document trivial code (e.g., `i++ // increment i`).
-*   **Action**: Document the **intent** and **usage constraints**. If the code is complex, explain the high-level logic rather than line-by-line mechanics.
-
-### 4. Semantic Linking
-*   **Rule**: Use language-specific linking features (e.g., `@see`, `{@link}`, `<see cref=.../>`) to refer to related types or methods.
-
-## Language Specifics
-
-| Language | Format | Key Tags |
-| :--- | :--- | :--- |
-| **C++** | Doxygen | `\brief`, `\param`, `\return`, `\throw` |
-| **C#** | XML Doc | `<summary>`, `<param>`, `<returns>`, `<exception>` |
-| **JS/TS** | JSDoc | `@description`, `@param`, `@returns`, `@throws` |
-| **Python** | Docstrings | `Args:`, `Returns:`, `Raises:` (Google/NumPy style) |
-
----
-
-## Example (Generic Pattern)
-
-```text
-[File Header]
-[Imports]
-
-[Component Documentation]
-[Implementation]
-```

package/.roo/skills/code-documentation/examples/cpp.md

@@ -1,29 +0,0 @@
-# C++ Documentation (Doxygen Style)
-
-### File Header
-```cpp
-/**
- * @file DataProcessor.hpp
- * @brief Handles high-performance transformation of raw sensor data.
- * @author Antigravity / ma-agents
- * @date 2026-02-22
- * @version 1.0.0
- */
-```
-
-### Method Documentation
-```cpp
-/**
- * @brief Calculates the moving average of a dataset.
- * 
- * This method uses a sliding window algorithm to smooth out volatility 
- * in sensor inputs.
- * 
- * @param data A span of float values to process.
- * @param windowSize The size of the averaging window (must be > 0).
- * @return The calculated moving average as a float.
- * @throw std::invalid_argument If data is empty or windowSize is invalid.
- * @see SignalFilter
- */
-float calculateMovingAverage(gsl::span<const float> data, size_t windowSize);
-```

package/.roo/skills/code-documentation/examples/csharp.md

@@ -1,28 +0,0 @@
-# C# Documentation (XML Style)
-
-### File Header
-```csharp
-/*
- * File: AuthenticationService.cs
- * Purpose: Manages user login, token validation, and multi-factor authentication.
- * Author: Antigravity / ma-agents
- * Date: 2026-02-22
- */
-```
-
-### Method Documentation
-```csharp
-/// <summary>
-/// Validates a user's credentials against the secure identity store.
-/// </summary>
-/// <param name="username">The unique identifier for the user.</param>
-/// <param name="password">The plain-text password (will be hashed internally).</param>
-/// <returns>
-/// An <see cref="AuthResult"/> indicating success or failure with a details message.
-/// </returns>
-/// <exception cref="SecurityException">Thrown if the account is locked.</exception>
-public async Task<AuthResult> LoginAsync(string username, string password)
-{
-    // ...
-}
-```

package/.roo/skills/code-documentation/examples/javascript_typescript.md

@@ -1,28 +0,0 @@
-# JavaScript & TypeScript Documentation (JSDoc Style)
-
-### File Header
-```typescript
-/**
- * @file api-client.ts
- * @description Centralized HTTP client with automatic retry and error handling.
- * @author Antigravity / ma-agents
- * @version 1.2.0
- */
-```
-
-### Method Documentation
-```typescript
-/**
- * Fetches data from a specific endpoint with optional caching.
- * 
- * @template T The expected type of the response data.
- * @param {string} url The target URL (must be absolute).
- * @param {RequestOptions} [options] Optional configuration for headers and timeouts.
- * @returns {Promise<T>} A promise that resolves to the parsed JSON response.
- * @throws {NetworkError} If the server is unreachable.
- * @throws {ValidationError} If the response schema does not match T.
- */
-async function fetchData<T>(url: string, options?: RequestOptions): Promise<T> {
-  // ...
-}
-```

package/.roo/skills/code-documentation/examples/python.md

@@ -1,57 +0,0 @@
-# Python Documentation (Google/NumPy Style)
-
-### File Header
-Every module should start with a docstring that provides a high-level overview.
-
-```python
-"""
-data_processor.py
-~~~~~~~~~~~~~~~~~
-Handles high-performance transformation of raw sensor data using NumPy.
-
-:copyright: (c) 2026 by Antigravity.
-:license: MIT, see LICENSE for more details.
-"""
-```
-
-### Method Documentation
-Preferred style is Google or NumPy style for readability and integration with tools like Sphinx.
-
-```python
-def calculate_moving_average(data, window_size):
-    """Calculates the moving average of a dataset.
-
-    This method uses a sliding window algorithm to smooth out volatility 
-    in sensor inputs.
-
-    Args:
-        data (list[float]): A list or array of float values to process.
-        window_size (int): The size of the averaging window (must be > 0).
-
-    Returns:
-        float: The calculated moving average.
-
-    Raises:
-        ValueError: If data is empty or window_size is invalid.
-
-    Note:
-        This implementation assumes data is already cleaned.
-    """
-    if not data or window_size <= 0:
-        raise ValueError("Invalid data or window_size")
-    # ... implementation
-```
-
-### Class Documentation
-```python
-class SignalFilter:
-    """A collection of signal processing utilities.
-    
-    Attributes:
-        sampling_rate (int): The frequency at which signals are sampled.
-    """
-    
-    def __init__(self, sampling_rate):
-        """Initializes the SignalFilter with a specific sampling rate."""
-        self.sampling_rate = sampling_rate
-```

package/.roo/skills/code-review/SKILL.md

@@ -1,43 +0,0 @@
----
-name: Code Review
-description: Performs comprehensive code reviews with best practices
----
-# Code Review
-
-Perform comprehensive code reviews following industry best practices.
-
-## What to Review
-
-1. **Code Quality**: Readability, naming conventions, structure
-2. **Best Practices**: Language-specific patterns, error handling, performance
-3. **Security**: Common vulnerabilities (SQL injection, XSS, CSRF, etc.)
-4. **Testing**: Coverage, edge cases, test quality
-5. **Documentation**: Comments, API docs, clarity
-
-## Review Process
-
-- Analyze code for bugs and logical errors
-- Check adherence to coding standards
-- Identify security vulnerabilities
-- Suggest refactoring opportunities
-- Assess test coverage and documentation
-
-## Output Format
-
-```
-## Code Review Summary
-
-### Strengths
-- [Positive aspects]
-
-### Issues Found
-- **[High/Medium/Low]** [Issue description]
-  - Location: [file:line]
-  - Fix: [recommendation]
-
-### Suggestions
-- [Improvements]
-
-### Overall Assessment
-[Summary and rating]
-```

package/.roo/skills/commit-message/SKILL.md

@@ -1,79 +0,0 @@
----
-name: Commit Message Generator
-description: Generates conventional commit messages from code changes
----
-# Commit Message Generator
-
-Generate meaningful commit messages following Conventional Commits specification.
-
-## Format
-
-```
-<type>(<scope>): <subject>
-
-<body>
-
-<footer>
-```
-
-## Types
-
-- `feat`: New feature
-- `fix`: Bug fix
-- `docs`: Documentation changes
-- `style`: Code style/formatting
-- `refactor`: Code refactoring
-- `test`: Adding/updating tests
-- `chore`: Maintenance tasks
-- `perf`: Performance improvements
-- `ci`: CI/CD changes
-- `build`: Build system changes
-- `revert`: Revert previous commit
-
-## Guidelines
-
-1. **Subject line** (max 50 chars):
-   - Use imperative mood ("Add" not "Added")
-   - Don't capitalize first letter
-   - No period at the end
-
-2. **Body** (optional):
-   - Explain what and why, not how
-   - Wrap at 72 characters
-
-3. **Footer** (optional):
-   - Breaking changes: `BREAKING CHANGE: description`
-   - Issue references: `Fixes #123`
-
-## Examples
-
-```
-feat(auth): add JWT token refresh mechanism
-
-Implement automatic token refresh to improve user experience
-and reduce re-authentication prompts.
-
-Fixes #456
-```
-
-```
-fix(api): resolve memory leak in user service
-
-The user cache was not being cleared properly, causing
-memory to grow over time.
-```
-
-```
-docs: update installation instructions
-
-Add steps for Windows users and clarify dependency requirements.
-```
-
-## Process
-
-1. Analyze the code changes
-2. Determine the type of change
-3. Identify the scope (component/module affected)
-4. Write clear, concise subject
-5. Add body if changes need explanation
-6. Add footer for breaking changes or issue refs