Stats
Actions
Tags
From docloom
Use when docloom-author, fix, or build-spec requires option-based interactive dialogue with approval.
How this skill is triggered — by the user, by Claude, or both
Slash command
/docloom:docloom-brainstormThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
docloom 生态专属交互引擎——接收 `topic` + `context`，AI 根据上下文生成 2-3 个候选方案（含推荐），用户选择后逐章/逐条推进。全部完成后呈现完整设计给用户批准，返回结构化结果给调用方。禁止开放式提问。
docloom 生态专属交互引擎——接收 topic + context，AI 根据上下文生成 2-3 个候选方案（含推荐），用户选择后逐章/逐条推进。全部完成后呈现完整设计给用户批准，返回结构化结果给调用方。禁止开放式提问。
调用方（docloom-author、docloom-fix、docloom-build-spec）需要跟用户进行结构化交互时使用。不直接由用户触发。
context 传入所有上下文数据topic 参数必填：author、fix、build-spec、collect-paramstopic — string，必填。author / fix / build-spec / collect-params
collect-params：逐参数收集，每次一个，已有值不重复问context — string，调用方传入的上下文数据禁止开放式提问。 每轮必须提供 ≥2 个候选方案，AI 给出推荐 + 理由。用户选择或要求修改一个方案——不回退到"你觉得应该怎么写？"。
所有 topic 共享流程：
逐章/逐条：AI 生成 2-3 个候选方案（含推荐）→ 用户选择/修改
↓
全部完成后：呈现完整设计 → 用户批准
↓
返回结构化结果给调用方
spec 章节清单——列出每章名称和 spec 要求。
待修复 entry 列表。
spec-doc.spec.md 完整内容 + doc_type。
spec-doc.spec.md，理解 ## 结构声明 的 3 段式结构doc_type 语义，自动填空——能推导的部分直接填入，不逐章问## 结构声明 各段的编写规则（Frontmatter 固定 type: spec-doc，元信息按 ## 必要章节 模板，规则集每条含 严重度/约束/检查）参数定义列表——调用方传入需要收集的参数名、类型、必填/可选、说明。
{param_name: value, ...}输入 context：3 章 spec（背景、目标、架构）
第 1 章 背景：
第 1/3 章：背景 — 2 种撰写方案
A（推荐）： 从业务痛点切入 → 引出技术现状 → 说明为什么要改变。详细程度：2-3 段，含具体数据和场景描述。 B： 简洁概述——1 段说明背景，不展开细节。适合快速原型文档。
推荐 A——详细的背景为后续目标和技术决策提供上下文支撑。
选择 A/B，或描述你想要的修改？
用户：A
第 2 章 目标：
第 2/3 章：目标 — 3 种撰写方案
A（推荐）： 功能驱动——按用户故事或功能模块列目标，每项目标可量化验证。3-5 条。 B： 问题驱动——按要解决的核心问题列目标，每项对应一个待解决问题。2-4 条。 C： 技术驱动——按技术里程碑列目标，适合基础设施类文档。3-4 条。
推荐 A——功能驱动对大多数设计文档最直观，下游 reviewer 可按功能逐项验证。
选择 A/B/C，或描述修改？
用户：B
第 3 章 架构： <AI 生成方案，用户选择>
汇总批准：
全部 3 章选择概览：
- 背景：方案 A（业务痛点切入）
- 目标：方案 B（问题驱动）
- 架构：方案 A（分层架构图 + 组件说明）
批准后开始生成文档？
用户：批准
输入 context：2 条 entry
第 1 条：
Entry 1/2：[严重] 缺少前置条件说明 位置：SKILL.md §前置条件
A（推荐）： 在 §前置条件 新增 2 条——"调用方传入完整 context"+"topic 参数必填" B： 在 §前置条件 新增 1 条——"调用方传入完整 context"（topic 必填已在参数声明体现，此处不重复） C： 新增独立 §调用约定 章节，包含 context 和 topic 的完整说明
推荐 A——前置条件章节是现有的自然位置，2 条覆盖了调用依赖，改动最小。
选择 A/B/C，或跳过？
用户：A
第 2 条： <AI 生成方案，用户选择>
汇总批准：
修复计划概览：
- Entry 1：已选 A
- Entry 2：跳过
批准后执行修复？
用户：批准
输入 context：doc_type=design，spec-doc.spec.md 完整内容
AI 先自动填空，完成后呈现：
已完成部分（自动推导）：
- Frontmatter：
type: spec-doc- 目的：确保设计文档覆盖问题陈述、方案设计、技术选型，每部分独立可验证
- 非目的：不覆盖实现细节、测试方案、部署计划
- 产出文件命名：
<topic>-design.md- 必要章节：问题陈述、方案设计、技术选型、风险、计划
需确认项（3 项）：
- 输入参数 — 建议：
topic（string，必填，设计主题）+context（string，可选，背景信息）。确认？- 结构声明 — 按 spec-doc 默认 3 段式。确认？
- 规则集 — 基于 5 个必要章节生成 6 条最小规则：
- DSG-001：必须包含问题陈述
- DSG-002：方案设计含架构图
- DSG-003：技术选型含理由
- DSG-004：风险含缓解方案
- DSG-005：计划含里程碑
- DSG-006：引用链接用引用式格式
确认或修改？
用户：输入参数加一个 stakeholders（可选）。其他确认。
AI 更新，呈现完整 spec → 用户批准
第 2/3 章：目标 — 3 种方案...
用户：都不合适，我想要从竞品对比角度写
接受用户描述的新方向，基于新方向重新生成方案而非退化为"那你想怎么写？"
返回格式与旧版一致（YAML），不变。
Q: 用户要求自己写内容怎么处理？
A: 接受。但不等同于"退化为开放式提问"——用户主动提供内容是合法的选择。区别在于 AI 不能主动以开放式问题启动一轮对话。
Q: context 信息不足时生成不了方案怎么办？
A: 基于已有信息推断——即使推断不完美，也比让用户从零开始想答案好。如果确实无法生成方案（如 doc_type 未知），告知调用方 context 不足并等待补充。
npx claudepluginhub mikforge/mikforge-agent-tools --plugin docloomProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.