Prepare for development

开发准备

This skill performs all the necessary actions to prepare an agent for the development of a fix or featurein a codebase.

本skill会执行所有必要操作，让agent为代码库中的问题修复或功能开发做好准备。

Starting point

起始点

The starting point is always a Github issue that describes a fix or feature that needs to be implemented in a codebase. If the user has not specified which Github issue to work on, ask for it. You must quit with a "CANNOT PROCEED - MISSING GITHUB ISSUE" message if the user does not provide a Github issue.

Checklist to begin: If this checklist is not all satisfied, as the user for the missing information. Do not start before all information is available:

You have a Github issue to work on.
[ ] The Github issue clearly specifies what fix needs to be done. The fix can be described either :
- In the body of the Github issue
- In a document in the code base that the Github issue refers to. Both are valid.
You know which codebase (project, repo) you are working on.

起始点必须是一个描述了代码库中需要实现的修复或功能的Github issue。如果用户未指定要处理的Github issue，请询问用户。若用户未提供Github issue，你必须退出并返回“CANNOT PROCEED - MISSING GITHUB ISSUE”消息。

开始前检查清单： 如果以下清单未全部满足，请向用户索要缺失的信息。不要在信息不全的情况下开始：

你有一个要处理的Github issue。
Github issue明确指定了需要完成的修复内容。修复内容可以通过以下两种方式描述：
- 在Github issue的正文中
- 在代码库中被Github issue引用的文档里。两种方式均有效。
你知道正在处理的代码库（项目、仓库）。

The Workflow

工作流程

You must always strictly follow this workflow when preparing the implementation of a feature:

Read the codebase to understand current state
Read any relevant feature description to understand the context of the fix.
Breakdown the fix into a plan: a series of changes you will need to implement. Prepare a task list. You MUST use the
```
breakdown-feature
```
skill to breakdown a fix into tasks. Once you have the tasks, make the plan as a task list.
Create a feature branch, if the codebase is not already in a feature branch. Feature branches are easy recognizable: they start with
```
feature/<something>
```
. Note that feature branches are used whether it is a fix or a feature.

在准备功能实现时，你必须始终严格遵循以下工作流程：

阅读代码库以了解当前状态
阅读任何相关的功能描述，理解修复的背景。
将修复内容拆解为计划：一系列需要实现的变更。准备任务列表。你必须使用
```
breakdown-feature
```
skill将修复内容拆解为任务。获得任务后，将计划整理为任务列表。
创建功能分支（feature branch），如果代码库尚未处于功能分支中。功能分支易于识别：它们以
```
feature/<something>
```
开头。请注意，无论问题修复还是功能开发，都使用功能分支。

Rules

规则

*When to engage the user:

NEVER engage the user. This skill is expected to be fully autonomous.

Rules for breaking down the fix into tasks:

Keep it simple: no need to have 100 tasks. 1-3 tasks for a fix should be more than enough.

Rules for creating the feature branch:

[ ] Make sure you start from the main branch. If you are not on the main branch, switch to it first. This is fundamental to avoid creating a feature branch that is not up to date with the main branch.
[ ] Always pull the latest changes from the main branch before creating a feature branch. Without this step, you risk creating a feature branch that is not up to date with the main branch.
Only create a feature branch if the codebase is not already in a feature branch. If the codebase is already in a branch, you can work in that branch and skip this step.
The feature branch must be named
```
feature/<name>
```
where <name> is a short name (dash-separated-words) of the feature or fix to be implemented.

*何时与用户交互：

绝不与用户交互。本skill应完全自主运行。

将修复内容拆解为任务的规则：

保持简洁：无需拆分成100个任务。一个修复拆分为1-3个任务就足够了。

创建功能分支的规则：

确保从主分支（main branch）开始。如果当前不在主分支上，请先切换到主分支。这是基础要求，以避免创建未与主分支同步的功能分支。
在创建功能分支前，务必拉取主分支的最新变更。如果跳过此步骤，你可能会创建未与主分支同步的功能分支。
仅当代码库尚未处于功能分支中时才创建功能分支。如果代码库已处于某个分支中，你可以在该分支中工作并跳过此步骤。
功能分支必须命名为
```
feature/<name>
```
，其中<name>是要实现的功能或修复的简短名称（用短横线分隔单词）。

Acceptance Criteria

验收标准

You are done with preparing the Fix for development ONLY IF:

The feature branch has been created
You have broken down the fix into a series of 1-3 tasks.

仅当满足以下所有条件时，你才完成了修复的开发准备工作：

已创建功能分支
已将修复内容拆解为1-3个任务的系列列表。

prepare

Original

Translation