# ElizaOS Developer Update (2026-03-12 → 2026-03-18)

## 1) Core Framework

### v2.0.0 “skills folder” architecture direction (in review)
Work is in progress to formalize a **skills folder structure** for v2.0.0, with an explicit push to avoid the “uncontrolled submissions” problem seen in the 0.x plugin era.

- **PR:** Skills folder structure for v2.0.0 — https://github.com/elizaos/eliza/pull/6597  
- **Open design question (not finalized):** ship **v2.0.0 with zero default skills** and encourage **decentralized discovery** via externally hosted `skills.md` indexes (e.g., `yourdomain.com/skills.md`). This keeps core lean while still enabling a rich, community-maintained ecosystem.

**Implications for developers**
- Expect a clearer separation between:
  - **Core runtime** (agent orchestration + safety defaults)
  - **Skills** (higher-level capabilities, potentially more opinionated and numerous)
  - **Plugins** (integrations/adapters, distributed via registry)

### Plugin distribution remains registry-first
For packaging/distribution, the team continues to point builders at the plugin registry as the canonical path:

- **Plugin registry:** https://github.com/elizaos-plugins/registry  
- **Plugin authoring docs:** https://docs.elizaos.ai

This is also the recommended integration point for new tooling like *unbrowse* (see below).

---

## 2) New Features

### “unbrowse” integration proposal: API-first web traversal for agents
A community developer introduced **unbrowse**, a “browser for agents” designed to run ~100x faster than DOM automation by traversing APIs instead of rendering pages, while passively indexing web APIs for other agents. The requested path forward is to integrate it as an ElizaOS plugin distributed via the registry.

- **Discussion context:** unbrowse integration guidance + registry pointers (Discord, Mar 17)

**Suggested plugin shape (high-level)**
If unbrowse exposes a client that can (a) discover API surfaces and (b) execute structured fetches, the most natural ElizaOS integration is:
- A **Tool/Action** for “navigate/search/fetch”
- A **Provider** for “API index / capability map” retrieval
- Optional **Memory adapter** hooks for persisting discovered endpoints per domain

Minimal illustrative skeleton (adapt names/APIs to the current SDK as documented):
```ts
// packages/plugin-unbrowse/src/index.ts
import type { Plugin } from "@elizaos/core"; // refer to docs.elizaos.ai for actual imports/types

export const unbrowsePlugin: Plugin = {
  id: "plugin-unbrowse",
  name: "Unbrowse",
  description: "API-first web traversal + endpoint indexing for agents",

  actions: [
    {
      id: "unbrowse.fetch",
      description: "Fetch a resource via API traversal (no DOM rendering).",
      // validate: (input) => ...
      handler: async (ctx, input) => {
        const { url, intent } = input;

        // Pseudocode: call unbrowse client
        // const result = await ctx.services.unbrowse.fetch({ url, intent });

        return {
          content: [
            // { type: "text", text: result.summary },
            // { type: "json", json: result.data },
          ],
          // Optionally emit discovered endpoints into memory/index
        };
      },
    },
  ],

  providers: [
    {
      id: "unbrowse.apiIndex",
      description: "Return known/discovered API endpoints for a domain.",
      handler: async (ctx, input) => {
        const { domain } = input;
        // const index = await ctx.services.unbrowse.getIndex(domain);
        return { /* index */ };
      },
    },
  ],
};
```

**Packaging + distribution**
- Publish to npm under the `@elizaos-plugins/*` or community scope as appropriate.
- Submit to the registry following the registry contribution workflow:
  - https://github.com/elizaos-plugins/registry

---

## 3) Bug Fixes

### plugin-evm: on-chain data expansion + issue cleanup (in progress)
There was active work reported on:
- adding **100+ on-chain data sources** via **goldrush.dev** integration
- fixing open issues in **plugin-evm**

This is meaningful because plugin-evm tends to sit on the hot path for DeFi agents (pricing, balances, tx simulation inputs), and data-source breadth directly affects reliability and latency.

**Status:** reported as ongoing; no merged PR links were provided in this week’s discussion snapshot. Track progress in the relevant plugin repository/issues once published.

### Discord role assignment via Google Form: “Invalid Dynamic Link”
A recurring onboarding issue was reported: a Google Form-based role assignment flow fails with **“Invalid Dynamic Link”** errors (likely Firebase Dynamic Links misconfiguration: domain not allowlisted / malformed deep link / invalid path component).

**Impact on developers:** blocks contributor onboarding in Discord, increasing friction for plugin authors and testers.

**Status:** reported; fix not yet confirmed in the provided activity.

---

## 4) API Changes

### Skills: upcoming organizational/API surface changes (v2.0.0 track)
While final API diffs aren’t enumerated in the available activity, PR #6597 implies developers should expect:
- a **new canonical location and loading/discovery flow** for “skills”
- likely changes in:
  - how skills are registered/loaded at runtime
  - how skills are packaged vs. plugins
  - how the project curates “default” capabilities (potentially none)

**Action for maintainers**
- Avoid hard-coding paths to skills until v2.0.0 structure is finalized.
- Prepare to publish skills externally (see “Breaking Changes” section).

---

## 5) Social Media Integrations (Twitter / Telegram / Discord / Farcaster)

No merged updates were captured this week for the official social plugins. The main social/integration-related developer activity was ecosystem-facing:
- pushing new integration concepts via the plugin registry (e.g., unbrowse)
- discussion of a **Clawhub-style directory/registry** to improve discoverability of both **skills and plugins** (see below)

**Related idea (community):** a unified directory/registry like “Clawhub” for skills + plugins  
- Discussed in `#xfn-framework`; agreement to pursue a more organized directory approach.

---

## 6) Model Provider Updates (OpenAI / Anthropic / DeepSeek / etc.)

No provider integration changes were recorded in the provided GitHub/Discord activity for this week.

(Separately, community shared an article about how Anthropic uses “skills” internally; relevant as conceptual validation for ElizaOS v2 skills direction, but not a code change.)

---

## 7) Breaking Changes (V1 → V2 migration warnings)

### v2.0.0 skills model: expect “where capabilities live” to change
If v2.0.0 ships with:
- a **skills folder structure** (PR #6597), and/or
- **zero default skills** with **external `skills.md` discovery**

…then projects upgrading from v1/0.x patterns should anticipate:

- **Breaking:** assuming built-in/default skills exist in core  
  - Mitigation: explicitly vendor skills into your project or reference a curated external `skills.md`.

- **Breaking:** reliance on “submit-anything-to-core/monorepo” contribution patterns  
  - Mitigation: publish skills/plugins through decentralized indexes + the plugin registry rather than landing everything in core.

### Recommended migration posture (now)
- Treat skills as **deployable artifacts** you own (version, review, provenance).
- Establish an internal “curated index” for your org/team:
  - `https://yourcompany.github.io/eliza/skills.md`
- Keep plugin distribution aligned with:
  - https://github.com/elizaos-plugins/registry
  - https://docs.elizaos.ai

---