31 lines
5.9 KiB
Markdown
31 lines
5.9 KiB
Markdown
> commands & skills都是将会提供给你使用的指导规范以及工具和能力，下文中会用LLM来指代你的角色，
|
||
|
||
对现有的 commands & skills & aide program 体系做一些调整：
|
||
|
||
创建一个类似docs的命令，但这个新命令主要面向人类用户，尤其是目标用户很可能是从未接触过工作目录下的项目对此项目完全没有了解的陌生新人，
|
||
- 入口是README.md，细节放在docs目录（因为是面向用户而非程序，所有都不要默认放在.aide目录下，而是直接放在外面，根目录下就好）下，（README.md和docs这两个路径都要在环境配置中设置，使用时必须用aide读取路径）
|
||
- 需要单独讨论一下README应该放些什么样的东西，我想的是，在配置中指定一个`make-readme-rules.md`，
|
||
- （需要注意，上面说的README.md、docs、make-readme-rules.md都是路径值，具体配置项的命名还需要你酌情考虑）
|
||
- 然后如果当前项目不存在make-readme-rules.md，就要首先引导用户设定入口编写规范，（引导用户设定入口编写规范前，应提示用户，如果还没有对此项目运行过docs+load，建议先完成面向LLM文档的构建再重新启动对话加载项目文档后再运行此命令以便于LLM更好的分析和提供对面向用户文档的编写建议，除非这个项目真的非常非常的简单微型，然后确定完成了load或是确定不需要load后，再建议把这个制定过程作为一个完整的对话，在这次对话中专注于README文档编写规范的制定，为这项任务允许消耗全部的上下文，当任务完成之后，要使用`/exit`退出本次对话重新开始一个新的对话继续完成之前的任务）
|
||
- 制作一个skills，包含一个SKILL.md和数个README.md规范模板，（需要把这数模版的编写作为一个完整的子任务单独执行，先完成该skill再实现这个第3点的其他需求）
|
||
- 可以向用户介绍有哪些可用模板，或者提供一些可选的模块化README内容规范板块供用户自由拼搭，
|
||
- 同时应该根据当前项目的项目文档（面向LLM的由docs命令构建的项目文档）进行分析，为用户提供可参考的建议
|
||
- 我需要你尽情发挥你的创造力和专业性，指导我，像这种面向用户的文档应该写些什么，怎么写，怎么组织分布，
|
||
- 如果是一个单纯的文档&材料类项目应该怎么处理
|
||
- 如果是一个单一的cargo、springboot、flutter、android、vue、react等这类的单体项目应该怎么处理
|
||
- 如果是一个项目下同时含有文档&材料和cargo等程序开发单体项目应该怎么处理
|
||
- 如果该项目下同时含有多个单体项目，例如同时含有多个cargo lib crate、cargo bin crate、多个springboot单体服务、vue前端单体项目，又应该怎么处理
|
||
- 这些情况之间是否应该有较明显的区分？
|
||
- 我希望要在细节文档目录下，docs目录下创建一个专用于面向用户的长期维护的完善的流程图目录，不同于run时创建的专用于当时任务的流程图，而是供用户快速理解用，
|
||
- 如果是不含程序开发内容的项目，就制作用于引导用户如何了解项目的流程图，
|
||
- 如果含程序开发，则同时制作引导的流程图和对于该项目的流程图，程序方面的流程图参考run中的程序逻辑流图规范，要求以一整套程序开发项目为单位，编写一整套流程图，例如cargo一整个目录就是一整个项目
|
||
- 如果同时含有多个开发项目，则要对于每一个项目都编写一套流程图，
|
||
- 一套流程图是指一整个专用于这套流程图的目录，目录下含有一个guide.puml和其他子模块的puml，
|
||
- 假设一个项目下同时含有一个cargo lib crate、一个 cargo bin crate 、一个vue项目，分别名为api-lib、api、user-interface，且假设已设定用户文档的流程图目录名为graph-guide，
|
||
- 则graph-guide目录下应该至少含有三个目录api-lib、api、user-interface，和一个文件guide.puml，且每个子目录下都至少有一个guide.puml，
|
||
- 在开始编写流程图前，应该要先根据load加载的项目文档对项目进行分析和流程图分划处理，用户文档的区块划分不同于项目文档，项目文档的要求是完完全全的深度且全面的覆盖，便于先脉络后枝叶的按需加载和检索，但用户文档要按照逻辑或业务呈现一个整体的形式为目标，
|
||
- 先按需读取项目文档知道足够对项目信息做出业务逻辑整体的区块划分，然后再深入分析其复杂度和工作量，对流程图的编写工作进行步骤计划，
|
||
- 步骤计划不一定是一个子项目一个计划，例如前面api-lib+api+ui的项目，可以分为3个整体区块，但不一定只要三步就能完成，如果api-lib过于庞大，可能即使每一次都消耗满上下文，分布工作10次也不一定能完成这一个区块的任务，
|
||
- 必须先分划好区块，然后分析具体步骤计划，编写计划进度文档然后才能开始具体的流程图设计，
|
||
- 也许可以把这个命令拆分为多个命令，先完成好流程图的任务，再处理文档的事，这样的话就可以在写文档时，如果需要用到图的话，直接插入已生成的png流程图，且做好拆分的话，更利于流程图的任务分步执行和接续执行，初始化以及后续的每次对话都只需要load+运行构建用户文档流程图的命令即可，第一次会开始分析和计划之后，之后的每次执行都会在产出的同时同步更新计划文档，后续的新对话中通过检索计划即可，计划文档应起到分布计划+状态记录+指导任务细节的作用，
|