From loom-engineering
Guides structured brainstorming of 2-3 implementation options with trade-offs for new features or requirements before writing a plan.
How this skill is triggered — by the user, by Claude, or both
Slash command
/loom-engineering:loom-brainstorming <feature request or product idea>When to use
Explore implementation options, trade-offs, or requirements for a new feature before writing a plan.
<feature request or product idea>The summary Claude sees in its skill listing — used to decide when to auto-load this skill
- 用户提出新需求、功能描述或 PRD。
loom-pipeline-selector 命中 quickfix/bugfix 流程。本阶段应创建或使用 specs/<date+feature>/ 作为 specDir。所有阶段产物都必须写入该目录内;禁止在项目根目录写 spec.md、progress.md 或 handoffs/。
.loom/rules/product.md,先读取,作为产品定位、目标用户和原型约束的视角依据(PM / pm-prototype 流水线)。.loom/rules/constitution.md,读取其中架构、目录和编码约束。如果预计涉及模型、布局、架构图等可视化内容,单独询问用户是否使用浏览器展示。详细流程见 references/visual-companion.md。
每个方案包含:方案名称、架构思路、数据流、trade-off、实现步骤。以推荐方案开头并解释原因;如果范围跨多个独立子系统,先建议拆分。
先区分问题来源:能通过读取代码、文档、spec 或现有约定回答的问题,必须先自行探索,不要问用户。
对简单需求,把待决议项集中展示给用户,优先给多选项:
## 待决议项
| # | 问题 | 选项 |
| --- | -------------- | --------------------------------- |
| 1 | 数据存储方式? | A: 关系型数据库 / B: 文档型数据库 |
对复杂需求进入一问一答澄清:
用户确认方案后,写入 specs/<date+feature>/spec.md。文件夹命名格式:<YYYY-MM-DD>+<功能名>,如 2026-04-26+user-management。
使用 assets/spec-template.md 作为结构模板,并按项目类型删去不适用章节。
TBD、TODO 或未完成段落。自审通过后让用户审查 spec。用户要求修改时,修复并重新自审;只有用户批准后才继续 writing-plans。
用户批准 spec 后,写入 specs/<date+feature>/handoffs/brainstorming.json,至少包含:
{
"stage": "brainstorming",
"status": "done",
"summary": "已确认的方案和关键取舍摘要",
"artifacts": ["spec.md"],
"decisions": ["用户已选择的关键方案"],
"open_questions": []
}
阶段结束后压缩 brainstorming 原始讨论、方案比较和搜索输出;下一阶段必须重新读取 specs/<date+feature>/spec.md、specs/<date+feature>/progress.md、specs/<date+feature>/handoffs/brainstorming.json 和必要规则文件,不依赖旧对话全文。
specs/<date+feature>/spec.md 保存、自审完成、用户批准,并完成 specs/<date+feature>/handoffs/brainstorming.json。
npx claudepluginhub xiqin/loom --plugin loomGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Reference for writing and editing skills with predictable behavior, covering invocation models, description writing, and information hierarchy.