anbaric 1.69.0 → 1.71.0

package/docs/README.md

@@ -28,6 +28,7 @@ What the framework gives you, one capability at a time.
 - [File storage](features/file-storage.md) — bytes at a path, local or in your tenant's storage
 - [Auditing](features/auditing.md) — the record of who changed what
 - [Entitlements](features/entitlements.md) — what a user has been granted, checked per request
+- [Skills](features/skills.md) — guidance your builders write for the agents working on your tenant
 - [Prompts](features/prompts.md) — versioned model instructions and schemas, saved at startup
 - [Serving a web UI](features/serving-a-web-ui.md) — putting your data on a page
 - [The admin console and widgets](features/admin-console-and-widgets.md) — dashboards and plugins

package/docs/features/admin-console-and-widgets.md

@@ -64,6 +64,13 @@ hardcoding styles.
 > components in separate files, or import server modules only inside the data
 > function.
 
+## Skills
+
+One console page is for the agents rather than the people: **Skills**, where a
+builder writes guidance - when to use it and what to do - that the Anbaric MCP
+offers to every agent working on the tenant as a tool of its own. See
+[Skills](skills.md).
+
 ## Turning plugins on
 
 `ANBARIC_PLUGINS` is a comma-separated list of plugin modules. Setting it

package/docs/features/entitlements.md

@@ -65,6 +65,17 @@ Apps can't grant. An administrator opens **Entitlements** in the console, picks
 the user, the entitlement and its scope, and adds a note; the same page revokes
 grants and creates global entitlements. Every grant records who made it.
 
+## Invitations and invite links
+
+Entitlements can be chosen when someone is invited, before they have signed
+in: an invitation by email holds them against that address and grants them the
+first time the person signs in. An **invite link** does the same for whoever
+opens it. An owner or admin creates one on the Users page, choosing how many
+people may use it, the role they join as, and the entitlements they receive;
+each person who opens the link and signs in becomes a member with exactly
+those, and the link counts down until it is used up or revoked. Anyone holding
+the link can join, so it is for sharing with the people you mean to invite.
+
 ## Locally
 
 There's no console on your laptop, so the local implementation is

package/docs/features/skills.md

@@ -0,0 +1,48 @@
+# Skills
+
+An agent building on your tenant learns the platform from these docs, which
+are the same for everyone. What they cannot tell it is what *your* tenant has:
+a service you run, a convention your team follows, an internal system an app
+should call a certain way. A **skill** is how you tell it. It is a short piece
+of guidance a builder writes once, in the console, and every agent working on
+the tenant through the Anbaric MCP sees from then on.
+
+## What a skill is
+
+A skill has four parts:
+
+| Field | What it is for |
+|---|---|
+| **id** | A short slug (lower-case letters, digits and hyphens, up to 50 characters). It becomes part of the tool's name. |
+| **title** | How the skill is named to people and to the agent. |
+| **usage hints** | *When* an agent should reach for it. This is what the agent reads before deciding, so say what task or situation the skill applies to. |
+| **body** | *What* to do: the instructions themselves. The agent reads this only once it has decided the skill applies. |
+
+Keep the hints short and specific - "Read before fetching an external web page
+or file from an app" - and put the detail in the body: endpoints, headers,
+examples, the mistakes to avoid.
+
+## Where skills live
+
+The **Skills** page in the console lists the tenant's skills and lets a builder
+(owner, admin or builder role) add, edit and remove them. Anyone in the tenant
+can read them. Skills belong to the tenant, not to an app, and deployed apps
+cannot see them: they are for the people and agents working on the tenant, not
+for its runtime.
+
+A skill marked **Managed service** is written by Anbaric for a service your
+tenant has, such as the additional services, and kept current by us. It is
+offered to your agents like any other but is not yours to edit or remove.
+
+## How an agent sees them
+
+Each skill is offered to the agent as a tool named `anbaric_skill_<id>` (hyphens
+in the id become underscores), whose description is the skill's title and usage
+hints. That is all the agent sees up front, which is how it decides relevance
+without reading everything. Calling the tool returns the body. A skill added or
+changed in the console appears the next time the agent's tools are listed,
+and straight after `anbaric_login`.
+
+Skills are not a replacement for these docs; they are the layer on top that is
+yours. An agent is told to read the skills whose hints match its task before
+building, and to prefer what they say where the two differ.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "anbaric",
-  "version": "1.69.0",
+  "version": "1.71.0",
   "description": "Everything needed to write an Anbaric app: state machines, jobs, document and secret stores, local in-memory implementations and the Anbaric Cloud clients",
   "license": "MIT",
   "type": "module",
@@ -24,9 +24,9 @@
     "prepublishOnly": "npm run build"
   },
   "dependencies": {
-    "anbaric-impl-cloud": "^1.69.0",
-    "anbaric-data-store": "^1.69.0",
-    "anbaric-state-machine": "^1.69.0",
-    "anbaric-tsapi": "^1.69.0"
+    "anbaric-impl-cloud": "^1.71.0",
+    "anbaric-data-store": "^1.71.0",
+    "anbaric-state-machine": "^1.71.0",
+    "anbaric-tsapi": "^1.71.0"
   }
 }