Capability packs

A capability pack is a governed, signed unit that grants a session a capability — an engineering method, an output optimizer, a guardrail, a tool. Packs are authored and signed in the enterprise panel and cascade global → team → workspace → session, the same way governed connections and context do. Teams get the good stuff on by default, not hand-installed per developer.

How packs are governed

Every pack is an entry in the signed catalog. Two fields define it:

• kind — what it is: mcp, skill, tool, optimizer or framework.
• runs_at — where it executes:
  • context — injected into the agent’s managed context layer at session start (skills, methods, conventions). Highest precedence, never committed to your repo.
  • broker — runs inside the local proxy the agent already talks to; the agent keeps seeing only 127.0.0.1.
  • adapter — materialized into the session’s sandbox (files or a vetted CLI on PATH inside the worktree), with every command audited.

The rules are the same as for every governed capability in Chronos:

• Packs come only from the signed catalog. An unsigned pack or one with an invalid signature is rejected, never silently degraded — and packs can’t be added locally.
• Anything that requires a network install is approval-gated and pinned by digest.
• Pack features that would move data across teams or sessions are forced off by policy.
• Which packs, versions and catalog version each session loaded is recorded in the audit trail.

Built-in packs

Chronos ships three packs by default. Like everything in the catalog, they can be scoped, overridden per team, or revoked from the panel.

Kairos

The governed method-skill pack: five software-engineering disciplines a model does not reliably apply on its own — Test-Driven Development, Verification Before Completion, Writing Plans, Brainstorming and Systematic Debugging. A skill pack that runs at context: the always-relevant disciplines are applied to every session, while situational ones are indexed and fetched on demand (see Memory & retrieval).

Tempo

The output/token optimizer (pack id tempo, kind: optimizer, runs_at: adapter). Tempo wraps the agent’s dev commands inside the sandbox and compresses their output — 60–90% fewer tokens — before it reaches the agent’s context. The audit trail always keeps the real, pre-compression output. Built from source, digest-pinned, telemetry-free and with no network access; enabling it routes through the approval gate because it involves an install.

Pulse

The reuse-first code-minimalism guardrail (pack id pulse, kind: skill, runs_at: context). Pulse keeps agents from over-building: YAGNI, reuse before rewrite, standard library before new dependencies. Less code means less to review — a direct fit for verified, review-ready output. Pure governed text: no runtime, no network, no secrets.

The Capabilities tab

Each session has a Capabilities tab in the right pane, next to All files · Changes · Checks. It answers one question: what is active in this session, and why. Rows are grouped by where the pack runs, and each row shows the pack’s kind, runs_at, scope (global / team / workspace), version and any approval gate.

A pack’s toggle has three states:

State	Appearance	Meaning
Governed / locked on	brand-colored, with a lock	Inherited from the global or team catalog; non-overridable. Clicking it explains that it’s managed in the panel.
Enabled by you	green	A pack policy lets this session toggle. Turning it off is audited.
Off / available	grey	Available but not enabled here.

You can tell governance from personal choice at a glance: brand means the organization turned it on; green means you did.

Approval gates. A pack whose source is a network install (such as Tempo’s binary) carries an approval · digest-pinned badge. Toggling it on queues an approval instead of enabling silently.

Per-session toggles only ever apply to packs the policy marks overridable — a governed lock can never be overridden from the app. Authoring packs, signing them, setting defaults and rolling back a bad version are panel operations; the app consumes, shows and invokes.

Signals in the agent stream

Ambient packs make their effect visible where you read the agent’s work:

• Pulse tags the agent’s thinking line (“reuse-first guardrail active”).
• Tempo tags the shell tool calls it compressed (via Tempo · output −84%, with raw → compressed token counts). The tag is a hint — the audit keeps the full output.
• A governed connection tags its calls broker · 127.0.0.1 · audited, confirming the agent never saw the real endpoint or a secret.

Invoking capabilities on demand

Ambient packs are on or off; other capabilities are commands you fire. The command palette (⌘K, or type / in an empty composer) lists them, grouped by source:

• Verification — the vetted, committed scripts from .chronos/settings.toml (/verify, /test, /qa, /pentest). Only named scripts appear; there is no free-text execution.
• Connection actions — discrete actions backed by a governed connection (for example jira: create issue). They go through the local broker like everything else.
• Skills — commands a context pack exposes.

Approval-gated commands show a warning and queue an approval instead of running immediately. Every run is sandboxed and audited.