メニュー
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/Playa-0v0/Cyrene-Agent --skill cyrene-plan-modeコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
使用 OpenXML SDK (.NET) 进行专业的 DOCX 文档创建、编辑和格式化。 三种管道：(A) 从零创建新文档，(B) 在已有文档中填充/编辑内容， (C) 应用模板格式化并通过 XSD 验证门控检查。 当用户需要生成、修改或格式化 Word 文档时，必须使用此 skill—— 包括他们说"写一份报告"、"起草建议书"、"制作合同"、 "填写此表单"、"按此模板重新排版"，或任何最终输出为 .docx 文件的任务。 即使用户未明确提及 "docx"，如果任务暗示生成可打印/正式文档，也应使用此 skill。
Create, inspect, fill, reformat, and visually verify PDFs on Windows with local Python rendering. Use whenever a PDF must preserve deliberate layout, including Chinese text, tables, charts, covers, or form fields.
生成、编辑和读取 PowerPoint 演示文稿。使用 PptxGenJS 从零创建（封面、目录、内容、章节分隔、总结幻灯片），通过 XML 工作流编辑已有 PPTX，或使用 markitdown 提取文本。触发词：PPT、PPTX、PowerPoint、演示文稿、幻灯片、slide、deck、slides。
SKILL.md を表示中
| name | cyrene-plan-mode |
| description | 当 Cyrene 处于 Plan Mode（计划模式），正在讨论、调查、细化或准备代码/文件改动的实施计划时使用。 |
| modes | ["code"] |
Plan Mode（计划模式）用于在真正动手修改之前，帮助 Cyrene：
目标不是“尽快写出一份计划”。
目标是：
让用户能够放心点击批准，因为重要事实、关键决策、实现边界和验证方式都已经讨论清楚。
核心流程：
理解 → 落地事实 → 讨论 → 查漏 → 收敛 → 写计划
不要从用户最初提出的一个想法，直接跳到最终计划。
开始设计实现方案之前，先判断用户真正想得到什么结果。
需要区分：
不要把“用户提出的一种实现方式”自动当成最终需求。
例如：
“能不能加一个 finish tool（结束工具）？”
这可能只是一个实现提议。
用户真正想解决的问题可能是：
“避免 Executor（执行器）在任务还没真正完成时就提前结束。”
讨论实现方式时，始终记住真正目标。
用户明确确认过的决定，应视为 Confirmed Decision（已确认决策）。
除非：
不要因为“还有其他合理方案”，就不断重新打开已经结束的讨论。
如果新的事实与用户已确认决定发生冲突，应明确指出冲突，而不是偷偷替换用户决定。
涉及现有代码库时，任何项目特定结论都应优先建立在真实代码与工具观察之上。
使用只读工具建立 Workspace Ground Truth（工作区事实依据）。
优先确认：
不要因为“类似项目一般会这样做”，就假设当前项目中存在某个：
来自：
目前合理，但尚未验证。
仍然需要：
不得把 Assumption（假设）和 Open Question（待确认）写成 Confirmed（已确认事实）。
在向用户提出技术问题之前，先判断：
如果能通过项目调查得到答案，优先调查。
真正需要询问用户的情况通常包括：
询问时应尽量把选择说具体。
推荐：
批准 Plan（计划）后有两个合理行为：
A. 立即开始执行；
B. 只解除限制，等待用户下一条消息再执行。
你希望哪个？
不要只问：
“你想怎么做？”
用户或模型提出方案后，不要立即围绕这个方案继续堆细节。
先确认：
优先选择：
能够满足需求的最小机制。
如果已有项目抽象已经具备所需语义，优先复用，不要为了“架构完整感”再造一套平行系统。
规划时应明确区分两类职责。
需要语义判断和灵活性的事情：
应该可靠、机械执行的不变量：
如果 Runtime（运行时）能够可靠保证某个机械规则，不要只依赖 Prompt（提示词）要求模型“记得遵守”。
反过来，如果某件事明显需要语义判断，也不要为了追求确定性，把它过度写死成 Runtime State Machine（运行时状态机）。
存在一个“看起来能做”的方案，不代表已经可以调用 write_plan。
以下情况应该继续讨论或调查：
只有当计划达到 Approval-Ready（可审批）状态时，才应该正式写入。
通常应满足：
不要为了追求“绝对确定”，强迫用户提前决定所有微小实现细节。
低层实现细节可以留给执行阶段根据实际代码决定。
在最终 write_plan 之前，读取：
references/coverage-check.md
它是一个 Relevance Scan（相关性扫描），不是必须全部写进计划的固定模板。
它的目的不是把每份计划写得越来越长，而是帮助发现：
只检查与当前任务真正相关的部分。
如果 Coverage Check（覆盖检查）发现了会阻塞实现的重要问题，应先继续讨论，而不是带着漏洞强行提交计划。
写计划前读取：
references/plan-templates.md
常见场景包括：
任务可能同时具有多个特征。
选择一个最主要的类型作为基础，再按需要加入少量其他章节。
模板只是结构工具。
不要为了套模板改变任务本身。
Plan（计划）有两个主要读者：
所以计划既要说明：
实现步骤使用 Markdown Checkbox（Markdown 复选框）：
- [ ] ...
每一个 Task（任务）应代表一个真正有意义、可以观察和验证的实现阶段。
这些描述无法直接指导执行。
Plan（计划）不是鼠标操作录像。
任务粒度应让执行阶段：
Approved Plan（已批准计划）是一份经过用户 Review（审阅）的实施方向。
它不是一份必须无条件逐字执行的脚本。
除非特别必要，不要把计划绑定到：
优先引用更稳定的对象：
关于批准后的执行规则，读取：
references/execution-handoff.md
write_plan 前 Self-Review（自检）调用 write_plan 前，快速重新检查：
发现重要问题时，先修正，再调用 write_plan。
当讨论真正达到 Approval-Ready（可审批）状态后：
write_plan 写入当前计划；write_plan。不要替用户批准计划。
不要在 Plan Mode（计划模式）中偷偷开始实施。
用户批准，是规划与执行之间的边界。