Token导航 LogoToken导航

Agent Skill · 开发

spec(规格说明)

spec 用于补充开发相关能力,适合在 Local Agent 中需要让 Agent 承接开发相关任务时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

spec 是开发类 Agent Skill,可用宿主为 Local Agent,通过unknown获取,权限为权限未标注;许可证信息还不明确,暂无第三方扫描结果,按安装量在开发类的 21,746 个 Skill 里排第 19,716。

总安装 259周安装 11下载 91核验 2026-05-01
开发权限未标注unknown未标认证来源可访问许可证需确认审计未展示Local Agent

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:spec(规格说明)
来源仓库:https://smithery.ai
仓库路径:spec
安装命令:
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。当前暂无明确安装命令,请以来源页面说明为准。

这个 Skill 是做什么的

开发类 Skill 面向写代码、改代码和排查问题,一般会读写仓库文件,部分还会执行构建或测试命令。

用于补充开发相关能力。spec 属于开发类 Skill,可作为该场景下的辅助能力补充。适合让 Agent 承接规格说明或技术文档任务。可结合来源仓库和原始 README 核验具体用法。安装前建议确认权限范围和维护状态。适用宿主包括 Local Agent,接入前应确认版本、权限和运行环境要求。

注意是否会触发联网、命令执行或文件读写操作。

来源仓库内路径:spec

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Local Agent;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    没有现成安装命令,按unknown的说明从来源页面获取,仓库路径是 spec。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    权限没有明确标注,第一次使用时只给一个无关紧要的任务,观察它到底读了哪些文件和网络。

常见问题

6 条

spec 怎么安装?

公开资料没有给出可以直接复制的命令,需要按来源页面说明手动安装,仓库内路径为 spec。

spec 支持哪些 AI 工具?

公开资料标注支持 Local Agent。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

spec 需要什么权限?

权限级别没有明确标注。第一次使用时建议只给无关紧要的任务,观察它实际读写了哪些内容。

spec 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

spec 用的人多吗?

公开数据是累计安装 259 次,近一周安装 11 次,下载 91 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

spec 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

值得选的地方和要先想清楚的地方

值得选的地方

  • 专注 Local Agent 一种宿主,触发方式和使用习惯不用来回切换。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 没有第三方扫描结果,安全性只能靠自己读源码判断。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Local Agent,想直接扩展它能力的人。
  • 需要处理开发类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 要求有安全扫描结论才肯安装的团队。
  • 需要厂商级技术支持和 SLA 的生产系统。

开发类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
skill-vetter

技能审查员 · OpenClaw

8,779,018986操作浏览器MIT-0通过
ontology

本体论 · OpenClaw

6,636,960576只读MIT-0通过
entra-app-registration

内部应用程序注册 · Codex、Claude

6,631,872764接触敏感数据未明确通过
entra-app-registration

内部应用程序注册 · Codex、Claude

3,757,680201接触敏感数据未明确通过
nano-banana-pro

纳米香蕉专业版 · OpenClaw

3,526,898364接触敏感数据MIT-0有提醒
spec

规格说明 · 本页

259—权限未标注未明确未收录

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

规格驱动开发(Spec-Driven Development)

概览

使用该方法进行系统化的软件功能开发,以减少歧义、提升质量与可维护性,并通过结构化规划提高交付成功率。

元信息

  • 名称: spec-driven-development
  • 描述: 使用需求、设计、任务三阶段的系统化方法,把模糊功能想法转为清晰、可实现的解决方案,以减少歧义、提升质量并促进 AI 协作。
  • 许可证: MIT
  • 兼容性: Claude Code、Cursor、VS Code、Windsurf
  • 元数据:

- 类别: methodology - 复杂度: intermediate - 作者: Kiro Team - 版本: 1.0.0

三阶段工作流

阶段 1:需求收集

目的: 将模糊的功能想法转化为清晰、可测试的需求。

流程:

  1. 编写能够表达价值与目的的用户故事
  2. 使用 EARS 格式定义验收标准
  3. 识别边界情况与约束
  4. 验证完整性与可行性

EARS 格式模式:

WHEN [event] THEN [system] SHALL [response]
IF [precondition] THEN [system] SHALL [response]
WHEN [event] AND [condition] THEN [system] SHALL [response]

示例:

**用户故事:** 作为一名新用户,我希望创建账户,以便访问个性化功能。

**验收标准:**
1. WHEN 用户提供有效邮箱和密码 THEN 系统 SHALL 创建新账户
2. WHEN 用户提供已存在的邮箱 THEN 系统 SHALL 显示“邮箱已注册”错误
3. WHEN 用户提供短于 8 位的密码 THEN 系统 SHALL 显示“密码过短”错误
4. WHEN 账户创建成功 THEN 系统 SHALL 发送确认邮件

阶段 2:设计文档

目的: 形成全面的技术实现计划。

流程:

  1. 调研技术方案与约束
  2. 定义系统架构与组件交互
  3. 明确数据模型与接口
  4. 规划错误处理与测试策略

设计文档结构:

## 概览
[高层方案摘要]

## 架构
[系统组件与关系]

## 组件与接口
[组件的详细说明]

## 数据模型
[数据结构与校验规则]

## 错误处理
[错误场景与响应策略]

## 测试策略
[不同层级的测试方式]

决策记录:

### 决策: [标题]
**背景:** [需要决策的情境]
**候选方案:**
1. [方案 1] - 优点: [收益] / 缺点: [不足]
2. [方案 2] - 优点: [收益] / 缺点: [不足]
**决策:** [选择的方案]
**理由:** [选择原因]

阶段 3:任务规划

目的: 将设计拆解为可执行、可顺序推进的实现步骤。

流程:

  1. 把设计元素转化为具体编码任务
  2. 按依赖关系排序以支持增量交付
  3. 为每个任务定义清晰目标与完成标准
  4. 关联需求以便追溯

任务结构:

- [ ] 1. [史诗/主要组件]
- [ ] 1.1 [具体实现任务]
  - [实现细节]
  - [要创建的文件/组件]
  - _需求: [需求引用]_

任务排序策略:

  • 基础优先: 先做核心接口与基础设施,再做依赖组件
  • 功能切片: 以端到端纵向切片验证主流程
  • 风险优先: 优先处理不确定或高风险部分
  • 混合: 根据项目特点组合使用

质量检查清单

需求清单

  • 识别并覆盖所有用户角色
  • 覆盖正常、边界与错误场景
  • 需求可测试、可衡量
  • 无冲突或相互矛盾的需求
  • EARS 格式使用一致

设计清单

  • 设计覆盖全部需求
  • 组件职责清晰
  • 组件间接口明确
  • 错误处理覆盖预期失败场景
  • 纳入安全考虑

任务清单

  • 设计中的每个组件都有实现任务
  • 任务顺序符合依赖关系
  • 每个任务产生可测试代码
  • 任务包含需求引用
  • 单个任务规模适中(2-4 小时)

与 AI 工作流集成

面向 Claude Code / AI 助手:

  1. 先提供背景、约束与目标
  2. 依次完成需求、设计、任务三个阶段
  3. 通过对话迭代完善输出
  4. 使用清单进行自检与复核
  5. 维持需求、设计与任务之间的可追溯性

用于启动规格的示例提示:

我正在做 [项目背景],需要新增 [功能描述]。

上下文:
- 技术栈: [stack]
- 用户: [目标人群]
- 约束: [关键限制]

请帮助我使用 EARS 格式编写需求,从用户故事与验收标准开始。

常见陷阱

  1. 跳过阶段:每个阶段都依赖前一步,跳过会导致返工
  2. 需求含糊:比如“系统要快”而非可衡量指标
  3. 把实现细节写进需求:需求关注“做什么”,不是“怎么做”
  4. 过度设计:只解决当前需求,避免为假设场景过度建设
  5. 任务过大:拆分到 2-4 小时的实现粒度
  6. 忽略错误场景:始终考虑失败与异常路径

后续步骤

  1. 按任务顺序开始实现
  2. 随进度勾选已完成任务
  3. 实现过程中发现缺口就更新规格
  4. 完成后对照需求进行验收
  5. 记录经验以便后续规格复用

平台分布

Local Agent

73.7%
按下载量换算67

安全审计

暂无安全审计结果可展示。

权限和风险

权限未标注

当前来源未能明确判断权限范围,默认进入异常复核队列。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills