diff --git a/statements/optimize.md b/statements/optimize.md
index c0fd936..349c01b 100644
--- a/statements/optimize.md
+++ b/statements/optimize.md
@@ -1,4 +1,4 @@
-沟通准则（优化版）
+口头话解析准则（优化版）
 
 1. 理解层面
     - 语义解析：分析口语化表达，提取核心意图和真实需求
diff --git a/task-now.md b/task-now.md
index aebf589..937556e 100644
--- a/task-now.md
+++ b/task-now.md
@@ -1,6 +1,23 @@
-1. 首先阅读 @statements/optimize.md，还有 @README.md 并根据其指引了解该体系的commands+skills+aide program的所有信息
-2. 然后把原本的README.md移至docs目录下，重命名为project-details.md
-3. 编写新的README.md，内容要求：
-    - 指导用户如何快速上手
-    - 如何从此处安装插件
-    - 如何安装和使用aide程序
+对当前的commands&skills&aide做一些调整，记得完成调整后同步更新所有相关文档
+
+添加一个新的skill，内容以@statements/optimize.md为基础，尽情发挥你的创造力，尝试将其进一步扩展和完善，然后做成一个新skill放入插件市场，
+然后在run中添加一条要求，不论任何时候，如果发现用户的对话消息内容或是给你的任务文档内容具有较明显的口头语气，就应该学习该skill然后对其内容进行深度理解（比如本任务文档就属于需要使用该skill进行解析的），
+
+我之前提出了按下面的要求对commands/run的流程图设计部分的内容进行调整，但现在看来没有实现目标效果，仅仅只做到了“无论如何要有图”，但没有约定要什么样的图，
+```
+调整在流程图阶段的要求：
+- 强化流程图的要求，不论是什么任务，只要有任务就必须有流程图，
+    - 因为整个任务的具体实现主要是LLM来完成，实际上用户主要处理的只是提供原任务信息和处理优化待定项的决定，还有后续可能的审阅，
+    - 但是如果审阅时要每一个文件的改动细节够一个一个看的话太过于耗费时间，
+    - 如果有图像形式的流程图，这会对用户很友好，而且如果能在流程图阶段就发现业务流上的逻辑错误，将能避免很多沉没成本，避免花了大量时间查看细节但其实大方向上就有错误浪费了时间
+- 我需要的流程图是那种，比如一个C/C++程序一般是从main函数开始，同时程序的本质其实就是顺序执行或分支/循环结构这些都能用流程图体现出来，代码的本质是为了实现业务逻辑也就是说可以把代码细节抽象为语义化简述（其实应该是写代码就是为了把高级抽象的人类语言业务逻辑实现为底层程序代码的过程），所以其实可以使用流程图把程序的逻辑流以语义化的方式呈现出来，
+- 而且一个函数可以被封装为一个用有规定的预期输入+输出的盒来表示，一个函数或模块就是一个子系统，子系统可以在一个单独的流程图中呈现其细节，就像是写代码时的模块化思维，封装分装到多个代码文件里那样类似的
+- 而对于有些不是写程序代码的任务也同样需要流程图，用户可以通过流程图来看出计划，将要做什么事，做事的顺序，
+```
+
+上面说的那些你能理解吗，能的话先写一个使用python语言模块化编程实现一个中低复杂的的程序（在test-cache目录下新建目录和文件），具体程序内容你自拟，然后为其程序执行的顺序流绘制流程图，
+
+将上面说的原本的要求内容转化为清晰明确的规定，同时新增一项要求，我希望含有程序设计与代码编写的任务要同时有任务本身的执行过程的流程图和程序的顺序流逻辑图，而不含程序代码的任务则只要有任务本身的执行过程的流程图即可
+
+调整aide程序中flow的一些过程，因为flow会每次更新流程状态元数据，还会集成git提交，而用户有可能会希望不要把.aide忽略提交，
+所以我希望的是，flow的所有过程，只要集成了git提交操作的，git提交都应该是最后一步，就是先更新当前flow步骤的数据，再git add . 和 commit
\ No newline at end of file