work-intake

工作请求受理

概述

每项工作请求都要经过受理。此技能用于确定范围、收集需求，并将请求分派到合适的工作流。

核心原则： 再小的工作也要跟踪，再大的工作也要拆解。

开始时声明：“我将使用 work-intake 来了解并界定此请求的范围，然后再开始处理。”

受理流程

┌─────────────────────────────────────────────────────────────────────┐
│                        REQUEST RECEIVED                              │
└─────────────────────────────┬───────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────────┐
│               STEP 0: PROJECT BOARD READINESS (GATE)                │
│  Is GITHUB_PROJECT_NUM set?                                         │
│  Is project board accessible?                                       │
│  Are required fields configured?                                    │
└─────────────────────────────┬───────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────────┐
│                    CLARIFYING QUESTIONS                              │
│  What is the user trying to achieve?                                │
│  What does success look like?                                        │
│  What constraints exist?                                             │
└─────────────────────────────┬───────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────────┐
│                      SCOPE ASSESSMENT                                │
│  How much investigation is needed?                                   │
│  How many deliverables?                                              │
│  How many unknowns?                                                  │
└─────────────────────────────┬───────────────────────────────────────┘
                              │
              ┌───────────────┼───────────────┬───────────────┐
              ▼               ▼               ▼               ▼
         ┌────────┐     ┌──────────┐    ┌──────────┐    ┌──────────┐
         │TRIVIAL │     │  SMALL   │    │  LARGE   │    │ MASSIVE  │
         │        │     │          │    │          │    │          │
         │1 issue │     │1-3 issues│    │1 epic    │    │Initiative│
         │no unkn.│     │few unkn. │    │research  │    │multi-epic│
         └───┬────┘     └────┬─────┘    └────┬─────┘    └────┬─────┘
             │               │               │               │
             ▼               ▼               ▼               ▼
      issue-prerequisite  issue-prerequisite  epic-management  initiative-
      + project-board-    + decomposition    + research spikes  architecture
        enforcement       + project-board-  + project-board-  + project-board-
                           enforcement       enforcement       enforcement

步骤 0：项目看板就绪情况（关卡）

受理任何工作请求之前，请先确认项目看板基础设施已就绪。

这是一个关卡。通过检查之前，不要继续提出澄清问题。

# Derive defaults from GITHUB_PROJECT if provided
if [ -z "$GITHUB_PROJECT_NUM" ] && [ -n "$GITHUB_PROJECT" ]; then
  NUM_CANDIDATE=$(echo "$GITHUB_PROJECT" | sed -E 's#.*/projects/([0-9]+).*#\1#')
  if [ -n "$NUM_CANDIDATE" ] && [ "$NUM_CANDIDATE" != "$GITHUB_PROJECT" ]; then
    export GITHUB_PROJECT_NUM="$NUM_CANDIDATE"
    echo "Derived GITHUB_PROJECT_NUM=$GITHUB_PROJECT_NUM from GITHUB_PROJECT"
  fi
fi

if [ -z "$GH_PROJECT_OWNER" ] && [ -n "$GITHUB_OWNER" ]; then
  export GH_PROJECT_OWNER="$GITHUB_OWNER"
  echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from GITHUB_OWNER"
fi

if [ -z "$GH_PROJECT_OWNER" ] && [ -n "$GITHUB_PROJECT" ]; then
  OWNER_CANDIDATE=$(echo "$GITHUB_PROJECT" | sed -E 's#https://github.com/(orgs|users)/([^/]+)/projects/[0-9]+#\2#')
  if [ -n "$OWNER_CANDIDATE" ] && [ "$OWNER_CANDIDATE" != "$GITHUB_PROJECT" ]; then
    export GH_PROJECT_OWNER="$OWNER_CANDIDATE"
    echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from GITHUB_PROJECT"
  fi
fi

if [ -z "$GH_PROJECT_OWNER" ]; then
  REMOTE_URL=$(git remote get-url origin 2>/dev/null || true)
  OWNER_CANDIDATE=$(echo "$REMOTE_URL" | sed -E 's#(git@|https://)github.com[:/]+([^/]+)/[^/]+(\.git)?#\2#')
  if [ -n "$OWNER_CANDIDATE" ] && [ "$OWNER_CANDIDATE" != "$REMOTE_URL" ]; then
    export GH_PROJECT_OWNER="$OWNER_CANDIDATE"
    echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from git remote"
  fi
fi

# Verify environment variables are set
if [ -z "$GITHUB_PROJECT_NUM" ]; then
  echo "BLOCKED: GITHUB_PROJECT_NUM not set"
  echo "Set with: export GITHUB_PROJECT_NUM=<number>"
  exit 1
fi

if [ -z "$GH_PROJECT_OWNER" ]; then
  echo "BLOCKED: GH_PROJECT_OWNER not set"
  echo "Set with: export GH_PROJECT_OWNER=@me  # or org name"
  exit 1
fi

# Verify project is accessible
if ! gh project view "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json > /dev/null 2>&1; then
  echo "BLOCKED: Cannot access project $GITHUB_PROJECT_NUM"
  echo "Verify project exists and you have access"
  exit 1
fi

# Verify required fields exist
FIELDS=$(gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json | jq -r '.fields[].name')

for required in "Status" "Priority"; do
  if ! echo "$FIELDS" | grep -q "^$required$"; then
    echo "WARNING: Required field '$required' not found in project"
    echo "Consider adding this field for full tracking support"
  fi
done
if ! echo "$FIELDS" | grep -q "^Type$" && ! echo "$FIELDS" | grep -q "^Issue Type$"; then
  echo "WARNING: Required field 'Type' (or 'Issue Type') not found in project"
  echo "Consider adding this field for full tracking support"
fi

echo "Project board ready: $GITHUB_PROJECT_NUM"

如果未通过关卡：

1. 配置缺失的环境变量
2. 如有需要，创建项目看板
3. 添加必需字段（Status、Type、Priority）
4. 重新运行就绪情况检查

技能： project-board-enforcement

---

步骤 1：澄清问题

界定范围之前，先了解请求内容。

不要询问能从仓库中找到答案的问题。 首先检查：

• README.md、FEATURES.md、BRANDING.md、docs/、Storybook，以及现有路由和页面
• 现有的 GitHub issues 和项目看板事项

检查仓库后，只向用户询问仍缺失的信息。

必要问题

问题	目的
“你想实现什么目标？”	了解目标，而不只是任务
“怎样才算成功？”	明确验收标准
“会影响谁或什么？”	确定影响范围
“有哪些我需要了解的限制？”	时间、技术、兼容性
“这是更大事项的一部分吗？”	关联现有计划

探索性问题（适用于不明确的请求）

问题	可了解的信息
“你能带我了解一下这个功能会如何使用吗？”	用户旅程、边缘情况
“目前已有些什么？”	当前起点、迁移需求
“你已经尝试过什么？”	失败的方法、限制
“是否有先例或示例？”	设计方向

步骤 2：范围评估

根据以下标准评估请求：

范围矩阵

因素	微小	小型	大型	超大型
未知项	无	少量，可解答	较多，需要调研	大量，需要探索性研究
交付项	1 项	2-5 项	6-20 项	20+ 项
代码范围	1-2 个文件	3-10 个文件	10+ 个文件	多个系统
依赖项	无	仅内部依赖	外部服务	新基础设施
持续时间	< 1 个工作时段	1-3 个工作时段	1-2 周	数周至数月
标准	1-2 项	3-5 项	6-15 项	15+ 项

范围判定

IF unknowns == none AND deliverables <= 2:
  → TRIVIAL: Use issue-prerequisite directly

IF unknowns == few AND deliverables <= 5:
  → SMALL: Use issue-prerequisite, maybe issue-decomposition

IF unknowns == many OR deliverables > 5:
  → LARGE: Use epic-management with research spikes

IF unknowns == extensive OR deliverables > 20 OR new_infrastructure:
  → MASSIVE: Use initiative-architecture

步骤 3：分派到合适的工作流

微小范围

**Assessment:** This is a trivial request (single deliverable, no unknowns).

**Next step:** Creating a single issue using `issue-prerequisite`.

分派到：issue-prerequisite

小型范围

**Assessment:** This is a small request (few deliverables, minimal unknowns).

**Plan:**
1. Create parent issue for the request
2. If needed, decompose into 2-3 sub-issues
3. Begin implementation

**Next step:** Creating issue structure using `issue-prerequisite`.

分派到：issue-prerequisite → 可能还需 issue-decomposition

大型范围

**Assessment:** This is a large request requiring structured planning.

**Unknowns identified:**
- [ ] Unknown 1 - needs investigation
- [ ] Unknown 2 - needs research spike

**High-level deliverables:**
1. Deliverable A
2. Deliverable B
...

**Next step:** Creating epic structure using `epic-management`.

分派到：epic-management（该工作流会根据需要创建探索性研究任务）

超大型范围

**Assessment:** This is a massive request requiring full initiative architecture.

**Why massive:**
- [Reason: extensive unknowns / new infrastructure / multi-system / etc.]

**Initial unknowns:**
- [ ] Does X exist?
- [ ] How does Y work?
- [ ] What are constraints of Z?

**Potential scope:**
- Multiple epics likely
- New capabilities needed
- Significant research required

**Next step:** Beginning initiative architecture using `initiative-architecture`.

分派到：initiative-architecture

可恢复性检查点

分派之前，将受理信息记录到记忆中：

# Store intake assessment
mcp__memory__create_entities([{
  "name": "Intake-[DATE]-[SHORT_DESC]",
  "entityType": "WorkIntake",
  "observations": [
    "Request: [Original request]",
    "Scope: [Trivial/Small/Large/Massive]",
    "Unknowns: [List]",
    "Route: [Target skill]",
    "Status: [Routing/In Progress/Complete]"
  ]
}])

示例

示例：微小范围

请求：“把登录页面按钮的颜色调浅一点。”

受理信息：

• 目标：调整按钮颜色
• 成功标准：按钮颜色变浅
• 未知项：无（CSS 更改）
• 交付项：1 项（颜色更改）
• 范围：微小

→ 分派到 issue-prerequisite

示例：大型范围

请求：“为应用添加深色模式。”

受理信息：

• 目标：支持切换主题
• 成功标准：用户可以切换深色/浅色模式
• 未知项：
  • 当前采用什么主题方案？
  • 组件库是否支持？
  • 如何实现持久化？
• 交付项：约 10 项（主题令牌、组件、切换控件、持久化等）
• 范围：大型

→ 分派到 epic-management

示例：超大规模

请求：“添加一项功能，让用户点击手机上的弹出通知即可登录。”

需求接收：

• 目标：通过移动推送通知登录
• 成功标准：用户收到推送通知，点击后即完成登录
• 未知事项：
  • 是否有移动应用？→ 调研任务
  • 是否有推送通知基础设施？→ 调研任务
  • 身份验证流程设计？→ 调研任务
  • 安全要求？→ 调研任务
• 交付项：30+（应用开发、后端、身份验证、通知等）
• 范围：超大规模

→ 转交给 initiative-architecture

表明范围较大的危险信号

留意以下短语，它们可能意味着请求的范围比表面看起来更大：

短语	可能的范围
“只需添加……” + 新能力	大（新能力 = 基础设施）
“用户应该能够……”	大（面向用户 = 全栈）
“与……集成”	大（外部服务 = API、身份验证、错误处理）
“像[其他产品]一样……”	超大规模（功能对等 = 大量工作）
“移动端/应用/通知”	超大规模（除非已有应用）
“实时/同步/在线”	大（基础设施）

绝不拒绝工作

无论请求的规模有多大：

1. 确认目标 - “我明白你想要实现 X”
2. 说明流程 - “这需要有条理的规划”
3. 开始调查 - 从我们尚不清楚的事项着手
4. 记录一切 - 每项决定、每个发现
5. 拆分任务 - 直到形成可处理的部分

从“超大规模请求”到“实施”的路径是：

Massive Request
    → Initiative Architecture (document unknowns, create research spikes)
    → Research Spikes (answer unknowns)
    → Epic Structure (group deliverables)
    → Issue Decomposition (create tractable tasks)
    → Implementation (one issue at a time)

检查清单

• 已确认项目看板就绪（通过第 0 步门槛）
• 已设置 GITHUB_PROJECT_NUM 和 GH_PROJECT_OWNER
• 已提出澄清问题
• 已理解目标（而不仅是任务）
• 已找出未知事项
• 已统计交付项
• 已评估范围（微不足道/小/大/超大规模）
• 已在记忆中记录需求接收信息
• 已转交给适当的技能（并启用 project-board-enforcement）

技能： project-board-enforcement

门槛： 未确认项目看板就绪前，不得继续使用任何下游技能。