@wentorai/research-plugins 1.0.0

package/skills/tools/code-exec/sandbox-execution-guide/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: sandbox-execution-guide
+description: "Secure sandboxed code execution environments for reproducible research computing"
+metadata:
+  openclaw:
+    emoji: "shield"
+    category: "tools"
+    subcategory: "code-exec"
+    keywords: ["sandbox execution", "code runner", "literate programming", "containerization", "reproducible computing"]
+    source: "wentor"
+---
+
+# Sandbox Execution Guide
+
+A skill for setting up and using sandboxed code execution environments for research computing. Covers containerized execution, security considerations, resource management, and integration with research workflows.
+
+## Why Sandboxed Execution?
+
+Research code often requires:
+- Isolation from the host system for security
+- Reproducible environments across machines
+- Resource limits to prevent runaway computations
+- Multi-language support (Python, R, Julia, MATLAB)
+
+## Docker-Based Sandboxes
+
+### Creating a Research Container
+
+```dockerfile
+# Dockerfile for a reproducible research environment
+FROM python:3.11-slim
+
+# System dependencies
+RUN apt-get update && apt-get install -y --no-install-recommends \
+    build-essential \
+    gfortran \
+    libopenblas-dev \
+    && rm -rf /var/lib/apt/lists/*
+
+# Create non-root user for security
+RUN useradd -m -s /bin/bash researcher
+USER researcher
+WORKDIR /home/researcher
+
+# Pin all dependencies
+COPY requirements.txt .
+RUN pip install --user --no-cache-dir -r requirements.txt
+
+# Copy project files
+COPY --chown=researcher:researcher . /home/researcher/project
+WORKDIR /home/researcher/project
+
+# Resource limits set at runtime, not build time
+CMD ["python", "main.py"]
+```
+
+### Running with Resource Limits
+
+```bash
+# Run with CPU, memory, and time constraints
+docker run \
+  --cpus="2.0" \
+  --memory="4g" \
+  --memory-swap="4g" \
+  --pids-limit=100 \
+  --network=none \
+  --read-only \
+  --tmpfs /tmp:size=512m \
+  --timeout 3600 \
+  research-sandbox:latest python analysis.py
+
+# Mount data as read-only, output directory as writable
+docker run \
+  -v /data/raw:/data:ro \
+  -v /data/results:/output:rw \
+  --cpus="4.0" \
+  --memory="16g" \
+  research-sandbox:latest python pipeline.py
+```
+
+## Python Sandbox with Resource Limits
+
+### Process-Level Isolation
+
+```python
+import subprocess
+import resource
+import signal
+import tempfile
+import os
+
+def run_sandboxed(code: str, timeout: int = 60,
+                   max_memory_mb: int = 512) -> dict:
+    """
+    Execute Python code in a sandboxed subprocess with resource limits.
+
+    Args:
+        code: Python code string to execute
+        timeout: Maximum execution time in seconds
+        max_memory_mb: Maximum memory in megabytes
+    """
+    with tempfile.NamedTemporaryFile(mode='w', suffix='.py', delete=False) as f:
+        f.write(code)
+        script_path = f.name
+
+    try:
+        result = subprocess.run(
+            ['python', '-u', script_path],
+            capture_output=True,
+            text=True,
+            timeout=timeout,
+            env={
+                'PATH': '/usr/bin:/usr/local/bin',
+                'HOME': '/tmp',
+                'PYTHONDONTWRITEBYTECODE': '1'
+            }
+        )
+        return {
+            'stdout': result.stdout,
+            'stderr': result.stderr,
+            'returncode': result.returncode,
+            'timed_out': False
+        }
+    except subprocess.TimeoutExpired:
+        return {
+            'stdout': '',
+            'stderr': f'Execution timed out after {timeout}s',
+            'returncode': -1,
+            'timed_out': True
+        }
+    finally:
+        os.unlink(script_path)
+
+# Example usage
+result = run_sandboxed("""
+import numpy as np
+data = np.random.randn(1000)
+print(f"Mean: {data.mean():.4f}")
+print(f"Std:  {data.std():.4f}")
+""", timeout=30, max_memory_mb=256)
+print(result['stdout'])
+```
+
+## Nix-Based Reproducible Environments
+
+For maximum reproducibility, use Nix to pin every dependency including system libraries:
+
+```nix
+# shell.nix for a research project
+{ pkgs ? import (fetchTarball {
+    url = "https://github.com/NixOS/nixpkgs/archive/nixos-23.11.tar.gz";
+  }) {} }:
+
+pkgs.mkShell {
+  buildInputs = with pkgs; [
+    python311
+    python311Packages.numpy
+    python311Packages.scipy
+    python311Packages.pandas
+    python311Packages.matplotlib
+    python311Packages.scikit-learn
+    R
+    rPackages.ggplot2
+    rPackages.dplyr
+  ];
+
+  shellHook = ''
+    echo "Research sandbox activated"
+    echo "Python: $(python --version)"
+    echo "R: $(R --version | head -1)"
+  '';
+}
+```
+
+```bash
+# Enter the reproducible environment
+nix-shell shell.nix
+
+# Or use flakes for even better reproducibility
+nix develop
+```
+
+## Security Best Practices
+
+When running untrusted or third-party code:
+
+1. **Network isolation**: Use `--network=none` in Docker to prevent data exfiltration
+2. **Filesystem restrictions**: Mount data as read-only, limit writable paths
+3. **Resource caps**: Always set CPU, memory, and time limits
+4. **User isolation**: Run as non-root user inside the container
+5. **Syscall filtering**: Use seccomp profiles to restrict system calls
+6. **Output sanitization**: Validate and sanitize all output before processing
+
+## Integration with CI/CD
+
+Automate research pipeline execution with GitHub Actions:
+
+```yaml
+name: Research Pipeline
+on:
+  push:
+    paths: ['src/**', 'data/**']
+
+jobs:
+  run-analysis:
+    runs-on: ubuntu-latest
+    container:
+      image: research-sandbox:latest
+      options: --cpus 4 --memory 8g
+    steps:
+      - uses: actions/checkout@v4
+      - run: python src/01_preprocess.py
+      - run: python src/02_analyze.py
+      - run: python src/03_visualize.py
+      - uses: actions/upload-artifact@v4
+        with:
+          name: results
+          path: output/
+```
+
+This ensures every commit triggers a fresh, sandboxed execution of the full pipeline, catching environment-dependent bugs and ensuring reproducibility.

package/skills/tools/diagram/mermaid-diagram-guide/SKILL.md

@@ -0,0 +1,269 @@
+---
+name: mermaid-diagram-guide
+description: "Create flowcharts, sequence diagrams, and architecture diagrams with Mermaid"
+metadata:
+  openclaw:
+    emoji: "📋"
+    category: "tools"
+    subcategory: "diagram"
+    keywords: ["flow chart", "architecture diagram", "Mermaid", "UML diagram", "graphical abstract"]
+    source: "N/A"
+---
+
+# Mermaid Diagram Guide
+
+## Overview
+
+Mermaid is a text-based diagramming tool that renders diagrams from Markdown-like syntax. For researchers, Mermaid offers a unique combination of version-controllable source code, instant rendering in documentation platforms (GitHub, GitLab, Notion, Obsidian), and enough expressiveness to create flowcharts, sequence diagrams, class diagrams, Gantt charts, and more.
+
+Unlike graphical tools like draw.io or Lucidchart, Mermaid diagrams live as plain text in your documentation, making them easy to maintain alongside code and papers. They are especially valuable for research documentation, README files, software architecture diagrams in methods sections, and graphical abstracts.
+
+This guide covers the most useful Mermaid diagram types for academic work, with complete syntax references and real-world examples from research contexts. Each diagram type includes a template you can copy and modify for your specific needs.
+
+## Flowcharts
+
+Flowcharts are the most common diagram type for describing algorithms, experimental procedures, and data processing pipelines.
+
+### Basic Syntax
+
+```mermaid
+flowchart TD
+    A[Start] --> B{Decision}
+    B -->|Yes| C[Process A]
+    B -->|No| D[Process B]
+    C --> E[End]
+    D --> E
+```
+
+### Node Shapes
+
+| Shape | Syntax | Use Case |
+|-------|--------|----------|
+| Rectangle | `A[text]` | Process step |
+| Rounded | `A(text)` | Start/end |
+| Diamond | `A{text}` | Decision |
+| Hexagon | `A{{text}}` | Preparation |
+| Parallelogram | `A[/text/]` | Input/output |
+| Circle | `A((text))` | Connector |
+| Stadium | `A([text])` | Terminal |
+
+### Research Pipeline Example
+
+```mermaid
+flowchart TD
+    subgraph Data Collection
+        A[Raw Data] --> B[Quality Check]
+        B --> C{Pass QC?}
+        C -->|No| D[Exclude]
+        C -->|Yes| E[Clean Data]
+    end
+
+    subgraph Analysis
+        E --> F[Feature Extraction]
+        F --> G[Model Training]
+        G --> H[Cross-Validation]
+    end
+
+    subgraph Evaluation
+        H --> I{Significant?}
+        I -->|Yes| J[Report Results]
+        I -->|No| K[Revise Hypothesis]
+        K --> F
+    end
+
+    style A fill:#3B82F6,color:#fff
+    style J fill:#16A34A,color:#fff
+    style D fill:#EF4444,color:#fff
+```
+
+### Direction Options
+
+| Direction | Code | Description |
+|-----------|------|-------------|
+| Top to bottom | `TD` or `TB` | Default, vertical |
+| Bottom to top | `BT` | Vertical, upward |
+| Left to right | `LR` | Horizontal |
+| Right to left | `RL` | Horizontal, reversed |
+
+## Sequence Diagrams
+
+Sequence diagrams show interactions between components over time. They are ideal for describing API calls, protocol steps, and system interactions.
+
+```mermaid
+sequenceDiagram
+    participant U as User
+    participant F as Frontend
+    participant A as API Server
+    participant DB as Database
+
+    U->>F: Submit experiment
+    F->>A: POST /experiments
+    A->>DB: INSERT experiment
+    DB-->>A: experiment_id
+    A->>A: Queue processing job
+
+    Note over A: Async processing begins
+
+    A-->>F: 202 Accepted {id}
+    F-->>U: "Experiment submitted"
+
+    loop Every 5 seconds
+        F->>A: GET /experiments/{id}/status
+        A-->>F: {status: "running"}
+    end
+
+    A-->>F: {status: "complete", results: {...}}
+    F-->>U: Display results
+```
+
+### Arrow Types
+
+| Arrow | Syntax | Meaning |
+|-------|--------|---------|
+| Solid with arrowhead | `->>` | Synchronous call |
+| Dotted with arrowhead | `-->>` | Response/return |
+| Solid | `->` | Message |
+| Dotted | `-->` | Optional message |
+| Cross | `-x` | Failed message |
+
+## Class Diagrams
+
+Class diagrams document code architecture and data models:
+
+```mermaid
+classDiagram
+    class Experiment {
+        +String id
+        +String name
+        +DateTime created_at
+        +Status status
+        +run()
+        +get_results() Results
+    }
+
+    class Dataset {
+        +String path
+        +int n_samples
+        +int n_features
+        +load() DataFrame
+        +split(ratio) TrainTest
+    }
+
+    class Model {
+        +String architecture
+        +Dict hyperparams
+        +train(Dataset)
+        +predict(Dataset) Array
+        +evaluate(Dataset) Metrics
+    }
+
+    Experiment "1" --> "1..*" Dataset : uses
+    Experiment "1" --> "1..*" Model : trains
+    Model ..> Dataset : depends on
+```
+
+## Gantt Charts
+
+Gantt charts are useful for project timelines and research plans:
+
+```mermaid
+gantt
+    title Research Project Timeline
+    dateFormat YYYY-MM-DD
+    axisFormat %b %Y
+
+    section Literature Review
+        Survey existing work     :done, lit1, 2026-01-01, 30d
+        Identify research gap    :done, lit2, after lit1, 14d
+
+    section Methodology
+        Design experiments       :active, meth1, after lit2, 21d
+        Implement baseline       :meth2, after meth1, 14d
+
+    section Experiments
+        Run baseline experiments :exp1, after meth2, 21d
+        Run proposed method      :exp2, after exp1, 21d
+        Ablation studies         :exp3, after exp2, 14d
+
+    section Writing
+        Draft paper              :write1, after exp2, 30d
+        Internal review          :write2, after write1, 14d
+        Submit to conference     :milestone, after write2, 0d
+```
+
+## State Diagrams
+
+State diagrams model entity lifecycles:
+
+```mermaid
+stateDiagram-v2
+    [*] --> Draft
+    Draft --> UnderReview : Submit
+    UnderReview --> MinorRevision : Reviewer feedback
+    UnderReview --> MajorRevision : Reviewer feedback
+    UnderReview --> Rejected : Reviewer feedback
+    MinorRevision --> UnderReview : Resubmit
+    MajorRevision --> UnderReview : Resubmit
+    UnderReview --> Accepted : Final decision
+    Accepted --> Published : Camera-ready
+    Rejected --> Draft : Revise for new venue
+    Published --> [*]
+```
+
+## Rendering and Integration
+
+### GitHub / GitLab
+
+Both platforms render Mermaid natively in Markdown files:
+
+````markdown
+```mermaid
+flowchart LR
+    A --> B --> C
+```
+````
+
+### Command-Line Rendering
+
+```bash
+# Install Mermaid CLI
+npm install -g @mermaid-js/mermaid-cli
+
+# Render to PNG
+mmdc -i diagram.mmd -o diagram.png -w 1200
+
+# Render to SVG (preferred for papers)
+mmdc -i diagram.mmd -o diagram.svg
+
+# Render to PDF
+mmdc -i diagram.mmd -o diagram.pdf
+```
+
+### Embedding in LaTeX
+
+```latex
+% Include the SVG generated by mmdc
+\usepackage{svg}
+\begin{figure}[h]
+  \centering
+  \includesvg[width=0.8\textwidth]{diagram}
+  \caption{System architecture overview.}
+\end{figure}
+```
+
+## Best Practices
+
+- **Keep diagrams focused.** One concept per diagram. If it exceeds 15-20 nodes, split it.
+- **Use subgraphs for grouping.** They clarify which components belong together.
+- **Label all edges.** Unlabeled arrows are ambiguous.
+- **Use consistent styling.** Define colors for success (green), failure (red), and process (blue) states.
+- **Export as SVG for papers.** SVG scales perfectly and produces crisp output at any size.
+- **Version-control your diagrams.** Since Mermaid is text, it diffs cleanly in Git.
+- **Test in the live editor.** Use [mermaid.live](https://mermaid.live/) to iterate quickly before committing.
+
+## References
+
+- [Mermaid Documentation](https://mermaid.js.org/) -- Official reference
+- [Mermaid Live Editor](https://mermaid.live/) -- Interactive diagram editor
+- [Mermaid CLI](https://github.com/mermaid-js/mermaid-cli) -- Command-line rendering tool
+- [GitHub Mermaid Support](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/) -- Native rendering in GitHub