mcpField
K
kk-add

kk-add

github.com/e0ipsoAgent 工作流3339 次安装1 周前更新
代码仓库

关于 kk-add

kk-add 是用于将用户提供的一条知识写入 Kenkeep 项目知识库的技能。它会先检查现有节点是否重叠，再起草并保存节点供审核。

主要功能

  1. 01向用户收集节点所需的七项信息
  2. 02检查现有节点是否重叠
  3. 03起草知识节点
  4. 04通过 Kenkeep CLI 写入节点
  5. 05支持可选的子 Agent 起草

适用场景

  1. 01记录项目特有的实践
  2. 02补充项目结构或概念的映射
  3. 03检查重复后捕获新知识

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/e0ipso/kenkeep --skill kk-add

安装后在 Claude Code 中输入/kk-add确认已加载。

详细介绍

kk-add

将一条知识记录到项目知识库中。你在本次会话中起草节点正文，并通过 node write 原语保存；审核者会审核磁盘上的文件。

向用户询问以下七项（不要自行编造）：kind（practice 或 map）、title（≤ 80 个字符）、summary（≤ 140 个字符）、tags（逗号分隔）、body（完整 Markdown；若为 practice，需包含理由）、relates_to（逗号分隔的节点 id，可为空）、confidence（high/medium/low，默认为 high）。

调用前，浏览 .ai/kenkeep/ENTRY.md（已在上下文中），并在 nodes/ 中搜索是否有重叠的节点。如果存在，向用户提出可选择编辑该节点、完善候选节点标题，或放弃记录。若候选内容属于以下任一类型，请提出异议：一看即明的代码、历史记录、调试步骤、进行中的计划或任务内容，或通用编程知识。

确定项目根目录

使用随附的检测器确定仓库根目录（即包含 .ai/kenkeep 的目录），然后将打印出的路径作为以下所有命令的工作目录：

KK_REPO_ROOT=$(node .ai/kenkeep/scripts/kk-detect-root.mjs) || exit $?
cd "$KK_REPO_ROOT" || exit $?
pwd

记录节点

探测并选择是否委派子 Agent（隔离上下文）

按照共享附录 .ai/kenkeep/.config/prompts/sub-agent-delegation.md（探测、回退规则），决定是否将正文起草工作委派给子 Agent（以隔离上下文），或在当前会话中起草。这是一次单单元委派——没有并行任务，也没有并发上限；这样做的目的仅仅是避免 Agent 的推理过程出现在主会话记录中。

如果探测结果表明存在调度原语：

  1. 生成一个 runId，并准备日志/草稿目录：

    RUN_ID=$(uuidgen 2>/dev/null || date -u +"add-%Y%m%dT%H%M%SZ")
mkdir -p .ai/kenkeep/_logs/kk-add
DRAFT_PATH="$(pwd)/.ai/kenkeep/_logs/kk-add/${RUN_ID}__1.draft.json"
LOG_PATH="$(pwd)/.ai/kenkeep/_logs/kk-add/${RUN_ID}.jsonl"
printf '%s\n' "{\"event\":\"delegating\",\"runId\":\"${RUN_ID}\",\"draftPath\":\"${DRAFT_PATH}\"}" >> "$LOG_PATH"

  2. 用一行话告诉用户：“正在通过子 Agent 起草此节点，以隔离上下文；如果你想查看 Agent 的完整推理过程，请参阅 .ai/kenkeep/_logs/kk-add/<runId>.jsonl。”将 <runId> 替换为实际的 runId。

  3. 委派给一个且仅一个子 Agent 起草节点正文，并提供等效于以下内容的指示：

    你正在为用户完善一个 kenkeep 节点正文。输入为：kind=<kind>、title=<title>、summary=<summary>、tags=<tags>、relates_to=<relates_to>、confidence=<confidence>、body-draft=<body>。将正文完善为 1–4 个简短段落，使用现在时，并体现项目特性。不要编造理由；如果用户未提供理由，就省略。标题不得超过 80 个字符，摘要不得超过 140 个字符；仅为清晰起见进行完善。根据标题生成 slug（小写，以连字符分隔，仅使用 ASCII 字符）。将完善后的节点作为 JSON 写入绝对路径 <DRAFT_PATH>，且必须包含以下八个键：kind、slug、title、summary、tags、confidence、relates_to、body。成功后返回该路径。

  4. 子 Agent 返回后，由主会话（绝不能由子 Agent）读取 $DRAFT_PATH 并验证 JSON（必须能解析，包含上述八个键，且不得超出长度限制），然后由主会话在同一会话中自行调用 node write。成功时追加一行 JSONL：{"event":"drafted",...}；失败时追加：{"event":"draft-invalid","reason":"..."}。验证失败时，不要中止——在本次调用中回退到下方的内联起草流程；无论如何，面向用户的摘要都保持不变。

如果没有可用的调度原语，则直接跳到下方的内联起草流程。

内联起草 + node write（默认和回退方案）

根据标题生成 slug（小写、以连字符分隔、仅 ASCII；例如，Use the rm analytics dispatcher → use-the-rm-analytics-dispatcher）。然后通过 stdin 将正文传给 node write（如果委派流程生成了有效草稿，则使用其 slug 和润色后的 body；否则根据用户提供的七个值直接起草）：

npx --yes kenkeep@latest node write <kind> <slug> \
  --title "<title>" --summary "<summary>" \
  --tags "<tags>" --relates-to "<relates-to>" \
  --confidence <high|medium|low> <<'EOF'
<body markdown>
EOF

node write 从 stdin 读取正文（heredoc 形式可避免多行 Markdown 出现转义）。成功时，它只输出解析后的节点 ID，并以 0 退出。架构验证失败时，它会以非零状态退出，并将错误输出到 stderr。

Slug 冲突行为。 如果磁盘上已存在使用拟定 slug 的节点，ensureUniqueId 会自动添加 -2、-3 等后缀，因此输出的 ID 可能与输入的 slug 不同。这不会导致失败——请将输出的 ID 原样告知用户，以便他们查看正确的文件。只有硬性架构错误（缺少 --title、--confidence 格式错误等）才会导致命令以非零状态退出。

命令返回后，向用户提供输出的 ID 及其文件路径（由于此技能未传入 --folder，文件位于根目录下的 nodes/<id>.md），并提醒他们审核该文件，然后选择接受（保留）或拒绝（rm）该文件。

评论

支持 Markdown