manage-notes
GitHub管理笔记的增删改移操作，强制所有写入先暂存供用户审核，防止误报完成。支持替换或撤回待审提案，确保编辑过程可控且可追溯。
触发场景
安装
npx skills add s2b-dev/smart-second-brain --skill manage-notes -g -y
SKILL.md
Frontmatter
{
"name": "manage-notes",
"metadata": {
"author": "S2B",
"version": "1.1",
"category": "core"
},
"description": "Create, update, delete, and move notes. All writes are staged for the user's review — never say a change has already been applied. Load this before performing any write operation; it holds the staging policy and edit conventions.",
"allowed-tools": "manage_notes"
}
Write Operations
- All write operations (create, update, delete, move) are staged for user approval. Never say a change has already been applied.
- Exception: writes inside your memory folder apply immediately and the result reports them as applied; describe them that way.
- Modify only what the user asked for and preserve surrounding content.
- Prefer batching related write operations so the user can review them together.
- Prefer targeted edits over full rewrites unless a full rewrite is clearly necessary.
Correcting an Edit You Already Staged
Staged changes wait for the user's review, so you can still revise them — but by default a new edit to the same note adds to your pending proposal rather than replacing it. The user then sees both edits. When the user is correcting you ("no, at the bottom", "actually make it X"), say which you mean:
- Replacing your own pending edit — re-stage the update with
"replace_pending": true. Your earlier proposal is dropped and only the new edit is reviewed. - Withdrawing an edit entirely — use a
discardoperation with the proposal'sid. It stages nothing and applies nothing; it just takes your proposal out of the review queue.
Every staged proposal is reported with an id, both when you stage it and in the
status block listing changes still awaiting review. discard takes that id, not
a path — one path can name more than one proposal, so a path cannot say which you
mean. Use an id you were actually given; never invent or guess one. If the tool
says no proposal has that id, the user has probably already reviewed it — say so
rather than implying you withdrew something.
- Genuinely adding a second, separate edit — change nothing; the default merge is what you want.
Never tell the user a new proposal replaces or supersedes an earlier one unless
you used replace_pending or discard. If the tool result says a proposal
contains both rounds of edits, describe it that way. Once the user has accepted a
change you cannot take it back — say so rather than implying you undid it.
版本历史
-
2.2.0
当前 2026-09-22 02:53
新增对记忆文件夹内写入操作的例外处理规则：允许直接应用并报告；明确修正已暂存编辑时的三种行为（替换、撤回、追加）及对应操作方法。
- 2.0.5 2026-09-08 21:10
