Skip to main content

Build for Worka

Use this section when you are extending Worka.

That includes:

  • reviewing and refining packs that Forge generated
  • building packs by hand when you need full control
  • exposing tools through MCP
  • building views through A2UI
  • composing workflows from AI team members, hooks, tools, and host services

The important thing to understand up front is that you are not building for a blank plugin host. You are building for a runtime with:

  • tenant and workspace boundaries
  • a brokered security model
  • a release and attachment model
  • host-owned services such as worka.runtime, worka.ui, and worka.db
  • generated and human-authored capability living side by side

If your pack works locally but ignores those constraints, it is not ready for Worka.

How to read this section​

Use this order if you are new to the platform:

  1. Pack Fundamentals
  2. Manifest and Security
  3. Views and UI
  4. Tools and Backends
  5. Host Services
  6. Data and Workflows
  7. Testing and Publishing

That path starts with what a pack is, then moves through how it declares its contract, how it renders views, how it exposes tools, how it uses host capability, and finally how it is tested and published.

What “done” means for a builder​

A Worka extension is done when:

  • the capability is described clearly in aip.json
  • the tools are discoverable and structured
  • the view layer binds to real data and actions
  • the pack uses sanctioned host paths instead of bypassing them
  • the result can be built, published, attached, and invoked in a real workspace

That is the standard this section is written to.