Library

The legacy /library route still exists in the app, but it no longer owns one standalone surface.

It now forwards to one of these current destinations:

• /agents/skills by default
• /agents/rules when the old link asked for the rules tab
• /agents/context when the old link asked for the context tab
• /settings#models when the old link asked for the models tab

Use those pages for the current product behavior.

Current mapping

If you are cleaning up old bookmarks or internal links, this is the mapping the app uses today:

• /library -> skills
• /library?tab=rules -> rules
• /library?tab=context -> context
• /library?tab=models -> models in Settings

Why the route still exists

Older navigation and saved links used /library as the entrypoint for shared skills, rules, context, and models.

Mogplex now splits that content between the Agents area and Settings, but the redirect remains in place so existing links do not break.

What the old Library concept became

The old Library idea has been split by responsibility.

Skills

Use Agents -> Skills for reusable behavior packs.

The current skills surface includes:

• a skills.sh registry browser
• a Vercel Docs importer for turning docs pages into local runbook-style skills
• a Local skills area for the skills you already have installed or created

Local skills are currently grouped by type:

• runbook
• tool
• prompt
• workflow

Rules

Use Agents -> Rules for global rule files that constrain or guide agent behavior.

This surface is file-oriented:

• create markdown rule files
• open and edit existing ones
• delete stale ones

Think of Rules as account-level instructions you want multiple agents to share.

Context

Use Agents -> Context for memory and reusable context records.

The current context surface is organized into four lanes:

• Session for the active working set
• Semantic for durable facts and preferences
• Episodic for timeline events and milestones
• Procedural for workflows and runbooks

You can search, add, delete, compact, and checkpoint memories there, and the surface scopes to the current repo or workspace session when that context is available.

Models

Use Settings -> Models for account-level model availability and defaults.

That is where you:

• enable or disable models
• choose the default model for new agents and new automation nodes

That default is only the starting point. Existing agent overrides and automation-node overrides still win over the account default.

How to think about it now

The old Library concept has been split by job:

• use Agents for reusable behavior such as skills, rules, and shared context
• use Settings for account-level model enablement and default selection

That split matches how the product works now: agent-building artifacts live with the roster, while model selection lives with the rest of your hosted configuration.

Rule of thumb

If the thing you are editing changes what agents know or how they behave, it belongs under Agents.

If the thing you are editing changes which models are available or what new agents default to, it belongs under Settings.