@elizaos/skills 2.0.0-alpha.21 → 2.0.0-alpha.211

package/skills/eliza-app-development/references/runtime-and-cloud.md

@@ -0,0 +1,61 @@
+# Runtime and cloud (eliza app)
+
+## Runtime shape
+
+This app persists canonical runtime state in config fields such as:
+
+- `deploymentTarget` for where the active runtime lives: `local`, `cloud`, or `remote`
+- `linkedAccounts` for which providers and cloud accounts are connected
+- `serviceRouting` for which backend handles each capability (`llmText`, `tts`, `media`, `embeddings`, `rpc`)
+
+This separation matters. Hosting on Eliza Cloud does not require all inference to run through Eliza Cloud, and direct provider keys can still be used for selected capabilities.
+
+## Onboarding model
+
+Onboarding chooses:
+
+1. identity and persona
+2. hosting target
+3. provider/account links
+4. service routing
+5. credentials
+
+The stored config then drives runtime behavior after restart.
+
+## Providers and skills
+
+The runtime injects context through providers (workspace, admin trust, autonomous state, UI catalog or action availability, etc.).
+
+Shipped skills are separate from providers. Skills are disk-backed knowledge assets discovered from `skills/` and the managed skills directory, then selected dynamically per turn by the app’s skill provider.
+
+## Eliza Cloud in this app
+
+Eliza Cloud is treated as a first-class managed backend:
+
+- cloud login and API key persistence
+- credit balance and in-app billing proxies
+- cloud-hosted agent provisioning
+- cloud media and TTS paths
+- app platform integration
+- containers and remote runtimes
+
+If a task is about app building and Cloud is enabled or requested, prefer the Cloud backend path before inventing custom auth, billing, analytics, or hosting.
+
+## Cloud-as-backend heuristic
+
+For new app work, the default path should usually be:
+
+1. create or reuse an Eliza Cloud app
+2. use its `appId` plus API key
+3. configure origins, redirect URIs, and domains
+4. use Cloud APIs for chat/media/agent features
+5. turn on monetization if the app should earn
+6. deploy a container only if server-side code is required
+
+## Current cloud monetization reality
+
+In this repo’s implementation, app monetization is driven by markup/share fields and creator earnings tracking, not only generic per-request pricing prose. When docs drift, prefer:
+
+- schema fields in `eliza/cloud/packages/db/schemas/`
+- app monetization UI under `eliza/cloud/packages/ui/src/components/apps/`
+- billing and earnings APIs used by the UI

package/skills/eliza-cloud/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: eliza-cloud
+description: "Use when the task involves Eliza Cloud or elizaOS Cloud as a managed backend, app platform, deployment target, billing layer, or monetization surface. Covers app creation, `appId` usage, app auth flows, cloud-hosted APIs, analytics, credits, creator monetization, and custom Docker container deployments."
+---
+
+# Eliza Cloud
+
+Use this skill whenever Eliza Cloud is enabled, linked, or the task involves building an app that could use Cloud as its backend.
+
+## Default Stance
+
+Treat Eliza Cloud as the default managed backend before inventing separate auth, billing, analytics, or hosting. In this repo, Cloud already supports:
+
+- app registration and API keys
+- `appId`-based app auth flows
+- cloud-hosted chat, media, agent, and billing APIs
+- app analytics, user tracking, domains, and credits
+- creator monetization
+- Docker container deployments for server-side workloads
+
+## Read These References First
+
+- `references/cloud-backend-and-monetization.md` for apps, auth, billing, and earnings
+- `references/apps-and-containers.md` for deployment, domains, and container workflow
+
+## Default Build Flow
+
+For most app work:
+
+1. create or reuse an Eliza Cloud app
+2. capture the app's `appId` and API key
+3. configure `app_url`, allowed origins, and redirect URIs
+4. use Cloud APIs as the backend
+5. enable monetization if the app should earn
+6. deploy a container only if server-side code is required
+
+## Important Reality Check
+
+Some older docs still describe generic per-request or per-token app pricing. In this repo's current implementation, the active app monetization controls are markup/share-based. Prefer the current schema, UI, and API behavior in this repo when prose docs conflict.

package/skills/eliza-cloud/references/apps-and-containers.md

@@ -0,0 +1,73 @@
+# Eliza Cloud Apps And Containers
+
+## Apps First
+
+For most product work, start with an app.
+
+Typical flow:
+
+1. create the app
+2. store `appId`
+3. configure `app_url` and `allowed_origins`
+4. register redirect URIs
+5. wire the client to Cloud APIs
+6. add domains if the app needs a branded URL
+
+Useful app capabilities already present in this repo:
+
+- analytics
+- user tracking
+- monetization settings
+- earnings dashboard
+- domain management
+- one-time API key display and regeneration
+
+## Domains
+
+Apps can get:
+
+- a managed subdomain
+- custom domains with verification
+
+If the task needs a production URL, prefer the existing app/domain model before inventing custom deployment plumbing.
+
+## When To Use A Container
+
+Use a Cloud container when the app needs backend code that cannot live purely in the browser or through the existing managed APIs.
+
+Good reasons:
+
+- custom server logic
+- webhooks
+- background jobs tied to the app
+- an existing Dockerized service
+
+Do not default to a container just to get a backend if the built-in Cloud APIs are already enough.
+
+## Container Deployment Flow
+
+Current container flow in this repo:
+
+1. get temporary ECR credentials
+2. push a Docker image
+3. create a container with `ecr_image_uri`
+4. poll status until it is running
+5. read logs/metrics or attach domains as needed
+
+Current implementation notes:
+
+- deployments are asynchronous
+- the API returns a poll endpoint
+- deployments deduct credits
+- health checks, metrics, and logs already exist
+
+## Practical Heuristic For Agents
+
+If you are building an app:
+
+- use an app record and Cloud APIs by default
+- use the app auth flow for user login
+- turn on monetization if appropriate
+- add a container only for real server-side code
+
+That keeps the app inside the platform's identity, billing, analytics, and earnings model.

package/skills/eliza-cloud/references/cloud-backend-and-monetization.md

@@ -0,0 +1,99 @@
+# Eliza Cloud Backend And Monetization
+
+## Why Use Cloud As The Backend
+
+When Cloud is enabled, it already gives the app most of the backend primitives agents usually try to reinvent:
+
+- authentication
+- API keys
+- usage tracking
+- credits and billing
+- analytics
+- domains
+- app users
+- creator earnings
+
+For app work, the default assumption should be that Cloud is the backend unless there is a specific reason not to use it.
+
+## App As The Integration Unit
+
+The core unit is an app record.
+
+Current app fields in this repo include:
+
+- `id` / `appId`
+- `name`
+- `app_url`
+- `allowed_origins`
+- `website_url`
+- `contact_email`
+- deployment status and production URL
+- monetization fields
+
+Creating an app yields a unique API key and an app identifier. Use the app identifier for frontend/browser-facing flows and keep the API key on trusted server paths.
+
+## User Auth Flow
+
+The existing app auth flow expects:
+
+- `app_id`
+- `redirect_uri`
+- optional `state`
+
+The user signs into Eliza Cloud, the app is validated, and the user is redirected back with a token. This means users logging into the app can use Eliza Cloud as the backend identity and service layer instead of a separate auth stack.
+
+## Billing And Credits
+
+Cloud already exposes:
+
+- credit balance APIs
+- billing summary
+- checkout / top-up flows
+- payment methods
+- billing history
+
+In Eliza, billing is intended to stay inside the app where possible, with hosted URLs treated as fallback.
+
+## Current App Monetization Model In This Repo
+
+The app monetization implementation currently centers on:
+
+- `monetization_enabled`
+- `inference_markup_percentage`
+- `purchase_share_percentage`
+- `platform_offset_amount`
+- `total_creator_earnings`
+
+The UI describes this as:
+
+- creators earn from inference markups
+- creators earn a share when users buy app credits
+- users pay app-specific credits
+
+So when an agent builds an app on Cloud, it should understand that app usage can be monetized directly instead of treated as pure cost.
+
+## Redeemable Earnings
+
+Redeemable earnings in this repo explicitly include:
+
+- app creator earnings
+- agent creator earnings
+- MCP creator earnings
+- affiliate and revenue-share flows
+
+That means apps, public agents, and MCP products can all participate in monetized Cloud flows.
+
+## Affiliate And Marked-Up Usage
+
+The Cloud UI also includes affiliate markup flows where a code can add markup to usage and credit top-ups. This is separate from per-app monetization, but it reinforces the same principle: Cloud is designed to let builders earn on top of platform usage rather than only consume credits.
+
+## Source Of Truth When Docs Drift
+
+Prefer these implementation surfaces:
+
+- `eliza/cloud/packages/db/schemas/app-billing.ts`
+- `eliza/cloud/packages/db/schemas/apps.ts`
+- `eliza/cloud/packages/db/schemas/redeemable-earnings.ts`
+- `eliza/cloud/packages/ui/src/components/apps/app-monetization-settings.tsx`
+- `eliza/cloud/packages/ui/src/components/apps/app-earnings-dashboard.tsx`
+- `eliza/cloud/packages/ui/src/components/auth/authorize-content.tsx`

package/skills/elizaos/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: elizaos
+description: "Use when the task involves elizaOS core runtime concepts, plugins, actions, providers, evaluators, services, memories, state composition, or upstream elizaOS development. Covers the main abstractions and the TypeScript runtime mental model."
+---
+
+# elizaOS
+
+elizaOS is the plugin-based agent runtime that Eliza builds on top of.
+
+## Read These References First
+
+- `references/core-abstractions.md` for the runtime mental model and message flow
+- `references/plugin-development.md` for plugin extension points and implementation patterns
+
+## Use This Skill When
+
+- a change touches `eliza/`
+- you need to reason about `AgentRuntime`
+- you are implementing or debugging actions, providers, evaluators, services, or model handlers
+- you need the correct plugin lifecycle instead of guessing from Eliza wrappers
+
+## Working Rules
+
+- Treat the TypeScript runtime in `eliza/packages/typescript/src/` as the primary reference implementation.
+- Prefer elizaOS-native abstractions over product-specific wrappers when reasoning about upstream behavior.
+- Remember the split between persistent `Memory` and ephemeral `State`.
+- Remember that plugins are the main composition mechanism.

package/skills/elizaos/references/core-abstractions.md

@@ -0,0 +1,101 @@
+# elizaOS Core Abstractions
+
+## Runtime
+
+The main TypeScript runtime is `AgentRuntime`.
+
+It owns:
+
+- registered plugins
+- actions, providers, evaluators, services, routes, and model handlers
+- database adapter access
+- message processing
+- cached per-message state
+
+`runtime.initialize()` registers plugins, initializes the adapter, creates the default message service, and can run plugin migrations.
+
+## Persistent Versus Ephemeral Data
+
+### `Memory`
+
+Persistent data. Messages, documents, fragments, and other stored knowledge live here.
+
+Typical fields:
+
+- `content`
+- `embedding`
+- `metadata`
+
+### `State`
+
+Ephemeral per-turn context used for prompt composition and action execution.
+
+Typical parts:
+
+- `values`
+- `data`
+- `text`
+
+Providers build `State`; memories persist across turns.
+
+## Core Conversation Model
+
+- **Entity**: participant identity
+- **Room**: conversation space
+- **World**: container for related rooms
+
+Typical flow:
+
+1. ensure the connection (`world`, `room`, `entity`)
+2. create a message memory
+3. call the message service
+
+## Provider Model
+
+Providers build context before inference.
+
+They can contribute:
+
+- `text` for human-readable prompt context
+- `values` for template variables
+- `data` for structured cached state
+
+Providers are ordered by `position`. `private` and `dynamic` providers are excluded from the default provider set unless explicitly requested.
+
+## Action Model
+
+Actions are elizaOS tools.
+
+The default flow is:
+
+1. model emits an action plan
+2. runtime executes actions
+3. action results can feed follow-up state or callbacks
+
+Single-action and multi-action modes both exist.
+
+## Evaluators
+
+Evaluators run after response generation and action execution.
+
+Use them for:
+
+- reflection
+- extraction
+- safety checks
+- policy enforcement
+
+## End-To-End Flow
+
+The default TypeScript pipeline is:
+
+1. ingest message
+2. persist incoming memory
+3. compose state via providers
+4. optionally process attachments
+5. decide whether to respond
+6. run model inference
+7. execute actions
+8. persist/send the response
+9. run evaluators
+10. emit lifecycle events

package/skills/elizaos/references/plugin-development.md

@@ -0,0 +1,74 @@
+# elizaOS Plugin Development
+
+## Plugin Shape
+
+An elizaOS plugin is a plain object that can register:
+
+- `actions`
+- `providers`
+- `services`
+- `models`
+- `evaluators`
+- `routes`
+- `events`
+- optionally an adapter or schema
+
+## Key Extension Points
+
+### Actions
+
+Use for tool execution or side effects.
+
+- declared in `plugin.actions`
+- executed by `runtime.processActions(...)`
+- can declare structured parameters
+
+### Providers
+
+Use for state and prompt context.
+
+- declared in `plugin.providers`
+- executed during `runtime.composeState(...)`
+- return `text`, `values`, and/or `data`
+
+### Services
+
+Use for long-lived shared logic such as API clients, caches, or background connections.
+
+### Models
+
+Use to register inference handlers for text, embeddings, image description, and related model types.
+
+### Evaluators
+
+Use for post-response analysis or policy checks.
+
+### Routes
+
+Use for plugin-owned HTTP endpoints. Routes are namespaced under the plugin name.
+
+## Practical Guidance
+
+- If the feature changes prompt context, it is usually a provider.
+- If the feature performs an operation, it is usually an action.
+- If the feature needs shared lifecycle-managed resources, it is usually a service.
+- If the feature changes inference backends, it is usually a model handler.
+
+## Runtime Registration Order
+
+At plugin registration:
+
+1. `plugin.init(...)` runs first
+2. components are registered
+3. routes are namespaced
+4. services are initialized asynchronously
+
+## Eliza Context
+
+In this repo, Eliza adds product behavior around elizaOS, but the underlying runtime composition rules still come from elizaOS. When a Eliza feature behaves strangely, check whether the root cause is actually in:
+
+- provider ordering
+- action planning
+- model handler selection
+- plugin auto-enable or plugin loading
+- database adapter initialization

package/skills/yara-authoring/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: yara-authoring
+description: "Write and test YARA rules for malware detection and threat hunting. Use when creating YARA signatures, detecting malware families, scanning files or memory for indicators of compromise, or building detection rules for threat intelligence."
+allowed-tools:
+  - Bash
+  - Read
+  - Write
+  - Glob
+  - Grep
+---
+
+# YARA Rule Authoring
+
+## When to Use
+
+- Writing YARA rules to detect malware samples or families
+- Creating detection signatures for indicators of compromise (IOCs)
+- Scanning files or directories for known threat patterns
+- Building threat hunting rules from intelligence reports
+- Classifying unknown samples based on behavioral or structural patterns
+
+## When NOT to Use
+
+- Dynamic malware analysis (use sandbox environments)
+- Network traffic analysis (use Suricata/Snort rules)
+- Static analysis of source code (use Semgrep/CodeQL)
+
+## Rule Template
+
+```yara
+rule MalwareFamily_Variant : tag1 tag2 {
+    meta:
+        author = "analyst"
+        description = "Detects MalwareFamily variant based on unique strings"
+        date = "2024-01-01"
+        reference = "https://example.com/report"
+        hash = "abc123..."
+        severity = "high"
+
+    strings:
+        $s1 = "unique_malware_string" ascii
+        $s2 = { 4D 5A 90 00 03 00 }  // hex pattern
+        $s3 = /https?:\/\/[a-z0-9]+\.evil\.com/ nocase  // regex
+
+    condition:
+        uint16(0) == 0x5A4D and  // MZ header (PE file)
+        filesize < 5MB and
+        (2 of ($s*))
+}
+```
+
+## String Types
+
+| Type | Syntax | Use Case |
+|------|--------|----------|
+| Text | `"string"` | ASCII strings |
+| Hex | `{ AA BB CC }` | Byte patterns, shellcode |
+| Regex | `/pattern/` | Flexible text matching |
+
+### Modifiers
+- `ascii` / `wide` — encoding
+- `nocase` — case insensitive
+- `fullword` — word boundary matching
+- `xor` — XOR-encoded strings
+- `base64` — base64-encoded strings
+
+## Condition Operators
+
+```yara
+condition:
+    all of them           // All strings match
+    any of ($a*)          // Any string starting with $a
+    2 of ($s1, $s2, $s3)  // At least 2 of listed strings
+    #s1 > 3               // String $s1 appears more than 3 times
+    @s1 < 0x100           // String $s1 found before offset 0x100
+    filesize < 1MB        // File size constraint
+    uint16(0) == 0x5A4D   // Magic bytes at offset
+```
+
+## Scanning
+
+```bash
+# Scan a file
+yara rule.yar target_file
+
+# Scan directory recursively
+yara -r rules/ /path/to/scan/
+
+# Scan with metadata output
+yara -m -s rule.yar target_file
+
+# Compile rules for faster repeated scanning
+yarac rules/ compiled.yarc
+yara -C compiled.yarc /path/to/scan/
+```
+
+## Best Practices
+
+1. Always include `meta` with author, description, date, and reference
+2. Use `filesize` and magic byte checks to limit scope
+3. Prefer multiple weak indicators over one strong indicator
+4. Test against known samples AND clean files for false positives
+5. Use `private` rules for helper conditions
+6. Avoid overly broad regex patterns that cause performance issues
+7. Version control your rules and track detection rates
+
+## Resources
+
+- YARA Documentation — https://yara.readthedocs.io/
+- YARA Rules Repository — https://github.com/Yara-Rules/rules
+- VirusTotal YARA — https://docs.virustotal.com/docs/yara

package/skills/bear-notes/SKILL.md

@@ -1,107 +0,0 @@
----
-name: bear-notes
-description: Create, search, read, tag, and append to Bear app notes on macOS via the grizzly CLI. Use when the user wants to create a new note in Bear, search Bear notes by tag, read or open a Bear note by ID, append text to an existing Bear note, list Bear tags, or automate note-taking in Bear. Requires the grizzly binary and Bear app running on macOS.
-homepage: https://bear.app
-metadata:
-  {
-    "otto":
-      {
-        "emoji": "🐻",
-        "os": ["darwin"],
-        "requires": { "bins": ["grizzly"] },
-        "install":
-          [
-            {
-              "id": "go",
-              "kind": "go",
-              "module": "github.com/tylerwince/grizzly/cmd/grizzly@latest",
-              "bins": ["grizzly"],
-              "label": "Install grizzly (go)",
-            },
-          ],
-      },
-  }
----
-
-# Bear Notes
-
-Use `grizzly` to create, read, and manage notes in Bear on macOS.
-
-Requirements
-
-- Bear app installed and running
-- For some operations (add-text, tags, open-note --selected), a Bear app token (stored in `~/.config/grizzly/token`)
-
-## Getting a Bear Token
-
-For operations that require a token (add-text, tags, open-note --selected), you need an authentication token:
-
-1. Open Bear → Help → API Token → Copy Token
-2. Save it: `echo "YOUR_TOKEN" > ~/.config/grizzly/token`
-
-## Common Commands
-
-Create a note
-
-```bash
-echo "Note content here" | grizzly create --title "My Note" --tag work
-grizzly create --title "Quick Note" --tag inbox < /dev/null
-```
-
-Open/read a note by ID
-
-```bash
-grizzly open-note --id "NOTE_ID" --enable-callback --json
-```
-
-Append text to a note
-
-```bash
-echo "Additional content" | grizzly add-text --id "NOTE_ID" --mode append --token-file ~/.config/grizzly/token
-```
-
-List all tags
-
-```bash
-grizzly tags --enable-callback --json --token-file ~/.config/grizzly/token
-```
-
-Search notes (via open-tag)
-
-```bash
-grizzly open-tag --name "work" --enable-callback --json
-```
-
-## Options
-
-Common flags:
-
-- `--dry-run` — Preview the URL without executing
-- `--print-url` — Show the x-callback-url
-- `--enable-callback` — Wait for Bear's response (needed for reading data)
-- `--json` — Output as JSON (when using callbacks)
-- `--token-file PATH` — Path to Bear API token file
-
-## Configuration
-
-Grizzly reads config from (in priority order):
-
-1. CLI flags
-2. Environment variables (`GRIZZLY_TOKEN_FILE`, `GRIZZLY_CALLBACK_URL`, `GRIZZLY_TIMEOUT`)
-3. `.grizzly.toml` in current directory
-4. `~/.config/grizzly/config.toml`
-
-Example `~/.config/grizzly/config.toml`:
-
-```toml
-token_file = "~/.config/grizzly/token"
-callback_url = "http://127.0.0.1:42123/success"
-timeout = "5s"
-```
-
-## Notes
-
-- Bear must be running for commands to work
-- Note IDs are Bear's internal identifiers (visible in note info or via callbacks)
-- Use `--enable-callback` when you need to read data back from Bear
-- Some operations require a valid token (add-text, tags, open-note --selected)