Back to Details

zeno-submitting-work

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Submitting Work (Contributor Workflow)

提交工作（贡献者工作流）

Overview

概述

Push completed work to main branch and create PR for peer review by other agents. Default workflow assumes main branch work unless ZŌE explicitly requested a different branch.
Trigger: Work validated and ready for review
Output: Changes pushed to main, PR created, task status updated
将完成的工作推送到main分支，并创建PR供其他Agent进行同行评审。默认工作流基于main分支开展，除非ZŌE明确要求使用其他分支。
触发条件： 工作已验证完成，准备进入评审阶段
输出结果： 变更已推送到main分支、PR已创建、任务状态已更新

Standard Workflow (Main Branch)

标准工作流（Main分支）

Step 1: Final Validation Already completed via 
validating-work
skill - all tests pass.
Step 2: Commit Changes
bash
undefined
步骤1：最终验证 已通过
validating-work
技能完成——所有测试均通过。
步骤2：提交变更
bash
undefined

Stage changes - be specific

暂存变更 - 请明确指定文件

git status git add src/specific/file.ts tests/specific/test.ts
git status git add src/specific/file.ts tests/specific/test.ts

Commit with conventional format

按照规范格式提交

git commit -m "feat[scope]: concise description"
git commit -m "feat[scope]: concise description"

or: git commit -m "fix[scope]: ..."

或：git commit -m "fix[scope]: ..."

or: git commit -m "docs[scope]: ..."

或：git commit -m "docs[scope]: ..."


**Commit message format:**
- `<type>[scope]: description`
- Types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `ci`, `build`, `perf`
- Scope: component like `stdb`, `backend`, `frontend`
- Description: imperative mood, no period
- Keep under 72 characters

**Git conventions:**
- Never `git add .` - always specify files explicitly
- One logical change per commit
- No generic messages like "updates" or "fixes"
- Conventional commits required

**Step 3: Push to Main**

```bash

**提交信息格式：**
- `<type>[scope]: description`
- 类型：`feat`、`fix`、`docs`、`refactor`、`test`、`chore`、`ci`、`build`、`perf`
- 范围：组件名称，如`stdb`、`backend`、`frontend`
- 描述：使用祈使语气，结尾无句号
- 长度控制在72字符以内

**Git规范：**
- 禁止使用`git add .`——始终明确指定文件
- 每次提交对应一个逻辑变更
- 禁止使用“updates”或“fixes”这类通用信息
- 必须遵循规范提交格式

**步骤3：推送到Main分支**

```bash

Push to your fork's main (or upstream if you have access)

推送到你的fork的main分支（若有权限也可推送到上游）

git push origin main

**Step 4: Create PR**

```bash
git push origin main

**步骤4：创建PR**

```bash

Create PR with task context

结合任务上下文创建PR

gh pr create --title "feat[scope]: description" --body "Task #[ID]: [brief description]
gh pr create --title "feat[scope]: description" --body "Task #[ID]: [brief description]

Changes

变更内容

  • [specific change 1]
  • [specific change 2]
  • [具体变更1]
  • [具体变更2]

Verification

验证情况

  • All tests pass: [test command output summary]
  • Component verification complete
  • 所有测试通过：[测试命令输出摘要]
  • 组件验证完成

Notes

备注

[Any special considerations for reviewers]"

**Step 5: Update Nexus Task**

Update task status to `Review` and link PR:
status: Review github_pr_url: [PR URL]
undefined
[给评审者的特殊注意事项]"

**步骤5：更新Nexus任务**

将任务状态更新为`Review`并关联PR：
status: Review github_pr_url: [PR URL]
undefined

When ZŌE Requests Different Branch

当ZŌE要求使用其他分支时

Rare case - explicitly requested in task:
Task description will say: "Work on branch: 
feature/name
"
Then:
bash
undefined
罕见情况——任务中明确要求：
任务描述会说明：“在
feature/name
分支上开展工作”
操作步骤：
bash
undefined

Create and checkout branch

创建并切换到分支

git checkout -b feature/name
git checkout -b feature/name

Make changes, commit, push

进行变更、提交、推送

git push -u origin feature/name
git push -u origin feature/name

Create PR

创建PR

gh pr create --title "..." --body "..."

**Default is always main unless explicitly stated.**
gh pr create --title "..." --body "..."

**默认始终使用main分支，除非明确说明。**

PR Requirements for Agent Review

Agent评审的PR要求

Your PR must:
  • Link to Nexus task (in description)
  • Include verification evidence
  • Be atomic (one logical change)
  • Pass all component checks
PR will be reviewed by:
  • Minimum 3 different Zeno agents
  • They check: Does it meet task requirements? Code quality?
  • ZŌE validates: Were reviews done? Any concerns raised?
你的PR必须满足：
  • 关联Nexus任务（在描述中）
  • 包含验证证据
  • 具备原子性（单个逻辑变更）
  • 通过所有组件检查
PR将由以下角色评审：
  • 至少3个不同的Zeno Agent
  • 他们会检查：是否符合任务要求？代码质量如何？
  • ZŌE会验证：是否完成评审？是否有提出问题？

Anti-Patterns

反模式

❌ Wrong: Push without creating PR ✅ Right: Always create PR for agent review
❌ Wrong: Giant PR with multiple unrelated changes ✅ Right: Atomic PRs, one task per PR
❌ Wrong: "WIP" or incomplete PRs ✅ Right: Only submit when ready for review
❌ Wrong: Work on feature branch without explicit ZŌE request ✅ Right: Default to main branch
❌ Wrong: Update task status before PR created ✅ Right: Link PR first, then update status to Review
❌ 错误做法： 不创建PR直接推送 ✅ 正确做法： 始终创建PR供Agent评审
❌ 错误做法： 大型PR包含多个不相关变更 ✅ 正确做法： 原子化PR，一个任务对应一个PR
❌ 错误做法： 提交“WIP”或未完成的PR ✅ 正确做法： 仅在准备好评审时提交
❌ 错误做法： 未得到ZŌE明确要求就使用功能分支 ✅ 正确做法： 默认使用main分支
❌ 错误做法： 创建PR前更新任务状态 ✅ 正确做法： 先关联PR，再将状态更新为Review

Integration

流程衔接

Previous: 
validating-work
(verified completion) Next: Agents use 
reviewing-prs
to review your work
上一环节： 
validating-work
（已验证完成） 下一环节： Agent使用
reviewing-prs
技能评审你的工作

Bottom Line

核心要点

Main branch workflow: Validate → Commit → Push → PR → Update task
Exception: Only use feature branches if ZŌE explicitly requested in task description.
Main分支工作流： 验证 → 提交 → 推送 → 创建PR → 更新任务
例外情况：仅当ZŌE在任务描述中明确要求时，才使用功能分支。