← 返回列表
⚠ 装前注意
从清晰的想法到经过验证的实现——原生运行于 DSH。
基本兼容但装前注意：未发布到 npm registry，仅可从源码安装 · 最近上游提交 2026/9/16 · 已提供中文文档
一个DSH插件，提供Github spec-kit的轻量版本。专为非子代理（non-subagent）实现而设计，适用于本地模型。
综合分
30.8
GitHub 分
30.8
用户评分
—
★ Stars
2
周下载量
—
安装插件（需先安装 dsh CLI 引擎：npm install -g @deepseek-ai/dsh）
dsh plugin --profile web add MarcSierszen/dsh-specify-lite未发布到 npm registry，仅可从源码安装，改用 GitHub 源安装
信任档位：已验证本站已于 2 天前真实安装成功（L4 · 真实安装）
- 是什么
- dsh 原生插件 · platform
- 装得上吗
- 本站已真实安装成功（L4 · 真实安装，非静态推断）
- 安全吗
- 本站尚未对该插件做风险分级（暂未覆盖，不等同于无风险）
- 还在维护吗
- 活跃：最近一次提交在 10 天前
档位由下列信号合成：本站实装验证（真实安装，当前最高到 L4）· 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。下方各区块是它的证据明细。 验证判据与等级说明 →
🟢实装验证通过· 2026/9/23
由本站实装验证器在真实 dsh 环境安装成功，非静态推断。
数据截至 2026/9/23（元数据每日更新 · 实装验证按队列轮转，单条结论的验证时间见上方）
安装兼容性检查⚠ 装前注意
以下结论由程序自动检查 npm 包、engines 声明与入口文件得出，未做人工实机验证——能装不等于用着没问题。
✗npm 包@marcsierszen/dsh-specify-lite（未发布到 npm，仅可源码安装）
✓Node 引擎要求 >=20 · 基线 Node 22.19 满足
✓dsh CLI 依赖未声明 dsh 版本约束
✓入口文件main/exports/bin 已声明
未发布到 npm registry，仅可从源码安装
验证方式：npm registry 存在性 + package.json 静态校验 · 最后验证 2026/9/23 05:50:51
依赖的 DSH / Cordis 模块
@deepseek-ai/cordis@deepseek-ai/dsh-skill用户评分
还没有人投票，来当第一个
订阅周报，不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
由 DeepSeek 最新模型翻译生成dsh-specify-lite
从清晰的想法到经过验证的实现——原生运行于 DSH。
Listed on dsh-plugin.org
DSH native
Node.js
License
清晰地规约。审慎地规划。安全地实现。
一个精简的、仅限 DSH 的插件，用于规约驱动开发（SDD）。它最初从 @904915452/dsh-specify 迁移而来，现在作为 dsh-specify-lite 独立维护。它受 GitHub Spec-Kit 启发，但独立且不兼容：它不会安装或使用 Spec-Kit 或任何外部 SDD CLI。
✨ 快速开始
安装插件，然后在你的项目根目录运行工作流：
dsh plugin --profile web add git+https://github.com/MarcSierszen/dsh-specify-lite.git
/speckit init
/speckit-constitution
/speckit-specify
/speckit-plan
/speckit-tasks
/speckit-analyze
/speckit-implement
初始化仅创建 .speckit/ 和 specs/，安全且幂等。经过测试的最低 DSH 版本为 0.1.1-rc.2；需要 Node.js 20 或更高版本。
🧭 工作流
principles contract design execution
│ │ │ │
▼ ▼ ▼ ▼
constitution → specify → plan → tasks → analyze → implement
每个阶段都会产出可检查的工件，保持范围明确，并以你可以验证的证据结束。
🧰 命令
| 命令 | 用途 |
| --- | --- |
| /speckit | 帮助、初始化以及推导出的项目阶段 |
| /speckit-constitution | 定义可选的、项目范围的原则 |
| /speckit-specify | 创建或修订功能规约 |
| /speckit-clarify | 解决有重大影响的歧义 |
| /speckit-plan | 产出基于仓库信息的技术计划 |
| /speckit-tasks | 产出有序、可追溯的任务列表 |
| /speckit-analyze | 执行只读的质量审查 |
| /speckit-implement | 实现已批准的任务并记录验证结果 |
为什么选择 dsh-specify-lite？ API 优先的思维、确定性的工件、写入前的明确确认、不修改 Git，以及对单一本地模型的出色支持——全部在 DSH 内完成。
⚡ 设计上采用单模型
免责声明： dsh-specify-lite 不使用子代理或并行任务执行。它在单个代理会话中运行工作流，使上下文、编辑和验证保持可预测。
这种聚焦式设计尤其适合单个本地模型：没有编排开销，没有多智能体协调，并且从规范到经过验证的实现有一条清晰的端到端路径。
第一步：章程与健康检查 API
这个示例先建立项目级原则，然后定义 API 契约并实现其第一个端点。
从项目根目录开始：
/speckit init
/speckit-constitution
当提示输入项目原则时，输入：
Use Python for the service. Design the API contract first. Follow RESTful API conventions.
然后创建第一个功能规范：
/speckit-specify
当提示输入功能时，输入：
Add a health endpoint: GET /health returns HTTP 200 and JSON {"status":"ok"}. The endpoint must not require authentication and should be suitable for automated health checks.
然后继续交付路径：
/speckit-plan
要求给出保持 /health 契约并遵循章程的最小实现。然后运行：
/speckit-tasks
/speckit-implement
实现应添加服务和 GET /health 的测试，验证 200 响应和确切的 JSON 正文，并将验证证据记录在 tasks.md 中。生成的契约是：
GET /health
Accept: application/json
200 OK
Content-Type: application/json
{"status":"ok"}
布局
.speckit/
└── constitution.md # optional
specs/
└── 001-feature-slug/
├── spec.md
├── plan.md
└── tasks.md
使用 --feature 001-feature-slug、唯一 slug 或 specs/001-feature-slug 来选择功能。功能标识绝不来自 Git 分支。
任务使用稳定的 T001 风格 ID。部分实现接受例如 --tasks T003,T005-T008；选定的工作按其在 tasks.md 中出现的顺序排列。tasks.md 中已完成的复选框和 JSON 验证记录决定派生阶段：not-started、specified、planned、tasked、in-progress 和 complete。完成要求每个任务都已完成，外加一条最终全范围通过的验证记录。
工件编辑是显式的：现有工件在被更改之前会先被读取、提议并确认。/speckit-implement 在其选定的源代码编辑、复选框更新和验证记录之前会询问一次。它在选择测试之前会检查项目文档和包脚本，如果没有明确的测试命令则会询问。
该插件从不改变 Git 状态：它不会创建、切换、重置、暂存、提交、合并或变基分支。
初始迁移与当前独立性
该项目最初是从 904915452/dsh-specify 迁移而来，并感谢该起点。当前的 dsh-specify-lite 代码库独立维护，不承诺与前任兼容。
破坏性重新设计
版本 0.2.0 是破坏性重新设计：它使用上述仅限 DSH 的三工件模型。
0.2.0 之前版本的遗留产物
使用旧版产物的项目必须手动迁移：将功能目录移入 specs/，将 specify.md 重命名为 spec.md，并将任何章程文件移动到 .speckit/constitution.md。丢弃不受支持的棕地或分支元数据；不要创建 status.json 或 checklist.md。