Back to Details

autonomous-workflow

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Autonomous Workflow

自主工作流

Proposal-First (CRITICAL)

提案优先（核心要求）

NEVER create or modify files without explicit approval. Always:
  1. PROPOSE the change (what, why, which files)
  2. WAIT for approval
  3. IMPLEMENT only after approval
Exceptions: bug fixes in already-approved work, read-only research, formatting.
绝不允许在未获得明确批准的情况下创建或修改文件。请始终遵循以下步骤：
  1. 提案说明变更内容（变更什么、原因、涉及哪些文件）
  2. 等待批准
  3. 仅在获批后实施变更
例外情况：已获批工作中的bug修复、只读研究、格式调整。

Decision Authority (for approved work)

决策权限（针对已获批工作）

  • Fix bugs, warnings, missing error handling, broken imports: proceed without asking
  • Add missing tests, fix linting issues, update outdated deps: proceed without asking
  • Change architecture, add new infrastructure, switch libraries: ASK first
  • Delete or significantly restructure existing code: ASK first
  • 修复bug、警告、缺失的错误处理、损坏的导入：无需询问即可进行
  • 添加缺失的测试、修复代码检查问题、更新过时的依赖：无需询问即可进行
  • 变更架构、添加新基础设施、切换库：需先询问
  • 删除或大幅重构现有代码：需先询问

After Every Change

每次变更后

  • Run the relevant test suite
  • Run the linter/type checker
  • Fix ALL warnings, not just errors
  • Run the project's formatter on changed files
  • 运行相关测试套件
  • 运行代码检查/类型检查工具
  • 修复所有警告，而非仅修复错误
  • 对变更文件运行项目的格式化工具

Unused Variables

未使用的变量

  • NEVER prefix unused variables with underscore (_var) to silence linters
  • Either USE the variable or REMOVE it entirely
  • If a function parameter is required by an interface but unused, restructure to avoid it
  • This applies to all languages: TypeScript, Rust, Python
  • 绝不允许通过给未使用变量添加下划线前缀（_var）来屏蔽代码检查工具的提示
  • 要么使用该变量，要么将其完全移除
  • 如果接口要求的函数参数未被使用，请重构代码以避免这种情况
  • 此规则适用于所有语言：TypeScript、Rust、Python

Commit Hygiene

提交规范

  • Never use --force, --no-verify, HUSKY=0 without explicit permission
  • Never commit .env files, credentials, or secrets
  • Atomic commits: one logical change per commit
  • Never add 
    Co-authored-by
    , 
    Ultraworked with
    , or any AI agent attribution to commits, PRs/MRs, comments, or changelogs. Keep commit messages clean and focused on the change itself.
  • 未经明确许可，绝不使用--force、--no-verify、HUSKY=0参数
  • 绝不提交.env文件、凭证或机密信息
  • 原子提交：每次提交对应一个逻辑变更
  • 绝不在提交记录、PR/MRs、评论或变更日志中添加
    Co-authored-by
    、
    Ultraworked with
    或任何AI Agent署名信息。保持提交信息简洁，聚焦于变更本身。

Fresh Context for Large Work

大型工作的全新上下文处理

Before starting large implementations (multi-phase plans, migrations, new stack deployments):
  • Commit and push all preparatory work (plans, config updates)
  • Start a fresh session / compact context to maximize available context window
  • Reference the plan file for implementation details rather than relying on conversation history
在开始大型实施工作前（多阶段计划、迁移、新栈部署）：
  • 提交并推送所有准备工作（计划、配置更新）
  • 开启新会话/精简上下文以最大化可用上下文窗口
  • 参考计划文件获取实施细节，而非依赖对话历史

Continuous Config Improvement

持续配置优化

Agent instructions are living documents. When you discover something that should be codified -- a new pattern, a gotcha, a convention, a lesson learned -- PROPOSE updating the relevant config file:
  1. What to codify: Recurring mistakes, new conventions, environment-specific gotchas, workflow patterns that should be standardized
  2. Always propose first: Never silently update config files. Describe what you learned and why it should be codified. Wait for approval.
Agent指令是动态文档。当你发现需要纳入规范的内容时——如新的模式、陷阱、约定、经验教训——请提案更新相关配置文件：
  1. 需纳入规范的内容：重复出现的错误、新约定、特定环境的陷阱、需标准化的工作流模式
  2. 始终先提案：绝不擅自更新配置文件。描述你学到的内容以及纳入规范的原因。等待批准。