|
|
@@ -0,0 +1,121 @@
|
|
|
+<task name="Git Commit ">
|
|
|
+
|
|
|
+<task_objective>
|
|
|
+Automate the Git commit process by intelligently analyzing file changes, generating semantic commit messages with file paths, and providing an interactive command execution workflow. The workflow opens a new terminal, checks Git status, analyzes changes to create descriptive commit messages, lists commands for user review, and executes Git operations step by step with user confirmation.
|
|
|
+</task_objective>
|
|
|
+
|
|
|
+<detailed_sequence_steps>
|
|
|
+
|
|
|
+# Git Commit Process - Detailed Sequence of Steps
|
|
|
+
|
|
|
+## 1. Open New Terminal and Check Git Status
|
|
|
+
|
|
|
+1. Use the `execute_command` tool to open a new terminal session.
|
|
|
+2. Use the `execute_command` tool to run `git pull` . if there is something wrong or conflict , prompt the user to interupt to fix
|
|
|
+
|
|
|
+3. Use the `execute_command` tool to execute `git status` to check current repository state.
|
|
|
+
|
|
|
+ - Identify modified files
|
|
|
+ - Identify new (untracked) files
|
|
|
+ - Identify deleted files
|
|
|
+ - Display current branch information
|
|
|
+
|
|
|
+4. Analyze the output to understand the scope of changes in the current working directory. you should ignore dev.ts file.
|
|
|
+
|
|
|
+## 2. Analyze File Changes and Generate Commit Message
|
|
|
+
|
|
|
+1. For each changed file identified in git status:
|
|
|
+
|
|
|
+ - Use the `read_file` tool to examine the content of modified files if needed for context , you should use 'git diff' command to check the file modification detail ,not simplely read all the file contents, focus on the diff which is really important !
|
|
|
+ - Analyze the type of changes (new features, bug fixes, documentation, refactoring, etc.)
|
|
|
+
|
|
|
+2. Based on the file changes and any user-provided context information:
|
|
|
+
|
|
|
+ - Generate a semantic commit message following conventional commit format
|
|
|
+ - Include the file paths of changed files in the commit message
|
|
|
+ - The version change should follow the commit message type ,especially whhen the commit type is feat or fix
|
|
|
+ - Examples:
|
|
|
+ - `feat (1.22.1 -> 1.23.0): add new workflow creation process in .clinerules/workflows/create-new-workflow.md`
|
|
|
+ - `fix (1.22.1 -> 1.23.0): resolve authentication issue in src/API/security/userActions.ts`
|
|
|
+ - `docs: update README.md with installation instructions`
|
|
|
+3. Based on the file changes , a new changelog item should be appended in the changelog.md file ,and the new content should be put at the top to ensuer it is the first changelog item , as to the content , you can refer the changelog.md file , and make sure the title should contain date and time such as ## [1.8.0] - 2025-12-15 16:14
|
|
|
+4. Based on the commmit message type ,such as feat , or fix .etc. you should change the version in the package.json file which is located in the project directory
|
|
|
+5. Ensure the commit message is descriptive and includes relevant file paths for clarity.
|
|
|
+6. Ensure the commit message contains modified files which are changed or new added files . the commit message should be in Chinese . the files list locates below the commit message and contribute to the commit messsage. Examplse :
|
|
|
+ `feat (1.22.1 -> 1.23.0): 实现曝光模式切换功能并集成设备API下发
|
|
|
+
|
|
|
+ - 在 APRActions.ts 中导出 setExposureModeFromAction API
|
|
|
+ - 在 aprSlice.ts 中添加 setExposureModeThunk 异步thunk和状态处理
|
|
|
+ - 在 ParaSettingCoordinator 中实现 setExposureMode 方法和MQTT事件监听
|
|
|
+ - 在 mqttServiceForDevice.ts 中添加NEW_EXPOSURE_MODE事件触发
|
|
|
+ - 更新三个UI组件使用受控组件模式,确保只在设备确认后才更新显示
|
|
|
+ - 利用React受控组件特性实现优雅的API-first更新流程
|
|
|
+
|
|
|
+ 改动文件:
|
|
|
+ - src/API/exam/APRActions.ts
|
|
|
+ - src/states/exam/aprSlice.ts
|
|
|
+ - src/domain/exam/paraSettingCoordinator.ts
|
|
|
+ - src/domain/mqttServiceForDevice.ts
|
|
|
+ - src/pages/exam/ContentAreaLarge.tsx
|
|
|
+ - src/pages/exam/ContentAreaMedium.tsx
|
|
|
+ - src/pages/exam/ContentAreaSmall.tsx
|
|
|
+ `
|
|
|
+
|
|
|
+## 3 Important ! Show the generated commit message prominently so the user can verify its accuracy.
|
|
|
+
|
|
|
+## 4. Present Command List for User Review
|
|
|
+
|
|
|
+
|
|
|
+## 5. Interactive Command Execution Confirmation
|
|
|
+
|
|
|
+1. Use the `ask_followup_question` tool to ask the user for confirmation with clickable options:
|
|
|
+
|
|
|
+ - Question: "是否要开始执行Git命令?"
|
|
|
+ - Options: ["开始执行命令", "修改提交信息", "取消操作"]
|
|
|
+
|
|
|
+2. Handle user response:
|
|
|
+ - If "开始执行命令": Proceed to step 6
|
|
|
+ - If "修改提交信息": Ask user for new commit message and update commands
|
|
|
+ - If "取消操作": Stop the workflow
|
|
|
+
|
|
|
+## 6. Execute Git Commands Step by Step
|
|
|
+
|
|
|
+1. **Execute git add .**
|
|
|
+
|
|
|
+ - Use the `execute_command` tool to run `git add .`
|
|
|
+ - Display the result and confirm success
|
|
|
+ - Wait for command completion before proceeding
|
|
|
+
|
|
|
+2. **Execute git commit**
|
|
|
+
|
|
|
+ - Use the `execute_command` tool to run `git commit -m "final commit message"`
|
|
|
+ - Use the standard git commit command (ignore any git aliases)
|
|
|
+ - Display the commit result including commit hash
|
|
|
+ - Confirm the commit was successful
|
|
|
+
|
|
|
+
|
|
|
+3. **Final Confirmation**
|
|
|
+ - Use the `attempt_completion` tool to present the final results
|
|
|
+ - Include summary of:
|
|
|
+ - Files that were committed
|
|
|
+ - The final commit message used
|
|
|
+
|
|
|
+
|
|
|
+## Error Handling
|
|
|
+
|
|
|
+- If any git command fails, display the error message clearly
|
|
|
+- Provide suggested solutions for common git errors
|
|
|
+- Allow user to retry or modify the approach based on the error
|
|
|
+
|
|
|
+## Notes
|
|
|
+
|
|
|
+- Always use standard git commands (`git commit -m`) and ignore user-defined git aliases
|
|
|
+- Ensure commit messages are informative and include file paths for better tracking
|
|
|
+- The workflow assumes the current working directory is already a git repository
|
|
|
+- Each command execution should be confirmed successful before proceeding to the next step
|
|
|
+- when analyzing modified files , ignore the dev.ts file unless the user tell to include the file . This is really important.
|
|
|
+- when use 'git diff' to get diff context for a file , you should use 'git --no-pager diff XXX' to ensure to get whole content , no pager , no need to manually help to get all contents.
|
|
|
+
|
|
|
+</detailed_sequence_steps>
|
|
|
+
|
|
|
+</task>
|