ma-agents 3.4.9 → 3.5.1

package/.roo/skills/MANIFEST.yaml

@@ -1,254 +0,0 @@
-# MANIFEST.yaml
-
-skills:
-  - id: ai-audit-trail
-    file: ai-audit-trail/SKILL.md
-    description: Tracks AI agent session activity, time spent, and token usage in a project-level AiAudit.md log file.
-    applies_when:
-      - starting a new agent task or workflow
-      - completing a document generation session
-      - finishing any multi-step agent workflow
-    always_load: true
-
-  - id: auto-bug-detection
-    file: auto-bug-detection/SKILL.md
-    description: Instructs agents to identify and report defects in already-delivered code
-
-  - id: cmake-best-practices
-    file: cmake-best-practices/SKILL.md
-    description: Enforce target-based, property-oriented CMake patterns (CMake 3.0+).
-    applies_when:
-      - creating or modifying CMakeLists.txt files
-      - managing C++ project dependencies via CMake
-      - defining C++ build configurations
-    always_load: true
-
-  - id: code-documentation
-    file: code-documentation/SKILL.md
-    description: Standardize file headers and method documentation across C++, C#, JS, TS, and Python.
-    applies_when:
-      - creating or modifying source code files
-      - defining new functions, methods, or classes
-      - refactoring code logic
-      - documenting APIs
-    always_load: true
-
-  - id: code-review
-    file: code-review/SKILL.md
-    description: Performs comprehensive code reviews with best practices
-
-  - id: commit-message
-    file: commit-message/SKILL.md
-    description: Generates conventional commit messages from code changes
-
-  - id: cpp-best-practices
-    file: cpp-best-practices/SKILL.md
-    description: Comprehensive C++ coding standards covering naming conventions, modern C++ idioms (C++17/20/23), error handling, and build guidelines. Cross-references domain-specific C++ skills for deep-dives.
-    applies_when:
-      - writing c++ code
-      - modifying c++ code
-      - creating new c++ files or classes
-      - reviewing c++ code style or conventions
-      - refactoring c++ code
-      - setting up a c++ project
-    always_load: true
-
-  - id: cpp-concurrency-safety
-    file: cpp-concurrency-safety/SKILL.md
-    description: Enforce safe multi-threading patterns using RAII locking and task-based parallelism (C++14+).
-    applies_when:
-      - working with C++ threads
-      - using C++ mutexes or locking primitives
-      - performing C++ asynchronous operations
-      - designing multi-threaded C++ systems
-
-  - id: cpp-const-correctness
-    file: cpp-const-correctness/SKILL.md
-    description: Enforce immutability-by-default and push logic to compile-time using constexpr (C++14+).
-    applies_when:
-      - declaring C++ variables
-      - defining C++ member functions
-      - performing C++ compile-time calculations
-      - optimizing C++ logic
-
-  - id: cpp-memory-handling
-    file: cpp-memory-handling/SKILL.md
-    description: Enforces Modern C++ practices (RAII, Smart Pointers) to prevent memory leaks, dangling pointers, and buffer overflows.
-    applies_when:
-      - writing c++ code
-      - modifying memory-intensive C++ logic
-      - debugging memory leaks in c++
-      - implementing new c++ classes
-
-  - id: cpp-modern-composition
-    file: cpp-modern-composition/SKILL.md
-    description: Replace legacy C patterns with STL, Ranges, and modern C++ abstractions (C++14+).
-    applies_when:
-      - writing C++ logic or algorithms
-      - performing C++ refactoring
-      - handling C++ data transformations
-      - working with C++ collections
-    always_load: true
-
-  - id: cpp-robust-interfaces
-    file: cpp-robust-interfaces/SKILL.md
-    description: Enforce contract-based design and strong typing in C++ interfaces (C++14+).
-    applies_when:
-      - creating or modifying C++ header files
-      - designing C++ function signatures
-      - defining C++ APIs or public interfaces
-
-  - id: create-hardened-docker-skill
-    file: create-hardened-docker-skill/SKILL.md
-    description: Creates production-ready hardened Docker configurations following CIS, OWASP, and NIST standards
-
-  - id: csharp-best-practices
-    file: csharp-best-practices/SKILL.md
-    description: Comprehensive C# coding standards covering modern C# (C# 10-12), async/await, LINQ, dependency injection basics, nullable reference types, and testing conventions.
-    applies_when:
-      - writing c# code
-      - creating new c# files or classes
-      - reviewing c# code style or conventions
-      - working with .net projects
-      - setting up a c# project
-    always_load: true
-
-  - id: docker-hardening-verification
-    file: docker-hardening-verification/SKILL.md
-    description: Audits Docker images for security best practices, least privilege, and OpenShift compliance.
-
-  - id: docker-image-signing
-    file: docker-image-signing/SKILL.md
-    description: Automates the signing of Docker images using certificates and Cosign/Notary.
-
-  - id: document-revision-history
-    file: document-revision-history/SKILL.md
-    description: Manages a revision history table at the beginning of generated documents, tracking changes per version.
-    applies_when:
-      - generating or updating planning documents
-      - creating specification or design documents
-      - modifying existing markdown documents that have a revision history table
-
-  - id: git-workflow-skill
-    file: git-workflow-skill/SKILL.md
-    description: MANDATORY worktree-based workflow for ALL file-changing activities. Enforces isolated feature branches, conventional commits, and PR-based merging.
-    applies_when:
-      - committing changes
-      - creating branches or PRs
-      - any code writing or modification task
-    always_load: true
-
-  - id: js-ts-dependency-mgmt
-    file: js-ts-dependency-mgmt/SKILL.md
-    description: Standardize package management and security across NPM, Yarn, and PNPM.
-    applies_when:
-      - managing JavaScript or TypeScript project dependencies
-      - configuring package.json, npmrc, or lockfiles
-      - updating NPM/Yarn/PNPM packages
-      - auditing JS/TS supply chain security
-    always_load: true
-
-  - id: js-ts-security-skill
-    file: js-ts-security-skill/SKILL.md
-    description: Verify security of JavaScript and TypeScript codebases against OWASP Top 10 2025 standards
-    applies_when:
-      - writing or reviewing security-critical code
-      - analyzing third-party dependencies
-      - performing security audits
-
-  - id: logging-best-practices
-    file: logging-best-practices/SKILL.md
-    description: Standardizes structured logging across Backend, Frontend, Realtime, and Algorithmic domains with mandatory exception handling.
-    applies_when:
-      - writing new service classes
-      - reviewing or modifying existing log statements
-      - adding error handling
-
-  - id: open-presentation
-    file: open-presentation/SKILL.md
-    description: Opens the BMAD-METHOD AI Development Training presentation from _bmad-output/methodology/
-    applies_when:
-      - user types /open-presentation
-      - user asks to open the methodology presentation or training slides
-
-  - id: opentelemetry-best-practices
-    file: opentelemetry-best-practices/SKILL.md
-    description: Standardizes distributed tracing, metrics, and semantic conventions for high-quality system observability.
-    applies_when:
-      - implementing api endpoints
-      - handling distributed requests
-      - optimizing performance
-      - adding monitoring
-
-  - id: python-best-practices
-    file: python-best-practices/SKILL.md
-    description: Comprehensive Python coding standards covering PEP 8 conventions, type hinting (3.10+), modern patterns (match/case, exception groups), async, and packaging best practices. Cross-references security-focused Python skills.
-    applies_when:
-      - writing python code
-      - modifying python code
-      - creating new python files or modules
-      - reviewing python code style or conventions
-      - refactoring python code
-      - setting up a python project
-
-  - id: python-dependency-mgmt
-    file: python-dependency-mgmt/SKILL.md
-    description: Standardize Python dependency handling using uv and pip (requirements.txt).
-    applies_when:
-      - managing Python project dependencies
-      - configuring Python build systems
-      - updating requirements.txt or uv.lock
-      - setting up Python development environments
-    always_load: true
-
-  - id: python-security-skill
-    file: python-security-skill/SKILL.md
-    description: Enforce secure Python coding standards following OWASP Top 10 2025.
-    applies_when:
-      - writing or reviewing Python code
-      - managing Python dependencies
-      - configuring Python application environments
-      - handling sensitive data in Python
-    always_load: true
-
-  - id: self-signed-cert
-    file: self-signed-cert/SKILL.md
-    description: Generates secure self-signed certificates and Root CAs using OpenSSL.
-
-  - id: skill-creator
-    file: skill-creator/SKILL.md
-    description: Guide for creating effective skills that extend Claude's capabilities with specialized knowledge, workflows, and tool integrations
-
-  - id: story-status-lookup
-    file: story-status-lookup/SKILL.md
-    description: Looks up the current status of a story to classify code as delivered or work-in-progress. Supports file-system backend now; Jira backend reserved for future configuration.
-    always_load: true
-
-  - id: test-accompanied-development
-    file: test-accompanied-development/SKILL.md
-    description: Enforces writing unit tests for every new public method created by the agent.
-    applies_when:
-      - writing or reviewing public APIs
-      - adding new public methods to a class
-      - code review tasks
-
-  - id: test-generator
-    file: test-generator/SKILL.md
-    description: Generates comprehensive unit and integration tests
-    applies_when:
-      - creating new code files
-      - adding complex logic
-      - refactoring existing code
-
-  - id: vercel-react-best-practices
-    file: vercel-react-best-practices/SKILL.md
-    description: Performance optimization framework for React and Next.js projects with 57 actionable rules across 8 categories
-    applies_when:
-      - working on React or Next.js components
-      - optimizing page performance
-      - reviewing frontend code architecture
-
-  - id: verify-hardened-docker-skill
-    file: verify-hardened-docker-skill/SKILL.md
-    description: Comprehensive security verification for Docker configurations against CIS, OWASP, and NIST standards
-

package/.roo/skills/ai-audit-trail/SKILL.md

@@ -1,23 +0,0 @@
----
-name: AI Audit Trail
-description: Tracks AI agent session activity, time spent, and token usage in a project-level AiAudit.md log file.
----
-# AI Audit Trail
-
-At the end of every significant agent session, append an entry to `{project_root}/AiAudit.md`. If the file does not exist, create it with a `# AI Audit Trail` header first.
-
-## Entry Format
-
-```markdown
-| Date | Task | Tokens (est.) |
-|------|------|---------------|
-| YYYY-MM-DD | Brief task description | In: ~X / Out: ~Y |
-```
-
-## Rules
-
-- **Append only** — never delete or modify previous entries
-- **One row per session** — combine multiple tasks in the same session into one entry
-- **Estimate tokens** — round to nearest thousand, prefix with `~`. Write `N/A` if unknown
-- Write the entry as the **last action** before presenting results to the user
-- Skip trivial interactions (single-question answers, quick lookups)

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)
-{
-    // ...
-}
-```