claude-code 可以在 CLAUDE.md 中定义流程
这是我用于检查 bug 的指示，会让它每次执行大幅操作前，都先制定 plan 和 todo, 然后按 todo 一个个来
### Principles
#### Editing
- You MUST not modify/write or delete any other files outside the project root directory, this is NOT ALLOWED
### Task execution process
#### Files structure
##### Overview
The execution process relevant files are stored in the .claude-local directory. Each subdirectory in the .claude-local directory represents a specific task, such as .claude-code/xxx, where xxx is the task name. Each task consists of the following components:
- Execution plan
- Task list
- Temporary file
The structure is as follows:
.claude-local
\
\---xxx
\--- plan-xxx.md
\-- todo-xxx.md
\- aa.md
##### plan file
When performing a complex or long task, I will ask you to plan it first, when I accept the plan, you MUST write the plan to .claude-code/xxx/plan-xxx.md.
Execution of task should follow the plan.
##### todo list
Then, you MUST generate a specific to-do list of execution steps from .claude-code/xxx/plan-xxx.md and store it in .claude-code/xxx/todo-xxx.md. You should number each step (including sub-step). This file is used to track the execution status. For each step, you should define 4 fields at least:
- task description
- task status: PENDING, IN PROGRESS, COMPLETED
- task result: store detail information of execution result, and you can use emoji as success/fail flag, like: ❌ ✅. If code bugs found, give it a ❗ flag even a step finised success.
- task data: store any other information, like:
- execution aborted reason
- a step finished with some useful information found
- listing all state/temporary files related to this step
- other notable messages
Its default content is empty.
If a step is complex, you can split it into sub task/step, and they also need to be tracked.
This file's format should be markdown. Each step should be organized as a markdown heading.
###### File update appointment
- When I tell you to start executing task xxx, after completing each step in the todo list, you MUST update the .claude-local/xxx/todo-xxx.md file in real-time and mark it as completed.
- When execution aborted, unfinished/running step MUST mark back to IN PROGRESS, and you also should update 'task data' field as well.
When I ask you to resume/continue execution, you should continue from last process point. Again, you should use todo list file to track process.
##### temporary file
During execution, if you need to record certain output, status, analysis results, or other useful information of the steps that have been executed, then you should create .claude-local/xxx/aa.md file, where the 'aa' part is generated by you. Notes that naming of temporary file must respect some rules:
- the first part, must be type name, like: analysis, report, output, status or something else (you decide)
- rest parts, should be identifiers, describes belonging or purpose of this file.
- multiple parts should be concatenated by '-'
Example: 'analysis-xxxx-aaaa.md'
After you creating a new temporary file, you should link it with specific step in todo list file (todo-xxx.md), using 'task data' field.
You should not use temporary file to track task execution process.
#### Behaviors standard
Behaviors standard below should be followed when you are executing some tasks, for better working:
##### execution progress tarcking
When you tracking task execution progress, the only standard is todo file. A step completed only when it is marked as COMPLETED. Other sources are references only.
When each time you need to report current progress, you should check lastest todo file first too.
##### find/anlysis/check bug/issue
- For each file, analysis its dependencies first (for example, for go, use `import` in a file to find this file's dependencies)
- You should check whether these dependencies file is accessible in project
- Before checking bug, Read all necessary code files and understand what they do first. Notes that you should read both: checked file itself and their all accessible dependencies files.
This also means: If you need read other sources (like: type/function/method define) from additional files, you should also read these files fully. Do not be lazy and stop using tools like grep/rg to read parts of code.
For example, you are analysising file A, it import/reference/depends on other 10 files, you should read other 10 files too, to understand full code base precisely.
- Before find/anlysis/check bug/issue, you must ensure you have read all related file and understand them.
- When checking bugs, you should think hard, check carefully, do not be lazy.
- When checking bugs, if I do not give limit range (for example, severity levels), you should list all bugs as many as possible
