By ssdiwu
diwu 编码工作流套件:项目初始化、任务规划、产品需求文档、架构决策记录、产品文档、纠偏恢复。内置规则体系重构、纠偏机制、证据优先级与误判防护
记录架构决策(ADR),输出到 .doc/adr/ 目录
纠偏恢复命令——当 AI 偏离主线时,按五步协议重新回到目标/主线/现象/验证四个锚点
将不确定性隔离为可复用的能力验证单元,输出 Demo 规格与目录结构
产品文档工具,支持正向(需求→文档)和逆向(代码→文档)两种模式
初始化项目的 Claude Code Agent 工作流结构——编排器模式。创建 CLAUDE.md、rules、agents、skills symlink、dtask.json、recording/、checks/ 等完整工作流骨架。触发场景:(1) 新项目初始化工作流结构,(2) 已有项目刷新/升级 diwu-workflow 配置,(3) 用户说"初始化"、"init"、"初始化工作流"、"dinit"。编排器模式:交互式步骤(信息收集/迁移检测/架构约束/git 初始化/验证清单)在主代理上下文执行,I/O 密集型步骤(代码库扫描/资产同步/文件创建)分发给子代理并行处理。
当需要编写 API 测试、设计测试策略或验证接口契约时触发。典型场景:设计测试金字塔策略(契约测试/集成测试/E2E 分层覆盖)、验证 OpenAPI/Swagger 规范与实际实现的一致性、编写边界用例与异常输入覆盖(空值/超长/特殊字符注入)、根据技术栈选择测试框架(Python pytest/JS Jest/Go testing)。Use proactively when writing API tests, designing test strategy, or validating interface contracts.
当需要设计新 API、选型数据库或排查服务端性能问题时触发。典型场景:评审 RESTful/GraphQL schema 设计(请求格式/版本控制/错误处理)、审查数据库 schema 与索引策略(规范化 vs 反范式化)、评估服务端分层架构选型(MVC/CQRS/微服务)、设计缓存策略(本地缓存/Redis/CDN 层级)。Use proactively when designing APIs, choosing database tech, or diagnosing backend performance.
当需要搭建 CI/CD 流水线、容器化应用或设计部署流程时触发。典型场景:设计 GitHub Actions/GitLab CI 流水线(构建/测试/部署阶段编排)、编写 Docker Compose/K8s 容器化配置、选择部署策略(蓝绿部署/金丝雀发布/滚动更新)、配置 Prometheus/Grafana 监控告警规则。Use proactively when setting up CI/CD, containerizing apps, or designing deployment pipelines.
代码库调查、架构分析、文件搜索、技术调研专家。当需要深入理解代码库结构、追踪依赖关系、分析模块边界时使用此代理。
当需要做前端技术选型、重构前端架构或优化加载性能时触发。典型场景:对比并选择状态管理方案(Redux/Zustand/Pinia/Jotai 适用边界)、评审组件架构(原子设计/复合组件拆分粒度)、制定构建优化策略(code splitting/tree shaking/lazy loading)、分析包体积并规划按需加载路径。Use proactively when doing frontend tech selection, refactoring architecture, or optimizing bundle size.
归档管理——Task 归档与 Recording 物理归档的双轨机制、触发条件、手动步骤、验证清单。触发场景:(1) 终态任务数超阈值,(2) session 文件数超阈值,(3) 用户说"归档"、"archive"、"清理"
纠偏与误判排查方法论——退化信号检测、四行重写模板、止损序列、六类泛化误判排查表、与 BLOCKED 的边界判定。触发场景:(1) 出现退化信号(反复纠偏/目标漂移/证据缺失等),(2) 需要纠偏恢复,(3) 排查误判,(4) 判断是 correction 还是 BLOCKED,(5) 用户说"纠偏"、"偏了"、"不对"、"重写"、"止损"、"误判"
积木式能力验证方法论——判断「直接做 vs 先验证」、将不确定性分层隔离、沉淀可复用能力资产。触发场景:(1) 讨论技术可行性或方案选型,(2) 评估某个实现的不确定性,(3) 决定直接集成 vs 先做 Demo 验证,(4) 分析能力复用或知识沉淀策略,(5) 用户说"积木"、"Demo"、"能力验证"、"不确定性"
产品文档工具——正向(需求→文档)或逆向(代码→文档)两种模式。触发场景:(1) 为已有产品还原/补全文档,(2) 为新功能/模块编写产品文档,(3) 用户说"写文档"、"还原文档"、"doc"、"产品文档"
阶段边界决策锚点——四段式判断(启动/实施/验收/纠偏),含正例/反例/边界例。覆盖:基线失败处理、不确定性决策、入口门控、大幅度判定、执行偏差分级、并行串行选择、超前实施、Done 人工确认、blocked_by 判定、循环依赖、continuous_mode 续跑、recording 写入时机、decisions.md 写入时机。触发场景:(1) 需要做阶段边界决策,(2) 判断幅度大小,(3) 选择并行还是串行,(4) 判断是否需人工确认,(5) 用户说"判断"、"决策"、"幅度"、"并行"、"确认"
Matches all tools
Hooks run on every tool call, not just specific ones
Executes bash commands
Hook triggers when Bash tool is used
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
Modifies files
Hook triggers on file write and edit operations
Modifies files
Hook triggers on file write and edit operations
Uses power tools
Uses Bash, Write, or Edit tools
Uses power tools
Uses Bash, Write, or Edit tools
diwu 编码工作流套件 — Claude Code 插件(v0.10.2)。让 AI 按确认的需求执行开发任务,而非自行发挥。
/plugin marketplace add ssdiwu/diwu-workflow
/plugin install diwu-workflow@ssdiwu
/dinit # 初始化工作流结构(CLAUDE.md / task.json / hooks / rules / agents)
/dprd # 讨论方案,生成 PRD,识别 Demo 需求
/dadr # 有架构决策时记录(可选)
/ddoc # 基于 PRD 正向生成产品文档
/ddemo # 对每个 Demo 需求生成落地方案
/dtask # Demo 验证通过后,拆解集成任务列表
示例:做「消息通知」功能 →
/dprd讨论推送方式 → 确定用 WebSocket 时/dadr记录决策 →/ddoc写产品文档 →/ddemo为不确定功能点生成验证方案 →/dtask拆集成任务。
/ddoc # 逆向还原现有代码的产品文档
/dprd # 基于现有产品讨论新需求
/dadr # 记录新的架构决策(可选)
/ddoc # 正向补充新功能文档
/dtask # 拆解新功能任务
| 命令 | 一句话 | 详细说明 |
|---|---|---|
/dinit | 初始化工作流结构 | v2 精简 CLAUDE.md + rules + agents + 迁移检测 |
/dprd | 生成产品需求文档(PRD) | 竞品分析、用户画像、需求优先级、非功能性需求 |
/dadr | 记录架构决策(ADR) | 输出到 .doc/adr/,支持新建与更新 |
/ddoc | 产品文档工具 | 正向(需求→文档)或逆向(代码→文档)两种模式 |
/ddemo | 不确定性功能点验证 | 将不确定性隔离为可复用的能力验证单元 |
/dtask | 任务管理 | 功能描述→task.json 任务列表,含 GWT acceptance |
/dcorr | 纠偏恢复协议 | 四行重写 → 误判排查 → 重判门控 → 恢复骨架 |
每个命令的约束表说明「必须同时为真的约束集合」——违反任一约束,输出即不可信。
| 维度 | 约束 |
|---|---|
| 业务 | 已存在的文件不覆盖(幂等);规则写入 .claude/rules/,不内联到 CLAUDE.md |
| 时序 | 收集信息 → 创建文件 → 验证清单;不可跳过信息收集直接创建文件 |
| 跨命令 | 创建的 .diwu/dtask.json 结构必须与 /dtask 写入格式兼容 |
| 感知 | 验证清单全部通过才算完成;缺少任一文件不算初始化成功 |
| 维度 | 约束 |
|---|---|
| 业务 | Layer 0 未通过时 Layer 1 不得开始;不写 task.json;不生成代码;Demo 需求名称必须 kebab-case |
| 时序 | 确认定位 → Q1-Q8 逐问(每次只问一个)→ 检查已有 PRD → 脊梁提炼(用户确认)→ 论证链设计(用户确认)→ 积木选取 → 反模式门禁 → 写入 → 自检 |
| 跨命令 | PRD README 的 Demo 需求列是 /ddemo 的输入;.doc/README.md 和 .doc/adr/README.md 是 Q5 的前置读取 |
| 感知 | 交付前自检:智能引号 0 命中、绝对路径 0 命中、乱码 0 命中;否则不可交付 |
| 维度 | 约束 |
|---|---|
| 业务 | 同一决策只有一个 ADR(更新不新建);Context 必须有具体数字;Consequences 的 ⚠️ 必须有触发条件和解决路径 |
| 时序 | 先读 README 判断新建/更新 → 写文件 → 更新 README;不可先写文件再判断 |
| 跨命令 | ADR README 是 /dprd Q5 的输入;ADR 编号格式 ADR-NNN 是 /dtask steps 引用的依据 |
| 感知 | 备选方案的缺点必须是具体技术风险和触发条件,不允许「复杂度高」等模糊描述 |
| 维度 | 约束 |
|---|---|
| 业务 | 代码是锚点,无法确认的内容标注 [待确认],不编造;逆向模式不写 task.json(大范围除外) |
| 时序 | 写文档 → 自审 → gap 分析(两层)→ 补充缺口 → 再次 gap 分析;gap 分析必须在自审之后 |
| 跨命令 | .doc/README.md 是所有命令的入口;每次写入文档后必须同步更新 README(通用货币维护义务) |
| 感知 | 有状态实体必须有 stateDiagram;核心业务流程必须有 flowchart;数据实体关系必须有 erDiagram |
flowchart TD
A[选择模式] --> B{正向 or 逆向?}
B -->|正向:需求→文档| C[六步设计法]
C --> C1[找约束:五维度]
C1 --> C2[定义原子]
C2 --> C3[设计组合]
C3 --> C4[划定边界]
C4 --> C5[降级路径]
C5 --> C6[同步策略]
C6 --> Out[输出到 .doc/]
B -->|逆向:代码→文档| D[读取代码库]
D --> E[写文档 + 自审]
E --> F[两层完整性检查]
F --> G{有缺口?}
G -->|是| H[补充后重新检查]
H --> E
G -->|否| Out
| 维度 | 约束 |
|---|---|
| 业务 | 每次只处理一个 Demo;两级门控(先判产品类型,再判能力 vs 功能);核心验证资产篇幅 > 50%;不写生产架构;不写 task.json |
| 时序 | 两级门控 → 读 README(不全量扫描)→ 建立上下文 → 生成 → 写入 → 更新 Demo README |
| 跨命令 | Demo 文件路径格式 DEMO-{kebab-case-name}-spec.md 是 /dtask 的查找依据;通过标准必须可量化(供 /dtask acceptance 引用) |
| 感知 | 核心验证资产必须可直接运行(Prompt 全文 / 测试矩阵 / 测试脚本),不允许伪代码占位 |
| 维度 | 约束 |
|---|---|
| 业务 | task ID 永不复用(跨 task.json 和 archive);functional/ui/bugfix 类 acceptance 必须 GWT 格式;steps 必须自包含(绝对路径,无隐式上下文依赖) |
| 时序 | 先确定最大 ID → 澄清问题 → 生成 → 质量检查 → 可选三视角审查 → 写入;ID 确定必须在生成之前 |
| 跨命令 | 写入的 task.json 是工作流引擎(hooks + Session 启动)的输入;blocked_by 引用的 ID 必须存在于 task.json 或 archive |
| 感知 | 质量检查发现问题时必须列出具体问题 + 建议修正,不可静默写入 |
flowchart TD
A[接收功能描述] --> B[澄清问题<br>目标 / 边界 / 成功标准]
B --> C[确定新任务 ID<br>task.json + archive 取最大值+1]
C --> D[生成任务列表<br>写入 .diwu/dtask.json]
D --> E[质量检查<br>GWT格式 / 可验证 / 垂直切片]
E --> F{复杂任务?}
F -->|functional/ui 且 acceptance>3| G[三视角审查<br>开发 / QA / 业务]
F -->|否| H[写入后提示]
G --> H
| 维度 | 约束 |
|---|---|
| 业务 | 不改变 task.json 状态(纠偏是过程修正,不是状态转移);不退化成全程运行总规范或禁止清单 |
| 时序 | 触发检测 → 停止 6 类动作 → 四行重写 → 误判排查(6 类泛化模式)→ 入口重判(A/B/C 三门控)→ 恢复执行骨架 → 结束前四问 |
| 跨命令 | 与 InProgress 任务共存时不改变状态,仅记录到 session 文件;恢复失败按止损序列处理(切上下文 → 缩任务 → 写缺口 → 请求人工) |
| 感知 | 恢复后第一条输出禁止宣称"已完成";判断必须有依据(正例/反例/现象/数据);验证优先级 L1-L3 主判,L5 不可宣称完成 |
触发条件(满足任一即启动):
| # | 退化信号 |
|---|---|
| 1 | 同一问题已被纠偏两次以上仍沿旧路径推进 |
| 2 | 同一前提被反复解释 |
| 3 | 输出越来越像通用套路,越来越不像当前任务 |
| 4 | 讨论越来越长,下一步动作越来越模糊 |
| 5 | 已改动却拿不出运行态或输出层证据 |
| 6 | 开始同时引用多个目录、多个入口、多个"真相源" |
核心变化:从旧版全量注入 ~1500 行重构为 v2 架构:「~80 行基线 CLAUDE.md + 10 个按需加载 Skill + 4 个参考文件」。
三层加载策略:
npx claudepluginhub ssdiwu/diwu-workflow --plugin diwu-workflowDocument Driven Development — a structured workflow for AI-assisted software development with TDD, specs, and cross-review
Specification-driven development workflow: specify → plan → tasks → implement
Complete development toolkit - documentation, PRDs, design docs, debugging, PR workflows, and planning
Spec-driven development for big features. When features get too big, plan mode gets too vague—leading to hallucinations during implementation. ShipSpec replaces vague plans with structured PRDs, technical designs, and ordered tasks that keep Claude grounded.
Hypo-Workflow for Claude Code. The plugin namespace is intentionally `hw`; plugin-root commands map /hw:* to existing workflow Skills.
Harness-native ECC operator layer - 67 agents, 271 skills, 92 legacy command shims, reusable hooks, rules, selective install profiles, and production-ready workflows for Claude Code, Codex, OpenCode, Cursor, and related agent harnesses