@marcsierszen/dsh-specify-lite
Lean 仅支持 DSH 的规范驱动开发技能
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:MarcSierszen/dsh-specify-lite#e678254ff475031adf1432e6c3247957ae3ce320Specify Lite 以 @marcsierszen/dsh-specify-lite 发布，当前版本为 0.2.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
Specify clearly. Plan deliberately. Implement safely.
A lean, DSH-only plugin for spec-driven development (SDD). It was initially migrated from @904915452/dsh-specify and is now independently maintained as dsh-specify-lite. It is inspired by GitHub Spec-Kit, but is independent and incompatible: it does not install or use Spec-Kit or any external SDD CLI.
Install the plugin, then run the workflow from your project root:
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
Initialization creates only .speckit/ and specs/, safely and idempotently. The minimum tested DSH release is 0.1.1-rc.2; Node.js 20 or newer is required.
principles contract design execution
│ │ │ │
▼ ▼ ▼ ▼
constitution → specify → plan → tasks → analyze → implement
Each stage produces inspectable artifacts, keeps scope explicit, and ends with evidence you can verify.
| Command | Purpose |
|---|---|
/speckit | Help, initialization, and derived project stage |
/speckit-constitution | Define optional project-wide principles |
/speckit-specify | Create or revise a feature specification |
/speckit-clarify | Resolve consequential ambiguity |
/speckit-plan | Produce a repository-informed technical plan |
/speckit-tasks | Produce an ordered, traceable task list |
/speckit-analyze | Perform a read-only quality review |
/speckit-implement | Implement approved tasks and record verification |
Why dsh-specify-lite? API-first thinking, deterministic artifacts, explicit confirmation before writes, no Git mutation, and excellent single-local-model support — all within DSH.
Disclaimer: dsh-specify-lite does not use subagents or parallel task execution. It runs the workflow in one agent session, keeping context, edits, and verification predictable.
That focused design works especially well with a single local model: no orchestration overhead, no multi-agent coordination, and a clear end-to-end path from specification to verified implementation.
This example establishes project-wide principles first, then defines the API contract and implements its first endpoint.
From the root of a project:
/speckit init
/speckit-constitution
When prompted for the project principles, enter:
Use Python for the service. Design the API contract first. Follow RESTful API conventions.
Then create the first feature specification:
/speckit-specify
When prompted for the feature, enter:
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.
Then continue the delivery path:
/speckit-plan
Ask for the smallest implementation that preserves the /health contract and follows the constitution. Then run:
/speckit-tasks
/speckit-implement
The implementation should add the service and tests for GET /health, verify the 200 response and exact JSON body, and record the verification evidence in tasks.md. The resulting contract is:
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
Use --feature 001-feature-slug, a unique slug, or specs/001-feature-slug to select a feature. Feature identity never comes from a Git branch.
Tasks use stable T001-style IDs. Partial implementation accepts, for example, --tasks T003,T005-T008; selected work is ordered as it appears in tasks.md. Completed checkboxes and JSON verification records in tasks.md determine derived stages: not-started, specified, planned, tasked, in-progress, and complete. Completion requires every task complete plus a final full-scope passing verification record.
Artifact edits are explicit: existing artifacts are read, proposed, and confirmed before changes. /speckit-implement asks once before its selected source edits, checkbox updates, and verification record. It inspects project documentation and package scripts before choosing tests and asks if no test command is clear.
The plugin never mutates Git state: it does not create, switch, reset, stash, commit, merge, or rebase branches.
This project began as an initial migration from 904915452/dsh-specify, with credit to that starting point. The current dsh-specify-lite codebase is independently maintained and does not promise compatibility with the predecessor.
Version 0.2.0 is the breaking redesign: it uses the DSH-only three-artifact model above.
Projects using older artifacts must migrate manually: move feature directories into specs/, rename specify.md to spec.md, and move any constitution to .speckit/constitution.md. Discard unsupported brownfield or branch metadata; do not create status.json or checklist.md.