Skip to main content

​
Overview

Beacon Skills are Agent Skills that let an agent in any harness run Beacon’s cross-harness memory loop. An agent working in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, or another supported harness can use them to recall what earlier sessions learned about a repository. It can also turn a recent session into a reviewed lesson, and promote that lesson into a skill the whole team loads. The skills do not replace Beacon’s capture or review model. They tell the agent which beacon commands to run and when to stop and ask. They keep the person reviewing in control of every write to memory.

​
Requirements

  • The Beacon CLI on PATH, with endpoint capture installed so traces exist. See the quickstart.
  • For beacon-memory-distill only: an evaluator key in TYPESAFE_API_KEY or BEACON_JEV_API_KEY, or BEACON_JEV_ENDPOINT pointing at your organization’s compatible evaluator. Recall and promote need no key.
The plugin also registers Beacon’s local MCP server (beacon mcp serve) in harnesses that accept MCP servers from plugins. When the server is available, recall uses the get_memory_context tool. Otherwise it falls back to beacon memory list.

​
Install

Beacon Skills install from the asymptote-labs/agent-beacon repository. Most harnesses read its plugin marketplace directly: Plugin installs also register Beacon’s local MCP server. Package, power, and skills installs add the skills only, and recall falls back to beacon memory list. In Claude Code the skills appear as /beacon:beacon-memory-recall, /beacon:beacon-memory-distill, and /beacon:beacon-memory-promote. Every harness also loads them on its own when a request matches.

​
Using the skills

You rarely name a skill. Each one describes when it applies, and the harness loads it when your request matches.
1

Recall before work

Starting a non-trivial task, or hitting a failure that might have a known fix, triggers beacon-memory-recall. The agent retrieves up to five approved memories for the current repository. When one changes what it does, it cites the memory’s ID. It treats memory as lessons from earlier sessions, not as policy. When a memory conflicts with your instructions or the repository’s docs, the agent follows you and the docs and says so.
2

Distill a session into memory

Ask something like “turn yesterday’s packaging fix into memory” or “review the Beacon memory candidates”. beacon-memory-distill then:
  1. Selects the traces you named, or proposes a short list.
  2. Runs beacon memory evaluations run --dry-run and shows the selection and estimated cost.
  3. Asks before the evaluation call, and runs it only on the selection you approved.
  4. Reads the source trace behind each candidate and drafts a lesson: title, kind, applicability, and body, each tied to the trace events that support it.
  5. Shows every draft with a recommendation to approve, reject, or supersede, and records only the decisions you confirm.
3

Promote memory to a skill

Ask to “make this a skill”. beacon-memory-promote previews the generated skill, checks it for anything that should not be committed, and installs it at .agents/skills/<slug>/SKILL.md once you confirm. Committing it shares it with every teammate and every harness that reads .agents/skills.

​
Why the agent writes the lesson

The evaluator returns probabilities, such as how likely the task succeeded and how likely the trace holds a reusable lesson. It does not return lesson text. On its own, an approved candidate would say only that no lesson text was extracted. beacon-memory-distill closes that gap. The agent reads the trace, writes the lesson, and you approve it with the reviewed text:
The approved memory stores your text. The candidate keeps the evaluator’s original, so the review history shows what changed. See beacon memory for every flag.

​
Privacy and control

  • Nothing runs from hooks. The skills act only when an agent loads them in response to a request.
  • One networked step. Only the evaluation in beacon-memory-distill leaves the machine, after a dry run and your explicit yes. It sends the bounded, redacted trace projection described in Jev evaluation.
  • Keys stay out of the chat. The agent checks whether a key is set without printing it, never asks you to paste one, and never passes it on the command line.
  • No silent writes. Approving, rejecting, superseding, and installing a skill each need your confirmation.
  • Memory is shared, so it stays clean. Lessons must not contain secrets, tokens, credentials, internal hostnames, customer data, or personal details, even when the trace does.

​
Publishing and source

The skills live in agent-skills/ in the Beacon repository. One skills/ directory serves every harness through its own manifest: .claude-plugin/plugin.json for Claude Code, an Agent Plugins plugin.json for Codex, Copilot, VS Code, Kiro, and Devin, .cursor-plugin/plugin.json for Cursor, kimi.plugin.json for Kimi Code, and gemini-extension.json for Gemini CLI. At the repository root, .claude-plugin/marketplace.json is the marketplace most harnesses read, .cursor-plugin/marketplace.json is Cursor’s, and package.json makes the repository a Pi and Prime Agent package. A test in the CLI checks every beacon command and flag the skills mention, so a change that renames one fails the same pull request.

Cross-harness memory

How traces become reviewed project memory.

beacon memory

Evaluate traces, review candidates, and install skills from the CLI.

beacon mcp

Serve approved memory to MCP clients.

beacon endpoint traces

Browse and search the traces the skills read.