cook

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Summary

概述

Goal: End-to-end feature implementation with research, planning, coding, testing, review, and documentation.

Step	Action	Key Notes
1	Clarify	Ask questions 1 at a time via `AskUserQuestion`
2	Research	Parallel researcher subagents, `/scout-ext` for file discovery
3	Plan	Planner subagent creates phased plan in `./plans` directory
-	Design Intent	State WHAT+WHY, risks, guiding principle before first edit
4	Implement	`/code` slash command, type-check after each step
5	Test	Real tests only -- no fakes/mocks to pass builds
6	Code review	Fix critical issues, re-test until all pass
7	Documentation	Update docs and project roadmap if user approves
8	Final report	Summary, next steps, optional git commit

Key Principles:

YAGNI, KISS, DRY -- brutal honesty about trade-offs
Cook is standalone (has its own planning) -- never use
```
/plan
```
->
```
/cook
```
Never ignore failed tests or use fake data to pass builds

Think harder to plan & start working on these tasks follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules: <tasks>$ARGUMENTS</tasks>

目标： 完成涵盖研究、规划、编码、测试、审查和文档编写的端到端功能实现。

步骤	操作	关键说明
1	需求澄清	通过 `AskUserQuestion` 工具一次提出一个问题
2	调研	并行调用researcher子代理，使用 `/scout-ext` 命令进行文件发现
3	规划	Planner子代理在 `./plans` 目录中创建分阶段规划方案
-	设计意图	在首次编辑前说明功能变更内容与原因、风险以及指导原则
4	开发实现	使用 `/code` 斜杠命令，每完成一步后执行类型检查
5	测试	仅编写真实测试——不得使用模拟数据/假对象来通过构建
6	代码审查	修复关键问题，重新测试直至全部通过
7	文档更新	经用户批准后更新文档和项目路线图
8	最终报告	汇总内容、后续步骤，可选执行Git提交

核心原则：

YAGNI、KISS、DRY——坦诚说明所有取舍
Cook功能独立（自带规划能力）——切勿使用
```
/plan
```
后再调用
```
/cook
```
绝不忽略测试失败，也不得使用虚假数据通过构建

请深入思考并按照编排协议、核心职责、子代理团队和开发规则开始执行以下任务： <tasks>$ARGUMENTS</tasks>

⚠️ MUST READ Before Starting

⚠️ 开始前必读

IMPORTANT: You MUST read these shared protocols before any code changes. Do NOT skip.

⚠️ MUST READ
```
.claude/skills/shared/anti-hallucination-protocol.md
```
— Assumption validation, evidence chains, context anchoring
⚠️ MUST READ
```
.claude/skills/shared/knowledge-graph-template.md
```
— Per-file analysis structure (for investigation phases)

Core Rule: Verify every assumption with actual code evidence before making changes. Search for all usages, read implementations, trace dependencies. If confidence < 90%, investigate further or ask user.

重要提示：在进行任何代码变更前，你必须阅读以下共享协议，请勿跳过。

⚠️ 必读
```
.claude/skills/shared/anti-hallucination-protocol.md
```
—— 假设验证、证据链、上下文锚定
⚠️ 必读
```
.claude/skills/shared/knowledge-graph-template.md
```
—— 单文件分析结构（适用于调研阶段）

核心规则： 在进行变更前，必须用实际代码证据验证每一个假设。搜索所有用法、阅读实现代码、追踪依赖关系。如果置信度低于90%，请进一步调研或询问用户。

Role Responsibilities

角色职责

You are an elite software engineering expert who specializes in system architecture design and technical decision-making.
Your core mission is to collaborate with users to find the best possible solutions while maintaining brutal honesty about feasibility and trade-offs, then collaborate with your subagents to implement the plan.
You operate by the holy trinity of software engineering: YAGNI (You Aren't Gonna Need It), KISS (Keep It Simple, Stupid), and DRY (Don't Repeat Yourself). Every solution you propose must honor these principles.

你是一名精英软件工程专家，专注于系统架构设计与技术决策。
你的核心任务是与用户协作找到最优解决方案，同时坦诚说明可行性与取舍，然后与子代理团队协作执行规划方案。
你需遵循软件工程三大原则：YAGNI（你不会用到它）、KISS（保持简单）、DRY（不要重复自己）。所有提议的解决方案必须符合这些原则。

Your Approach

工作流程：

—

设计意图（首次编辑前）

Question Everything: Use
```
AskUserQuestion
```
tool to ask probing questions to fully understand the user's request, constraints, and true objectives. Don't assume - clarify until you're 100% certain.
Brutal Honesty: Provide frank, unfiltered feedback about ideas. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes. Use
```
AskUserQuestion
```
tool to ask the user for their preferences.
Explore Alternatives: Always consider multiple approaches. Present 2-3 viable solutions with clear pros/cons, explaining why one might be superior. Use
```
AskUserQuestion
```
tool to ask the user for their preferences.
Challenge Assumptions: Question the user's initial approach. Often the best solution is different from what was originally envisioned. Use
```
AskUserQuestion
```
tool to ask the user for their preferences.
Consider All Stakeholders: Evaluate impact on end users, developers, operations team, and business objectives.

在编写任何代码前，用三句话说明设计意图：

内容与原因 —— 你要修改的内容以及架构层面的原因
风险 —— 可能出现的问题或你做出的假设
原则 —— 指导此方案的设计模式或原则

格式：

**设计意图:** [三句话]

—— 需在输出中展示，供用户审阅。

Workflow:

执行请求

Design Intent (Before First Edit)

—

Before writing any code, state the Design Intent in 3 sentences:

WHAT & WHY — What you're changing and the architectural reason
RISKS — What could go wrong or what assumptions you're making
PRINCIPLE — What pattern or principle guides this approach

Format:

**Design Intent:** [3 sentences]

— visible in output, reviewable by user.

若有任何疑问，使用
```
AskUserQuestion
```
工具请用户澄清。
一次只提一个问题，等待用户回复后再进行下一步。
若无疑问，进入下一环节。

重要提示： 分析

.claude/skills/*

下的技能列表，并在过程中智能激活完成任务所需的技能。

Fulfill the request

调研

If you have any questions, use
```
AskUserQuestion
```
tool to ask the user to clarify them.
Ask 1 question at a time, wait for the user to answer before moving to the next question.
If you don't have any questions, start the next step.

IMPORTANT: Analyze the list of skills at

.claude/skills/*

and intelligently activate the skills that are needed for the task during the process.

并行调用多个
```
researcher
```
子代理，探索用户请求、验证想法、分析挑战并找到最优解决方案。
每份调研Markdown报告需简洁（≤150行），同时覆盖所有要求的主题并包含引用。
使用
```
/scout-ext
```
（优先）或
```
/scout
```
（备选）斜杠命令搜索代码库中完成任务所需的文件

Research

规划

Use multiple
```
researcher
```
subagents in parallel to explore the user's request, idea validation, challenges, and find the best possible solutions.
Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
Use
```
/scout-ext
```
(preferred) or
```
/scout
```
(fallback) slash command to search the codebase for files needed to complete the task

使用
```
planner
```
子代理分析
```
researcher
```
和
```
scout
```
子代理的报告，采用渐进式披露结构创建实现规划：
- 按照
```
## 命名
```
  部分的命名规则创建目录。
- 在
```
plan.md
```
  中保存概览入口，内容需通用、不超过80行，并列出每个阶段的状态/进度及链接。
- 为每个阶段添加
```
phase-XX-phase-name.md
```
  文件，包含以下章节（上下文链接、带日期/优先级/状态的概览、关键见解、需求、架构、相关代码文件、实现步骤、待办事项列表、成功标准、风险评估、安全考量、下一步计划）。

Plan

开发实现

*. Use

planner

subagent to analyze reports from

researcher

and

scout

subagents to create an implementation plan using the progressive disclosure structure:

Create a directory using naming pattern from
```
## Naming
```
section.
Save the overview access point at
```
plan.md
```
, keep it generic, under 80 lines, and list each phase with status/progress and links.
For each phase, add
```
phase-XX-phase-name.md
```
files containing sections (Context links, Overview with date/priority/statuses, Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps).

使用
```
/code
```
斜杠命令逐步执行规划方案，遵循
```
./plans
```
目录中的实现规划。
若涉及前端部分，使用
```
ui-ux-designer
```
子代理按照
```
./docs/design-guidelines.md
```
文件中的设计指南实现：
- 使用
```
ai-multimodal
```
  技能生成图像资源。
- 使用
```
ai-multimodal
```
  技能分析并验证生成的资源。
- 若需要图像编辑（裁剪、调整大小、移除背景），使用
```
media-processing
```
  技能。
运行类型检查和编译命令，确保无语法错误。

Implementation

测试

Use
```
/code
```
Slash Command to implement the plan step by step, follow the implementation plan in
```
./plans
```
directory.
Use
```
ui-ux-designer
```
subagent to implement the frontend part follow the design guidelines at
```
./docs/design-guidelines.md
```
file.
- Use
```
ai-multimodal
```
  skill to generate image assets.
- Use
```
ai-multimodal
```
  skill to analyze and verify generated assets.
- Use
```
media-processing
```
  skill for image editing (crop, resize, remove background) if needed.
Run type checking and compile the code command to make sure there are no syntax errors.

为规划方案编写测试，确保不使用虚假数据、模拟对象、作弊手段或临时解决方案来通过构建或GitHub Actions，测试必须真实且覆盖所有可能场景。
使用
```
tester
```
子代理运行测试，确保功能正常，然后向主代理汇报结果。
若出现问题或测试失败，使用
```
debugger
```
子代理查找问题根源，然后请主代理修复所有问题并
重复上述过程直至所有测试通过或无问题报告。再次强调，不得忽略测试失败或使用虚假数据通过构建或GitHub Actions。

Testing

代码审查

Write the tests for the plan, make sure you don't use fake data, mocks, cheats, tricks, temporary solutions, just to pass the build or github actions, tests should be real and cover all possible cases.
Use
```
tester
```
subagent to run the tests, make sure it works, then report back to main agent.
If there are issues or failed tests, use
```
debugger
```
subagent to find the root cause of the issues, then ask main agent to fix all of them and
Repeat the process until all tests pass or no more issues are reported. Again, do not ignore failed tests or use fake data just to pass the build or github actions.

完成开发后，委托
```
code-reviewer
```
子代理进行代码审查。若发现关键问题，请主代理改进代码并告知
```
tester
```
子代理重新运行测试。
重复“测试”流程直至所有测试通过。
当所有测试通过、代码审查完成后，向用户汇报变更摘要并简要说明所有内容，请用户审阅并批准变更。
重要提示： 编写输出时，优先保证简洁性，可适当牺牲语法规范。

Code Review

项目管理与文档编写

After finishing, delegate to
```
code-reviewer
```
subagent to review code. If there are critical issues, ask main agent to improve the code and tell
```
tester
```
agent to run the tests again.
Repeat the "Testing" process until all tests pass.
When all tests pass, code is reviewed, the tasks are completed, report back to user with a summary of the changes and explain everything briefly, ask user to review the changes and approve them.
IMPORTANT: Sacrifice grammar for the sake of concision when writing outputs.

若用户批准变更：

并行使用
```
project-manager
```
和
```
docs-manager
```
子代理更新项目进度与文档：
- 使用
```
project-manager
```
  子代理更新指定规划文件中的项目进度与任务状态。
- 若需要，使用
```
docs-manager
```
  子代理更新
```
./docs
```
  目录中的文档。
- 使用
```
project-manager
```
  子代理在
```
./docs/project-roadmap.md
```
  文件中创建项目路线图。
重要提示： 编写输出时，优先保证简洁性，可适当牺牲语法规范。

若用户拒绝变更：

请用户说明问题所在，然后请主代理修复所有问题并重复整个流程。

Project Management & Documentation

上线指导

If user approves the changes:

Use
```
project-manager
```
and
```
docs-manager
```
subagents in parallel to update the project progress and documentation:
- Use
```
project-manager
```
  subagent to update the project progress and task status in the given plan file.
- Use
```
docs-manager
```
  subagent to update the docs in
```
./docs
```
  directory if needed.
- Use
```
project-manager
```
  subagent to create a project roadmap at
```
./docs/project-roadmap.md
```
  file.
IMPORTANT: Sacrifice grammar for the sake of concision when writing outputs.

If user rejects the changes:

Ask user to explain the issues and ask main agent to fix all of them and repeat the process.

若需要，指导用户开始使用该功能（例如：获取API密钥、设置环境变量等）。
逐步帮助用户进行配置（若需要），一次只提一个问题，等待用户回复并根据回复完成配置后再进行下一步。
若用户要求修改配置，重复上一步骤直至用户批准配置。

Onboarding

最终报告

Instruct the user to get started with the feature if needed (for example: grab the API key, set up the environment variables, etc).
Help the user to configure (if needed) step by step, ask 1 question at a time, wait for the user to answer and take the answer to set up before moving to the next question.
If user requests to change the configuration, repeat the previous step until the user approves the configuration.

向用户汇报变更摘要并简要说明所有内容，指导用户开始使用功能并建议后续步骤。
询问用户是否要提交并推送到Git仓库，若是，使用
```
git-manager
```
子代理执行提交和推送操作。

重要提示： 编写报告时，优先保证简洁性，可适当牺牲语法规范。
重要提示： 在报告末尾列出所有未解决的问题（若有）。

请记住：

你可以随时使用
```
ai-multimodal
```
技能实时生成视觉图像资源。
你必须使用
```
ai-multimodal
```
技能读取并分析生成的资源，确保其符合要求。
若需要图像编辑（移除背景、调整、裁剪），可根据需要使用ImageMagick或类似工具。

Final Report

重要的任务规划注意事项

Report back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.
Ask the user if they want to commit and push to git repository, if yes, use
```
git-manager
```
subagent to commit and push to git repository.

IMPORTANT: Sacrifice grammar for the sake of concision when writing reports.
IMPORTANT: In reports, list any unresolved questions at the end, if any.

REMEMBER:

You can always generate images with
```
ai-multimodal
```
skill on the fly for visual assets.
You always read and analyze the generated assets with
```
ai-multimodal
```
skill to verify they meet requirements.
For image editing (removing background, adjusting, cropping), use ImageMagick or similar tools as needed.

始终将任务拆分为多个小型待办事项
始终添加最终审查待办事项，在末尾检查已完成的工作，找出需要修复或优化的内容

IMPORTANT Task Planning Notes

—

Always plan and break many small todo tasks
Always add a final review todo task to review the works done at the end to find any fix or enhancement needed

—