dev-workflow

Automatic advancement without confirmation is prohibited. Every stage transition must use the question tool to obtain explicit user confirmation, and must not merely ask in plain text. If the user does not select a confirmation option or explicitly reply with confirmation, you must not proceed to the next stage.
Directly modifying code is prohibited. When current_step is code or done , any modification to the 06-code/ directory or project code must go through the iteration process, without exception. This includes: bug fixes, minor adjustments, copy changes, configuration changes—no matter how small.
Skipping stages is prohibited. The user saying "just write the code directly" or "this is just a small bug" is not a reason to skip the process. The correct approach is to guide the user into the iteration process.
state.json must be read first on every call. Before generating any content or performing any action, first read .dwf/state.json to determine the current stage. Then act strictly according to the requirements of that stage.
Use Chinese throughout. All interactions with the user (including the question tool's options and titles), all generated documents (requirements document, design draft, requirements breakdown document, technical solution, implementation checklist), as well as the titles/labels/descriptions in the documents, must use Chinese. Only content that itself cannot be translated, such as code, file paths, and technical terms (e.g., React, Vue, API), may use English.

Violating any of the above is a disruption of the workflow.

dev-workflow workflow

A workflow executed strictly in order, gradually transforming requirements into deliverable code. Each stage must be completed and confirmed by the user before proceeding to the next stage.

Core principles

No stage can begin before the previous stage has been confirmed by the user. This is non-negotiable. If the user tries to skip, guide them back to the current unconfirmed stage.

Programming standards and templates

Coding-related stages must read and follow references/coding_standards.md. This file is the unified source for this skill's standardized code output, covering pre-execution analysis, code style, React frontend conventions, task execution, and verification requirements.

When a project is created from scratch and the technical solution selects a React frontend, prioritize using assets/ the templates in as the basis for 06-code/ :

Target end	Template directory	Purpose
PC end	`assets/react-pc/`	React PC project template
Mobile end	`assets/react-mobile/`	React Mobile project template
Common capabilities	`assets/shared/`	Reusable configuration, types, hooks, utils, request wrappers, etc.

When using templates, only copy the source code and configuration that match the selected end and technical solution; do not copy unrelated end templates, and do not treat dist/ build artifacts as source code for subsequent development, unless the user explicitly requests it.

Confirmation Mechanism

Every step that requires user confirmation must use the question tool for interaction, and must not be asked using plain text only.question The tool provides structured options to ensure the user makes a clear decision.

All question calls enable custom input by default (custom: true), allowing users to enter free text beyond the options. For the standard question format of each scenario, see references/question_templates.md, which includes the following scenarios:

Scenario	Purpose
Phase document confirmation	Review and confirmation of documents for each phase
Design draft method selection	Phase 2: select the method for obtaining the design draft
Technical solution selection confirmation	Phase 4: select one of multiple technical solutions
Iteration naming confirmation	Iteration step 1: confirm the iteration name
Iteration impact scope confirmation	Iteration step 1: confirm the list of affected phases
Workflow completion	Follow-up actions after workflow completion
New project risk confirmation	Secondary risk notification and confirmation after the user selects "Start New Project"

Important: If the user selects "Start New Project",do not execute immediately. You must first provide a secondary risk notification and confirmation (refer to references/question_templates.md → New project risk confirmation). Only after the user explicitly selects "Confirm deletion and restart" in the secondary confirmation should the "Restart" process be executed.

Status Tracking

The workflow tracks its status in .dwf/state.json . On each call, first read this file to determine the phase the user is currently in.

Status values and their meanings:

Status	Meaning
`init`	The workspace has not yet been initialized (transient, not persisted; once the status file is written it is `requirements`）
`requirements`	The requirements document has been generated, awaiting user confirmation
`design`	The design draft has been collected/generated/recorded, awaiting user confirmation (can be skipped)
`breakdown`	The requirements breakdown document has been generated, awaiting user confirmation
`plans`	Technical solutions have been generated (≥2), awaiting user selection and confirmation
`todos`	The implementation checklist has been generated, awaiting user confirmation
`code`	Preparing to execute the implementation checklist, coding in progress
`done`	All tasks have been completed
`iteration`	In iteration mode, check the iteration sub-object for detailed phase progress

If .dwf/state.json does not exist, it means the workflow has not yet started; begin from Phase 1.

state.json structure

{
  "current_step": "requirements",
  "project_name": "项目名称",
  "iteration_count": 0,
  "design_skipped": false,
  "selected_plan": null,
  "created_at": "2026-06-24T10:00:00",
  "updated_at": "2026-06-24T10:00:00"
}

Iteration status structure

When the workflow enters iteration mode,state.json will add an iteration sub-object:

{
  "current_step": "iteration",
  "project_name": "项目名称",
  "iteration_count": 0,
  "design_skipped": false,
  "selected_plan": "方案A",
  "iteration": {
    "name": "bugfix-修复样式问题",
    "dir": "07-需求迭代/2026-06-24-bugfix-修复样式问题",
    "affected_stages": ["requirements", "todos"],
    "current_substep": "requirements",
    "confirmed_stages": []
  },
  "created_at": "2026-06-24T10:00:00",
  "updated_at": "2026-06-25T14:30:00"
}

iteration.name is the iteration name, in the format {type}-{描述}, proposed by the AI and confirmed by the user when entering the iteration.
iteration.dir is the save directory for iteration documents, relative to the workspace root, in the format 07-需求迭代/{date}-{type}-{描述}。
iteration.affected_stages is the list of phases that need to be updated in this iteration, arranged in phase order. It is analyzed and proposed by the AI, and confirmed or adjusted by the user.
iteration.current_substep is the phase currently being processed; after each phase confirmation is completed, it advances to the next affected phase.
iteration.confirmed_stages is the list of confirmed phases; after confirmation they are appended, used for breakpoint recovery.

General field descriptions:

project_name is the project name, provided by the user at initialization or extracted from the requirements document.
iteration_count records the number of completed iterations; it is 0 while the first iteration is in progress and increments after completion.
design_skipped marks whether the design draft phase was skipped.
selected_plan records the option selected by the user during the technical solution phase (such as "方案A"), and is not reset during iterations.
created_at is the first creation time of the workflow, andupdated_at is the most recent status change time.
When writing state.json , be sure to update updated_at to the current time.

Directory structure

The document directory is stored under the workspace root directory, and the status tracking file is stored in .dwf/ :

工作区根目录/
├── .dwf/
│   └── state.json                              # 当前阶段状态
├── 01-需求文档/
│   └── 需求文档.md                              # 需求文档
├── 02-设计稿/
│   ├── 设计稿.md                                # 设计稿说明（含链接等）
│   └── images/                                  # 设计稿图片
├── 03-需求拆解文档/
│   └── 需求拆解文档.md                          # 需求拆解文档
├── 04-技术方案/
│   └── 技术方案.md                              # 技术方案（含多个并列方案）
├── 05-实现清单/
│   └── 实现清单.md                              # 实现清单
├── 06-code/                                     # 实际项目代码
│   └── ...
└── 07-需求迭代/
    └── 2026-06-24-bugfix-修复样式问题/          # 迭代目录（date-type-描述）
        ├── 需求文档/                             (受影响时才包含)
        ├── 设计稿/                               (受影响时才包含)
        ├── 需求拆解文档/                         (受影响时才包含)
        ├── 技术方案/                             (受影响时才包含)
        └── 实现清单/                             (受影响时才包含)

Phases

Phase 0: Self-check (must be executed on every invocation)

Read .dwf/state.json(if it exists).
Determine the current phase based on current_step .
If the user request involves code modifications and current_step is code or done, you must inform the user that the iteration process will be entered, and must not directly modify the code.
Act according to the requirements of the current phase, and do not skip.

Phase 1: Initialization & Requirements Capture

Entry conditions: state.json does not exist, or the status is init。

Create the .dwf/ directory and state.json, and create the document subdirectory under the workspace root directory:01-需求文档/、02-设计稿/、02-设计稿/images/、03-需求拆解文档/、04-技术方案/、05-实现清单/、06-code/、07-需求迭代/。

Write .dwf/state.json, with the content:

{
  "current_step": "requirements",
  "project_name": "<项目名称>",
  "iteration_count": 0,
  "design_skipped": false,
  "selected_plan": null,
  "created_at": "<当前时间>",
  "updated_at": "<当前时间>"
}

Determine the requirements acquisition method based on user input:
- The user provides a complete requirements document(markdown / Feishu document / Google docs / plain text / image):
  - Read and extract the requirements content. Use the lark-doc skill to read Feishu document URLs; use the web-access skill to read web documents; read local files directly.
  - Normalize into a requirements document according to the references/requirements_template.md template.
- The user provides a rough requirements description:
  - Ask clarifying questions,one question at a time(prefer multiple choice), iterating over multiple rounds until you understand: what to build (goals, scope, boundaries), why to do it (background and business value), who the users/roles are, the target end, key constraints and assumptions, dependencies and risks, and acceptance criteria.
  Coding guideline: follow karpathy-guidelines "Think Before Coding" — explicitly state assumptions, ask when uncertain, and do not hide confusion.
  - Generate the requirements document according to the references/requirements_template.md template.
Save to 01-需求文档/需求文档.md。
Use the question tool to show the document to the user and request confirmation (refer to references/question_templates.md → phase document confirmation).
Wait for user confirmation. Do not proceed to Phase 2 before the user explicitly confirms.
- If the user selects "needs modification" or enters modification comments: directly modify 01-需求文档/需求文档.md, update updated_at, and use the question tool again to request confirmation.
- Only after the user selects "confirm": update .dwf/state.json 's current_step to "design" and updated_at, then proceed.

Stage 2: Design Draft

Entry conditions: state.json exists and current_step is design。

Use the question tool to collect design draft information from the user (refer to the 'Confirmation Mechanism → Design Draft Method Selection' format).
Handle according to the user's reply:
- User provides a link or image:
  - Record the link in 设计稿.md ; if it is an image, save it to the 02-设计稿/images/ directory.
  - If it is an online design draft link such as Figma, try to download a screenshot and save it to images/; if the download fails, only record the link and inform the user.
  - Generate the design draft description document according to the template in references/design_template.md and save it to 02-设计稿/设计稿.md。
- User chooses AI generation:
  - Read 01-需求文档/需求文档.mdand generate a design plan based on the user's design ideas.
  - Analyze the project type (PC / mobile / both) and determine the design dimensions and specifications.
  - Generate the design document according to the template in references/design_template.md , including: overall layout and page structure description, design descriptions of key pages (visual specifications such as layout, color scheme, font size, spacing, etc.), interaction description, design specifications (color system, font system, spacing system, component specifications).
  - Generate design draft images (PNG) and save them to the 02-设计稿/images/ directory (mechanism: render HTML/CSS mockup as PNG; if not applicable, use nanobanana-skill to generate).
  - Save the design document to 02-设计稿/设计稿.md。
  - Update the state.json of design_skipped to false。
- User chooses to skip:
  - Record "design draft stage skipped" in 02-设计稿/设计稿.md .
  - Update the state.json of design_skipped to true。
Use the question tool to show the result to the user and request confirmation (refer to references/question_templates.md → Stage Document Confirmation).
Wait for user confirmation.
- If the user chooses "needs modification" or enters modification suggestions: after modification, use the question tool again to request confirmation.
- Only after the user chooses "confirm": update the .dwf/state.json of current_step to "breakdown" and updated_at, then proceed.

Stage 3: Requirements Breakdown Document

Entry conditions: state.json exists and current_step is breakdown。

Read 01-需求文档/需求文档.md; if design_skipped is false, also read 02-设计稿/设计稿.md。
Combine the requirements document and design draft to break down functionality, and generate the document according to the template in references/breakdown_template.md , covering:
- Target platform: PC / mobile / both.
- Page and function breakdown: List each page's platform, dependencies, and functional modules by page; modules shared across pages are categorized separately.
- Assets/dependency list: What assets the user needs to provide (such as API keys, accounts, third-party service credentials, image assets, etc.).
- Scope boundaries: Clearly specify what is not within this implementation.
Save to 03-需求拆解文档/需求拆解文档.md。
Use the question tool to present the document to the user and request confirmation (refer to references/question_templates.md → Phase Document Confirmation).
Wait for user confirmation.
- If the user selects "Needs modification" or enters modification feedback: directly modify 03-需求拆解文档/需求拆解文档.md, update updated_at, and use the question tool again to request confirmation.
- Only after the user selects "Confirm": update .dwf/state.json 's current_step to "plans" and updated_at, then proceed.

Phase 4: Generate Technical Solutions

Entry conditions: state.json exists and current_step is plans。

Read 01-需求文档/需求文档.md and 03-需求拆解文档/需求拆解文档.md; if design_skipped is false, also read 02-设计稿/设计稿.md。
Analyze the codebase (if it exists) to understand the current architecture, conventions, and patterns.
Read references/coding_standards.md, and explain the coding standards, verification strategy, and template usage in the solutions; if creating a React frontend project from scratch, at least one solution should preferably be based on the assets/react-pc/ or assets/react-mobile/ template.
Generate technical solutions according to the template in references/plans_template.md ,at least 2 parallel solutions must be provided. Each solution includes:
- Framework/tech stack selection and its rationale
- Required third-party libraries
- Backend API requirements (which APIs the backend needs to provide, API field definitions)
- Data model changes
- Affected files and modules
- Coding standards and template usage instructions
- Risk assessment and mitigation strategies
- Pros and cons comparison
In 04-技术方案/技术方案.md , include all solutions and the solution comparison table, update updated_at。
Use the question tool to present the solutions to the user and request a selection (refer to the "Confirmation Mechanism → Technical Solution Selection Confirmation" format, appending options according to the actual number of solutions).
Wait for user selection.
- If the user selects "Needs modification" or enters modification feedback: directly modify 04-技术方案/技术方案.md, update updated_at, and use the question tool again to request confirmation.
- Only after the user selects a solution: in .dwf/state.json 's selected_plan record the selected solution (e.g., "方案A"), update current_step to "todos" and updated_at, then proceed.

Phase 5: Generate Implementation Checklist

Entry conditions: state.json exists and current_step is todos。

Simultaneously read 01-需求文档/需求文档.md、03-需求拆解文档/需求拆解文档.md and 04-技术方案/技术方案.md(primarily the solution specified by selected_plan ).
Read references/coding_standards.md, and convert the coding standards, template usage, and verification requirements into execution constraints in the implementation checklist.
Break down the selected solution into specific, ordered tasks, following the template in references/todos_template.md . Task requirements:
- Break down as much as possible; do not implement a feature or page all at once(for example, a page should be split into independent tasks such as skeleton, Component A, Component B, state integration, API integration, and styling).
- Specific enough to be executed unambiguously.
- Sort by dependency relationships (earlier tasks unblock later tasks).
- Assign priorities (Must/Should/Could/Won't, MoSCoW).
- Each task must include a "coding standards check" and "verification criteria" to ensure the coding phase can check them off item by item.
Save to 05-实现清单/实现清单.md, update updated_at。
Use the question tool to present the implementation checklist to the user and request confirmation (refer to references/question_templates.md → phase document confirmation).
Wait for user confirmation.
- If the user selects "needs modification" or enters modification feedback: directly modify 05-实现清单/实现清单.md, update updated_at, and use the question tool again to request confirmation.
- Only after the user selects "confirm": update .dwf/state.json 's current_step to "code" and updated_at, then proceed.

Phase 6: Coding Execution

Entry conditions: state.json exists and current_step is code。

Read 05-实现清单/实现清单.md and 04-技术方案/技术方案.md(with the approach specified by selected_plan as primary).
Read references/coding_standards.md. If 06-code/ does not yet have project code and the selected approach is based on the React template, first initialize the code for the target platform using assets/react-pc/ or assets/react-mobile/ , and merge as needed assets/shared/。
In the 06-code/ directory, execute tasks one by one in order. After completing each task, check it against the "coding standards check" and "verification criteria" in the implementation checklist, then mark it as completed in 05-实现清单/实现清单.md .
If a task exposes a problem that invalidates the approach or requirements, pause execution and notify the user. Do not silently deviate.
After all tasks are completed, write .dwf/state.json as {"current_step": "done", ...} and update updated_at。
Summarize the work done and any follow-up items, and ask the user about next steps using the "confirmation mechanism → workflow completion" format.

Iteration Mechanism

Trigger Conditions

The iteration process must be entered when any of the following occurs:

The user proposes a new feature request
The user reports a bug or requests a bug fix
The user requests any modification to existing code (including configuration adjustments, copy changes, style tweaks, etc.)
The user proposes improvement requests such as performance optimization or refactoring
The user requests any addition, deletion, or modification to existing functionality

Regardless of the size of the change, the iteration process must be followed. Even a one-line code change must go through iteration confirmation.

Iteration Naming

The iteration directory is named {date}-{type}-{描述}, for example 2026-06-24-bugfix-修复样式问题。type uses a conventional-commit style prefix:feat(new feature),bugfix(fix),refactor(refactor),perf(performance),style(style),docs(docs),chore(chore). The AI proposes a formatted name based on the user's description, and the user confirms.

Iteration Process

The iteration process is the same as the initial process, following the strict principle of step-by-step confirmation. The documents of each affected phase must be confirmed by the user one by one before proceeding to the next phase.

Iteration Step 1: Initialization & Impact Analysis

Propose an iteration name based on the user's description ({type}-{描述}), use the question tool to ask the user to confirm the name.
Create the 07-需求迭代/{date}-{type}-{描述}/ directory.
Analyze which stages are affected by the change, and propose a list of affected stages. Stages are ordered as follows:
- requirements → design → breakdown → plans → todos
- Include only the affected stages; if design_skipped is true, automatically exclude design。
Use the question tool to confirm the affected stages with the user (refer to the "Confirmation Mechanism → Iteration Impact Scope Confirmation" format).

Wait for user confirmation. The user may add or remove stages.

If the user selects "needs adjustment" or enters adjustment feedback: adjust the affected_stages list based on the feedback, and use the question tool again to request confirmation.

After the user confirms: update .dwf/state.json：

{
  "current_step": "iteration",
  "project_name": "<项目名称>",
  "iteration_count": <当前值>,
  "design_skipped": <当前值>,
  "selected_plan": <当前值>,
  "iteration": {
    "name": "<type>-<描述>",
    "dir": "07-需求迭代/<date>-<type>-<描述>",
    "affected_stages": ["<阶段1>", "<阶段2>", ...],
    "current_substep": "<第一个受影响阶段>",
    "confirmed_stages": []
  },
  "created_at": "<保持不变>",
  "updated_at": "<当前时间>"
}

Iteration Steps 2-N: Confirm affected stages step by step

For affected_stages each stage instrictly follow the list order, execute one by one (if affected_stages is empty, skip this step and go directly to the final iteration step):

Based on the current iteration.current_substep, read the confirmed stage and initial process stage documents as context, and generate the iteration document for that stage.
Generate the document according to the corresponding template in references/ , and save it under {iteration.dir}/{阶段子目录}/{文件名} (see the table below for the stage subdirectory mapping).
Use the question tool to show the iteration document to the user and request confirmation (refer to the "Confirmation Mechanism → Stage Document Confirmation" format, with the header being "Iteration Document Review"). The technical solution stage must likewise provide ≥2 solutions for the user to choose from.
Wait for user confirmation.
- If the user selects "needs modification" or enters modification feedback: directly modify the corresponding document, update updated_at, and use the question tool again to request confirmation.
- After the user confirms:
  - Add this stage to iteration.confirmed_stages。
  - If this stage is plans, write the solution selected by the user into state.json in selected_plan。
  - Advance iteration.current_substep to affected_stages the next stage in
  - Update updated_at。
  - If there is still a next affected stage, return to step 1 to continue processing.
  - If all affected stages have been confirmed, proceed to the final iteration step.

Final Iteration Step: Implement the change

The documents for all affected stages have been confirmed.
Read references/coding_standards.md。
Read the confirmed 技术方案/ and 实现清单/for this iteration (located under iteration.dir , if that stage is affected) as the basis for implementation; for unaffected stages, continue to use the main directory (04-技术方案/、05-实现清单/) documents. Implement the change in 06-code/ . The iteration implementation must only change the affected scope confirmed this time, and must not incidentally improve unrelated code.
After completion, update .dwf/state.json：
- Increment iteration_count。
- Clear the iteration sub-object.
- Set current_step back to "code"。
- Update updated_at。
Summarize the changes made in the iteration and follow-up items.

Stage-to-iteration subdirectory mapping

Stage	Iteration subdirectory	Template	File name
`requirements`	`需求文档/`	`requirements_template.md`	`需求文档.md`
`design`	`设计稿/`	`design_template.md`	`设计稿.md`
`breakdown`	`需求拆解文档/`	`breakdown_template.md`	`需求拆解文档.md`
`plans`	`技术方案/`	`plans_template.md`	`技术方案.md`
`todos`	`实现清单/`	`todos_template.md`	`实现清单.md`

Iteration directory example

07-需求迭代/
├── 2026-06-24-bugfix-修复样式问题/
│   ├── 需求文档/
│   │   └── 需求文档.md
│   └── 实现清单/
│       └── 实现清单.md
└── 2026-06-25-feat-新增下载按钮/
    ├── 需求文档/
    │   └── 需求文档.md
    ├── 需求拆解文档/
    │   └── 需求拆解文档.md
    ├── 技术方案/
    │   └── 技术方案.md
    └── 实现清单/
        └── 实现清单.md

Resume

When the skill is triggered and .dwf/state.json already exists, first perform the Stage 0 self-check, then read the state and resume from the corresponding stage. Do not reinitialize or restart the workflow.

If the state is requirements, display the requirements document and use the question tool to request confirmation.
If the state is design, display the design draft information and use the question tool to request confirmation.
If the state is breakdown, display the requirements breakdown document and use the question tool to request confirmation.
If the state is plans, display the technical solution and use the question tool to request the user to select a solution.
If the state is todos, display the implementation checklist and use the question tool to request confirmation.
If the state is code, check 05-实现清单/实现清单.md: if there are unfinished tasks, resume execution from the interruption point; if all tasks are completed (an iteration has already been entered), the project is in a stable state, waiting for the user to propose new requirement changes and enter the iteration process.
If the state is iteration, read the iteration sub-object:
- Determine the affected stage pointed to by iteration.current_substep .
- If the document for that stage has already been generated, display the document and use the question tool to request confirmation.
- If the document for that stage has not yet been generated, generate the document and use the question tool to request confirmation.
- After the user confirms, proceed to the next affected stage or enter implementation.
If the state is done, use the question tool to ask the user for follow-up actions (refer to the workflow completion format).

Restart

If the user wants to start from scratch (a brand-new project or requirement),a second risk notification and confirmation must be performed first：

Use the question tool to perform a second risk confirmation with the user (refer to the "Confirmation Mechanism → New Project Risk Confirmation" format), clearly informing them that the .dwf/ directory and all document directories (01-需求文档/、02-设计稿/、03-需求拆解文档/、04-技术方案/、05-实现清单/、06-code/、07-需求迭代/) and all their files will be permanently deleted, and that the operation is irreversible.
Wait for the user's second confirmation.
- If the user chooses "Cancel, keep the existing project" or enters a cancellation intent: do not delete anything, and return to the current workflow.
- Only after the user explicitly chooses "Confirm deletion and restart" should the above directories be deleted, and then start from Stage 1.

Before the user's second confirmation, no files or directories may be deleted.

Guardrails

Non-violable rules

Never skip stages. If the user says "just start writing code" or "this is just a small bug", you must explain that the workflow requires following the process first, and then guide them into the correct stage or iteration process.
Never auto-advance. Every stage transition must use question The tool obtains user confirmation. You may proceed only after the user selects the "confirm" option or explicitly confirms via custom input. If no confirmation is received, stop and wait.
Never modify code directly. When the project already has code (current_step is code or done), any modification to the code must go through the iterative process. This includes: bug fixes, minor adjustments (colors, copy, spacing, etc.), configuration changes, dependency updates, refactoring, performance optimization—no matter how small the change, it must go through iteration.
Never skip confirmation and act directly. Even if the user asks you to "confirm whether it is a bug," your answer can only be "yes/no and analysis," and must not include code modifications. If code needs to be modified, you must first enter the iterative process.
Never overwrite without asking. If documents already exist in the document directory, show the user the existing content and ask whether to keep, modify, or replace. When modifying, overwrite the original file directly and do not create a new version.
During iteration, generate documents only for the affected stages. Do not regenerate documents for unchanged stages.
During iteration, confirm step by step, not in batches. Each affected stage in the iteration must be confirmed one by one before proceeding to the next.
When resuming from an iteration breakpoint, you must continue from the current stage. When resuming, continue from the stage pointed to by iteration.current_substep , and do not skip unconfirmed stages.
The technical solution must provide at least 2 options. Stage 4 (and the plans stage during iteration) must generate ≥2 parallel options, and you may proceed only after the user selects one using the question tool.
Starting a new project requires secondary confirmation. When the user selects "start a new project" or requests to restart, you must first use the question tool to disclose risks (list the directories that will be permanently deleted and explain that the operation is irreversible), and you may delete any files only after the user provides secondary confirmation. Before secondary confirmation, you must not delete any content.
Never use English output. Text interactions with the user, the options and titles of thequestion tool, and the content of documents generated in all stages must all use Chinese. Exceptions are content that cannot be translated, such as code, file paths, and technical terms.