ANOLISA is a server-side operating layer for AI agent workloads that provides terminal access, token-saving tool-output compression, runtime controls, security, observability, skills, memory, and sandbox management. It is for running and supervising agents from a Linux terminal while retaining an existing shell, agent framework, and sandbox. The catalogue add-ons are components of its agent operating environment and workflows.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/alibaba/anolisa/ws-ckptnpx skills add alibaba/anolisa --skill ws-ckptgit clone --depth 1 https://github.com/alibaba/anolisaWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/alibaba/anolisa/ws-ckpt)<a href="https://agentmods.dev/skills/alibaba/anolisa/ws-ckpt"><img src="https://agentmods.dev/badge/skills/alibaba/anolisa/ws-ckpt.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00115 | $0.01673 |
| Opus 5 | $0.00057 | $0.00837 |
| Sonnet 5 | $0.00023 | $0.00335 |
| Haiku 4.5 | $0.00012 | $0.00167 |
Grade A, and why
ws-ckpt scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 157 lines — stays where its author put it; the contents beside it link to each section on GitHub.
ws-ckpt 工作区快照管理
基于 btrfs COW 快照,为任意工作区提供微秒级 checkpoint/rollback。
工作区路径(关键 — 必须遵守)
⚠️ 绝对禁止猜测或推断工作区路径。
ws-ckpt 的所有命令都需要 -w <workspace> 指定工作区路径。执行任何命令前,必须按以下顺序确定 -w 参数:
- 用户在当前消息中明确给出了路径 → 直接使用
- 否则 → 必须向用户询问:"请提供工作区路径(传给
-w的目录)",拿到回复后再执行
不得从环境变量、默认路径、或任何隐含上下文中猜测。
确定后,本次会话内复用同一个 workspace 路径,不要重复询问。
cwd 占用的拦截由 daemon 层统一处理,skill 不再做前置守卫。
触发规则
| 用户说 | 执行命令 | 说明 |
|---|---|---|
| "保存一下"、"存个快照"、"checkpoint"、"备份当前状态" | checkpoint |
创建快照 |
| "回滚"、"撤销"、"恢复到之前"、"rollback"、"改坏了" | rollback |
回滚到指定快照 |
| "对比快照"、"快照差异"、"diff"、"改了什么" | diff |
查看两个快照间的文件变更 |
| "删掉快照"、"清理快照"、"delete snapshot" | delete |
删除指定快照 |
| "看看快照"、"有哪些快照"、"list"、"列一下" | list |
列出快照 |
| "状态"、"空间"、"status"、"工作区怎么样" | status |
查看工作区状态 |
命令用法
checkpoint — 创建快照
ws-ckpt checkpoint -w <workspace> [-s <snapshot-id>] [-m <message>] [--metadata <json>]
-w:工作区路径(必填)-s:快照 ID(可选,省略时自动生成)-m:快照描述(可选)--metadata:附加 JSON 元数据(可选)
ws-ckpt checkpoint -w <path-to-workspace> -s before-refactor -m "重构前备份"
ws-ckpt checkpoint -w <path-to-workspace> # ID 自动生成
rollback — 回滚到快照
ws-ckpt rollback -w <workspace> [-s <snapshot> | -n <steps>] [--preview]
-w:工作区路径(必填)-s:目标快照 ID(与-n互斥)-n:沿父链回滚 N 步(与-s互斥)--preview:预览文件变更,不实际执行回滚
ws-ckpt rollback -w <path-to-workspace> -s before-refactor
ws-ckpt rollback -w <path-to-workspace> -n 1 # 回滚到上一个快照
ws-ckpt rollback -w <path-to-workspace> -s snap1 --preview # 仅预览
diff — 查看快照间差异
ws-ckpt diff -w <workspace> -f <from-snapshot> [-t <to-snapshot>]
-w:工作区路径(必填)-f:源快照 ID(必填)-t:目标快照 ID(可选,省略时与当前工作区状态比较)
# 两个快照之间的差异
ws-ckpt diff -w <path-to-workspace> -f before-refactor -t after-refactor
# 快照与当前工作区的差异
ws-ckpt diff -w <path-to-workspace> -f before-refactor
delete — 删除快照
ws-ckpt delete -s <snapshot> --force [-w <workspace>]
-s:要删除的快照 ID(必填)--force:跳过确认,agent执行必须要求跳过确认-w:快照 ID 跨工作区重复时必须指定
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 157 lines · 115 tokens per session scan A 1bc03aafbe77
ws-ckpt is a skill published in the GitHub repository alibaba/anolisa (618 stars, last pushed yesterday), licensed Apache-2.0. It adds 115 tokens to every session and 1,673 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
beevibe-team-mesh-negotiation
Multi-round negotiation protocol — covers both initiator and peer roles. Use when about to call negotiate(), when receiving a intent block as a peer, or when receiving an 'escalated' sentinel from a blocked respondnegotiate. Covers proposal crafting, counter-strategy, deadlock detection, when to accept early…
beevibe-verify-pr
CI verification before marking a PR-bearing task done. Use BEFORE calling mcpbeevibeupdateprogress(done) on any session whose deliverable is a pull request — including the first dispatch (you opened the PR with gh pr create) and any revision dispatch (you pushed new commits to an existing PR). Watches the PR's…
beevibe-pre-task-setup
Cold-start git workspace setup for a fresh beevibe task. Use at the start of a session whose intent has a block but NO or block — i.e. the first dispatch of this task. Checks for an existing repo clone, pulls the base branch if present (clone if missing), prunes any per-task worktrees from earlier tasks whose work has…
beevibe-use-repo
You are the child agent inside a fresh Docker sandbox. Borrow the given GitHub repo, produce a real artifact for the goal, and export it. Do not review the repo. The proof is that it works.
beevibe-discover-repo
Find the best GitHub repo for a goal, then call userepo to run it in a sandbox. Use whenever the user's goal requires a capability you don't have natively and you haven't been given a specific repo.
evaluate_positioning
Product Positioning Evaluation Framework.