协作

---
name: agent-team-workflow
description: name: agent-team-workflow
---

---
name: agent-team-workflow
description: name: agent-team-workflow
---

---
name: agent-team-workflow
description: "Use when Codex should run a task with Agent Team role separation: classifying task size, creating a numbered task spec, implementing from that spec, independently reviewing with evidence, or managing issue-based rework. Trigger when the user mentions Agent Team, 三窗口, 多窗口, task-spec, worker-report, review-report, issue 闭环, independent review, or wants complex Codex work split into requirements, implementation, and verification roles."
---

# Agent Team Workflow

Use this skill to keep complex Codex work from becoming one long self-validating chat. Treat each "window" as an independent Codex conversation or role context. The roles are:

1. Requirements analysis: define what to do and how to verify it.
2. Implementation: implement only from the spec and self-test.
3. Review: independently verify against the spec with evidence.

For tiny tasks, do not force the full process.

## Start With Task Size

Classify before choosing the workflow:

- `S`: typo, one-line config, small style tweak, clear error fix. Use one window and do the work directly.
- `M`: one module, limited frontend/backend linkage, clear acceptance points. Create a light spec, implement, then self-check.
- `L`: permissions, database, multiple modules, core business logic, or release risk. Use the full three-window workflow.
- `XL`: payment, orders, user permissions, migrations, core paths, or business-loss risk. Use the full workflow with stricter evidence and consider multiple implementation windows.

If a mistake would cause business damage, avoid single-window mode.

## Default Files

Use these files unless the user requests another location:

```text
docs/agent-team/
  task-spec.md
  worker-report.md
  review-report.md
  issues.json        # only when review finds issues
  evidence/          # only when screenshots, logs, responses, or other proof are needed
```

Keep files few and traceable. Put important content in files, not only in chat.

## Numbering

Number everything that will be handed between roles:

- Requirement: `REQ-001`
- Non-goal: `NON-001`
- Business rule: `RULE-BIZ-001`
- Permission rule: `RULE-AUTH-001`
- Data rule: `RULE-DATA-001`
- Implementation task: `TASK-001`
- Acceptance criterion: `AC-001`
- Issue: `ISSUE-001`

Later roles should cite IDs instead of repeating long requirement text.

## Requirements Analysis Role

Use this role when starting `M`, `L`, or `XL` work.

Do:

- Read only necessary context.
- Clarify background, goal, scope, and non-goals.
- Write business, permission, data, and boundary rules.
- Recommend implementation steps without writing code.
- Write executable acceptance criteria.
- Put uncertainty in "待确认事项".
- Ensure each `REQ` maps to at least one `AC`.

Do not:

- Write business code.
- Decide final acceptance.
- Use vague criteria such as "正常处理", "尽量优化", or "适配一下".

Output only `docs/agent-team/task-spec.md`.

Suggested sections:

```text
# Task Spec

## 背景和目标
## 本次范围
## 本次不做
## 业务规则
## 权限规则
## 数据规则
## 影响范围
## 推荐实现步骤
## 验收标准
## 待确认事项
```

## Implementation Role

Use this role after `task-spec.md` exists.

First read `docs/agent-team/task-spec.md`, then do an executability check:

```text
需求是否清晰：是 / 否
实现计划是否合理：是 / 否
验收标准是否可执行：是 / 否
是否需要补充：是 / 否
```

If the spec is not executable, stop coding and explain the missing information.

If executable:

- Implement only the requested scope.
- Do not change requirements.
- Do not lower acceptance standards.
- Do not do unrelated refactors.
- Run relevant self-tests.
- Record what changed and what remains risky.

Output `docs/agent-team/worker-report.md`.

Suggested sections:

```text
# Worker Report

## 可执行性复核
## 实现摘要
## 修改文件
## 覆盖范围
## 自测结果
## 未覆盖项
## 风险与验收关注点
```

Final response should say only that implementation and self-test are done and review is waiting. Do not claim independent acceptance.

## Review Role

Use this role after implementation.

Read:

- `docs/agent-team/task-spec.md`
- `docs/agent-team/worker-report.md`
- Current code diff
- Necessary test evidence

Do:

- Verify each `AC` by ID.
- Run necessary tests.
- Use browser verification for frontend behavior.
- Use requests for API behavior.
- Inspect data results for database work.
- Record commands, actions, evidence, expected results, and actual results.

Do not:

- Fix code.
- Change the spec.
- Give `PASS` without evidence.

Output `docs/agent-team/review-report.md`. If issues exist, also create `docs/agent-team/issues.json`.

Review conclusion must be one of:

- `PASS`
- `FAIL`
- `BLOCKED`

Suggested sections:

```text
# Review Report

## 验收结论
## 验收范围
## 执行命令和验证动作
## 逐项验收记录
## 问题摘要
## 最终说明
```

## Issue Loop

Create `issues.json` only when review finds problems. Use these statuses:

- `OPEN`: review found issue, waiting for fix.
- `FIXED_WAIT_RETEST`: implementation fixed it, waiting for review.
- `CLOSED`: review retested and passed.
- `BLOCKED`: blocked by external condition.
- `WONT_FIX`: explicitly accepted out of scope, with reason.

Rules:

- Only the review role may mark `CLOSED`.
- Implementation may only move `OPEN` to `FIXED_WAIT_RETEST`.
- `WONT_FIX` must include a reason.
- Every issue must bind to at least one `REQ` or `AC`.
- During rework, read only `issues.json`, related `REQ` / `AC`, and relevant code by default.

Example issue:

```json
[
  {
    "id": "ISSUE-001",
    "severity": "P1",
    "type": "权限",
    "status": "OPEN",
    "requirement": "REQ-003",
    "acceptance_item": "AC-003",
    "steps": ["使用无导出权限账号登录", "直接请求订单导出接口"],
    "expected": "接口拒绝访问",
    "actual": "接口返回导出文件",
    "evidence": ["docs/agent-team/evidence/export-auth-fail.log"],
    "suggestion": "后端导出接口补充权限校验"
  }
]
```

## Lightweight Single-Window Mode

Use this for `M` tasks or when the user does not want multiple conversations:

1. Write a short numbered spec in chat or `task-spec.md`.
2. Wait for confirmation if requirements are uncertain.
3. Implement.
4. Write `worker-report.md`.
5. Self-check each `AC`, but do not describe it as independent review.

## Copyable Prompts

Requirements window:

```text
你是需求分析窗口，只负责分析需求并写 docs/agent-team/task-spec.md。禁止写业务代码和做最终验收。请阅读必要上下文，判断任务等级，编号整理 REQ / NON / RULE / TASK / AC，不确定内容写入待确认事项，每个 REQ 至少对应一个可执行 AC。
```

Implementation window:

```text
你是工作实现窗口，只负责按 docs/agent-team/task-spec.md 实现并自测。先做可执行性复核；如果需要补充，停止编码并说明缺口；如果可以执行，再修改代码、自测并创建 docs/agent-team/worker-report.md。禁止改需求、降低验收标准、做无关重构或宣布验收通过。
```

Review window:

```text
你是验收窗口，只负责独立验收，不修代码。读取 docs/agent-team/task-spec.md、docs/agent-team/worker-report.md、当前代码 diff 和必要证据，按 AC 编号逐项验收。输出 docs/agent-team/review-report.md；有问题时创建 docs/agent-team/issues.json。最终结论只能是 PASS / FAIL / BLOCKED。
```

---
name: ai-native-collaboration
description: name: ai-native-collaboration
---

---
name: ai-native-collaboration
description: 协调本机 Codex 与服务器 Hermes 的 AI Native 协作。用于涉及项目开发、线上发布、持续巡检、定时任务、服务器运行、跨项目上下文或需要在两者之间交接任务与结果的请求。
---

# AI Native 协作

将 Codex 与 Hermes 视为同一工作体系中的两名 AI 员工：Codex 负责工程交付，Hermes 负责持续运营。保持一个事实来源和一个工程写入者。

## 职责边界

- 将代码、配置、测试、构建、发布、回滚、设计实现、本机文件与浏览器操作交给 Codex。Codex 是唯一工程写入者。
- 将定时任务、线上健康检查、运行状态观察、异常归纳、跨项目长期上下文和通知交给 Hermes。Hermes 是持续运营者。
- 将目标优先级、商业判断、对外承诺、付费行为、凭据授权、删除数据和不可逆操作交给用户。
- 不让 Hermes 直接修改项目源码、发布包或生产配置。将需要工程改动的问题回传给 Codex。
- 不假定 Hermes 能自动调用本机 Codex。当前没有受控执行端时，由用户在本机 Codex 发起本机步骤。

## 交接事实

每次跨角色交接都记录足以继续工作的最小事实：

- `project_id`：项目或站点。
- `target`：URL、服务、仓库、功能或本机资源。
- `state`：`planned`、`implementing`、`observing`、`intervention_required` 或 `resolved`。
- `source_or_release`：源码提交、发布版本或当前线上基线。
- `expected_result`：可验证的目标状态。
- `evidence`：真实页面、日志摘要、命令结果、版本号或其他可回读证据。
- `next_owner`：`codex`、`hermes` 或 `user`。

不要以“已通知”“构建成功”或聊天结论代替实际证据。不要为此建立第二套项目管理系统；优先复用仓库、发布记录和运行时状态。

## 执行闭环

1. 判定任务归属。纯工程或本机任务由 Codex 完成；持续观察或定时运行由 Hermes 完成；混合任务拆为可交接的两段。
2. 由当前 Owner 完成自己的动作并留下交接事实。Codex 发布后留下版本、目标地址和验证结果；Hermes 检查后留下时间、对象、结果和异常证据。
3. Hermes 发现需要工程修复的问题时，交给 Codex 一条结构化任务：问题、影响、证据、建议动作和验收条件。
4. Codex 修复后重新验证真实路径，并把下一 Owner 交回 Hermes 继续观察，或交给用户做必要决策。

## 发布版本一致性门

涉及正式网页与接口的发布，静态文件、后端服务和运行依赖必须来自同一个已批准的版本目录；不得只切换其中一侧，也不得让未完成候选通过服务启动脚本自动接管。切换前验证该版本的发布清单、启动入口和依赖闭包（尤其是运行时必需模块）；切换时同时更新应用与静态入口，并让发布保护程序以批准版本为唯一来源。重启后必须从全新页面回读真实用户路径，至少确认服务存活、模型目录接口可读、画布显示已接入模型；任一项失败都保留原批准版本并标记发布未通过，不能用 HTTP 状态、服务进程存在或配置文件仍在来代替真实验收。

## 权限与验证

- 在执行删除、系统设置变更、对外发送、凭据读取、付费调用或其他不可逆动作前，请用户确认。
- Hermes 的巡检默认只读。除非用户明确授权且已有可验证流程，不把巡检结论直接转为生产写入。
- 每一次发布由 Codex 验证实际用户路径；每一次持续运营结论由 Hermes 附带可回读证据。
- 优先先跑一个真实闭环，再把同一模式复制到其他项目。默认样板为：Codex 发布，Hermes 观察，Codex 修复，Hermes 复核。

---
name: ai-video-champion-handoff
description: name: ai-video-champion-handoff
---

---
name: ai-video-champion-handoff
description: AI 短剧五冠军的总控说明与统一交接契约。用户需要判断当前该用哪位冠军、五个冠军分别做什么、何时接手、交付什么，或需要在冠军之间交接项目、资产和连续性事实时使用；下级 Skill 只能在用户明确批准后调用。
---

# AI 短剧冠军 Skill 统一交接契约

这是一份共享数据契约，不负责写剧本、生成资产或调用模型。五个冠军 Skill 构成唯一正式生产链，必须读取并遵守本文件；稳定字段名保留为机器接口，用户可见标签必须使用中文。

## 四个权威交接对象

### `project_state`（项目状态）

每次交接都必须携带同一个对象，不得另起一套“当前状态”字段：

```yaml
project_state:
  project_id: "稳定项目编号"
  title: "项目名称"
  source_version: "剧本或上游材料版本"
  stage: "剧本|资产|拆镜|导演提示|生成|剪辑|交付"
  approved_gates: ["已确认的阶段"]
  decisions: ["创作者已拍板的事实"]
  blockers: ["阻塞项；没有则为空数组"]
  next_action: "唯一下一动作"
```

### `asset_manifest`（资产清单）

资产只能用稳定 `asset_id` 交接，禁止用文件名或聊天顺序代替：

```yaml
asset_manifest:
  - asset_id: "稳定资产编号"
    category: "角色|状态|场景|道具|参考图|音频|视频"
    name: "用户可读名称"
    version: "资产版本"
    source: "上传|念念画布生成|外部导入"
    status: "候选|待确认|已确认|淘汰"
    dependencies: ["依赖的 asset_id"]
    approved_by_user: false
```

### `continuity_ledger`（连续性台账）

只记录已确认事实；每条锁定必须能定位到场次或镜头：

```yaml
continuity_ledger:
  - lock_id: "稳定锁定编号"
    scope: "场次或镜头编号"
    characters: ["asset_id"]
    wardrobe_state: "服装、妆发、伤口、年龄状态"
    prop_state: "道具位置、朝向、损坏状态"
    spatial_state: "人物、镜头、地标的相对位置"
    lighting_state: "光源方向、色温、反差"
    camera_state: "轴线、焦段、运动方向"
    audio_state: "对白、环境声、音乐连续性"
    source: "用户确认|已验收片段|剧本事实"
```

### `accepted_clip`（已验收片段）

只有用户确认或质量门通过后才能写入；生成任务刚完成时仍是候选片段：

```yaml
accepted_clip:
  clip_id: "稳定片段编号"
  shot_id: "镜头编号"
  task_id: "念念画布任务编号"
  asset_id: "注册到资产库的视频资产编号"
  duration_seconds: 15
  status: "候选|已验收|返工|淘汰"
  acceptance_note: "验收结论"
  rejection_reason: "返工原因；已验收时为空"
  parent_clip_id: "替换片段编号；没有则为空"
  continuity_snapshot: "写入片段时的连续性台账版本"
```

### `canvas_group_contract`（念念画布分组与连接合同）

念念画布只允许使用系统默认的五个顶层分组：`分镜`、`角色`、`场景`、`道具`、`声音`。项目分类、集数、镜头组和视频段只能作为这五组下的子组，不得新建自定义顶层分组。

```yaml
canvas_group_contract:
  top_level_groups: ["分镜", "角色", "场景", "道具", "声音"]
  custom_top_level_groups: false
  shot_subgroups:
    - group_id: "分镜/第1集/镜头组1"
      shot_ids: ["镜头编号"]
      video_node_ids: ["视频节点编号"]
      referenced_assets:
        - asset_id: "稳定资产编号"
          role: "首帧|角色|场景|道具|声音|参考"
          source_group: "角色|场景|道具|声音"
          linked: true
```

角色、场景、道具和声音资产保留在各自默认分组；凡被视频生产消费的资产，必须同时挂接到对应的`分镜`子组，并与视频节点、镜头编号和参考职责建立可回读的连接。画布不支持多父级时使用连接关系或资产引用，不重复上传制造第二份资产。缺少任一必需连接时，生产节点保持未就绪，不得提交视频任务。

## 任务选人

| 用户现在要解决什么 | 该用的冠军 | 交付到哪里 |
|---|---|---|
| “这些小说、参考图、导演资料里哪些规则能用？” | `knowledge-card-skill` | `knowledge_brief`，交给后续冠军 |
| “把创意/小说变成能拍的剧本，或改人物、结构、对白。” | `screenwriter` | 剧本、故事圣经、`project_state` |
| “剧本定了，确定导演基调、人物长相和关键道具。” | `chaoge-assets-trial` | 创作基准、角色/道具和 `asset_manifest` |
| “按剧本和资产逐镜头拍，决定机位、走位和镜头节奏。” | `shotlist-builder` | `shotlist`、连续性草案 |
| “提示词效果不稳，角色表演、物理、镜头或连续性要修。” | `hell-grind` | 最终提示词、锁定后的 `continuity_ledger` |

不要为了“看起来完整”跳过上游：没有资料事实先用知识卡；没有可拍剧本先用编剧；没有已确认角色与关键道具不拆镜；没有拆镜事实不做提示质控。

## 五个 Skill 的职责边界与交接

| Skill | 只负责 | 必须读取 | 必须输出 |
|---|---|---|---|
| `knowledge-card-skill` | 按需检索用户提供的资料，形成有来源的知识简报 | 当前任务与已确认事实 | `knowledge_brief`；不改写项目、资产或连续性事实 |
| `screenwriter` | 故事、人物、场次、对白和可拍摄剧本 | `project_state`、适用的 `knowledge_brief` | 更新后的 `project_state`、剧本、故事圣经 |
| `chaoge-assets-trial` | 角色/状态/关键道具参考资产 | `project_state`、剧本 | 更新后的 `project_state`、`asset_manifest` |
| `shotlist-builder` | 场次拆镜、空间走位、镜头和视频提示计划 | `project_state`、剧本、`asset_manifest` | 更新后的 `project_state`、`shotlist`、待写入的 `continuity_ledger` |
| `hell-grind` | 表演微动作、镜头运动、物理与提示质量控制 | `project_state`、`shotlist`、`asset_manifest`、`continuity_ledger` | 更新后的 `project_state`、最终图像/视频提示、锁定后的 `continuity_ledger` |

生成和剪辑节点还必须读入 `continuity_ledger`，并在任务完成后产生候选 `accepted_clip`；未验收片段不得反向成为连续性事实。

## 统一交接规则

1. 不复制字段：下游只引用上游对象，更新时保留未改变字段。
2. 不静默猜测：缺少 `project_id`、`asset_id`、版本或用户确认状态时暂停并指出缺口。
3. 不越权生成：五个冠军只编译计划和提示；图片/视频必须提交到念念画布任务链，由服务器登记任务、状态和资产。
4. 不丢失失败信息：`blockers`、`rejection_reason` 和返工版本必须保留。
5. 用户看到的阶段名、按钮、表格列、交付说明全部用中文；`project_state` 等稳定机器字段、模型名、文件扩展名和代码标识不翻译。
6. 正式链路外的 15 个下级 Skill 均为 `approval_required`：在读取或调用任一项之前，先向用户说明具体 Skill、用途和本次原因，等待明确批准；不得由总路由自动分派。
7. 进入念念画布生成前，必须先验证 `canvas_group_contract`：只存在五个默认顶层分组、视频素材已归入分镜子组、视频节点与镜头及全部参考资产均已连接；否则停在画布准备门，不把“已上传”当作“已连接”。

## 完整链路

```text
剧本输入
→ knowledge-card-skill
→ screenwriter
→ chaoge-assets-trial
→ shotlist-builder
→ hell-grind
→ 念念画布图像/视频生成任务
→ 候选片段
→ 连续性与质量验收
→ accepted_clip
→ 剪辑、声音、字幕、导出与交付
```