关于 grok-wiki-cli
grok-wiki-cli 是指导使用公开 grok-wiki 命令生成代码库 Wiki、询问一个或多个代码库问题的技能。这些操作依赖已就绪的本地 CLI Agent,而非云端模型 API。
主要功能
- 01从 GitHub 或本地来源生成 Wiki
- 02询问单个或多个代码库
- 03检查本地 Agent 就绪状态
- 04列出已保存的 Wiki
- 05启动服务器、worker 或 sidecar
适用场景
- 01为 GitHub 代码库生成 Wiki
- 02比较工作区中的多个代码库
- 03调查代码库功能的实现方式
- 04检查可用的本地 CLI Agent
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ asyncfuncai/ grok-wiki --skill grok-wiki-cli安装后在 Claude Code 中输入/grok-wiki-cli确认已加载。
附带文件agents/openai.yaml
详细介绍
Grok-Wiki CLI
当任务需要通过公开的 grok-wiki 命令完成,而不是点击桌面 UI、直接调用服务端 API 或使用特定提供商的脚本时,请使用此技能。
适用场景
以下情况请使用 grok-wiki:
- 根据 GitHub 简写、GitHub URL 或本地文件夹生成代码库 Wiki
- 针对单个代码库或多代码库工作区提问
- 检查本地 CLI Agent 是否就绪
- 列出本地保存的 Wiki
- 启动本地服务、工作进程或 local-cli sidecar
- 说明或调试 Grok-Wiki CLI 命令
除非用户明确要求使用 CLI,否则如果任务是编辑 Grok-Wiki 源代码,请勿使用 grok-wiki。
前置条件
- 优先使用公开的
grok-wiki命令。 - 如果
grok-wiki不可用,但当前代码库是 Grok-Wiki,请使用bun run ./bin/grok-wiki.ts。 rlm-wiki是行为相同的旧版别名;仅在不得已时或用户指定时使用。- Wiki 生成和 Ask 仅支持 local-cli。对于这些命令,不要检查提供商 API 密钥,也不要通过云端模型 API 路由。
- 必须安装并完成身份验证的本地 Agent:
grok、codex、claude、pi-codex、pi-claude或antigravity。
首先检查 CLI 和本地 Agent 是否可用:
command -v grok-wiki || command -v rlm-wiki
grok-wiki agents --rescan
如果未安装该命令,但你当前位于 Grok-Wiki 代码库中:
bun run ./bin/grok-wiki.ts agents --rescan
如果没有就绪的本地 Agent,请报告 grok-wiki agents --rescan 给出的所选 Agent 设置提示,并在开始生成前停止。
核心工作流
-
确定来源:
- GitHub 简写:
owner/repo - GitHub URL:
https://github.com/owner/repo - 本地路径:
./repo、/abs/path/repo、~/repo - 本地路径引用:
~/repo#main
- GitHub 简写:
-
检查 Agent 是否就绪:
grok-wiki agents --rescan
-
选择 Agent 行为:
- 省略
--agent,使用第一个就绪的本地 CLI Agent。 - 用户选择了特定的本地 Agent 时,传入
--agent <id>。 - 仅当所选本地 Agent 支持时,才传入
--model <model>和--reasoning <level>。
- 省略
-
运行
generate、ask或其他命令。 -
对于长时间运行的生成任务,请简要向用户更新进度。只有命令成功退出并报告 Wiki 已保存后,才能宣称任务成功。
命令概览
Agents
grok-wiki agents --rescan
用途:验证本地 sidecar 是否可用,以及哪些本地 Agent 已安装、完成身份验证并可运行。
支持的 Agent ID:
grok
codex
claude
pi-codex
pi-claude
antigravity
生成 Wiki
grok-wiki generate <source...> [--agent ID] [--model MODEL] [--reasoning LEVEL] [--pages N] [--page-count-mode auto|fixed] [--style STYLE] [--language LANG] [--concurrency N]
示例:
grok-wiki generate expressjs/express
grok-wiki generate expressjs/express --agent codex --model gpt-5.5 --pages 8 --style first-30
grok-wiki generate ./api ./web --agent claude --page-count-mode fixed --pages 6
grok-wiki generate ~/work/repo#main --style custom --style-prompt "Write as an operator runbook."
默认值:
- agent:第一个就绪的本地 CLI Agent
- style:
first-30 - pages:
auto,最多6个 - language:
en - storage:
~/.rlm-wiki,除非设置了GROK_WIKI_ROOT或RLM_WIKI_ROOT
仅当同时使用 --style-prompt 或 --style-prompt-file 时,才使用 --style custom。
Ask
grok-wiki ask <source> "question" [--agent ID] [--model MODEL] [--reasoning LEVEL] [--mode fast|deep]
grok-wiki ask <source...> --question "question" [--workspace-goal compare|steal|understand|bridge|audit]
示例:
grok-wiki ask expressjs/express "How does routing work?" --mode deep
grok-wiki ask ./api ./web --question "Compare auth flows" --workspace-goal compare
grok-wiki ask owner/repo-a owner/repo-b --question "What should we steal?" --workspace-goal steal
Ask 模式:
fast:聚焦检查并给出简洁回答deep:进行更广泛的调查并提供更充分的证据
工作区目标:
comparestealunderstandbridgeaudit
列出已保存的 Wiki
grok-wiki list
重新生成前,使用此命令查找现有的本地 Wiki 记录。
服务、工作进程和 Sidecar
grok-wiki serve --port 3141 --host 127.0.0.1
grok-wiki worker --once
grok-wiki sidecar --token TOKEN --port 0 --host 127.0.0.1 --stamp PATH
使用 serve 启动本地 Web/API 运行时。只有当任务明确涉及 Grok-Wiki 运行时进程模型或本地 CLI 适配器调试时,才使用 worker 和 sidecar。
Agent 指引
- 仅将
grok-wiki用作本地命令行工具来生成 Wiki 和执行 Ask。不要要求提供OPENAI_API_KEY、ANTHROPIC_API_KEY、GEMINI_API_KEY或其他服务提供商 API 密钥。 - 保持 BYOC/BYOK 行为不变:由用户选定的本地命令行 Agent 负责处理服务提供商和身份验证细节。
- 仅在用户选择了 Agent 时才显式使用
--agent。否则,使用命令行工具默认的第一个就绪 Agent。 - 验证类似枚举的标志值,不要猜测:Agent ID、Ask 模式、工作区目标、样式、页面数量模式和语言都必须是已知值。
- 对本地仓库直接使用本地路径;不要强制使用 GitHub 远程仓库。
- 对于多仓库任务,将每个源作为位置参数传入,并在 Ask 中使用
--question。 - 不要使用
--runtime rlm或云服务提供商运行时标志。对于这些流程,命令行工具仅接受--runtime local-cli。 - 如果运行因 sidecar 或所选 Agent 不可用而失败,请运行
grok-wiki agents --rescan并提供设置提示。 - 若要更改命令行工具的源代码,至少运行:
bun test src/cli.test.ts
bunx tsc --noEmit
git diff --check
如果更改生成器、Ask、sidecar 或流式传输行为,还需针对修改部分运行相应测试,并保留作用域内的流式渲染约定。