---
name: neow-proj
description: 项目对接的对话脚本（task card 协议执行版）。发起方 Agent 用它把「那个事你弄一下」问成一张可验收的卡；接手方 Agent 用它复述、找缺口、给承诺；双方用它写出可验证的验收与日报。
---

# proj · 项目对接脚本（agent 执行）

先判断你是谁这一方的 Agent：

- **发起方**：你有事要交给别人做 → 读第一节，产出 task card。
- **接手方**：你收到一张卡 → 读第二节，确认后开工。
- 两个角色都可能要写日报/阻塞/坏消息 → 读第三节。

## 一、发起方：把一句话变成卡片

**不要听到需求就建卡。** 一次一问，问完六件再落卡；答不齐就先不建——这比建一张含糊的卡省时间。

### 六问（按顺序）

1. **现象**：「现在具体哪里不对？最近一次发生是什么时候、什么表现？」
2. **目标**：「做成之后，谁的行为会变？变成什么样？」
3. **不做**：「这次明确不碰什么？」（范围护栏）
4. **验收**：「怎么算完成？给我一条能当场验证的句子——谁、看什么、达到什么。」
5. **时限**：「什么时候要？硬性原因是什么？最晚能拖到哪天？」
6. **决策人**：「范围变了、验收有争议时，谁拍板？」

### 追问阶梯（答虚时用）

- 「优化一下」→「优化到什么程度算完？现在是多少、目标是多少？」
- 「尽快」→「如果下周三才给你，会发生什么坏事？」
- 「按你说的做」→「验收谁签字？他能接受的标准写下来了吗？」
- 「先做出来看看」→「看到什么你会说『不对，重做』？」
- 「大家配合一下」→「具体谁执行？谁验收？两个人不能是同一个人。」

### 落卡

用 `.proj/cards/YYYY-MM-DD-标题.md`，字段见 `/proj/llms.txt`。写卡时守三条：

1. `acceptance` 每一条都要**可当场验证**；写不出验证动作的，不算验收。
2. `non_goals` 至少一条；没有范围护栏的卡一定会膨胀。
3. `context` 一段话说清「为什么现在做、以前怎么处理、有哪些坑」。

### 建卡后

- 把卡链接发给 owner 和 reviewer（或他们的 Agent），说明「这是要交接的东西，有疑问先 comment 再开工」。
- 状态留 `todo`，等接手方走完接卡确认再变 `doing`；不要替对方改状态。

## 二、接手方：接卡确认四步

收到卡，先别开工。四步做完才把 `todo` 改成 `doing`：

1. **复述**：「我理解要做的是 X，范围是 Y，验收是 Z，截止 W——对吗？」
2. **找缺口**：以下任一情况就退回补卡，不带着疑问开工：
   - 验收项无法当场验证（「体验更好」这类）
   - 依赖没写（要的数据/权限/接口在谁那）
   - 决策人缺失（范围争议时找谁）
   - 时限与工作量明显不匹配
3. **给方案**：「我打算这样做……预计 N 天，需要你配合 A、B。」
4. **落状态**：确认后 `todo → doing`，留 comment：开工时间 + 承诺完成时间。

**卡在 `todo` 超过 3 天没人接，发起方要主动问一次**——沉默不是接单。

## 三、日报、阻塞与坏消息

### 每日 sync（自动生成，只列事实）

```
今日完成：<卡号 + 结果，可验证的那种>
明日计划：<卡号 + 做什么>
阻塞：<等谁、等什么、从哪天起>（没有就写"无"）
```

### 阻塞话术（blocked）

「卡 TC-xxx 从 10-21 起阻塞：等财务开 SAP 供应商主数据权限，找的是老周，已等 1 天。如果 24 小时内没进展，我建议先按现有供应商清单做，风险是新增供应商漏掉。」

写清三件：等谁、等什么、从哪天起。**阻塞超过 24 小时升级到 decision_owner。**

### 坏消息话术

「坏消息：TC-xxx 原定周五交，现在要延到下周二。原因：数据口径对不上，多花了两天。影响：不耽误月底对账；需要你决定的是——先交 80% 可用的版本，还是等完整版？」

坏消息当天说；带原因、影响、选项，不带辩解。

## 四、评审（reviewer 用）

- 48 小时内给结论；给不了先约定时间（「我周五前看完」）。
- 结论三选一：
  - **通过**：「3 条 acceptance 都过，evidence 已回填。」
  - **不通过**：「第 2 条没过：口径和 645 台账差 3 个供应商，具体是 A/B/C。改完再提。」——逐条指，不评价人。
  - **改验收**：「原验收在现有数据下不可验证，建议改为 ___，理由是 ___。」
- 通过时把 evidence 链接补进卡里；这是下次复用的证据。

## 五、变更

- 需求变了：改卡前先写变更理由 + 重估时间，通知 reviewer。
- 范围超过原估算 30%，或交付推后超过一周：**重开卡**，旧卡标 `cancelled` 写原因。
- 进入 `review` 后冻结需求；要加东西就退回 `doing`，不允许边验收边加需求。

## 六、收尾

1. 交付物链接、验收记录、踩坑回填进卡。
2. 复盘三问：哪里估错？哪里返工？下次协议改哪条？
3. 可复用部分抽进项目资产（模板/脚本/检查清单）。