用途：帮助把一个问题转化为可评审的设计提案（RFC 形态），文件放在 proposals/ 目录，用来迫使评审者在多个选项间做出选择，而不是直接做决定或写实施计划。
主要能力与章节结构：提案文件名格式为 0001-feature-name.md，即四位零填充序号加 kebab 标题；状态流转为 draft → fcp → accepted/rejected（fcp 指最终评论期）。固定骨架包含 Motivation、Design、Drawbacks、Alternatives、Unresolved questions 五个二级章节，并要求完整 frontmatter：type: proposal、一行 description（写被强制回答的决定而非功能名）、status: draft、authors、created、tags: [proposal]。
使用方式：所有 markdown 操作由 open-knowledge 技能统一管理（读取用 exec/search，写入用 write/edit，链接用普通相对 markdown）。执行顺序为：先扫描 proposals/ 与 decisions/ 中已有相关内容（search、exec("ls -A proposals/")、exec("grep -rln <keyword> proposals/ decisions/")）；再框定问题（受益者、可观察变化、被强制回答的决定、大致方向）并等待确认；然后取最高序号加一创建文件，例如 write({ document: { path: "proposals/0007-async-export-pipeline.md", template: "proposal" } })；依次填写 Motivation、Design、Alternatives（至少两个真实选项并说明为何不选）、Drawbacks、Unresolved questions（每个问题写明所需证据与决定者）；最后校验链接与 frontmatter，做小结。
限制：不得跳过问题框定关卡，不得用稻草人选项填充 Alternatives 或留空 Drawbacks；不记录决定、不写实施规格，也不得自行把状态推进为 fcp 或 accepted，这些均是人的行为。若问题已由已接受决定覆盖且情况未变，应提示可能不需要提案。其他具体收费、平台与效果资料暂未提供。