MemClaw / docs
Skill Factory

Skills Inbox

The human-in-the-loop review queue for staged skills — the card an operator sees, the five actions, and how to recover a quarantined skill.

The Skills Inbox is where a staged skill waits for a human decision before it goes live. Both Forge candidates (after they clear the gates) and direct agent writes land here. Until someone acts, the skill is not delivered to any agent.

The Inbox is an admin surface under POST/GET /api/v1/skills-inbox/. Every endpoint returns SKILLS_FACTORY_DISABLED if the tenant hasn't opted in.

If you've set skills_factory.sentinel.auto_promote_clean = true, clean fully-gated Forge candidates bypass the Inbox and go straight to active — the Inbox then only holds candidates that need attention (warnings, direct agent writes, edits).

The card

GET /api/v1/skills-inbox/ returns the staged skills for a tenant (filter by fleet_id; capped by skills_factory.inbox_max_pending). Each item is an InboxCard — enough to make a decision without leaving the queue:

FieldWhat it tells you
name, description, summaryWhat the skill is and when it should fire.
domain, tags, kindGrouping; create vs update.
sourceforge (auto-mined), agent, or manual.
scan_state, scan_critical, scan_warnSentinel result — clean with zero criticals is required to approve.
origin, evidenceFor Forge cards: the cluster (size, distinct agents, window) and the traces behind it.
fingerprintThe cluster fingerprint (drives poison/dedup).
content_hash, created_at, deferred_atProvenance + queue position.

The five actions

ActionEndpointBodyEffect
ApprovePOST /{slug}/approveRe-scans, then staged → active only if the scan is clean — the skill goes live (pull + push). A non-clean re-scan is refused (422) and the skill stays staged; fix it with Edit.
EditPOST /{slug}/edit{ content?, description?, summary? }Revise in place; re-hashes and re-scans; stays staged for a fresh decision.
RejectPOST /{slug}/reject{ reason, cooloff_days? }staged or quarantinedrejected; poison-flags the fingerprint for a cool-off (defaults to skills_factory.rejection_cooloff_days) so Forge won't immediately re-mint it.
QuarantinePOST /{slug}/quarantine{ reason }staged → quarantined; held out of delivery for investigation.
DeferPOST /{slug}/defer{ reason? }Leaves it staged; stamps deferred_at to push it down the queue.

Approve/reject/quarantine return an ActionResponse with previous_status and the new status, so the transition is auditable.

Typical workflow

  1. Triage the queue. Sort by scan_state — anything not clean needs a closer look. For Forge cards, check origin/evidence to see how strong the cluster is.
  2. Approve the good ones — they go live immediately.
  3. Edit a promising-but-rough skill (tighten the summary, fix the content); it re-scans and stays staged so you can approve the revision.
  4. Reject noise with a reason — the cool-off stops Forge re-proposing the same cluster right away.
  5. Defer anything you're unsure about to revisit later.

Recovering a quarantined skill

A quarantined skill (Sentinel flagged a critical, or you quarantined it manually) is held out of delivery. Approve and Edit operate only on staged skills, so you can't fix a quarantined skill in place or force it live past a critical scan — the one Inbox action available on it is Reject (which also poison-flags the cluster fingerprint for a cool-off). To ship a corrected version, publish a fixed skill afresh, or let Forge re-propose a clean candidate once the cool-off lapses. (Direct quarantined → staged recovery is planned lifecycle work.)

Where to look in the source