Mcp Probe Kit

mcp-probe-kit — 了解上下文，把握当下

---

空谈无益，展示上下文。

mcp-probe-kit 是一款协议级工具包，面向希望让 AI 理解项目意图、选择精准工作流，并保留已验证经验，同时避免用内部操作淹没模型的开发者。

语言：English | 简体中文 | 日本語 | 한국어 | Español | Français | Deutsch | Português (BR)

🚀 AI 驱动的完整开发工具包——覆盖整个开发生命周期

一款功能强大的 MCP（模型上下文协议）服务，默认提供 29 个模型可见工具（24 个基础工具 + 5 个 History Session 工具；设置 MCP_HISTORY_SESSION=0 可停用 History）；配置 Memory 后提供 35 个工具，并可通过 MCP_TOOLSET=full 使用包含 39 个工具的兼容工具集。它覆盖从产品分析到最终发布的完整工作流，并支持结构化输出。

🎉 v4 稳定版：原生 MCP Apps、可恢复计划、证据收敛、托管式 GitNexus Sidecar、父子规格，以及版本锁定的 CLI 回退方案。

支持所有 MCP 客户端：Cursor、Claude Desktop、Cline、Continue 等

协议支持：Legacy MCP（2025 年左右）+ Modern MCP 2026-07-28 · SDK：拆分为多个 TypeScript SDK v2 软件包

运行环境：Node.js 20 或更高版本。默认使用 MCP_PROTOCOL_MODE=auto；仅在兼容性诊断时使用 legacy 或 modern。

---

🎬 v4 实际演示

v4 将委派的 Agent 工作转化为可观察、可验证的交付闭环。以下动画均由 npm 包中发布的同一份 MCP App 源码渲染而成，并非单独制作的宣传样图。

功能工作台 — 父子规格、当前步骤、输出、证据和跨会话恢复。

记忆中心 — 语义搜索、完整内容检查、生命周期状态、证据、标记为过时以及确认删除。

收敛门禁 — 当步骤或需求／规格／实现／测试／审查证据不完整时，阻止关闭。

• 五个原生 MCP Apps：记忆中心、功能工作台、Bug 工作台、产品工作台和收敛门禁。
• 历史会话（默认开启）：在 docs/history-session/ 下无损交接本地聊天记录 — 引导 → 检查点 → 搜索／读取，无需向量数据库。
• 可恢复的委派计划：plan_heartbeat 持久化实际进度；resume_plan 恢复下一个可执行步骤。
• 基于证据的收敛：converge 对交付和长期记忆写入进行门禁控制。
• 托管式 GitNexus Sidecar：隔离版本／平台／架构／Node，验证完整性，执行真实 FTS 探测，并安全降级。
• 版本锁定的 CLI 后备方案：当宿主丢弃 MCP 工具租约时，项目本地的 probe 包装器仍可访问同一工具注册表。
• 父子规格：将复杂发布拆解并递归验证，而不是压缩成一个过大的规格。

打开五个实时只读 MCP App 演示

**v4 稳定版：**当前稳定版本为 [email protected]，也是 npm latest 通道的版本。

---

📚 完整文档

👉 https://mcp-probe-kit.bytezonex.com

• 快速开始 - 5 分钟完成设置
• 本地记忆技术栈（Qdrant + Nomic Embed） - Docker Compose、端口 50008 / 50012、MCP 环境变量
• 所有工具 - 默认（+ 历史会话）、条件启用的记忆、仅 App 和完整兼容性界面
• 最佳实践 - 完整开发工作流指南
• v3 → v4 迁移指南 - 工具界面、协议、Apps、计划状态、记忆和兼容性
• MCP Apps 实时演示 - 基于发布的 App 源码生成的五个真实只读工作台

---

✨ 核心功能

📦 工具界面

默认的 compact 界面保留了每个可独立使用的工作流，同时将相互竞争的内部条目和维护条目从模型上下文中移除。

• 🧭 路由（1）— workflow
• 🔁 计划状态与收敛（3）— plan_heartbeat、resume_plan、converge
• 🔄 工作流编排（6）— start_feature、start_bugfix、start_onboard、start_ui、start_product、start_ralph
• 📦 项目与规范（4）— init_project、init_project_context、check_spec、estimate
• 🏗️ 架构（1）— architecture
• 🔍 代码、测试与 Git（6）— code_insight、gentest、code_review、refactor、gencommit、git_work_report
• 🎨 UI/UX 实用工具（2）— ui_design_system、ui_search
• 🗣️ 结构化访谈（1）— interview

共有 24 个基础 compact 工具，默认还包括 5 个 History Session 工具（history_session_bootstrap|checkpoint|validate|search|read），模型可见工具总数为 29。设置 MCP_HISTORY_SESSION=0|false|off 可隐藏 History。配置完整的 Memory 堆栈后，会动态添加 6 个 Memory 工具，模型可见工具总数增至 35（关闭 History 时为 30）：

search_memory、read_memory_asset、memorize_asset、update_memory_asset、delete_memory_asset、scan_and_extract_patterns

为兼容性和诊断目的，MCP_TOOLSET=full 会恢复全部 39 个模型工具。compact 界面有意省略了 add_feature、fix_bug、sync_ui_data 和 ask_user：这些工具的实现仍可通过编排、维护脚本或完整兼容模式使用。

workflow 是备用的工具选择指南，而不是自然语言意图分类器。Agent 通常会根据当前对话、Skill 和工具描述直接选择合适的 MCP 工具。scenario=auto 仅返回指导信息（firstTool=null）；指定 scenario 则会针对 Agent 已选择的场景返回确定性指导。

📜 History Session（默认开启）——无损项目交接

聊天托管平台会遗忘。History Session 会保留一份无损、项目本地的归档，让下一轮 Agent 对话（或新的会话）可以根据用户的真实措辞、决策和待办事项继续工作，而无需将整段聊天塞进提示词。

重要原因

• 托管平台的上下文窗口和“新建聊天”重置会丢失先前的发现；History 会将这些内容以 Markdown 格式持久保存到 docs/history-session/。
• 默认开启，且无需 Qdrant / 嵌入式技术栈——开箱即用，可与 24 个基础精简工具一起使用（模型可见的工具总数为 29 个）。
• 它与其他层互为补充，而非取而代之：

层	职责	典型工具
History Session	本项目的对话交接、用户输入原文、轮次检查点	history_session_*
Delegated Plan	可恢复的步骤、证据、收敛关卡	plan_heartbeat / resume_plan / converge
Memory	可跨仓库复用的经验（需要 MEMORY_*）	search_memory / memorize_asset

Agent 如何使用

1. 对话开始时——调用 history_session_bootstrap，并设置 initial_user_input=<user’s first message>。在没有平台会话的托管环境中，仅一次不提供 session_key；服务端会生成 hs_<uuid> 并开启一个新归档（不会与 project-active 共用）。后续调用时传入该标识。不要自行编造键值。
2. 每次最终回复前——调用 history_session_checkpoint，传入 bootstrap 返回的 session_key 和 expected_path，以及本轮的 raw_user_input / user_intent。填写 Skill 的最低要求清单（findings、decisions、files_changed、tests、runtime_state、next_actions）——不要用空数组凑数。
3. 需要查询较早的信息时——调用 history_session_search → history_session_read（按 next_cursor 继续读取）。优先使用有边界的 bootstrap state；默认不要加载完整历史记录。
4. 编号 / 索引损坏时——调用 history_session_validate（必要时设置 repair=true）。

操作细节

• 当归档超过 MCP_HISTORY_MAX_LINES / MCP_HISTORY_MAX_BYTES（默认值分别为 800 / 131072）时进行软轮转；checkpoint 会返回新的 expected_path。轮转后的归档会沿用最新的 initial_user_input。
• 会对归档文本中的常见机密信息进行脱敏；checkpoint 根据内容指纹实现幂等。
• 设置 MCP_HISTORY_SESSION=0|false|off 可禁用此功能（隐藏这 5 个工具）。
• 不要提交 docs/history-session/——将其添加到 .gitignore（仅用于本地交接；不属于 npm 包）。

Skill 和 AGENTS.md 会说明读写时机规则；All Tools 目录列出了每个 history_session_* 工具的一行调用提示。

🔁 委派计划状态、恢复与收敛

• 每个 v4 委派计划都会声明 executionStatePolicy，并指示 Agent 在第一步创建本地检查点。
• plan_heartbeat 会将已完成 / 已跳过的步骤、未解决事项、证据以及最后验证的修订版本持久保存到 .mcp-probe-kit/plans/。
• 在中断、重启或 Agent 交接后，resume_plan 会根据已存储的依赖关系重新计算就绪和受阻步骤。
• 如果步骤、未解决事项或需求 / 规格 / 实现 / 测试 / 审查证据尚未完成，converge 会拒绝结束流程。只有收敛检查通过后，才允许写入正式的长期记忆。
• 这些工具用于跟踪和验证 Agent 的执行情况；它们不会将文件、Shell、Git 或实现工作转移到 MCP 服务中。

🛡️ 质量约束（唯一可信来源）

所有硬性质量规则都集中在一个模块（src/lib/quality-constraints.ts）中，并注入 code_review、add_feature 任务模板和 UI 工具。修改一次，处处生效——灵感来自 taste-skill 和 impeccable。

• 代码限制：单个文件 ≤ 500 行（超出时拆分为模块/组件），函数 ≤ 50 行，嵌套层级 ≤ 4，参数 ≤ 3 个。
• 完整性黑名单：code_review 会将占位符/省略模式（// ...、// TODO、// rest of code、裸 ...）标记为 CRITICAL——“不完整的输出就是有问题的输出”。
• 反偷懒任务模板：add_feature 任务现在包含 Scope-lock 交付物数量、强制证据块（先读代码再编写）、逐文件行数预算，以及对占位符实行二元零容忍规则。check_spec 会验证这些内容（缺少 Scope-lock = 错误，缺少证据的单薄任务 = 警告）。
• UI 硬性红线：可量化、机器可检查的规则——4pt 间距比例、WCAG 对比度（4.5/3/3）、字号比例 ≥ 1.25、主视觉字体 ≤ 6rem、OKLCH、八种交互状态、认知负荷 ≤ 4、动效 150-300ms。
• UI 禁用列表 + Pre-Flight 检查清单：对 AI 味设计实行匹配即拒绝的黑名单（默认使用 Inter/Roboto、AI 紫蓝渐变、渐变文本、千篇一律的卡片网格、em dash、奶油色/米色正文背景、嵌套卡片），另附交付门禁自检矩阵。

🧠 代码图谱桥接（GitNexus）

• code_insight 默认通过 GitNexus 桥接来进行查询、上下文分析和影响分析
• 桥接优先使用显式配置的 GitNexus CLI 或系统 GitNexus CLI，其次使用版本锁定的托管 Sidecar；GitNexus 不会打包进主包，也不会全局安装
• init_project_context 会在 docs/graph-insights/ 下引导生成基线图谱文档；如果 docs/project-context.md 已存在，则保留旧的上下文文档，仅补充图谱文档和索引条目
• start_feature 会刷新 GitNexus 索引，并在生成规格说明前运行任务级 query/context/impact 收窄分析，以减少范围过大的情况
• start_bugfix 会刷新 GitNexus 索引，并在 TBP RCA 前运行任务级图谱分析，以约束故障边界和影响范围
• 对于已有 project-context.md 但没有图谱文档的旧项目，系统会通过 init_project_context 步骤自动引导生成图谱文档
• 如果 GitNexus 不可用，服务会自动回退，不会中断编排
• 实际图谱查询会读取 .gitnexus 索引；docs/graph-insights/latest.md|json 是供人类和 AI Agent 阅读的快照
• MCP 客户端设置中的 MCP 资源列表包含 2 个条目（probe://status、probe://project/bootstrap）。图谱运行时快照（probe://graph/latest 等）以及 probe://project/skill|agents|context|graph，在工具公开 URI 时仍可通过 resources/read 读取
• 图谱快照会持久化到 .mcp-probe-kit/graph-snapshots（可通过 MCP_GRAPH_SNAPSHOT_DIR 自定义）
• 工具响应包含 _meta.graph，其中提供快照 URI 和本地 JSON/Markdown 文件路径

🐛 SRC-8 缺陷根因工作流（受 TBP 启发）

• SRC-8 方法论（中文：src8-methodology.zh-CN.md）——受 Toyota TBP / PDCA 启发、针对代码和 AI Agent 调整的软件根因分析 8 步协议
• start_bugfix 会先缩小图谱范围，然后在修复和测试之前执行委派的 SRC-8 计划（metadata.plan.steps 中的 src8-1~8）
• fix_bug 会返回委派的计划（src8-1~8）、src8Checklist、rootCauseWorksheet（第 4 步的核心），以及硬性门槛（根因分析工作表完成前不得修改代码）
• 与制造业 TBP 相比的亮点：复现契约、归因层级（包括 agent_behavior）、促成因素、用于跨仓库学习的 memorize_asset

继承自 Toyota TBP： 差距思维、先计划后执行、不跳过步骤直接进行根因分析、基于事实开展调查、针对问题而非症状采取对策、评估后再标准化。

我们的提升： 将 genchi-genbutsu 转化为阅读代码、日志和复现结果；第 4 步工作表；仅提供指导的 MCP，通过强制规范流程引导 Agent 执行。

🧠 记忆检索

• 记忆工具使用 Qdrant 作为向量数据库后端
• 嵌入服务支持两种模式：
  • ollama
  • openai-compatible

记忆工具：

• search_memory - 在共享记忆池中进行语义搜索（可选优先使用 type / tags）；文本输出包含 id、score、摘要、描述，以及 --- content --- 正文（通过 MEMORY_SEARCH_CONTENT_MAX_CHARS 设置默认最多 1500 个字符）
• memorize_asset - 将已验证的 MemoryCandidate 持久化到向量记忆中；对于委派工作流，仅在 converge 通过后调用
• read_memory_asset - 通过 asset_id 读取完整资源内容（文本输出包含完整的 content 正文）
• update_memory_asset - 通过 asset_id 更新现有资源（保留 ID；content 变更时会重新生成嵌入）
• delete_memory_asset - 从共享池中通过 asset_id 删除资源
• scan_and_extract_patterns - 在决定是否持久化之前，从代码/文件/目录中提取可复用模式

跨仓库记忆池： 不要依赖 source_project / source_path 进行共享检索；请将文件路径放入 content。除非 MEMORY_REPO_ID 匹配或 MEMORY_SEARCH_SHOW_SOURCE=true，否则搜索注入会隐藏外部的 sourcePath。

记忆后端和嵌入配置：

• 向量数据库：Qdrant
• 推荐的本地设置： Qdrant (port 50008) + Infinity / nomic-embed (port 50012) — 比 Ollama 更轻量；请参阅 本地记忆栈指南（中文：memory-local-setup.zh-CN.md）
• 支持的嵌入服务提供商：
  • ollama
  • openai-compatible（Infinity、OpenAI 等）
• 记忆写入/搜索所需的环境变量：
  • MEMORY_QDRANT_URL
  • MEMORY_EMBEDDING_URL
  • MEMORY_EMBEDDING_MODEL
• 可选环境变量：
  • MEMORY_QDRANT_API_KEY
  • MEMORY_QDRANT_COLLECTION（默认值：mcp_probe_memory）
  • MEMORY_EMBEDDING_API_KEY
  • MEMORY_EMBEDDING_PROVIDER（默认值为 ollama）
  • MEMORY_SEARCH_LIMIT（默认值：3）
  • MEMORY_SUMMARY_MAX_CHARS（默认值：280）
  • MEMORY_SEARCH_MIN_SCORE（默认值：0 = 已禁用；对于噪声较多的池，可尝试 0.72）
  • MEMORY_SEARCH_SHOW_SOURCE（默认值：false）
  • MEMORY_REPO_ID（可选；仅当 sourceProject 匹配时显示 sourcePath）
  • MEMORY_INJECTION_CONTENT_MAX_CHARS（默认值：1500；注入到 start_* 指南中的每条命中内容上限）
• 行为说明：
  • 只读记忆访问仅需配置 MEMORY_QDRANT_URL
  • 仅当 MEMORY_QDRANT_URL、MEMORY_EMBEDDING_URL 和 MEMORY_EMBEDDING_MODEL 均已配置时，才会启用记忆写入
  • 首次写入时会自动创建 Qdrant 集合，并根据第一个嵌入响应推断向量维度

推荐的本地记忆设置（Qdrant + Nomic Embed / Infinity）：

完整的 Docker Compose 配置、端口和故障排除说明：docs/memory-local-setup.md

{
  "mcpServers": {
    "mcp-probe-kit": {
      "command": "npx",
      "args": ["-y", "[email protected]"],
      "env": {
        "MEMORY_QDRANT_URL": "http://127.0.0.1:50008",
        "MEMORY_QDRANT_API_KEY": "your-qdrant-api-key",
        "MEMORY_QDRANT_COLLECTION": "mcp_probe_memory",
        "MEMORY_EMBEDDING_PROVIDER": "openai-compatible",
        "MEMORY_EMBEDDING_URL": "http://127.0.0.1:50012/embeddings",
        "MEMORY_EMBEDDING_MODEL": "nomic-ai/nomic-embed-text-v1.5",
        "MEMORY_EMBEDDING_API_KEY": "your-infinity-api-key",
        "MEMORY_SEARCH_LIMIT": "3",
        "MEMORY_SUMMARY_MAX_CHARS": "280"
      }
    }
  }
}

替代方案：Qdrant + Ollama（如果你已运行 Ollama）：

docker run -d --name mcp-qdrant -p 6333:6333 qdrant/qdrant
ollama pull nomic-embed-text

"MEMORY_QDRANT_URL": "http://127.0.0.1:6333",
"MEMORY_EMBEDDING_PROVIDER": "ollama",
"MEMORY_EMBEDDING_URL": "http://127.0.0.1:11434/api/embeddings",
"MEMORY_EMBEDDING_MODEL": "nomic-embed-text"

OpenAI 兼容嵌入（托管 API）：

{
  "mcpServers": {
    "mcp-probe-kit": {
      "command": "npx",
      "args": ["-y", "[email protected]"],
      "env": {
        "MEMORY_QDRANT_URL": "http://127.0.0.1:6333",
        "MEMORY_QDRANT_COLLECTION": "mcp_probe_memory",
        "MEMORY_EMBEDDING_PROVIDER": "openai-compatible",
        "MEMORY_EMBEDDING_URL": "https://your-embedding-endpoint/v1/embeddings",
        "MEMORY_EMBEDDING_API_KEY": "your-api-key",
        "MEMORY_EMBEDDING_MODEL": "text-embedding-3-small"
      }
    }
  }
}

🎯 结构化输出

核心工具和编排工具支持结构化输出，可返回机器可读的 JSON 数据，提高 AI 解析准确性，并支持工具链式调用和状态跟踪。

⏱️ 原生任务、进度与取消

• 使用与 SDK 无关的 Internal Task Runtime，通过 Legacy Adapter 暴露当前 SDK 的任务协议
• 支持任务生命周期端点：tasks/get、tasks/result、tasks/list、tasks/cancel
• 声明 capabilities.tasks.requests.tools.call，以便客户端为 tools/call 创建任务
• 协议任务存储不可用时，回退到同步执行
• 客户端提供 _meta.progressToken 时，发送 notifications/progress
• 终止完成后忽略迟到的进度；工具/任务结果是最终完成信号
• 通过 AbortSignal 处理请求取消，并保留明确的 cancelled 状态
• 长时间运行的编排工具（start_*）和 sync_ui_data 支持协作式取消/进度回调
• 内部任务持久化默认使用内存。设置 MCP_TASK_STORE=json 可使用 .mcp-probe-kit/tasks.json；设置 MCP_TASK_STORE_PATH 可指定其他 JSON 路径。对于无法重建其执行器的中断任务，重启时会明确标记为失败，而不会继续报告为运行中。

🔌 官方 MCP Apps 与 Memory Center

v4.0.0 使用官方 @modelcontextprotocol/ext-apps SDK 和稳定的 io.modelcontextprotocol/ui 扩展。

• 默认启用 MCP Apps，可通过 MCP_ENABLE_UI_APPS=0 禁用。
• 仅当客户端声明支持 text/html;profile=mcp-app 后，才会暴露 UI 元数据和 ui:// 资源。
• 包含五个稳定的 Apps：Memory Center、Feature Workbench、Bug Workbench、Product Workbench 和 Convergence Gate。
• Memory Center 使用响应式主从布局，用于浏览历史记录、语义搜索、检查完整内容、查看生命周期状态和证据、标记过时内容，以及确认删除。
• Feature Workbench 和 Bug Workbench 会呈现实时计划步骤条。App 在可见时会轮询 resume_plan，并且只有在 Agent 通过 plan_heartbeat 记录真实步骤状态后，进度才会推进。
• Product Workbench 和 Convergence Gate 使用相同的开发者控制台设计系统来展示交付路径、阻碍因素和证据缺口。
• list_memory_assets 是仅限 App 使用的操作，设置 _meta.ui.visibility=["app"]。在支持 Apps 的主机上，它可能会出现在原始 tools/list 响应中，但符合规范的主机不得向模型提供该操作。默认情况下，模型可见的工具数量仍为 24，启用 Memory 后为 30。
• 不支持 MCP Apps 的客户端仍会收到常规文本和 structuredContent 响应；现有工作流无需 GUI 功能。
• 设置 MCP_ENABLE_EXTENSIONS_CAPABILITY=1 后，仍可使用 Trace 元数据透传功能。

🧪 工具与真实 Agent 契约验证

# Deterministic server-side audit across compact, Memory, full, App-only, and Legacy surfaces
npm run audit:tools

# Optional real-host audit: Claude Code calls and evaluates all 34 model tools
npm run audit:tools:agent

直接审计会验证可读文本非空、存在 structuredContent，并确认所有引用的 MCP 工具都存在于当前活动接口上。真实 Agent 审计还会检查 Agent 是否理解每个工具、能否遵循返回的指导、是否能看到文本与结构化内容之间不存在矛盾，以及能否执行所述的下一步。它有意与 release:verify 分开，因为该审计需要配置 Claude Code 账户，并会产生模型用量。

🧭 委派式编排协议

所有 start_* 编排工具都会在 structuredContent.metadata.plan 中返回一个执行计划。
AI 需要逐步调用工具并持久化文件，而不是由工具在内部执行。

计划架构（核心字段）：

{
  "mode": "delegated",
  "steps": [
    {
      "id": "spec",
      "tool": "add_feature",
      "args": { "feature_name": "user-auth", "description": "User authentication feature" },
      "outputs": ["docs/specs/user-auth/requirements.md"]
    }
  ]
}

字段说明：

• mode：固定为 delegated
• steps：执行步骤数组
• tool：工具名称（例如 add_feature）
• action：没有工具时的手动操作说明（例如 update_project_context）
• args：工具参数
• outputs：预期产物
• when/dependsOn/note：可选条件和备注

🧩 结构化输出字段规范（关键字段）

编排工具和原子工具都会返回 structuredContent，其中包含以下常用字段：

• summary：单行摘要
• status：状态（pending/success/failed/partial）
• steps：执行步骤（编排工具）
• artifacts：产物列表（路径 + 用途）
• metadata.plan：委派执行计划（仅限 start_*）
• specArtifacts：规格产物（start_feature）
• estimate：估算结果（start_feature / estimate）

🧠 需求澄清模式（需求循环）

需求不明确时，请在 start_feature / start_bugfix / start_ui 中使用 requirements_mode=loop。
此模式会在进入规格编写／修复／UI 执行前，进行 1–2 轮结构化澄清。

示例：

{
  "feature_name": "user-auth",
  "description": "User authentication feature",
  "requirements_mode": "loop",
  "loop_max_rounds": 2,
  "loop_question_budget": 5
}

🧩 模板系统（适用于常规模型）

add_feature 支持模板配置，默认的 auto 会自动选择：需求不完整时优先选择 guided（包含详细填写规则和检查清单），需求完整时选择 strict（结构更精简，适用于能力较强的模型或归档场景）。

示例：

{
  "description": "Add user authentication feature",
  "template_profile": "auto"
}

适用工具：

• start_feature 将 template_profile 传递给 add_feature
• start_bugfix / start_ui 也支持通过 template_profile 控制引导强度（auto/guided/strict）

模板配置策略：

• guided：需求信息较少／不完整时，优先用于常规模型
• strict：需求结构清晰时，优先采用更精简的引导
• auto：默认推荐选项，自动选择 guided/strict

父子规格

对于版本级或 Epic 工作，start_feature 默认使用 spec_layout: "auto"；当需求涉及多个模块、阶段或能力领域时，会选择 parent-child。如果尚不清楚子规格的边界，委派计划会先返回一个 decompose-spec 步骤。你仍可显式传入 flat 或 parent-child；add_feature 仍是原子工具，除非布局和 subspecs 已定义，否则默认使用 flat。MCP 服务会返回模板和 pendingFiles；调用方 Agent 在审核后创建父规格、spec-manifest.json 和子规格。随后，check_spec 会递归验证完整层级结构。

start_feature 使用仅查询的 GitNexus 窄化机制，并设有 8 秒降级预算，因此图谱冷启动不会阻塞规格规划。默认禁用自动索引刷新；当 MCP 进程应在图查询前刷新索引时，请设置 MCP_GITNEXUS_AUTO_REFRESH=1。

{
  "feature_name": "commerce-v2",
  "description": "Upgrade the commerce domain while preserving v1 compatibility",
  "spec_layout": "parent-child",
  "subspecs": [
    { "id": "01-foundation", "title": "Data foundation", "fr": ["FR-1"] },
    { "id": "06-inventory-ledger", "title": "Inventory ledger", "fr": ["FR-2"], "dependsOn": ["01-foundation"] }
  ]
}

🔄 工作流编排

6 个智能编排工具会自动组合多个基础工具，一键完成复杂开发工作流：

• start_feature - 新功能开发（需求 → 设计 → 估算）
• start_bugfix - 修复 Bug（SRC-8 根因分析 → 修复 → 测试）
• start_onboard - 项目入门（生成项目上下文文档）
• start_ui - UI 开发（设计系统 → 组件 → 代码）
• start_product - 产品设计（PRD → 原型 → 设计系统 → HTML）
• start_ralph - Ralph 循环（迭代开发，直至完成目标）

🚀 产品设计工作流

start_product 是一个完整的产品设计编排工具，涵盖从需求到交互式原型的全过程：

工作流：

1. 需求分析 - 生成标准 PRD（产品概述、功能需求、页面列表）
2. 原型设计 - 为每个页面生成详细的原型文档
3. 设计系统 - 根据产品类型生成设计规范
4. HTML 原型 - 生成可在浏览器中查看的交互式原型
5. 项目上下文 - 自动更新项目文档

结构化输出新增字段：

• start_product.structuredContent.artifacts：产物列表（PRD、原型、设计系统等）
• interview.structuredContent.mode：usage / questions / record

🎨 UI/UX Pro Max

4 个 UI/UX 工具，统一入口为 start_ui：

• start_ui - 一键式 UI 开发（支持智能模式）（编排工具）
• ui_design_system - 智能生成设计系统
• ui_search - UI/UX 数据搜索（BM25 算法）
• sync_ui_data - 在本地同步最新的 UI/UX 数据

注意：start_ui 会自动调用 ui_design_system 和 ui_search，无需单独调用。

灵感来源：

• ui-ux-pro-max-skill - UI/UX 设计系统理念
• json-render - JSON 模板渲染引擎

用于 UI/PRD 工作流的 Skill Bridge：

• start_ui 和 start_product 现在会在指导内容和 structuredContent.metadata.skills 中包含 Skill Bridge 部分。
• 建议的技能调用顺序：ui-ux-pro-max → interaction-design → frontend-design。
• 如果缺少某些技能，工作流会继续执行 MCP 主计划，并在元数据中标记不可用的技能。

为什么使用 sync_ui_data？

我们的 start_ui 工具依赖丰富的 UI/UX 数据库（颜色、图标、图表、组件、设计模式等），以生成高质量的设计系统和代码。这些数据来自 npm 包 uipro-cli，包括：

• 🎨 配色方案（主流品牌色、调色板）
• 🔣 图标库（React Icons、Heroicons 等）
• 📊 图表组件（Recharts、Chart.js 等）
• 🎯 落地页模板（SaaS、电商、政府等）
• 📐 设计规范（间距、字体、阴影等）

数据同步策略：

1. 内嵌数据：在构建时同步，可离线使用
2. 后台自动同步：将最新数据下载到 ~/.mcp-probe-kit/ui-ux-data/，但不会更改当前会话的输出
3. 下次启动时生效：新下载的数据会在下次进程启动时应用（确保当前会话具有确定性）
4. 手动同步：使用 sync_ui_data 立即强制刷新缓存（默认仍会在下次启动时应用）

这样可以确保 start_ui 即使在离线状态下也能生成专业级 UI 代码。

🎤 需求访谈

2 个用于在开发前明确需求的访谈工具：

• interview - 结构化需求访谈
• ask_user - AI 主动提问

---

🧭 工具选择指南

何时使用编排工具，何时使用单个工具？

在以下情况使用编排工具（start_*）：

• ✅ 需要完整工作流（多个步骤）
• ✅ 希望自动执行多个任务
• ✅ 需要生成多个产物（文档、代码、测试等）

在以下情况使用单个工具：

• ✅ 只需要特定功能
• ✅ 已有项目上下文文档
• ✅ 需要更精细的控制

常见场景选择

场景	推荐工具	原因
开发新功能（完整流程）	start_feature	自动完成：规格→估算
只需要功能规格文档	add_feature	更轻量，只生成文档
修复 Bug（完整流程）	start_bugfix	委派的 SRC-8 计划（src8-1~8）→ 修复 → 测试 → 记忆
只需要 Bug 分析	fix_bug	委派的 SRC-8 计划 + 根因分析工作表（方法论：文档）
生成设计系统	ui_design_system	直接生成设计规范
开发 UI 组件	start_ui	完整流程：设计→组件→代码
产品设计（从需求到原型）	start_product	一键完成：PRD→原型→HTML
一句话需求分析	init_project	生成完整的项目规格文档
项目入门文档	init_project_context	生成技术栈/架构/规范文档

---

🚀 快速开始

方法 1：直接使用 npx（推荐）

无需安装，直接使用最新版本。

Cursor / Cline 配置

配置文件位置：

• Windows：%APPDATA%\Cursor\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
• macOS：~/Library/Application Support/Cursor/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
• Linux：~/.config/Cursor/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

配置内容：

{
  "mcpServers": {
    "mcp-probe-kit": {
      "command": "npx",
      "args": ["-y", "[email protected]"]
    }
  }
}

技能与 AGENTS 自动引导（v3.6.3+）：每次调用 MCP 工具时，都会写入 .agents/skills/mcp-probe-kit/SKILL.md，并将 mcp-probe:context 区块合并到 AGENTS.md 中。工作区根目录会自动检测（Cursor 会注入 WORKSPACE_FOLDER_PATHS；OpenCode 项目的 opencode.json 会设置 cwd）。除非全局 MCP 无法解析工作区，否则无需为每个客户端设置 MCP_PROJECT_ROOT；若无法解析，请设置 MCP_PROJECT_ROOT 或在工具参数中传入 project_root。

多宿主适配器（v3.6.8+）：AGENTS.md 和规范技能始终是唯一的规则来源。如果项目中已存在 .trae/、.lingma/、.comate/、.codebuddy/ 或 .claude/，系统会自动写入匹配的轻量适配器（技能镜像或规则指针）——无需环境变量。

锁定版本的 CLI 回退方案（v4.0.0+）：引导过程还会写入 .mcp-probe-kit/bin/probe.cmd|probe.ps1|probe 和 .mcp-probe-kit/runtime.json。如果修改过的宿主或第三方 Agent 提供方连接了 MCP 服务，但未将其工具注入 Agent 会话，生成的技能和 Cursor 规则会指示 Agent 通过项目包装器调用同一个工具注册表。该包装器会锁定确切的 MCP 软件包版本，不会全局安装，也不会修改项目的 package.json。

CLI 回退方案的记忆功能：install-agent 还会创建 .mcp-probe-kit/local.env（以及 local.env.example）。CLI 回退路径（probe.* exec ...）不会继承 IDE 的 mcp.json 环境变量；请使用相同的 MEMORY_* 键编辑 local.env。

直接 CLI 示例：

# JSON from stdin is the most portable option
printf '%s' '{"intent":"build a task board","scenario":"feature","project_root":"."}' \
  | ./.mcp-probe-kit/bin/probe exec workflow --stdin

# Repair or install the project wrappers without a working MCP tool lease
npx --yes mcp-probe-kit@<exact-version> install-agent --project-root .

Claude Desktop 配置

配置文件位置：

• Windows：%APPDATA%\Claude\claude_desktop_config.json
• macOS：~/Library/Application Support/Claude/claude_desktop_config.json
• Linux：~/.config/Claude/claude_desktop_config.json

配置内容：

{
  "mcpServers": {
    "mcp-probe-kit": {
      "command": "npx",
      "args": ["-y", "[email protected]"]
    }
  }
}

OpenCode 配置

配置文件位置：

• 项目级：opencode.json（位于项目根目录）
• 全局：~/.config/opencode/opencode.json

配置内容：

{
  "mcp": {
    "mcp-probe-kit": {
      "type": "local",
      "command": ["npx", "-y", "[email protected]"],
      "enabled": true
    }
  }
}

**注意：**OpenCode 使用的 opencode.json 架构不同于 Cursor / Claude Desktop。键 mcp 会替代 mcpServers，command 是一个数组，必须包含 type: "local"，环境变量使用 environment 而非 env。详情请参阅 OpenCode MCP 文档。

方法 2：项目本地 Agent 回退方案

npx --yes [email protected] install-agent --project-root .

这会写入锁定版本的 .mcp-probe-kit/bin/probe.* 启动器。优先使用原生 MCP；如果宿主未注入工具，则由 Agent 使用这些包装器。请勿全局安装该软件包。

可选的记忆系统设置

如果要使用 memorize_asset、update_memory_asset、read_memory_asset、delete_memory_asset 和 scan_and_extract_patterns，请按以下方式配置：

• 仅 Qdrant（MEMORY_QDRANT_URL）：read_memory_asset、delete_memory_asset
• Qdrant + 嵌入（全部三个 MEMORY_* 写入/搜索变量）：search_memory、memorize_asset、update_memory_asset
• 无记忆后端：scan_and_extract_patterns（仅本地扫描；准备就绪后通过 memorize_asset 持久化）

要完整支持写入/搜索，需要具备以下两项：

1. Qdrant 向量数据库
2. 采用 ollama 或 openai-compatible 模式的嵌入服务

注意（CLI 回退）：如果运行项目包装器（./.mcp-probe-kit/bin/probe* exec ...），而非原生 MCP，Memory 环境变量将从 .mcp-probe-kit/local.env 读取（由 install-agent 创建）。

完整指南（用于 Qdrant + Infinity 的 Docker Compose、端口 50008 / 50012、MCP 环境变量及冒烟测试）：

• 英文：docs/memory-local-setup.md
• 中文：docs/memory-local-setup.zh-CN.md

选项 A：Qdrant + Nomic Embed / Infinity（推荐）

轻量级本地栈；无需 Ollama。通过 Docker Compose 部署 Qdrant 和 nomic-embed（参见指南），然后：

{
  "mcpServers": {
    "mcp-probe-kit": {
      "command": "npx",
      "args": ["-y", "[email protected]"],
      "env": {
        "MEMORY_QDRANT_URL": "http://127.0.0.1:50008",
        "MEMORY_QDRANT_API_KEY": "your-qdrant-api-key",
        "MEMORY_QDRANT_COLLECTION": "mcp_probe_memory",
        "MEMORY_EMBEDDING_PROVIDER": "openai-compatible",
        "MEMORY_EMBEDDING_URL": "http://127.0.0.1:50012/embeddings",
        "MEMORY_EMBEDDING_MODEL": "nomic-ai/nomic-embed-text-v1.5",
        "MEMORY_EMBEDDING_API_KEY": "your-infinity-api-key",
        "MEMORY_SEARCH_LIMIT": "3",
        "MEMORY_SUMMARY_MAX_CHARS": "280"
      }
    }
  }
}

嵌入 URL 必须为 /embeddings（不能是 /v1/embeddings）。设置 QDRANT__SERVICE__API_KEY 时，Qdrant 需要 api-key。

选项 B：Qdrant + Ollama

docker run -d --name mcp-qdrant -p 6333:6333 qdrant/qdrant
ollama pull nomic-embed-text

"MEMORY_QDRANT_URL": "http://127.0.0.1:6333",
"MEMORY_EMBEDDING_PROVIDER": "ollama",
"MEMORY_EMBEDDING_URL": "http://127.0.0.1:11434/api/embeddings",
"MEMORY_EMBEDDING_MODEL": "nomic-embed-text"

选项 C：Qdrant + 托管的 OpenAI 兼容 API

"MEMORY_QDRANT_URL": "http://127.0.0.1:50008",
"MEMORY_EMBEDDING_PROVIDER": "openai-compatible",
"MEMORY_EMBEDDING_URL": "https://your-embedding-endpoint/v1/embeddings",
"MEMORY_EMBEDDING_API_KEY": "your-api-key",
"MEMORY_EMBEDDING_MODEL": "text-embedding-3-small"

历史会话环境变量

• MCP_HISTORY_SESSION：默认开启；设置为 0|false|off 可隐藏五个 history_session_* 工具
• MCP_HISTORY_MAX_LINES：软轮换行数阈值（默认 800）
• MCP_HISTORY_MAX_BYTES：软轮换字节数阈值（默认 131072）

记忆环境变量

• MEMORY_QDRANT_URL：Qdrant 基础 URL，所有记忆功能都需要
• MEMORY_QDRANT_API_KEY：可选的 Qdrant API 密钥
• MEMORY_QDRANT_COLLECTION：集合名称，默认 mcp_probe_memory
• MEMORY_EMBEDDING_PROVIDER：ollama 或 openai-compatible
• MEMORY_EMBEDDING_URL：嵌入端点 URL
• MEMORY_EMBEDDING_API_KEY：Ollama 可选；托管的 OpenAI 兼容服务提供商通常需要
• MEMORY_EMBEDDING_MODEL：默认值为 nomic-embed-text
• MEMORY_SEARCH_LIMIT：默认搜索结果数量为 3
• MEMORY_SUMMARY_MAX_CHARS：默认摘要截断长度为 280

说明

• 只有配置了 MEMORY_QDRANT_URL、MEMORY_EMBEDDING_URL 和 MEMORY_EMBEDDING_MODEL，才会启用记忆写入功能
• 记忆读取功能只需要 MEMORY_QDRANT_URL
• 首次写入时会自动创建 Qdrant 集合，并使用 Cosine 距离
• 向量大小根据首次嵌入响应推断

GitNexus 托管运行时

适用于 code_insight、start_feature、start_bugfix 和 init_project_context。

由于 GitNexus 包含平台专属的原生依赖，并采用 PolyForm Noncommercial 许可证，因此不会随 mcp-probe-kit npm tarball 一起打包。运行时策略如下：

1. 如果明确配置了 MCP_GITNEXUS_COMMAND，则使用它。
2. 否则，复用 mcp-probe-kit 用户缓存中已验证的托管 Sidecar。
3. 否则，使用 PATH 中已有的兼容 gitnexus CLI。
4. 如果未安装任何运行时，图分析会立即降级，不会阻塞主工作流。Agent 可以运行 doctor gitnexus --install 并自动重试。

已验证的兼容性：

Node.js	托管 GitNexus
20-21	已禁用托管 Sidecar；请使用系统 GitNexus CLI 或降级模式
22+ / Windows、macOS、Linux	1.6.9

每个托管安装都按 GitNexus 版本、操作系统、CPU 架构和 Node.js 主版本隔离。在接受运行时之前，会根据固定的版本元数据检查 npm 完整性。随后，安装程序会运行 gitnexus doctor 和实际的 TypeScript 索引探测，并拒绝会静默禁用 FTS/BM25 搜索的运行时。

通过项目启动器安装或修复托管 Sidecar：

# Windows
& ./.mcp-probe-kit/bin/probe.cmd doctor gitnexus --install

# macOS / Linux
./.mcp-probe-kit/bin/probe doctor gitnexus --install

首次安装可能需要几分钟，因为 GitNexus 包含原生解析器、LadybugDB、ONNX Runtime 以及安装后的语法构建。它会在项目目录之外运行，不会修改项目的 package.json 或 node_modules。

可用模式：

• MCP_GITNEXUS_MODE=auto — 默认模式；使用显式指定的、系统中的或现有的托管运行时，否则快速降级。
• MCP_GITNEXUS_MODE=managed — 要求使用托管 Sidecar，并允许在图请求期间安装。
• MCP_GITNEXUS_MODE=system — 仅使用显式指定的或系统中的 GitNexus；绝不安装。
• MCP_GITNEXUS_MODE=off — 禁用 GitNexus。
• MCP_GITNEXUS_AUTO_INSTALL=1 — 允许 auto 模式同步安装；不建议对延迟敏感的客户端使用。

部分 GitNexus 依赖使用原生模块。在 Windows 上，LadybugDB FTS 还需要 Git for Windows 随附的 OpenSSL 运行时；mcp-probe-kit 会查找其 mingw64/bin 目录，并仅将其提供给托管子进程。如果 Git 安装在非标准位置，请将 MCP_GITNEXUS_WINDOWS_RUNTIME_BIN 设置为对应目录。预构建二进制文件下载失败时，可能仍需要安装包含 C++ 工作负载的 Visual Studio Build Tools。安装失败绝不会阻止 mcp-probe-kit 工作流继续以降级模式运行。

使用预装 gitnexus CLI 的示例配置：

{
  "mcpServers": {
    "mcp-probe-kit": {
      "command": "mcp-probe-kit",
      "env": {
        "MCP_GITNEXUS_MODE": "system",
        "MCP_GITNEXUS_COMMAND": "gitnexus",
        "MCP_GITNEXUS_ARGS": "mcp",
        "MCP_GITNEXUS_CONNECT_TIMEOUT_MS": "30000",
        "MCP_GITNEXUS_TIMEOUT_MS": "45000"
      }
    }
  }
}

重启客户端

配置完成后，彻底退出并重新打开 MCP 客户端。

👉 详细安装指南

---

💡 使用示例

日常开发

code_review @feature.ts    # Code review
gentest @feature.ts         # Generate tests
gencommit                   # Generate commit message

新功能开发

start_feature user-auth "User authentication feature"
# Auto-complete: Requirements analysis → Design → Effort estimation

修复 Bug

start_bugfix
# Then paste error message
# Auto-complete: Problem location → Fix solution → Test code

产品设计

start_product "Online Education Platform" --product_type=SaaS
# Auto-complete: PRD → Prototype → Design system → HTML prototype

UI 开发

start_ui "Login Page" --mode=auto
# Auto-complete: Design system → Component generation → Code output

项目上下文文档

# Single file mode (default) - Generate a complete project-context.md
init_project_context

# Modular mode - Generate 6 category docs (suitable for large projects)
init_project_context --mode=modular
# Generates: project-context.md (index) + 5 category docs

Git 工作报告

# Generate daily report
git_work_report --date 2026-02-03

# Generate weekly report
git_work_report --start_date 2026-02-01 --end_date 2026-02-07

# Save to file
git_work_report --date 2026-02-03 --output_file daily-report.md
# Auto-analyze Git diff, generate concise professional report
# If direct command fails, auto-provides temp script solution (auto-deletes after execution)

👉 更多使用示例

---

❓ 常见问题

Q1：工具无法运行或出现错误？

查看详细日志：

Windows（PowerShell）：

npx -y [email protected] 2>&1 | Tee-Object -FilePath .\mcp-probe-kit.log

macOS/Linux：

npx -y [email protected] 2>&1 | tee ./mcp-probe-kit.log

Q2：配置后客户端无法识别工具？

1. 重启客户端（彻底退出后重新打开）
2. 检查配置文件路径是否正确
3. 确认 JSON 格式正确，没有语法错误
4. 检查客户端开发者工具或日志中的错误消息

Q2b：Cursor 显示已连接，但工具数为 0／Agent 提示没有可用的 MCP 服务？

这是一个已知的 Cursor 端问题：stderr 可能会报告有效的精简工具集，但 Mcp FileSystem Writer 显示 lease returned 0 tools 和 toolCount=0——Agent 租用层悄无声息地丢弃了工具列表。

常见原因：

日志中的症状	可能的原因
tools/list ≈ 50+ KB，然后出现 lease returned 0 tools	Cursor 内部载荷大小限制（整个列表被悄无声息地丢弃）
latched shared-process MCP routing disabled + ipcReady 超时	Windows mcpProcess 实用程序失败；旧版回退机制能发现工具，但 Agent 租用仍为空
设置中显示绿点，Agent 提示 No MCP servers available	此会话未接通 Renderer ↔ shared-process MCP 路由

我们采取的措施：tools/list 默认省略 outputSchema，默认精简模型工具集包含 29 个工具（24 个基础工具 + 5 个 History Session 工具）。结构化输出仍可通过 tools/call 中的 structuredContent 使用。设置 MCP_INCLUDE_OUTPUT_SCHEMA=1 可恢复输出 schema，设置 MCP_TOOLSET=full 可恢复包含 39 个工具的兼容工具集。

你可以尝试：

1. 重新加载 MCP，或完全退出 Cursor（不只是关闭窗口）后再重新打开
2. 检查 Output → MCP 中是否有 lease returned 0 tools／ipcReady／MessagePort
3. 在 Composer 中打开工具面板，确认服务器开关已打开（部分版本默认关闭）
4. 升级 Cursor（3.7.36+ 出现过 Windows ipcReady 回归问题；请尝试最新版本，或回退到已知正常的版本）
5. 如果更新服务器后仍未修复，请向 Cursor 报告以下信息：connected=true、stderr 中的工具数、租用信息中的 toolCount=0，以及 shared-process MCP routing disabled

当宿主 Agent 路径被替换或无法转接 MCP 工具时的回退方案：

如果 MCP 面板和工具缓存正常，但实际 Agent 请求由不支持 MCP 工具转接的第三方提供商处理，那么重启服务器也无法修复该路径。请使用 bootstrap 生成的项目包装器：

# Windows
'{"intent":"continue the current feature","scenario":"feature","project_root":"."}' |
  .\.mcp-probe-kit\bin\probe.cmd exec workflow --stdin

# macOS / Linux
printf '%s' '{"intent":"continue the current feature","scenario":"feature","project_root":"."}' \
  | ./.mcp-probe-kit/bin/probe exec workflow --stdin

当原生 MCP 工具不可用时，Skill 会自动选择此路径。plan_heartbeat、resume_plan 和 converge 会在不同的 CLI 进程和原生 MCP 会话中使用相同的项目文件。

诊断：.cursor/projects/<project>/mcps/user-mcp-probe-kit/

此文件夹由 Cursor 写入（Mcp FileSystem Writer），而不是由 mcp-probe-kit 写入。成功租用工具后，你应该会看到：

mcps/user-mcp-probe-kit/
├── SERVER_METADATA.json
├── STATUS.md
├── tools/           ← one JSON per model-visible tool (~24 by default); Agent reads these for CallMcpTool
│   ├── init_project.json
│   └── ...
└── resources/       ← from resources/list (may exist even when tools/ is empty)

状态	含义
存在 resources/，但缺少 tools/ 或该目录为空	resources/list 正常，但工具租用失败（符合 lease returned 0 tools 的情况）
tools/ 中的条目少于所选模型工具集的数量（默认 24 个，使用 Memory 时为 30 个，full 时为 34 个）	写入不完整或会话中断；请重新加载 MCP
STATUS.md 显示服务器出错	Cursor 将该服务器标记为 Agent 不可用，即使设置中显示绿点

健康的会话中，MCP 连接后几秒内 tools/ 就会自动填充，无需手动设置或仓库配置。

Q3：如何更新到当前稳定版本？

在 MCP 配置中固定使用确切的版本号：[email protected]。然后刷新项目本地回退方案：

npx --yes [email protected] install-agent --project-root .

不要使用 @next、浮动的 @latest 版本号或全局 npm install -g。

Q4：为什么首次安装 GitNexus 可能需要很长时间？

GitNexus 包含原生解析器、图数据库、ONNX Runtime 和安装后语法构建。首次安装可能需要几分钟，尤其是在 Windows 系统或网络较慢的情况下。

在默认的 auto 模式下，常规功能和缺陷修复工作流不会等待安装完成。它们会返回结构化的 managed_install_required 降级结果，Agent 可以自动运行：

& ./.mcp-probe-kit/bin/probe.cmd doctor gitnexus --install

安装内容存储在 mcp-probe-kit 用户缓存中，使用精确的兼容版本和 npm 完整性锁定，不会修改业务项目。如果原生安装失败，图分析功能会继续处于降级状态，而工作流的其余部分仍会正常进行。

👉 更多常见问题

---

🤝 贡献

欢迎提交问题和拉取请求！

改进建议：

• 添加实用工具
• 优化现有工具的提示词
• 改进文档和示例
• 修复缺陷

---

📄 许可证

MIT 许可证

---

🔗 相关链接

• 作者：Kyle (小墨)
• GitHub：mcp-probe-kit
• npm：mcp-probe-kit
• 文档：https://mcp-probe-kit.bytezonex.com

相关项目：

• Model Context Protocol (MCP) - MCP 官方协议文档
• GitHub Spec-Kit - GitHub 规范驱动开发工具包
• ui-ux-pro-max-skill - UI/UX 设计系统理念来源
• json-render - JSON 模板渲染引擎灵感来源
• uipro-cli - UI/UX 数据源

---

为 AI 驱动的开发倾注 ❤️

---

致谢

感谢 Linux.do 社区支持推广本项目并提供反馈。