Back to Details

work-intake

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Work Intake

工作请求受理（Work Intake）

Overview

概述

Every work request flows through intake. This skill determines scope, gathers requirements, and routes to the appropriate workflow.
Core principle: No work is too small to track, no work is too large to decompose.
Announce at start: "I'm using work-intake to understand and scope this request before beginning."
所有工作请求都需经过受理流程。此Skill负责确定任务范围、收集需求，并将请求路由至合适的工作流。
核心原则： 再小的工作也需要追踪，再大的工作也可以拆解。
开始时需告知： "我正在使用work-intake技能在开始前理解并确定此请求的范围。"

The Intake Flow

受理流程

┌─────────────────────────────────────────────────────────────────────┐
│                        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
┌─────────────────────────────────────────────────────────────────────┐
│                        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

Step 0: Project Board Readiness (GATE)

步骤0：项目看板就绪检查（关卡）

Before any work intake, verify project board infrastructure is ready.
This is a gate. Do not proceed to clarifying questions until this passes.
bash
undefined
在受理任何工作请求前，请先验证项目看板基础设施是否就绪。
这是一个关卡，未通过此检查前不得进入澄清问题环节。
bash
undefined

Derive defaults from GITHUB_PROJECT if provided

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
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

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
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

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
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

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"

**If gate fails:**
1. Configure missing environment variables
2. Create project board if needed
3. Add required fields (Status, Type, Priority)
4. Re-run readiness check

**Skill:** `project-board-enforcement`

---
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. 重新运行就绪检查

**关联Skill：** `project-board-enforcement`

---

Step 1: Clarifying Questions

步骤1：澄清问题

Before scoping, understand the request.
Do not ask questions that can be answered from the repo. First inspect:
  • README.md
    , 
    FEATURES.md
    , 
    BRANDING.md
    , 
    docs/
    , Storybook, and existing routes/pages
  • Existing GitHub issues and project board items
Only ask the user for information that is still missing after reviewing the repo.
在确定范围前，请先理解请求内容。
不要询问可从仓库中找到答案的问题。 请先检查以下内容：
  • README.md
    、
    FEATURES.md
    、
    BRANDING.md
    、
    docs/
    目录、Storybook，以及现有路由/页面
  • 现有GitHub issues和项目看板条目
仅当查看仓库后仍有信息缺失时，再向用户询问。

Essential Questions

核心问题

QuestionPurpose
"What are you trying to achieve?"Understand the goal, not just the task
"What does success look like?"Define acceptance criteria
"Who/what is affected?"Identify scope of impact
"Are there constraints I should know about?"Time, tech, compatibility
"Is this part of something larger?"Link to existing initiatives
问题目的
"你想要实现什么目标？"理解核心目标，而非仅任务本身
"成功的标准是什么？"定义验收条件
"会影响到谁/什么？"确定影响范围
"是否存在我需要了解的约束条件？"时间、技术、兼容性等约束
"这是否是某个更大项目的一部分？"关联到现有计划

Discovery Questions (for unclear requests)

探索性问题（针对模糊的请求）

QuestionReveals
"Can you walk me through how this would be used?"User journey, edge cases
"What exists today?"Starting point, migration needs
"What have you already tried?"Failed approaches, constraints
"Is there prior art or examples?"Design direction
问题可揭示的信息
"你能演示一下这个功能的使用流程吗？"用户旅程、边缘情况
"当前已有哪些相关功能？"起点、迁移需求
"你已经尝试过哪些方法？"失败的方案、约束条件
"是否有参考案例或示例？"设计方向

Step 2: Scope Assessment

步骤2：范围评估

Evaluate the request against these criteria:
根据以下标准评估请求：

Scope Matrix

范围矩阵

FactorTrivialSmallLargeMassive
UnknownsNoneFew, answerableMany, need researchExtensive, need spikes
Deliverables1 thing2-5 things6-20 things20+ things
Code areas1-2 files3-10 files10+ filesMultiple systems
DependenciesNoneInternal onlyExternal servicesNew infrastructure
Duration< 1 session1-3 sessions1-2 weeksWeeks to months
Criteria1-23-56-1515+
评估因素微小（Trivial）小型（Small）大型（Large）庞大（Massive）
未知项无少量，可解答较多，需要调研大量，需要研究 spike
交付物1项2-5项6-20项20+项
代码涉及范围1-2个文件3-10个文件10+个文件多个系统
依赖项无仅内部依赖外部服务新基础设施
持续时间< 1个工作时段1-3个工作时段1-2周数周至数月
验收条件1-2条3-5条6-15条15+条

Scope Decision

范围判定规则

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
如果 未知项 == 无 且 交付物 <= 2:
  → 微小范围：直接使用`issue-prerequisite`

如果 未知项 == 少量 且 交付物 <=5:
  → 小型范围：使用`issue-prerequisite`，必要时使用`issue-decomposition`

如果 未知项 == 较多 或 交付物 >5:
  → 大型范围：使用`epic-management`并创建研究spike

如果 未知项 == 大量 或 交付物 >20 或 需要新基础设施:
  → 庞大范围：使用`initiative-architecture`

Step 3: Route to Appropriate Workflow

步骤3：路由至合适的工作流

Trivial Scope

微小范围

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

**Next step:** Creating a single issue using `issue-prerequisite`.
Route to: 
issue-prerequisite
markdown
**评估结果：** 这是一个微小请求（单一交付物，无未知项）。

**下一步：** 使用`issue-prerequisite`创建单个issue。
路由至：
issue-prerequisite

Small Scope

小型范围

markdown
**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`.
Route to: 
issue-prerequisite
→ maybe 
issue-decomposition
markdown
**评估结果：** 这是一个小型请求（少量交付物，极少未知项）。

**计划：**
1. 为该请求创建父issue
2. 若需要，拆解为2-3个子issue
3. 开始实施

**下一步：** 使用`issue-prerequisite`创建issue结构。
路由至：
issue-prerequisite
→ 必要时使用
issue-decomposition

Large Scope

大型范围

markdown
**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`.
Route to: 
epic-management
(which will create research spikes as needed)
markdown
**评估结果：** 这是一个需要结构化规划的大型请求。

**已识别的未知项：**
- [ ] 未知项1 - 需要调研
- [ ] 未知项2 - 需要研究spike

**高层级交付物：**
1. 交付物A
2. 交付物B
...

**下一步：** 使用`epic-management`创建史诗（epic）结构。
路由至：
epic-management
（将根据需要创建研究spike）

Massive Scope

庞大范围

markdown
**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`.
Route to: 
initiative-architecture
markdown
**评估结果：** 这是一个需要完整计划架构的庞大请求。

**判定为庞大的原因：**
- [原因：大量未知项 / 新基础设施 / 多系统 等]

**初始未知项：**
- [ ] X是否存在？
- [ ] Y的工作原理是什么？
- [ ] Z的约束条件有哪些？

**潜在范围：**
- 可能包含多个epic
- 需要新功能
- 需要大量调研

**下一步：** 使用`initiative-architecture`启动计划架构设计。
路由至：
initiative-architecture

Resumability Checkpoint

可恢复性检查点

Before routing, document the intake in memory:
bash
undefined
在路由前，请将受理信息存储至内存：
bash
undefined

Store intake assessment

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]" ] }])
undefined
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]" ] }])
undefined

Examples

示例

Example: Trivial

示例：微小范围

Request: "Make the login page button a little lighter."
Intake:
  • Goal: Adjust button color
  • Success: Button is lighter
  • Unknowns: None (CSS change)
  • Deliverables: 1 (color change)
  • Scope: TRIVIAL
→ Route to 
issue-prerequisite
请求： "把登录页面的按钮调浅一点。"
受理结果：
  • 目标：调整按钮颜色
  • 成功标准：按钮颜色变浅
  • 未知项：无（仅需修改CSS）
  • 交付物：1项（颜色修改）
  • 范围：TRIVIAL
→ 路由至
issue-prerequisite

Example: Large

示例：大型范围

Request: "Add dark mode to the application."
Intake:
  • Goal: Theme switching capability
  • Success: Users can toggle dark/light mode
  • Unknowns:
    • Current theming approach?
    • Component library support?
    • Persistence mechanism?
  • Deliverables: ~10 (theme tokens, components, toggle, persistence, etc.)
  • Scope: LARGE
→ Route to 
epic-management
请求： "为应用添加深色模式。"
受理结果：
  • 目标：实现主题切换功能
  • 成功标准：用户可切换深色/浅色模式
  • 未知项：
    • 当前的主题实现方案？
    • 组件库是否支持？
    • 状态持久化机制？
  • 交付物：约10项（主题令牌、组件适配、切换按钮、持久化等）
  • 范围：LARGE
→ 路由至
epic-management

Example: Massive

示例：庞大范围

Request: "Add the ability for users to log in by clicking on a popup in their phone."
Intake:
  • Goal: Mobile push notification login
  • Success: User receives push, taps, logged in
  • Unknowns:
    • Is there a mobile app? → Research spike
    • Push notification infrastructure? → Research spike
    • Authentication flow design? → Research spike
    • Security requirements? → Research spike
  • Deliverables: 30+ (app work, backend, auth, notifications, etc.)
  • Scope: MASSIVE
→ Route to 
initiative-architecture
请求： "添加用户点击手机弹窗即可登录的功能。"
受理结果：
  • 目标：实现移动端推送通知登录
  • 成功标准：用户收到推送，点击后完成登录
  • 未知项：
    • 是否有移动端应用？→ 需要研究spike
    • 推送通知基础设施？→ 需要研究spike
    • 认证流程设计？→ 需要研究spike
    • 安全要求？→ 需要研究spike
  • 交付物：30+项（应用开发、后端适配、认证、通知等）
  • 范围：MASSIVE
→ 路由至
initiative-architecture

Red Flags That Indicate Larger Scope

需警惕的大范围任务信号

Watch for these phrases that suggest the request is larger than it appears:
PhraseLikely Scope
"Just add..." + new capabilityLarge (new capability = infrastructure)
"Users should be able to..."Large (user-facing = full stack)
"Integrate with..."Large (external = API, auth, error handling)
"Like [other product]..."Massive (feature parity = extensive)
"Mobile/app/notification"Massive (unless app exists)
"Real-time/sync/live"Large (infrastructure)
请注意以下表述，它们通常意味着请求的实际范围比表面更大：
表述可能的范围
"只需添加..." + 新功能大型（新功能需要基础设施支持）
"用户应该能够..."大型（面向用户的功能需要全栈实现）
"与...集成"大型（外部集成需要API、认证、错误处理等）
"像[其他产品]一样..."庞大（功能对齐需要大量工作）
"移动端/应用/通知"庞大（除非已有应用）
"实时/同步/在线"大型（需要基础设施支持）

Never Turn Away Work

绝不拒绝任何工作

No matter how massive the request:
  1. Acknowledge the goal - "I understand you want X"
  2. Explain the process - "This will require structured planning"
  3. Begin investigation - Start with what we don't know
  4. Document everything - Every decision, every finding
  5. Break it down - Until we have tractable pieces
The path from "massive request" to "implementation" is:
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)
无论请求多么庞大：
  1. 确认目标 - "我理解你想要实现X"
  2. 解释流程 - "这需要结构化的规划"
  3. 启动调研 - 从我们未知的内容开始
  4. 记录所有内容 - 每一个决策、每一个发现
  5. 拆解任务 - 直到我们得到可处理的小任务
从“庞大请求”到“实施”的路径如下：
庞大请求
    → 计划架构设计（记录未知项，创建研究spike）
    → 研究spike（解答未知项）
    → Epic结构设计（分组交付物）
    → Issue拆解（创建可处理的任务）
    → 实施（逐个处理issue）

Checklist

检查清单

  • Project board readiness verified (Step 0 gate passed)
  • GITHUB_PROJECT_NUM and GH_PROJECT_OWNER set
  • Asked clarifying questions
  • Understood the goal (not just the task)
  • Identified unknowns
  • Counted deliverables
  • Assessed scope (Trivial/Small/Large/Massive)
  • Documented intake in memory
  • Routed to appropriate skill (with project-board-enforcement)
Skill: 
project-board-enforcement
Gate: Cannot proceed to any downstream skill without project board readiness verified.
  • 已验证项目看板就绪（步骤0关卡已通过）
  • 已设置GITHUB_PROJECT_NUM和GH_PROJECT_OWNER
  • 已提出澄清问题
  • 已理解核心目标（而非仅任务本身）
  • 已识别未知项
  • 已统计交付物数量
  • 已评估范围（Trivial/Small/Large/Massive）
  • 已将受理信息存储至内存
  • 已将请求路由至合适的Skill（已启用project-board-enforcement）
关联Skill： 
project-board-enforcement
关卡： 未通过项目看板就绪检查，不得进入任何下游Skill。