소스 검색

docs: 添加Kilo Code工作流配置

- 添加git-commit-and-push.md工作流,实现智能分析文件变更、生成语义化提交信息和交互式命令执行

- 添加create-new-workflow.md工作流,指导用户按照约定创建标准化的Cline工作流文件

- 添加build-and-deploy-production.md工作流,简化生产环境H5应用的构建和远程部署流程

改动文件:
- .kilocode/workflows/git-commit-and-push.md
- .kilocode/workflows/create-new-workflow.md
- .kilocode/workflows/build-and-deploy-production.md
dengdx 3 일 전
부모
커밋
aa869aa2c5
3개의 변경된 파일207개의 추가작업 그리고 0개의 파일을 삭제
  1. 31 0
      .kilocode/workflows/build-and-deploy-production.md
  2. 55 0
      .kilocode/workflows/create-new-workflow.md
  3. 121 0
      .kilocode/workflows/git-commit-and-push.md

+ 31 - 0
.kilocode/workflows/build-and-deploy-production.md

@@ -0,0 +1,31 @@
+<task name="Build and Deploy Production">
+
+<task_objective>
+简化的生产环境构建和部署流程,执行npm构建命令生成生产版本的H5应用,然后将构建产物复制到远程Linux服务器。该工作流只包含核心的构建和复制操作。
+</task_objective>
+
+<detailed_sequence_steps>
+
+# Build and Deploy Production Process - Detailed Sequence of Steps
+
+## 1. Execute Build Command
+
+1. Use the `execute_command` tool to run the production build:
+   ```
+   npm run h5_for_production
+   ```
+
+## 2. Copy Build Artifacts to Remote Server
+
+1. Use the `execute_command` tool to copy files to remote server:
+   ```
+   scp -r dist/h5/* ccos@192.168.110.112:/home/ccos/dros/linux-arm64-unpacked/h5/
+   ```
+
+## 3. Complete Workflow
+
+1. Use the `attempt_completion` tool to present the final results showing the execution status of both commands.
+
+</detailed_sequence_steps>
+
+</task>

+ 55 - 0
.kilocode/workflows/create-new-workflow.md

@@ -0,0 +1,55 @@
+<task name="Create New Workflow">
+
+<task_objective>
+Guide the user through the process of creating a new standardized Cline workflow file according to the established conventions. The output will be a properly structured workflow file in the .clinerules/workflows directory.
+</task_objective>
+
+<detailed_sequence_steps>
+
+# Create New Workflow Process - Detailed Sequence of Steps
+
+## 1. Define Workflow Purpose
+
+1. Use the `ask_followup_question` command to ask the USER for the purpose of the new workflow.
+2. Use the `ask_followup_question` command to ask the USER for a concise name for the workflow.
+3. Determine the appropriate filename using kebab-case format (e.g., `analyze-system-requirements.md`).
+
+4. Inform the USER of the upcoming workflow file creation process and the main steps they will be asked to complete.
+
+## 2. Define Task Objective
+
+1. Use the `ask_followup_question` command to ask the USER for the primary objective of the workflow. Remind the user to provide breadcrubs of the inputs to be used, the output to be generated, and a generalization of the processing to formulate the outputs.
+2. Use the `ask_followup_question` command to ask the USER if know what MCP servers will be required at this point by providing of a list of Cline's active MCP server names.
+3. Use the `ask_followup_question` command to ask the USER what the expected output format will be (e.g., markdown file, code file, terminal output).
+4. Formulate a clear, concise task objective statement (1-3 sentences) based on the USER's responses.
+
+## 3. Outline Major Steps
+
+1. Use the `ask_followup_question` command to ask the USER to list the major steps in the workflow (3-7 steps recommended) and they will have a oppurtunity provide more details later or let Cline determine this for them
+2. For each major step, determine the following:
+   - Required tools or resources
+   - Expected outputs or transitions to the next step
+
+## 4. Define Detailed Substeps
+
+1. For each major step identified and analyzied, present the user what how you intended to perform the step and use the `ask_followup_question` command to see confirmation or clarification.
+
+## 5. Generate Workflow File
+
+1. Determine if the `.clinerules/workflows` directory exists. If not, create it.
+
+2. Create a markdown file named `.clinerules/workflows/{{workflow-filename}}.md` with the following structure:
+   i. Task definition with name attribute
+   ii. Task objective section
+   iii. Detailed sequence steps section with proper formatting
+   iv. Proper tool references and formatting conventions
+
+3. Use the `read_file` command to read the `.clinerules/workflow-template.md` file to ensure the new workflow follows all conventions.
+
+4. Use the `write_to_file` command to write the completed workflow file.
+
+5. Use the `attempt_completion` command to present the USER with the completed workflow file and confirmation of its creation.
+
+</detailed_sequence_steps>
+
+</task>

+ 121 - 0
.kilocode/workflows/git-commit-and-push.md

@@ -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>