메뉴
"灵感探讨的思维搭档。用户抛出模糊设计想法（"帮我想想 X 怎么做"、"纠结 A 和 B 方案"、"你觉得这样做怎么样"、"帮我过一遍思路"）、要对比方案、或需要把碎片需求拆成清晰设计决策时触发。过程工具，边聊边在浏览器里画探索画板（黑白点阵风格），不是产出最终文档。如果用户已有成型日志要转可视化长页，改用 visual-design-book；写代码前所有"还没想清楚怎么做"的环节都应先走 ideate。"
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | ideate |
| description | "灵感探讨的思维搭档。用户抛出模糊设计想法（"帮我想想 X 怎么做"、"纠结 A 和 B 方案"、"你觉得这样做怎么样"、"帮我过一遍思路"）、要对比方案、或需要把碎片需求拆成清晰设计决策时触发。过程工具，边聊边在浏览器里画探索画板（黑白点阵风格），不是产出最终文档。如果用户已有成型日志要转可视化长页，改用 visual-design-book；写代码前所有"还没想清楚怎么做"的环节都应先走 ideate。" |
| 维度 | 声明 |
|---|---|
| reads | yyMM/*.md（参考已有日志）、identity/README.md（用户背景） |
| writes | yyMM/raw/{topic}/（HTML 探索稿）、yyMM/*.md（方案存档） |
| depends | 无 |
你是用户的思维搭档。任务：把模糊想法拆解为清晰设计决策。在对话中保持克制，每次抛出最有启发的那一个问题，必要时用可视化画板辅助决策。
与 visual-design-book 的区别：ideate 是过程工具，输入是想法碎片，输出是决策 + 探索画板（黑白点阵）；visual-design-book 是后处理工具，输入是已完成日志，输出是叙事长页（金橙暖色）。两者视觉语言互不侵犯。
核心原则：Show, Don't Tell.
当你要确认布局、排版、组件形态、风格走向、信息架构时，直接写自包含 HTML 用 open 打开，不需要 server。
详细规范读 references/visual-companion.md（含 Canvas 美学、模板清单、注入 canvas.css 的机制）。
核心流程：
scripts/ 挑模板（ab-test.html / wireframe.html / styleguide.html / flow.html / bento.html）scripts/canvas.css 完整内容，整段注入 <style> — 这是保持画板视觉一致的唯一方式，不要自己发明样式open 命令自动打开不要复用文件名 — 每次迭代写 v2、v3，保留设计演进轨迹。
先观察项目结构决定路由：
日记工作区（存在 yyMM/ 或 identity/ 目录）：
yyMM/raw/{topic}/DD-ideate-{topic}-v{n}.htmlyyMM/DD-ideate-{标题}.md普通代码项目（无日记结构）：
.ideate/{topic}-v{n}.html（提示用户加入 .gitignore）.ideate/{topic}-summary.md 或项目约定的设计文档目录（如 docs/design/）讨论结束后把方案总结写入 Markdown，frontmatter 必须包含 HTML 探索稿路径以便回溯：
---
summary: 一句话精准概括设计方向与核心决策
tags: [idea, design]
sources:
- yyMM/raw/{topic}/DD-ideate-{topic}-v1.html
- yyMM/raw/{topic}/DD-ideate-{topic}-v2.html
---
文档自动维护（Docs Maintenance）——git commit 前，凡本次改动对应的 story 已 verified 且其 design.md 影响面涉及架构 / 设计 / 约定变更，必须使用本技能。文档已覆盖变更则跳过——本技能的产出是文档与代码一致，不是每次都改文档。
Use when dispatching independent subagents via opencode CLI in the Journal repository, especially for verification-gate, requirements-gate, or docs-maintenance tasks where context isolation and standardized report output are required.
需求门禁（Requirements Gate）——只要用户提出开发需求或变更请求（实现 / 新增 / 开发 / 加一个 / 修改 / 重构 / 优化 / 接入 / 修复 / add / implement / build / feature / fix），哪怕措辞很随意，且该任务还没有 status: approved 的 story.md，就必须在写任何代码之前使用本技能。不要因为需求看起来很简单而跳过。
验收门禁（Verification Gate）——与 requirements-gate 成对的下游环节：需求门禁确保做对的东西，验收门禁确保做的东西是对的。开发完成、准备 git commit、或想宣称'做完了'之前，凡存在与本次改动相关、status: approved 但尚未 verified 的 story.md，必须使用本技能。注意：测试全部通过不等于验收通过——技术正确性归 verification-before-completion，需求符合度归本技能。
文档自动维护（Docs Maintenance）——git commit 前，凡本次改动对应的 spec 已 verified 且影响面涉及架构 / 设计 / 约定变更，必须使用本技能判断并同步更新 AGENTS.md / ARCH.md / DESIGN.md，并按需维护 README、llms.txt、用户使用说明与技术开发说明文档。当 PreToolUse hook 注入「文档维护」提醒时必须使用。文档已覆盖变更则跳过——本技能的产出是文档与代码一致，不是每次都改文档。
维护 identity/ 下任何档案前必须加载。定义人物五维度画像、