npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

specworkflow

v0.1.0

Published

Workflow skill pack for DeepSeek Harness: requirement grilling, specs, implementation, delivery review, repair planning, bug diagnosis, and source-backed research.

Readme

SpecWorkflow

English | 中文

SpecWorkflow 是一套可分享的 workflow skill pack,面向 DeepSeek Harness 和其它兼容 Agent Skills 的工具。它给 Agent 一条清晰路径:从粗糙需求开始,推进到需求澄清、实施规格、代码执行、交付检查、修复规划、bug 诊断和带来源的调研。

它不会把每个请求都拖进重流程。简单明确的修改可以直接处理;需求模糊、跨模块、影响产品体验、数据、权限、接口或发布风险的工作,才进入完整 workflow。

SpecWorkflow Architecture

功能

| 阶段 | Skill | 处理内容 | | --- | --- | --- | | 调研 | deep-research | 基于官方文档、API、标准、源码等一手来源做调研。 | | 1 | to-grill | 需求质询、消除歧义、风险审查,并判断直接实施还是进入完整流程。 | | 2 | to-spec | 编写可实施 spec、修订说明、验收标准、验证计划和可选 tickets。 | | 3 | spec-do | 根据已批准的 spec、issue、修订或修复计划进行实施。 | | 4 | do-review | 对照需求、spec、代码和证据做最终交付检查。 | | 5 | fix-review | 把 must-fix review findings 转成修复 spec 和修复 tickets。 | | 调试 | bugs-fix | 针对 bug、回归和性能问题做复现、根因定位、修复和证据留存。 |

安装

DSH

dsh plugin --profile web add specworkflow
dsh web

其它 Agent

npx specworkflow install codex

使用 -g 安装到全局目录:

npx specworkflow install -g codex

需要时把 codex 换成其它预设:

| 输入 | 项目安装位置 | -g 全局安装位置 | | --- | --- | --- | | codex, openai, agents, agent, agent-skills, agents-md, goose, zed, amp, sourcegraph-amp | .agents/skills | ~/.agents/skills | | gemini, gemini-cli, antigravity, google-antigravity | .agents/skills | ~/.gemini/antigravity/skills | | claude, claude-code, claudecode | .claude/skills | ~/.claude/skills | | cursor, cursor-agent, cursor-native | .cursor/skills | ~/.cursor/skills | | copilot, github-copilot, vscode, vs-code | .github/skills | ~/.github/skills | | dsh, deepseek, deepseek-harness | .dsh/skills | ~/.dsh/skills | | opencode, open-code | .opencode/skills | ~/.opencode/skills | | windsurf, cascade | .windsurf/skills | ~/.windsurf/skills | | cline, claudine | .cline/skills | ~/.cline/skills | | roo, roo-code, roocode | .roo/skills | ~/.roo/skills | | qwen, qwen-code, qwencode | .qwen/skills | ~/.qwen/skills | | kiro | .kiro/skills | ~/.kiro/skills | | kilo, kilo-code, kilocode | .kilo/skills | ~/.kilo/skills | | augment, augment-code, augmentcode, auggie | .augment/skills | ~/.augment/skills | | openclaw, claw | skills | ~/.openclaw/skills |

未识别的纯名称会直接报错,避免因为拼错而创建错误目录。如果当前工具不在预设里,请传入明确的项目级 skills 路径:

npx specworkflow install .my-agent/skills

-g 时,相对显式路径会从用户 home 目录解析。

快速开始

典型功能开发:

使用 to-grill 澄清这个需求,需求收口后再进入 to-spec。

简单修改保持简单:

把表格字体调大一点。

这类请求应该直接实施,不应该强行进入五阶段流程。

工作流

SpecWorkflow 的第一步不是写 spec,而是判断这件事值不值得进入 spec。很多请求本来就很小,比如改一段文案、调一个样式、补一个明显遗漏的判断;这类工作应该直接完成。

只有当需求开始牵涉产品含义、数据语义、权限边界、跨模块影响、发布风险,或者“做错了会很难收拾”时,才进入完整流程。同一件事产生的材料都放在同一个 .spec-workflow/<feature-slug>/ 目录下,后续每一轮都能接得上。

to-grill -> to-spec -> spec-do -> do-review -> fix-review -> spec-do repair -> do-review

to-grill 负责把模糊需求压实。它不是机械提问,也不是把仓库里能查到的事实甩给用户确认;它会先自己读上下文、找现有实现、识别真正需要用户拍板的地方。到这一阶段结束时,应该已经知道这件事是直接改、暂缓、还是进入 spec,并留下可以交给下一步使用的需求结论。

to-spec 把结论变成实施契约。好的 spec 不只是“要做什么”,还要写清楚不做什么、哪些模块会受影响、数据和权限怎么处理、用户最终会看到什么、验收时看哪些证据。如果是在已有 spec 上做调整,它会记录修订和影响范围,而不是把历史上下文抹掉重写一份。

spec-do 才真正动代码。实施前先处理 git 分支、脏工作区和是否允许自动提交;实施时按已批准的 spec、tickets、修订或修复计划推进。临时证据、调试脚本、截图和运行记录可以放进 .spec-workflow,但长期存在的测试必须回到项目自己的测试目录。这里有一条硬规则:业务逻辑要真实接上,不能为了让验证变绿而 mock 掉系统本身。

实现完成后,do-review 接手判断能不能交付。它会把原始需求、spec、代码 diff、测试和证据放在一起看,找遗漏、回归、边界和验收缺口。review 不是顺手修代码的阶段,也不应该暗中扩大范围;它只负责给出清楚的 ship / no-ship 判断。

如果 review 发现必须修的问题,fix-review 会把这些 finding 收束成修复计划。它关心根因、优先级、验证方式和是否需要拆 ticket,然后把修复计划交回 spec-do。修完以后再回到 do-review,形成一个很短的闭环;直到结果可以交付,或者下一步确实需要用户做决定。

deep-researchbugs-fix 不属于主链上的固定阶段,更像两条随时可以插入的支线。遇到外部事实、官方文档、API 行为、标准差异时,先用 deep-research 把依据找齐;如果起点不是新需求,而是失败、回归、异常或性能问题,就直接走 bugs-fix,先复现和定位根因。

Goal Mode 是给单个 spec 用的连续执行开关。用户明确启用后,Agent 可以从实施一路跑到 review、修复规划、修复实施和再次 review,不必每个交接点都停下来等确认。但它不是无限授权;遇到产品选择、安全风险、git 决策、验证缺口、环境问题或 scope 变化时,仍然要停下来。

目录产出

SpecWorkflow 把 workflow 文件放在 .spec-workflow 下,避免把项目代码和 Agent 证据混在一起。

.spec-workflow/<feature-slug>/
  requirements.md
  spec.md
  issues/
  amendments/
  implementation/
  review/
  repair-spec.md
  repair-issues/
  verification/
  debug/
  bugs/
  research/

项目长期测试仍然放在项目原本的测试目录,不放进 .spec-workflow

验证

安装到 DSH 后运行:

dsh --profile web --dump-config

组合配置里应该出现:

# == specworkflow
- id: specworkflow
  name: specworkflow

也可以直接询问 Agent 当前有哪些 SpecWorkflow skills,以及什么时候使用 to-grill

卸载

dsh plugin --profile web remove specworkflow

web 换成你实际安装的 profile。

许可证

MIT. See LICENSE.