Forem: Lin Zhu

Building on Zeeren in 2026: Unified MiniApp Provision, Durable Schedules, and the Composable Skills Layer

Lin Zhu — Tue, 12 May 2026 14:13:44 +0000

A quick orientation

Zeeren is an agentic overseas-ops platform. The core abstraction is a Work — a persistent, collaborative context that holds a resource tree, runs agent nodes, and owns schedules, MiniApps, and data assets. Think of it like a long-lived project container that agents can read, write, and schedule work into.

If you're building on top of Zeeren, there are three recent changes worth knowing about.

1. Unified MiniApp provision: one call instead of 14

The old flow (pre-2026-04) required chaining 14 discrete API calls to scaffold a MiniApp — create the record, create the resource tree, link the Work, apply migrations, spin the dev container, and more. Any partial failure left you in an inconsistent state.

The new endpoint, POST /api/v1/miniapps/provision (gated by MINIAPP_UNIFIED_PROVISION=true), wraps the entire transaction. One body, one round-trip:

{
  "slug": "project-tracker",
  "name": "Project Tracker",
  "work_id": 5821,
  "stack": {
    "frontend": "react",
    "backend": "python-fastapi",
    "runtime": "docker"
  },
  "data_mode": "tenant_db",
  "schema": {
    "tables": [
      {
        "name": "projects",
        "columns": [
          { "name": "name",   "type": "text",  "nullable": false },
          { "name": "status", "type": "text",  "default": "'open'" },
          { "name": "owner",  "type": "text" }
        ]
      }
    ]
  },
  "scope": "tenant",
  "visibility": "private"
}

The response comes back with the dev container's host_port, a live preview_url, and the materialised workdir path — everything you need to start generating code immediately.

A few sharp edges worth knowing:

SLUG_CONFLICT (409): append -N and retry once. The platform won't do this for you.
provision_failed (500): the transaction rolled back cleanly. Same body is safe to retry.
WORK_ALREADY_AUTHORING (409): don't retry — the Work already has a MiniApp. Call /miniapps/{id}/status to find where to resume.
The platform auto-adds id, created_at, updated_at. Don't declare them; you'll get a 422.

The legacy 14-action surface still exists for Works provisioned before April 2026, but new Works should use the unified endpoint.

2. WorkSchedules with multi-trigger support

Scheduling in Zeeren is handled through WorkSchedule records. What's useful is the range of trigger_type options — it's not just cron:

Trigger type	When to use it
`CRON`	Fixed calendar cadence: "every weekday at 9am"
`INTERVAL`	Rolling repeat: "every 5 minutes"
`WEBHOOK`	External system POSTs to a generated endpoint
`EVENT`	Internal platform event, e.g. `log.error`
`CHAT`	When a user DMs a Work with a specific prefix
`MQ`	Kafka/message-queue topic subscriber

The execution_mode field controls whether each fire opens a new Work (NEW_WORK) or appends a node to the existing one (APPEND_NODE). The latter is the right default when you want the schedule's output to stay in the same conversational context as the Work that owns it.

A minimal CRON body:

{
  "owner_scope": "USER",
  "owner_work_id": 653,
  "name": "Daily standup digest",
  "trigger_type": "CRON",
  "trigger_config": { "cron": "0 9 * * 1-5" },
  "execution_mode": "APPEND_NODE",
  "payload_template": "Generate today's standup digest.",
  "is_active": true
}

For WEBHOOK triggers, the 201 response includes an hmac_secret_plaintext that is not retrievable later. Store it on creation.

3. The skills layer: composable, declarative, skill-card-driven

The thing that ties Work + MiniApp + Schedule together is the skills layer. A skill is a declarative unit (SKILL.md + optional scripts) that defines inputs, outputs, estimated cost, and a procedure for an agent to follow. Skills compose: a meta-skill like zeeren-overseas-retention calls zeeren-goal-decomposer, which fans out into content, concern-triage, and attribution skills.

From a developer perspective, a skill card looks like:

inputs:
  - name: brief
    type: string
    required: true
outputs:
  - name: channel_drafts
    output_type: draft_action
    action_type: "publish_<channel>_post"
estimated_cost_usd: 0.12
estimated_duration_seconds: 45

Skills target either a WORK_DOMAIN agent (flexible reasoning, tool access) or a deterministic SKILL runner (fixed procedure, no LLM calls beyond the skill's own prompts). Schedules can invoke either.

The skill model makes it straightforward to build reliable automated workflows without wiring together microservices — the platform handles routing, retries, and output persistence into the Work's resource tree.

Getting started

The three moving parts — Works, MiniApps, and Schedules — are enough to build most internal tooling. Start with the unified provision endpoint to scaffold your app, use APPEND_NODE schedules to run recurring tasks inside the same Work context, and use skill cards to define the agent procedures your schedules will invoke.

The legacy 14-action surface is still there if you're maintaining an older Work, but new development should default to the unified API.

HappyCapy ships skill-share analytics, contributor leaderboards & one-click install for Claude agents

Lin Zhu — Tue, 12 May 2026 03:47:56 +0000

What HappyCapy is (30-second version)

HappyCapy is a marketplace for Claude Skills — composable units of agent behavior you can drop into any Claude-powered app. Think npm for agent reasoning patterns, but with first-class Anthropic SDK integration.

This week we shipped three things: skill-share analytics, a contributor leaderboard, and a one-click installer. Here's what each means for you as a builder.

One-click skill adoption

Previously, adding a community skill to your agent meant copying boilerplate, wiring up the tool manifest, and hoping the author's README was accurate. The new installer does all that in one call:

import anthropic
from happycapy import install_skill

skill = install_skill("web-search-summarizer", version="1.2.0")

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1024,
    tools=skill.tools,           # auto-wired tool definitions
    system=skill.system_prompt,  # author's tested system prompt
    messages=[
        {"role": "user", "content": "Summarize the top 3 AI papers from last week."}
    ]
)
print(response.content)

skill.tools and skill.system_prompt are pre-validated against the Anthropic tool-use spec. If the skill author updates to a new schema format, the installer adapts on the fly — your call site stays unchanged.

Skill-share analytics

As a consumer, you can now see how a skill performs in the wild before you adopt it. The dashboard surfaces:

Invocation counts — how often the skill's tools are called across all installs
Error rate by model — whether the skill behaves differently on Haiku vs Sonnet vs Opus
Latency p50 / p95 — useful when a skill sits in a latency-sensitive path
Token usage histogram — reason about cost before you commit

As an author, the same data flows into your contributor dashboard. You can see which tools are actually invoked, where users drop off, and which model tiers trigger the most errors.

Claude's tool-use behavior varies subtly across model tiers. A skill that's solid on Opus can hit edge cases on Haiku. Analytics makes that visible before it bites you in prod.

Contributor leaderboards

The leaderboard ranks contributors by a composite score: installs, 30-day retention, and community ratings — not raw download counts.

High-retention skills tend to be the ones that actually work in production rather than just demos that look sharp in a README. The leaderboard surfaces those.

For contributors, it creates a concrete feedback loop. High installs but low retention means something is wrong with the out-of-the-box experience — more actionable than a vague thumbs-down.

Skills compose

Skills are designed to layer. The installer supports loading multiple skills and merging their tool manifests:

from happycapy import install_skill, merge_skills

search = install_skill("web-search-summarizer")
memory = install_skill("persistent-memory")

combined = merge_skills(search, memory)

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2048,
    tools=combined.tools,
    system=combined.system_prompt,
    messages=[...]
)

merge_skills handles tool name collisions and system prompt merging with a priority stack — last skill listed wins on conflicts. Inspect combined.manifest to see the resolved state before you run anything.

What's next

Skill versioning with semantic diff (see exactly what changed between v1.1 and v1.2 before upgrading) and a local test runner that replays real invocation traces against a new skill version.

If you're building Claude agents and want to stop copy-pasting tool boilerplate, check it out: https://happycapy.ai. Free to browse; publishing requires an account.