Install any skill in seconds. Free to start, no credit card required.
Get Started Free →meta_skill (ms) — the skill-search/load
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 65% | 0% |
| case-02 | ✗→✓ | ▲ Improved | -33% | 0% |
| case-04 | ✗→✓ | ▲ Improved | 731% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 113% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 58% | 0% |
<!-- TOC: Core Insight | Constraints | Quick Start | Consume (MCP) | Write/Admin (CLI) | Output | Production Skill Handoff | Footguns | Concurrency | Scenarios | Quality | References -->
> Core Insight: ms is the skill-search engine over both configured corpora (agentops + jsm). Consume via MCP, write/admin via CLI. One law: after ANY reindex/wipe, every running ms mcp serve MUST be killed (sessions respawn fresh). A surviving server silently reads pre-wipe data and returns recorded:true on writes that land in orphaned files.
full: true or --full when the intent is to execute a skill, because metadata cards and packed overviews omit runnable guidance.mcp__ms__* tools are unavailable, use the skill-local one-shot MCP helper for search. A zero-result ms search CLI response is not evidence that MCP BM25 found no match and must not silently substitute for it.scripts/ms-reindex.sh, because it sweeps stale servers and proves source equivalence after rebuilding the index.skills/**.ms retrieval-only for production skill work. It returns search and loadresults; the caller owns authoring, validation, and every subsequent decision.
Find a skill (MCP-primary — BM25, currently strictly better than CLI search), then load the FULL runnable SKILL.md in one call (always full: true when you mean to use it):
bashmcp__ms__search {query: "handle a rate limit switching accounts"} mcp__ms__load {skill: "account-rotation", full: true}
No attached MCP tool: start one disposable stdio server, return only the structured search JSON, and reap it on success, error, or timeout:
bashpython3 skills/ms/scripts/mcp-search.py "switch accounts on rate limit" ms load account-rotation --full -O json | jq -r '.data.content'
State root: ~/Library/Application Support/ms/.
mcp__ms__*)Prefer the MCP tools whenever a ms mcp serve is attached — they are the fast, verified read path.
| Tool | Use | |------|-----| | mcp__ms__search {query} | BM25 search. Currently strictly better than CLI search (see Footguns — CLI hybrid is BM25-only; ms never stores doc embeddings). | | mcp__ms__load {skill, full: true} | Returns the full runnable SKILL.md in ONE call, zero extraction friction. full: false returns a useless metadata card — always full: true when you intend to use the skill. | | mcp__ms__show {skill} | Metadata card for a skill. | | mcp__ms__suggest {cwd} | Suggests skills for a directory. Works — but ignore its project-language detection (misdetects Makefile repos as C; cosmetic only). |
No attached MCP tool: use the server-backed one-shot helper so retrieval still follows the MCP BM25 path:
bashpython3 skills/ms/scripts/mcp-search.py "<query>"
The helper writes a clean search object (query, count, results) to stdout, reports transport/protocol errors on stderr, applies a 30-second timeout by default, and owns the disposable server process group through termination and reap. Override its executable with MS_BIN and its timeout with MS_MCP_SEARCH_TIMEOUT or --timeout.
The CLI remains the supported full-load fallback after search:
bashms load <id> --full -O json | jq -r '.data.content' # content lives in .data.content
Do not replace the helper with ms search. The CLI path is useful only for diagnostics while its retrieval parity gap remains; in particular, zero CLI results do not prove the corpus has no matching skill.
The MCP feedback tool exists, but only the CLI write path is verified to land — trust the CLI for writes.
bashms feedback add <skill> --positive --comment "..." # feedback on a skill ms feedback add <skill> --negative --comment "..." ms outcome <skill> --success # record only AFTER downstream factory use + validation ms outcome <skill> --failure ms doctor # admin: health scripts/ms-reindex.sh # (re)index THE way: rebuild + sweep + probe + source-equivalence check scripts/ms-reindex.sh --check-source # read-only freshness proof against current skills/** source # Optional operator policy only; rebuild completeness is derived from live # discovered/indexed/errors accounting, not a historical absolute count: MS_REINDEX_MIN_INDEXED=100 scripts/ms-reindex.sh ms list -O jsonl --limit 1000 # counting / enumeration ms config # resolved config + skill_paths
stdout; durable index state remains under ~/Library/Application Support/ms/..data.content for ms load --full -O json.skills/ms/scripts/validate.sh for the retrieval boundary and scripts/ms-reindex.sh --check-source for normalized source equivalence.Production-intent handoff: When the query concerns creating or editing a skill, ms retrieves relevant guidance and stops. The caller may separately invoke skill-builder (create, heal, or audit mode) or another authoring tool.
Authority boundary: skills/** is canonical source; the generator owns the ms Codex twin and other projections. Never edit the index, loaded copies, or generated projections as source.
ms never validates or interprets downstream work. A failed search, load, write, or reindex is returned as evidence and ends this invocation.
Outcome timing: Record ms outcome only after the caller has independent evidence about downstream usefulness, never after retrieval alone. That observation does not change core state.
| Footgun | Truth | |---|---| | MCP server survives a DB wipe/reindex | An ms mcp serve NEVER reopens handles — it follows renamed inodes into the backup, giving stale reads AND silent misdirected writes (recorded:true into orphaned files). Reindex via scripts/ms-reindex.sh — THE way to reindex (rebuilds, proves every live-discovered skill was indexed or reported as an allowed error, TERMs every server, probes a fresh server, then compares normalized local loads with current skills/** source); never run bare ms index and leave servers up. Sessions respawn fresh. | | ms load --pack N | Trap: caps at the gutted overview tier for ANY N (800 == 20000) — drops the executable steps and returns LESS than the no-flag default. Use --full (CLI) or full: true (MCP). | | -O plain | Prints name-only on load; truncates list output ([N more lines]). The content lives in -O json → .data.content. | | CLI ms search "hybrid" | Effectively BM25-only — ms never stores doc embeddings (upsert_embedding is called only from a unit test), so hybrid ≡ BM25 under ANY backend; no config/backend change fixes it (upstream gap, feature-noted; measured 2026-07-02, age-s3jf). It can return zero while MCP BM25 returns ranked matches. Without attached tools, use scripts/mcp-search.py; never treat zero CLI results as a successful MCP fallback. | | Stale ms.lock | ms doctor prints "Lock held" for a DEAD pid yet still says all-pass. A dead-pid lock is safe to delete. | | Symlinks | ms does NOT follow directory symlinks — skill_paths must list BOTH roots explicitly: the ~/.codex skills dir AND the ~/dev/agentops/skills repo dir. | | Binary | Source build only (~/dev/meta_skill, branch local/frontmatter-id); the 0.1.2 release binary corrupts IDs on Anthropic-frontmatter skills. Update: git fetch && git rebase origin/main && cargo install --path . --locked. |
Parallel CLI + MCP load measured clean — no lock errors. The lock hazard is the survive-a-wipe case above (kill the serve), not concurrent reads.
gherkinScenario: Load a skill's full runnable guidance Given an ms mcp serve is attached When I call mcp__ms__load {skill: "account-rotation", full: true} Then the full runnable SKILL.md content is returned in one call Scenario: Search without an attached MCP tool Given mcp__ms__search is unavailable When I run python3 skills/ms/scripts/mcp-search.py with the query Then it returns only structured MCP search JSON And its disposable ms mcp serve process is reaped on success, error, or timeout Scenario: Reindex invalidates every running server Given one or more ms mcp serve processes are running When I run ms index (or wipe/rebuild the DB) Then I kill every ms mcp serve so sessions respawn against fresh data And a surviving server would silently read pre-wipe data and mis-land writes Scenario: A stale local projection fails closed Given AgentOps skills are authoritative and ms is a disposable local index When a full ms load has a different normalized name or description from source Then scripts/ms-reindex.sh exits nonzero and names the stale skill
ms after retrieval; generated twins and loaded/indexed copies are never hand-edited as source.ms outcome records observed usefulness only after independent downstream evidence.meta_skill (source at ~/dev/meta_skill, branch local/frontmatter-id).cass (session archaeology). The jsm cass-memory (cm) procedural-memory tool is the write-side complement (installed separately, not in this repo).scripts/validate.sh.| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→pass | 11,315 | 5,592 | -51% | 1 | 1 | 0% | 1,852 | 3,048 | +65% | 0 | 0 | — |
case-02 | fail→pass | 26,447 | 1,544 | -94% | 1 | 1 | 0% | 4,396 | 2,927 | -33% | 0 | 0 | — |
case-03 | fail→fail | 5,641 | 6,921 | +23% | 1 | 1 | 0% | 860 | 3,111 | +262% | 0 | 0 | — |
case-04 | fail→pass | 2,589 | 2,701 | +4% | 1 | 1 | 0% | 379 | 3,151 | +731% | 0 | 0 | — |
case-05 | pass→pass | 3,556 | 2,902 | -18% | 1 | 1 | 0% | 571 | 3,269 | +473% | 0 | 0 | — |
case-10 | pass→pass | 4,088 | 3,214 | -21% | 1 | 1 | 0% | 626 | 3,215 | +414% | 0 | 0 | — |
case-06 | fail→pass | 10,220 | 3,970 | -61% | 1 | 1 | 0% | 1,613 | 3,443 | +113% | 0 | 0 | — |
case-07 | fail→pass | 12,626 | 3,137 | -75% | 1 | 1 | 0% | 2,056 | 3,257 | +58% | 0 | 0 | — |
case-08 | fail→pass | 14,173 | 4,566 | -68% | 1 | 1 | 0% | 1,386 | 3,519 | +154% | 0 | 0 | — |
case-09 | fail→pass | 5,543 | 4,678 | -16% | 1 | 1 | 0% | 826 | 3,459 | +319% | 0 | 0 | — |
case-11 | pass→pass | 9,664 | 4,902 | -49% | 1 | 1 | 0% | 1,741 | 3,485 | +100% | 0 | 0 | — |
case-12 | fail→pass | 8,821 | 3,984 | -55% | 1 | 1 | 0% | 1,361 | 3,410 | +151% | 0 | 0 | — |
case-13 | fail→pass | 8,453 | 4,396 | -48% | 1 | 1 | 0% | 1,266 | 3,388 | +168% | 0 | 0 | — |
case-14 | fail→pass | 11,676 | 2,799 | -76% | 1 | 1 | 0% | 1,793 | 3,105 | +73% | 0 | 0 | — |
case-15 | fail→pass | 12,053 | 3,491 | -71% | 1 | 1 | 0% | 2,212 | 3,341 | +51% | 0 | 0 | — |
case-16 | fail→pass | 10,933 | 5,176 | -53% | 1 | 1 | 0% | 1,583 | 3,518 | +122% | 0 | 0 | — |
case-17 | fail→pass | 20,556 | 4,107 | -80% | 1 | 1 | 0% | 1,121 | 3,399 | +203% | 0 | 0 | — |
case-18 | pass→pass | 7,128 | 3,123 | -56% | 1 | 1 | 0% | 1,336 | 3,188 | +139% | 0 | 0 | — |
case-19 | fail→pass | 7,915 | 1,862 | -76% | 1 | 1 | 0% | 1,238 | 2,990 | +142% | 0 | 0 | — |
case-20 | pass→fail | 14,747 | 7,460 | -49% | 1 | 1 | 0% | 2,720 | 3,163 | +16% | 0 | 0 | — |
case-21 | pass→fail | 7,410 | 5,638 | -24% | 1 | 1 | 0% | 1,272 | 3,097 | +143% | 0 | 0 | — |
case-22 | pass→pass | 4,347 | 3,279 | -25% | 1 | 1 | 0% | 752 | 3,249 | +332% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 18 counted toward the lift figure. The other 4 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +55 percentage points is the difference between those two pass rates over the 18 comparable cases. 3 cases got worse with the skill loaded, and they are included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.