用途：把交互层面的不确定性变成可检验的证据。它保持产品真实事实与设计语言不变，只改变交互架构，让用户在写生产代码前体验不同取舍。适用于选择依赖行为、状态、工作流、层级或渐进披露的场景；静态视觉风格校准、全新设计系统或静态 mockup 应使用其他技能。
主要能力：默认提出三个候选交互架构，每个候选是一个自包含、可运行的 HTML 文件，内联 CSS/JavaScript，无运行时网络依赖。候选必须实现声明的状态，装饰性按钮不算交互原型。Design Board 让用户操作每个候选、记录具体反馈、选择一个或请求具名混搭。
使用方式：先冻结决策契约（用户任务、决策范围、不可变事实、现有语言、首屏不变量、交互状态、停止条件）。阅读 references/interaction-design-method.md 后提出候选。用 references/board-contract.md 创建 board.json，再运行： python3 "$SKILL_ROOT/scripts/build_board.py" --manifest <session-dir>/board.json --output <session-dir>/design-board.html 预期输出 BOARD_BUILT variants=<derived count> output=<absolute path>。若已安装 gstack design 可执行文件，用其 serve 命令启动并获取 BOARD_URL；无法解析时可直接用浏览器打开 design-board.html，Submit 与 Remix 会下载 feedback.json 或 feedback-pending.json。反馈后保留已接受部分、只改指定失败轴、重新生成受影响候选并构建带版本的 Board；已有 Board 服务时用 curl 调用 /api/reload 重载。用户确认反馈摘要后写 approved.json，之后才在产品中实现。
限制：不得把候选变成不同产品或数据模型；不得用静态图片代替可运行交互；不得在用户操作前实现看似胜出的方案；不得把原型写入生产组件目录；不得仅凭作者点击声称可用性验证。构建器会拒绝字节相同候选、路径穿越、缺失声明状态和静态外部样式/脚本/媒体，并注入拒绝网络的 CSP。若项目已有设计 SSOT，应把批准的交互决策写入其中。资料未提供具体收费、平台支持范围等信息。