Opc Resource Audit

---
name: opc-resource-audit
description: Inventory all founder resources across 8 categories for a one-person company. Use when Codex needs to systematically confirm what resources the founder has — experience, network, skills, relationships, channels, assets, time/money constraints, hard limits — by first doing a broad scan of each category, then drilling into specifics (distribution, usable portions, how to use, cost of use), and producing a confirmed detailed resource inventory written to `opc-doc/`. Does NOT analyze directions, preferences, suitability, or risk tolerance — those belong to downstream skills.
---

# 资源盘点

## 目标

把创始人当前拥有的所有资源，按类别逐一确认并摸清细节，形成一份有内容、有厚度的资源清单。

**这一步唯一的产出是：资源清单。**

不分析方向，不判断适合什么，不评估偏好或风险承受力——那些是后续技能的工作。

## 核心原则

- 默认读写当前工作目录下的 `opc-doc/`
- 一次只问一个问题；如果几个问题都很轻且紧密相关，可以合并 2 到 3 个
- 每轮先给即时反馈，再进入下一问
- 用户确认后再写入正式结果
- **不做方向分析、不评价哪项资源更有潜力、不讨论偏好或风险——只摸资源**

## 本阶段边界

### 只做这些

- 按 8 个资源类别，逐一确认用户有哪些资源
- 对每一项已确认的资源，深挖具体情况（分布、可用方式、代价）
- 输出一份用户确认过的完整资源清单

### 不做这些（属于后续技能）

- ❌ 不判断"哪项资源最有价值"（属于 opc-niche-positioning）
- ❌ 不评估偏好或风险承受力（属于后续决策阶段）
- ❌ 不给业务建议或产品方向

**越界检测**：如果对话出现"你适合做""这个方向更好""你应该先做"等分析性话题，先记录，然后说：
> "这个判断很有价值，不过它属于后续阶段的工作。我们先把资源底数摸清楚，后面的分析才有依据。"

## 资源类别

共 8 类，详见 [references/resource-categories.md](references/resource-categories.md)：

1. **经验资源**：行业经验、职业经验、做过并跑通的事
2. **人群资源**：最懂哪类人、和谁长期打过交道
3. **能力资源**：专业能力、表达、审美、判断力、学习能力
4. **关系资源**：客户关系、合作伙伴、熟人信任网络
5. **渠道资源**：社交账号、社群、私域、分发入口
6. **资产资源**：案例、素材、模板、工具链、作品集
7. **约束资源**：时间限制、精力限制、现金流压力、家庭约束
8. **硬性边界**：绝对不能碰的事、必须叫停的情况（记录事实，不分析原因）

## 开场白规则

**用户的开场自我介绍不等于完成了资源盘点。**

无论开场白提供多少背景信息，都只是上下文，不能替代对各类别的正式确认。开场白通常只覆盖经验资源和部分能力资源，其余 6 个类别几乎一定是空白。

识别开场白中已有的信息，做一次简短确认，然后继续推进未覆盖的类别。

## 执行流程（两阶段）

---

### 第一阶段：粗扫——确认有哪些资源

**目标**：快速走完 8 个类别，确认每个类别里用户有什么。

**规则**：
- 每个类别用 1～2 个问题，得到基本答案后立即进入下一个
- 不停留，不深挖，不评价，只记录
- 遇到用户主动展开某一项，简短记下，礼貌拉回：「好，记下了，我们先把其他几块也过一遍。」

**推进顺序**（开场白未覆盖的优先）：

1. 渠道资源：有没有社交账号或私域？大概多少关注 / 好友？
2. 关系资源：现在能直接联系到的、最可能支持你的是哪类人？
3. 资产资源：手里有没有现成可用的——案例图、模板、素材、工具？
4. 约束资源：目前最硬的约束是什么——时间、现金流，还是其他？
5. 硬性边界：有没有绝对不能碰的事？（有就记，没有就跳过）
6. 人群资源：打过交道的人里，哪类人你最了解？
7. 能力资源：专业能力里有哪几项是你自己认为拿手的？
8. 经验资源：有没有哪段经历是别人很难复制的？

粗扫完成后，进入第二阶段。

---

### 第二阶段：深挖——把每项资源的细节摸清楚

**目标**：对第一阶段确认的每一项资源，逐一深挖具体情况。

**对每一项资源，需要摸清以下几个维度**（根据资源类型灵活选用）：

- **具体是什么**：规模、数量、质量、现状
- **分布在哪里**：领域、人群、平台、场合
- **哪些可以用**：现在可以直接动用的部分
- **怎么用**：以什么方式可以调动或转化
- **代价是什么**：用这个资源需要付出什么（时间、关系消耗、金钱、互惠等）

**示例**：

> 用户说有人脉资源 →
> - 这些人脉主要在哪些行业或圈层？
> - 其中和你关系最近、最可能帮你的是哪类人？
> - 如果你找他们帮忙，通常以什么方式——介绍客户、转发、背书，还是其他？
> - 动用这些关系，你觉得代价是什么？

不需要对每项资源都问完所有维度，根据对话中已有的信息灵活补充。关键是：每项资源结束时，有足够的细节可以写进清单。

深挖完成后，进入清单确认。

---

### 清单确认

把所有信息整理成完整资源清单，呈现给用户确认：

```
这是我目前整理的资源情况，请逐项看一下，有没有遗漏或需要修正？

---
资源清单 · 初稿

1. 经验资源
   - [从对话中提取的具体内容]

2. 人群资源
   - [从对话中提取的具体内容]

3. 能力资源
   - [从对话中提取的具体内容]

4. 关系资源
   - [规模 / 分布 / 可用方式 / 代价]

5. 渠道资源
   - [平台 / 规模 / 活跃度]

6. 资产资源
   - [具体内容及可用程度]

7. 约束资源
   - [时间、现金流、家庭等具体情况]

8. 硬性边界
   - [记录，不分析]
---

有没有哪个类别还有重要内容没提到？或者有哪条需要修正？
```

用户确认（或补充修正后确认）→ 落盘。

---

## 完成标准

- 8 个资源类别已全部覆盖
- 每项已确认的资源都有足够的细节（不只是一个标签，而是有内容的描述）
- 用户确认清单没有遗漏

**完成即止**：清单确认后，本技能任务结束。不要延伸到方向分析或建议。

## 落盘检查点（阶段必须完成，不可跳过）

用户确认清单后，**立即**使用 Write 工具创建以下文件：

**写入文件：**

- `opc-doc/outputs/01-resource-audit/inventory.md`（用户确认过的完整资源清单，8 个类别，包含细节）
- `opc-doc/outputs/01-resource-audit/scorecard.json`（结构化资源条目，供后续技能读取）

**更新状态文件：**

- `opc-doc/state/current-stage.json`（写入：`{"stage": "01-resource-audit", "status": "completed", "next_stage": "02-niche-positioning", "summary": "一句话描述最关键的资源特征"}`）

**落盘完成后，在对话中告知用户：**
> "✅ 资源清单已保存到 opc-doc/。下次对话可以从利基定位继续。"

## gbrain 同步（可选，默认关闭）

如果环境变量 `OPC_AUTO_SYNC=1`，落盘完成后**自动**调用：

```bash
OPC_TAG="$(basename "$PWD")" ~/.claude/scripts/opc-to-gbrain.sh "$OPC_TAG"
```

把本阶段产出同步到 gbrain，以后可跨项目用 `gbrain query "<项目代号> 资源清单"` 检索回忆。
未设置 `OPC_AUTO_SYNC` 时**不要**自动调，不要询问——用户可手动跑同样命令同步。

**只有落盘完成后，才可以提示进入 `opc-niche-positioning`。**

## 何时调用其他技能

只有落盘完成后，才提示进入 `opc-niche-positioning`。

## 输入

优先读取：

- `opc-doc/inputs/founder-profile.md`
- `opc-doc/inputs/raw-ideas.md`

如果 `opc-doc/` 不存在，直接基于对话开始，落盘时按需创建目录。

## 异常处理

- 如果用户某个类别完全没有资源，如实记录"暂无"，继续推进，不停留
- 如果用户回答过于宽泛，追问一个具体问题，而不是连续追问一串
- 如果用户在第 9 轮后明确要求延长，可以继续，但说明这是应用户要求延长