workbench
一个用于管理代码仓库内规范、架构、工作项和验证的 .NET CLI 工具。
安装使用
复制下面这段提示词发给你的 AI（Claude / Cursor / TRAE / Codex / WorkBuddy 等），它会自动帮你完成安装：
帮我安装这个 AI Skill：workbench。 它的用途是：一个用于管理代码仓库内规范、架构、工作项和验证的 .NET CLI 工具。 完整的 Skill 内容见：https://321skill.com/skills/workbench/raw/index.md 请读取该页面内容，如果是 SKILL.md 格式直接安装，如果是 README 提炼核心 prompt 后安装。
提示词包含完整的 Skill 内容链接，AI 读取后即可完成安装。你也可以 查看完整内容 确认无误。
使用示例
“我想为我们的新微服务创建一个需求规范文档。”，它会引导你使用 `workbench spec new` 命令，并按照 SpecTrace 模型生成结构化的 JSON 需求文件。接着，你可以说：“为这个需求创建一个关联的工作项。”，它会提示你使用 `workbench item new` 和 `workbench item link` 来创建并链接实现任务，确保需求与工作可追溯。
介绍
Workbench 是一个 .NET CLI 工具，旨在解决软件开发中规范、需求、架构、工作项和验证文档分散、难以追踪和验证的问题。它将所有与项目相关的规范性内容（如需求规格、架构设计、工作项、验证证据）都作为代码的一部分进行管理，确保这些“活的文档”与代码库同步，并可通过工具进行自动化验证和导航生成。
使用 Workbench，开发者可以在项目根目录下通过简单的 CLI 命令（如 workbench spec new 创建新需求规范，workbench item new 创建工作项）来创建和管理这些结构化文档。所有文档都遵循 SpecTrace 规范模型，并以 JSON 等可验证的格式存储，便于工具处理和自动化。
它非常适合需要严格遵循规范、进行安全或合规审计、或管理复杂项目文档的团队，尤其是后端开发、全栈开发、项目经理和文档工程师。这些角色需要确保项目意图、实现和证据之间的一致性。
建议在项目初期或重构阶段引入 Workbench，并建立团队规范来使用其命令流。注意，它主要面向以代码仓库为中心的工作流，重度依赖 GitHub 等外部平台进行问题跟踪的团队可能需要通过其同步功能进行适配。
核心特点
与同类文档或项目管理工具（如单纯用 Markdown 或 Confluence）相比，Workbench 的核心区别在于它将所有规范、需求和验证都“代码化”并置于版本控制之下，通过强制的模型验证（SpecTrace）确保文档间的可追溯性，并原生集成了生成导航和自动化验证的能力，使文档成为可构建、可测试的“单一事实来源”。
注意事项
不适合仅需轻量级、非结构化文档管理或完全依赖第三方 SaaS 平台（如 Jira, Confluence）进行核心工作流管理的团队。
常见问题
Workbench 和 GitHub Issues 是什么关系？
GitHub Issues 是 Workbench 的一个可选同步和镜像层，Workbench 将仓库本地的规范和工作项作为主要记录系统，可以双向同步到 GitHub。
它支持哪些文档格式？
主要支持规范的 JSON 格式（基于 SpecTrace 模型），同时兼容传统的 Markdown 格式（带 Front Matter），但当 JSON 和 Markdown 并存时，JSON 被视为权威来源。
给 AI 助手的安装指引
如果你的 AI 编程助手（Claude Code、Cursor、TRAE 等）能看到这个页面，把下面这段发给它即可自动完成安装：
请访问 https://321skill.com/skills/workbench/raw/index.md 读取 workbench 的原始 Skill 定义（Markdown 格式），按其中说明在我的环境里完成安装和配置。
AI 可直接读取的原始 Markdown 地址：/skills/workbench/raw/index.md（查看排版版本）