Founder pitch — pixel.fund

Founder: Maya Chen (CEO, ex-Stripe), co-founder Aria Patel (CTO, ex-Robinhood). YC W26.

What

A donation-budget tool for solo creators. Set a monthly $ floor for causes you care about, pixel.fund auto-allocates each dollar across your chosen orgs (Direct Relief, GiveDirectly, etc.) the moment a Stripe payout lands. One-line embeddable receipt. 1% platform fee.

Traction

• 2026-04-01 launched private beta with 14 creators from her newsletter
• 2026-05-15 hit 51 paying creators, $4,200 MRR
• Waitlist of 230 from a single tweet by a tech-Twitter influencer
• Two creators asked about a "team plan" (multi-seat) unprompted

Status quo

Creators today either (a) write checks ad-hoc and forget about it, or (b) use Patreon-style platforms where the "cause" is opaque (general fund). Maya talked to 40 creators in YC interviews — 31 said they "want to give more but it's mental overhead."

What Maya wants from office hours

Should she chase the team-plan signal, or go deeper on the solo flow first? She's two weeks from running out of YC dorm food.

把这份 pitch 与 `/office-hours` 的 [Startup Mode 诊断流程](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L1056-L1216)对照看，会发现每个字段都精确落在技能的某个"提问点"上：

| brief.md 字段 | 承载的信息 | 在 `/office-hours` 管线中的落点 |
|---|---|---|
| `Founder` 头部 | 人名（Maya Chen / Aria Patel）、背景（ex-Stripe / ex-Robinhood）、批次（YC W26） | Phase 2.5/回写阶段的 **entity stub 实体抽取**原料（person / organization） |
| `What` | 产品定义：donation-budget tool、Stripe payout 自动分配、1% platform fee | **Problem Statement** 与商业模式约束（fee 结构是可被 Premise Challenge 追问的硬信息） |
| `Traction` | 四个可量化事件：14 人 beta、51 付费、$4,200 MRR、230 waitlist、2 个 team-plan 询问 | **Q1 Demand Reality** 的需求证据 + Phase 1 的 **产品阶段评估**（has paying customers） |
| `Status quo` | (a) ad-hoc 写支票 (b) Patreon 式不透明 general fund；40 人访谈、31 人"想要更多但心理负担重" | **Q2 Status Quo** 的直接答案——正是技能要求听到的"用户今天真实的工作流及其代价" |
| `What Maya wants from office hours` | 决策困境 + 紧迫性（两周转尽 dorm food） | 触发 Phase 4 的 **alternatives 决策与 APPROVAL gate**，也是"assignment（下一步动作）"的锚点 |

值得注意的是 Traction 部分的措辞**刻意区分了"兴趣"与"需求"**。这正好踩中 [SKILL.md 的 Operating Principles](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L1060-L1075)：`Interest is not demand. Waitlists, signups, "that's interesting" — none of it counts.` 在这份 pitch 里，51 个付费创作者与 $4,200 MRR 属于"行为/金钱证据"（Q1 会采信），而 230 人 waitlist 只算兴趣信号——技能在 Q1 的红旗清单里明确点名了 `"We got 500 waitlist signups."` 这类说法。E2E 测试的 prompt 也照此把最强证据固定为"230 from a single tweet + 51 paying creators in 6 weeks"（见 [测试 prompt](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/test/skill-e2e-office-hours-brain-writeback.test.ts?utm_source=gitcode_repo_files#L211-L220)）。

同时 `Status quo` 字段与技能"status quo is your real competitor"原则呼应——它给出的不是一个真空市场，而是"支票+通用基金"两套真实工作流，恰好是可被继续深挖的现状材料。

## `/office-hours` 如何消费这份 pitch：从模式选择到诊断管线

### 1. 模式路由：为何是 Startup Mode

[Phase 1 Context Gathering](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L962-L1041) 会先通过 AskUserQuestion 询问用户目标。pixel.fund 明确是"正在融资/规模化的创业项目"，因此路由到 **Startup Mode（Phase 2A）**；而测试 prompt 直接要求"Select Startup Mode. Skip any AskUserQuestion"并用 auto-decide 替代人工回答，保证确定性执行。E2E 同时假设创始人已确认 Q1、Q2、Q3 与那个"team-plan vs solo flow"的 forcing question 答案，把可变因素锁死，让测试只聚焦于"回写是否发生"这一个结论。

### 2. 六道追问与"按产品阶段智能路由"

[Phase 2A 的六道 Forcing Questions](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L1126-L1216) 是 Startup Mode 的核心。技能要求"ONE AT A TIME"逐题提问，每道题都要追问到"specific、evidence-based、uncomfortable"为止：

- **Q1 Demand Reality**：最强需求证据是什么？（不是"感兴趣"，而是"明天消失会抓狂"）
- **Q2 Status Quo**：用户现在如何凑合解决？代价几何？
- **Q3 Desperate Specificity**：点名那个最需要它的具体的人，说出头衔、晋升/被开/失眠场景
- **Q4 Narrowest Wedge**：这周就有人愿意付钱的最小版本是什么？
- **Q5 Observation & Surprise**：有没有不插手、坐背后看人用的真实观察与意外？
- **Q6 Future-Fit**：三年后世界变化让产品更必需还是更不必需？

并且技能根据产品阶段给出了 **smart-routing 表**（见 [SKILL.md](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L1130-L1136)）：

| 产品阶段 | 应问的问题 |
|---|---|
| Pre-product（无用户） | Q1、Q2、Q3 |
| Has users（有用户未付费） | Q2、Q4、Q5 |
| **Has paying customers（有付费）** | **Q4、Q5、Q6** |
| 纯工程/基础设施 | Q2、Q4 |

按 Traction 部分披露的"51 paying creators"，pixel.fund 属于"有付费用户"档，理论上走 Q4/Q5/Q6（楔子、观察、未来契合），而"两轮 YC 宿舍饭"的紧迫感则会逼出创始人真实的 Q3 答案。若用户中途不耐烦，技能提供 escape hatch：最多再问两道最关键的题就进入下一阶段，只有用户给出"含真实用户、收入数字、具体客户名"的完整计划才允许整体跳题（[Escape hatch](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L1211-L1216)）。

### 3. 追问之后的强制步骤：Premise Challenge 与 Alternatives

光提问不够。Startup Mode 在给出方案前还有三道闸门：

- **[Phase 3 Premise Challenge](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L1323-L1341)**：把"这是正确的问题吗？""什么都不做会怎样？"等前提以 `PREMISES:` 列表呈现，要求用户逐条同意；
- **[Phase 3.5 跨模型第二意见](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L1345-L1445)**：可选地把上下文摘要交给 Codex 冷读或 Claude subagent，输出 steelman、被挑战的前提与 48 小时原型建议；
- **[Phase 4 Alternatives Generation（强制）](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L1449-L1481)**：无论结论多明显，都必须产出至少两个、最好三个差异化方案（minimal viable / ideal architecture / creative-lateral），逐一标注 Effort、Risk、Pros/Cons、Reuses，然后 `RECOMMENDATION: Choose [X] because ...`。

对 pixel.fund 而言，`What Maya wants` 里"追 team-plan 信号，还是先把 solo 流程做深"恰恰就是 Phase 4 要裁决的 alternatives。而且技能在 [Phase 4 末尾设有 STOP gate](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L1481)：**即便一个方案"明显更优"，也必须等用户显式批复后才允许写入设计文档**——把"推荐写进正文"而绕过用户确认是此门要防住的失败模式。这让 office hours 的产出始终是"决策记录"而非"AI 自言自语"。

## 设计文档如何生成：双写与 Startup 模板

在 Phase 4 获批复后，技能进入 [Phase 5 Design Doc + Phase 6 Handoff](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/sections/design-and-handoff.md?utm_source=gitcode_repo_files)。这一步通过 [SKILL.md 的 Section index](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L1046-L1054) 指向的 carve 分节实现按需加载，核心行为有两点：

**双写落盘。** 设计文档先写入私有状态目录 `~/.gstack/projects/{slug}/{user}-{branch}-design-{datetime}.md`（供 memory ingest 与跨会话发现），若当前在 git 仓库内还**同时**写入 `docs/designs/{topic-slug}.md` 供团队查看与提交。Repo 副本离开私有存储前必须先过 `gstack-redact` 扫描：exit 3（HIGH）阻断 repo 副本仅保留 `~/.gstack` 副本并说明原因；exit 2（MEDIUM）逐条确认后才写。read-only checkout 或非 git 目录等回退场景一律非阻塞，handoff 照常继续。若同一分支已有历史设计文档，还会通过 `Supersedes:` 字段形成可回溯的修订链。

**Startup Mode 文档模板。** [design-and-handoff.md 中的 Startup 模板](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/sections/design-and-handoff.md?utm_source=gitcode_repo_files#L51-L110)把整个对话压缩成一份决策记录，包含 Problem Statement、Demand Evidence、Status Quo、Target User & Narrowest Wedge、Constraints、Premises、Cross-Model Perspective、Approaches Considered（A/B）、Recommended Approach、Open Questions、Success Criteria、Distribution Plan、Dependencies、The Assignment、以及 "What I noticed about how you think"。模板明确要求：Approaches 中被否掉的方案只写一行（名字+拒绝理由），绝不复活成完整章节重新辩论。把 pixel.fund 的 brief 填入后即可得到 `# Design: pixel.fund` 的草稿。随后还要经过 **Spec Review Loop**（dispatch 独立 reviewer 子代理按 Completeness/Consistency/Clarity/Scope/Feasibility 五维打分、最多 3 轮修正、convergence guard 后把遗留问题写入 Reviewer Concerns），再以 AskUserQuestion 请用户 A) Approve / B) Revise / C) Start over。

文档获批后进入 **Phase 6 关系收尾**，依据 builder profile 中的 `SESSION_TIER` 走 introduction / welcome_back / regular / inner_circle 四条分层路径，并可按创始人信号数（[Phase 4.5 信号综合](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/office-hours/SKILL.md?utm_source=gitcode_repo_files#L1652-L1692)：命名具体用户、反驳前提、领域专长、品味、agency 等）选择对应的 Garry 式结语档位与 Founder Resources。pixel.fund 的 Traction 里"两名创作者主动问团队版"这种 unprompted 信号，恰好是信号综合里典型的"taste / real need"证据形态。

## Brain write-back：结论如何沉淀为 gbrain 页面

### 渲染条件：探测驱动的动态块

脑回写并非无条件存在。规划类技能里"Save Results to Brain"这类压缩块**只在 gbrain 被探测到时才渲染**。根据 [docs/gbrain-write-surfaces.md](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/docs/gbrain-write-surfaces.md?utm_source=gitcode_repo_files#L12-L24) 的渲染矩阵：

- 任意 host + `gbrain_local_status: ok` → 渲染 brain-aware 块，Agent 真正执行保存时才按需读本文档，每个规划技能仅约 250 token 开销；
- gbrain 未被探测到 → 生成期即抑制该块，**零 token 开销**（校准 takes 走独立 resolver）；
- GBrain/Hermes 等 host → 无论探测结果如何始终渲染。

同时 `.gbrain-source` 只钉住**读**的指向，写入始终走 `~/.gbrain/config.json` 配置的默认引擎；trust policy（`personal` vs `shared`，按 endpoint-hash）控制自动推送与回写，PGLite 本地安装自动默认 `personal`。

### SAVE_RESULTS 模板与 slug/title/tag 规范

当回写被激活，Agent 按 [§Save Template](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/docs/gbrain-write-surfaces.md?utm_source=gitcode_repo_files#L53-L141) 执行保存。完整 CLI 形态如下：

```bash
gbrain put "<slug-prefix>/<feature-slug>" --content "$(cat <<'EOF'
---
title: "<Title>: <feature name>"
tags: [<tag>, <feature-slug>]
---
<skill output in markdown — the actual deliverable, not a summary>
EOF
)"

配套三条元数据规范：

• slug：kebab-case 小写、在 prefix 内唯一，宁可用具体产品名如 auth-rate-limit，不用抽象标签如 security-fix。对 office-hours 场景，prefix 由技能级 resolver 提供为 office-hours/，feature-slug 由执行者代入——在 pixel.fund 场景中即 pixel-fund，最终期望落到 office-hours/pixel-fund；
• title：固定前缀（如 "CEO Plan"、"Eng Review"）是常量，后缀用该功能/主题的人类可读名；
• tags：第一个 tag 是技能元数据里的常量 tag，第二个是 <feature-slug> 以支持跨页遍历，有显而易见的关联可追加（如 [ceo-plan, auth-rate-limit, security]）。

Entity-stub 与 backlink、错误处理

主页面写完后，Agent 还会对输出中提到的真实人名与组织名做实体富化（entity-stub enrichment）：先 gbrain search "<entity name>" 查重，无结果则 gbrain put "entities/<entity-slug>" 写入占位 stub，people 用 tags: [entity, person]，companies/teams 用 tags: [entity, organization]。产品名、功能名、技术术语与文件路径一律跳过，规则是"when in doubt, skip"。在 pixel.fund fixture 上，这意味着 Maya Chen、Aria Patel（person）与 Direct Relief、GiveDirectly 等组织（organization）都是该阶段的抽取对象。

若输出提到其他 brain 页面，则在正文底部追加 Related: [[other-page-slug]] backlink，由 gbrain 把 [[slug]] 语法渲染为可点击链接。错误处理上：stderr 含 throttle/rate limit/capacity/busy 视为节流，推迟保存不重试；其他非零退出视为瞬时失败；gbrain: command not found 则说明探测器失效，静默跳过。技能收尾时用一行汇报大脑使用情况，例如 "Brain: read 3 pages, saved 1 page, enriched 2 entity stubs, 0 throttles."，让用户看到覆盖度在随时间增长。

E2E 测试如何证明"回写真的发生了"

回到 test/skill-e2e-office-hours-brain-writeback.test.ts。它的任务不是验证 gbrain 自身（那是 test/skill-e2e-gbrain-roundtrip-local.test.ts 用真实 gbrain init --pglite + put + get 做的事），而是证明 agent 在 gbrain 可用时真的会去调用它。测试头部注释给出三个明确的范围外事项：gbrain 是否真正持久化、.gbrain-source 是否重路由写入、source-targeting——这些都属于 gbrain 的契约。

fake gbrain 脚本是关键夹具。它以 printf %q 逐参转义把每次调用追加到 gbrain-calls.log，并对 put 的 --content 值按 slug 落盘到 gbrain-payloads/，从而同时捕获"调用形态"与"payload 内容"两个维度。核心断言链（L244-L297）：

1. 必须真的调用了：gbrain-calls.log 存在且包含 gbrain put，并匹配 gbrain put .*pixel-fund；
2. payload 必须是合法 frontmatter：找到路径含 pixel-fund 的 .md，断言以 ^--- 开头、包含 title: 与 tags:、正文长度超过 200 字符——真正有内容的交付物而非空壳；
3. 实体 stub 为 best-effort：gbrain put entit(?:y|ies)/ 出现次数被扫描，0 次仅告警不失败（接受 entities/ 与 entity/ 两种形态）。

测试还从提示层面预防了两类 AI 常见失误：明令"Do NOT explore gbrain --help; follow the SAVE_RESULTS template's exact CLI shape"，并提示运行时守卫（"gbrain not on PATH 则跳过"）在此不适用，因为 fake gbrain 确实在 PATH 上。整个场景以 claude-sonnet-4-6 驱动、上限 12 轮、超时 360 秒，归类为 periodic tier（单次约 $0.5–1 成本），maxTurns 与超时均可在 describeIfSelected 的选区机制下按需单独触发。

若想脱离自动化、在自己真实 brain 上手动核验一次规划技能跑完后页面确实落位，docs/gbrain-write-surfaces.md 提供了四连探针：

gbrain get "<prefix>/<slug>"           # 期望得到 markdown + frontmatter
gbrain search "<slug fragment>"        # 期望 slug 出现在前排结果
gbrain sources list                    # 确认 gstack-brain-<user> source
gbrain get "entities/<person>"         # 期望看到每个具名人物的 stub