Back to Details

execute

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Execute

执行

Receive a task, classify its difficulty, think proportionally, and start working immediately.
<request_routing>
接收任务，分类难度，匹配对应思考深度，立即开始工作。
<request_routing>

Positive triggers

正向触发条件

  • A direct task instruction with a clear deliverable: "add pagination to the user list", "implement dark mode toggle".
  • An explicit execution request: "do this", "build this", "make this work".
  • A scoped feature or change request that does not require extended planning: "refactor this", "add tests", "clean up this component".
  • 带有明确交付成果的直接任务指令："为用户列表添加分页功能"、"实现暗黑模式切换"。
  • 明确的执行请求："做这个"、"构建这个"、"让这个正常运行"。
  • 无需扩展规划的限定性功能或变更请求："重构这个"、"添加测试"、"清理这个组件"。

Out-of-scope

超出范围

  • Bug reports with error messages or failing symptoms. Route to 
    bug-fix
    .
  • Repository-wide build, CI, or deployment failures. Route to 
    deploy-fix
    .
  • Pre-release validation or build readiness checks. Route to 
    pre-deploy
    .
  • Strategic planning or architecture decisions. Route to a dedicated planning or architecture skill when available; in this repo prefer 
    prd-maker
    for requirements and framework-specific architecture skills for implementation architecture.
  • Code review or quality audit. Route to a dedicated review or QA skill when available; in this repo prefer 
    qa
    for systematic QA work.
  • Security analysis. Route to a dedicated security skill when available; in this repo use framework-specific security skills such as 
    tanstack-start-security
    when applicable.
  • Explicit workflow invocations such as 
    $autoresearch-skill
    , 
    $ralph
    , or another 
    $skill
    request. Preserve the explicitly requested workflow instead of treating the prompt as a generic execute task.
  • 带有错误信息或失败症状的Bug报告。请路由至
    bug-fix
    。
  • 仓库级别的构建、CI或部署失败。请路由至
    deploy-fix
    。
  • 预发布验证或构建就绪检查。请路由至
    pre-deploy
    。
  • 战略规划或架构决策。若有专门的规划或架构skill请路由至对应skill；本仓库中优先使用
    prd-maker
    处理需求，框架特定架构skill处理实现架构。
  • 代码评审或质量审计。若有专门的评审或QA skill请路由至对应skill；本仓库中优先使用
    qa
    处理系统性QA工作。
  • 安全分析。若有专门的安全skill请路由至对应skill；本仓库中适用时可使用框架特定安全skill，如
    tanstack-start-security
    。
  • 显式的工作流调用，如
    $autoresearch-skill
    、
    $ralph
    或其他
    $skill
    请求。保留显式请求的工作流，而非将提示视为通用执行任务。

Boundary cases

边界情况

  • If the request mixes a bug fix with new work, execute owns it when the primary intent is the new work.
  • If the task scope is genuinely unclear (no deliverable identifiable), ask one clarifying question — then execute.
  • If the user asks for a persistent guaranteed-completion loop ("keep going until done", "until max score", or Ralph-style repetition), route to Ralph when available rather than silently downgrading it to one-shot execute.
  • If the task turns out to require architectural decisions mid-flight, pause and consult the user rather than guessing.
</request_routing>
<argument_validation>
If ARGUMENT is missing or too vague to identify a deliverable, ask briefly:
text
What should I execute?
- Task or feature to implement
- Target files or area
- Any constraints or requirements
Do not over-interrogate. One round of clarification maximum, then start working.
</argument_validation>
<difficulty_classification>
Classify before thinking. Use these signals:
DifficultySignalsThinking depth
EasySingle file, clear scope, familiar pattern, mechanical change1-3 thoughts
MediumMulti-file, some ambiguity, moderate scope, requires context gathering4-6 thoughts
HardCross-cutting, architectural impact, unfamiliar domain, complex interactions7+ thoughts
For compound tasks (e.g. "refactor + add tests"), classify by the hardest sub-task. Treat the compound as one deliverable, not separate jobs.
When uncertain, round up one level. It is cheaper to over-think slightly than to redo work.
</difficulty_classification>
<mandatory_reasoning>
  • 如果请求同时包含Bug修复和新工作，当主要意图是新工作时，由执行模块负责。
  • 如果任务范围确实不明确（无法识别交付成果），提出一个澄清问题——然后执行。
  • 如果用户要求持续的保证完成循环（"直到完成"、"直到最高分"或Ralph式重复），若有Ralph则路由至Ralph，而非静默降级为单次执行。
  • 如果任务执行中途需要做出架构决策，请暂停并咨询用户，而非自行猜测。
</request_routing>
<argument_validation>
如果ARGUMENT缺失或过于模糊，无法明确交付成果，请简要询问：
text
我需要执行什么任务？
- 需实现的任务或功能
- 目标文件或区域
- 任何约束或要求
不要过度询问。最多进行一轮澄清，然后开始工作。
</argument_validation>
<difficulty_classification>
思考前先进行分类。参考以下判断信号：
难度判断信号思考深度
简单单文件、范围明确、熟悉模式、机械性变更1-3个思考点
中等多文件、存在一定歧义、范围适中、需要收集上下文4-6个思考点
复杂跨模块、有架构影响、陌生领域、复杂交互7个以上思考点
对于复合任务（如“重构+添加测试”），按难度最高的子任务分类。将复合任务视为一个交付成果，而非独立任务。
若不确定，向上提升一个等级。略微过度思考比重做工作成本更低。
</difficulty_classification>
<mandatory_reasoning>

Adaptive Sequential Thinking

Adaptive Sequential Thinking

Always run 
sequential-thinking
before implementation. The number of thoughts scales with difficulty:
Easy (1-3 thoughts):
  1. What exactly needs to change
  2. Where to change it
  3. How to verify
Medium (4-6 thoughts):
  1. Scope and deliverable clarity
  2. Relevant code exploration plan
  3. Implementation approach
  4. Edge cases or risks
  5. Verification strategy
  6. (Optional) Alternative approach comparison
Hard (7+ thoughts):
  1. Scope and deliverable clarity
  2. Codebase context and dependencies
  3. Design approach
  4. Implementation breakdown
  5. Edge cases and failure modes
  6. Cross-cutting impact
  7. Verification strategy 8+ (as needed) Revision, branching, deeper analysis
Announce the classification briefly before starting:
Difficulty: [easy/medium/hard] — [one-line reason]
</mandatory_reasoning>
<execution_rules>
始终在实施前运行
sequential-thinking
。思考次数随难度递增：
简单（1-3个思考点）:
  1. 具体需要变更什么
  2. 在哪里进行变更
  3. 如何验证
中等（4-6个思考点）:
  1. 范围和交付成果清晰度确认
  2. 相关代码探索计划
  3. 实现方案
  4. 边缘情况或风险
  5. 验证策略
  6. （可选）替代方案对比
复杂（7个以上思考点）:
  1. 范围和交付成果清晰度确认
  2. 代码库上下文和依赖关系
  3. 设计方案
  4. 实现拆解
  5. 边缘情况和失败模式
  6. 跨模块影响
  7. 验证策略 8+（按需）修订、分支、深度分析
开始前简要宣布分类结果：
难度：[简单/中等/复杂] — [一句话说明理由]
</mandatory_reasoning>
<execution_rules>

Core principle: act, don't deliberate

核心原则：行动，而非犹豫

  • Start implementing after thinking. Do not present options or wait for confirmation.
  • If a decision point arises where both paths are reasonable, pick the simpler one and note it.
  • Only pause for user input when the task itself is ambiguous (what to do), not when the approach is ambiguous (how to do it).
  • Keep scope to what was asked. Do not add unrequested improvements.
  • 思考完成后立即开始实施。不要提供选项或等待确认。
  • 如果遇到两种方案都合理的决策点，选择更简单的方案并备注。
  • 仅当任务本身不明确（要做什么）时才暂停等待用户输入，而非方案不明确（怎么做）时。
  • 严格遵循请求范围。不要添加未被要求的改进。

Implementation

实施要求

  • Read relevant code before editing.
  • Make targeted changes — smallest diff that achieves the deliverable.
  • Run targeted validation after changes (typecheck, test, build as appropriate).
  • If validation fails, fix it within scope. Do not leave broken state.
</execution_rules>
<workflow>
StepTaskTool
1Validate input — identify the deliverable-
2Classify difficulty (easy/medium/hard)-
3Think proportionallysequential-thinking
4Explore relevant codeRead/Grep/Glob
5ImplementEdit/Write
6Validate (typecheck/test/build)Bash
7Report outcome and changed files-
Steps 4-6 may repeat as needed. The goal is a working deliverable, not a single pass.
</workflow>
<completion_report>
After execution, report briefly:
markdown
undefined
  • 编辑前先阅读相关代码。
  • 做出针对性变更——以最小的代码差异实现交付成果。
  • 变更后进行针对性验证（按需进行类型检查、测试、构建）。
  • 如果验证失败，在范围内修复问题。不要留下损坏状态。
</execution_rules>
<workflow>
步骤任务工具
1验证输入——明确交付成果-
2分类难度（简单/中等/复杂）-
3匹配对应思考深度sequential-thinking
4探索相关代码Read/Grep/Glob
5实施Edit/Write
6验证（类型检查/测试/构建）Bash
7报告结果和变更文件-
步骤4-6可按需重复。目标是交付可正常运行的成果，而非单次完成。
</workflow>
<completion_report>
执行完成后，简要报告：
markdown
undefined

Done

已完成

Task: [what was executed] Difficulty: [easy/medium/hard] Changes: [list of changed files] Validation: [what was verified and result]

If anything remains unverified, say what and why.

</completion_report>

<validation>

Execution checklist:

- [ ] ARGUMENT validated — deliverable is clear
- [ ] Difficulty classified
- [ ] sequential-thinking completed (proportional depth)
- [ ] Relevant code read before editing
- [ ] Implementation complete
- [ ] Validation executed (typecheck/test/build)
- [ ] Outcome reported with changed files

Forbidden:

- [ ] Presenting options and waiting for selection (this is execute, not diagnose)
- [ ] Over-thinking easy tasks (1-3 thoughts max for easy)
- [ ] Under-thinking hard tasks (7+ thoughts minimum for hard)
- [ ] Expanding scope beyond what was asked
- [ ] Claiming completion without running validation

</validation>
任务：[已执行的内容] 难度：[简单/中等/复杂] 变更：[变更文件列表] 验证：[已验证内容及结果]

如果有未验证的内容，请说明是什么及原因。

</completion_report>

<validation>

执行检查清单：

- [ ] ARGUMENT已验证——交付成果明确
- [ ] 已完成难度分类
- [ ] 已完成sequential-thinking（匹配对应深度）
- [ ] 编辑前已阅读相关代码
- [ ] 实施完成
- [ ] 已执行验证（类型检查/测试/构建）
- [ ] 已报告结果及变更文件

禁止操作：

- [ ] 提供选项并等待选择（这是执行模块，而非诊断模块）
- [ ] 简单任务过度思考（简单任务最多1-3个思考点）
- [ ] 复杂任务思考不足（复杂任务至少7个思考点）
- [ ] 扩展请求范围之外的内容
- [ ] 未运行验证就声称完成

</validation>