Indie

给独立开发者的一套完整 Agent Skills：从机会判断和项目战略，到设计、规划、开发、修复、独立验收与发布学习。

Indie 把产品交付压缩为 9 个职责明确、可单独调用的工作流。它不是强制跑完的瀑布流程，也不会用自然语言猜测代替确定性命令：在 OMP/Pi 中输入 /indie: 即可通过自动补全选择下一步。

快速开始

omp install npm:@0xfig/indie

重启 OMP 后运行：

/indie:menu

九个工作流都会注册为 OMP 原生 namespaced slash command，可被自动补全并直接输入：

/indie:think 我想做一个帮助自由职业者追踪回款的产品

每个工作流都以统一的 Current / Done / Next / Blocked by 结束；适用时 Next 给出可复制的 /indie:* 命令。只建议，不自动执行下一阶段或外部动作。

九个工作流

命令	何时使用	主要产出	常见下一步
/indie:think	新想法、用户问题、机会、竞品、PM 范围	必要时先做一轮最多 5 问的对齐，再给推荐方向、MVP、非目标、验证策略和稳定 AC-*	UI 产品进入 design；否则进入 plan
/indie:strategy	已有项目的发展方向、定位、增长、商业化、维护或止损	先确认用户掌握的关键业务信息，再诊断阶段与主约束，选择一个有指标和停止条件的战略下注	新机会进入 think；交付进入 design/plan；发布进入 launch
/indie:design	前端、UX、响应式、无障碍、页面/组件状态	Hallmark 驱动的体验与视觉合同、状态矩阵、必要原型	/indie:plan
/indie:plan	架构、数据/API 契约、迁移、技术风险、多人并行	技术合同、纵向切片、验证、回滚、Agent 边界	/indie:build
/indie:mission	长时自主运行或跨 Agent 交接	2,000 字符内的宿主适配 Goal 条件	可选，不属于必经流程
/indie:build	已批准计划或边界明确的小功能	最小实现、测试、自验证、文档状态更新	/indie:proof
/indie:fix	Bug、回归、难复现问题、性能退化、热修	复现、根因、最小修复、回归证据	按风险进入 /indie:proof
/indie:proof	独立验收、安全/性能/证据审计、发布前检查	Spec/Standards 双轴结论、阻塞项、证据	修复或发布
/indie:launch	通过 Proof 后的上线、分发、指标、反馈与学习	最小 launch plan、观测窗口、Keep/Pivot/Kill 决策	明确授权后执行或继续学习

/indie:menu <任务> 会先让你选择工作流，再直接提交带任务的命令；不带参数时只把命令填入编辑器，方便继续补充。

确认机制

九个工作流使用同一套 Alignment gate，先把缺失信息分成三类：

• **Discoverable：**仓库、文档、代码、测试、运行结果和当前官方资料中可以查到的事实，由 Agent 自己调查，不反问用户；
• **Safe default：**不改变用户价值、范围、合同、数据/安全边界、成本、验收或授权的可逆细节，声明后继续；
• **User-owned：**只有用户能决定，且会改变方向、行为、风险、预算、维护承诺或完成标准的选择，集中询问后再继续。

问题按需一次提出，最多 5 个，不为了凑数采访。用户明确委托推荐默认值时可以继续，但默认值永远不代表 commit、push、publish、deploy、生产修改、花费、外联或删除授权。

各阶段停止点不同：Think 不提前冻结 AC-*；Strategy 不提前选择下注；Design 不提前冻结体验合同；Plan 不提前冻结架构；Mission 不提前输出 Goal；Build/Fix 不提前改代码；Proof 不提前作发布结论；Launch 不提前标记上线就绪或执行外部动作。

推荐路径

新的前端产品或页面

/indie:think → /indie:design → /indie:plan → /indie:build → /indie:proof → /indie:launch

已有项目选择下一阶段方向

/indie:strategy → /indie:think 或 /indie:plan、/indie:fix、/indie:launch

Strategy 会检查用户需求、激活/留存、竞品与替代品、定位、分发、商业化、技术风险和独立维护成本，但最终只选择一个主约束和一个有界下注；缺少会改变选择的用户意图、业务数据、预算或维护承诺时先集中确认，不自行补全。

Think 可以评估已有产品中的一个具体机会或功能；涉及整个项目的定位、优先级、增长、商业化、维护或止损时使用 Strategy。Strategy 选定的新机会仍需经过 Think 转成产品定义和 AC-*，不会直接跳到开发。

纯后端或非视觉功能

/indie:think → /indie:plan → /indie:build → /indie:proof → /indie:launch

从个人 Starter 创建新项目

在预期的新项目根目录运行正常流程，不需要记忆新的命令或参数：

/indie:plan 做一个接收 webhook 和定时任务的 API
/indie:build

Plan 仅在没有现有项目实现时读取 0xfig-labs/starter 的当前目录并选择模板；通用全栈 Web 产品优先 starter-nuxt，无 UI 的 API/webhook/定时 Worker 使用 starter-hono-worker。Build 不会重新猜测，而是自动执行 Plan 中已批准的 Bootstrap 决策：先拉到临时目录、检查来源与冲突，再保留 .indie/ 和所有用户文件完成初始化并运行模板基线。已有项目、未批准选择、未发布模板或任何路径冲突都会停止，不会覆盖或退化为从零搭建。

边界明确的小功能

/indie:build → /indie:proof

涉及认证、支付、隐私、破坏性数据、迁移、共享 API/Schema 或跨模块边界时，即使改动很小，也会先路由到 /indie:plan。

Bug 与性能问题

/indie:fix → /indie:proof

Fix 会先建立反馈回路和可证伪假设；连续三个假设失败后停止盲改，输出证据交接。

跨 Agent 交接

/indie:mission

Mission 默认生成五段式精简 Goal（Objective / Success criteria / Verification / Boundaries / Stop conditions），引用已有文档而不复制计划；可用 --host=codex|claude|omp|generic 指定宿主。它不写代码、不自动创建宿主 Goal，也不会继承旧会话中的 push/deploy 授权。

Design 与 Hallmark

/indie:design 使用 Hallmark 作为视觉设计引擎：

• Indie 管理阶段边界、UX 合同、活文档和下一步；
• Hallmark 管理前端预检、结构、视觉系统、交互状态、响应式、无障碍和 anti-slop 设计规则；
• 不复制 Hallmark 提示词，也不在 Hallmark 缺失时凭记忆模仿。

OMP/Pi 可按以下方式安装 Hallmark（已验证）：

npx skills add nutlope/hallmark -a pi -g -y --copy

重启宿主后再运行 /indie:design。若未安装，Design 会完成有证据支持的非视觉 UX 部分，并明确将视觉设计标记为阻塞，不会静默退化为通用 AI 风格。

分层活文档

Indie 优先复用项目已有的产品、战略、设计、技术计划和状态文档。项目没有约定时按职责创建，只创建当前范围需要的文件：

.indie/
├── PRODUCT.md   # Think：用户问题、机会、范围、唯一 AC 定义
├── STRATEGY.md  # Strategy：已有项目的方向、当前下注、指标和停止条件
├── DESIGN.md    # Design：仅 UI/UX 项目需要
├── PLAN.md      # Plan：技术契约、依赖、风险、纵向切片
├── STATUS.md    # Build/Fix/Proof：当前状态、证据指针、阻塞
└── LAUNCH.md    # Launch：仅进入发布/学习阶段需要

规则：

• 每类事实只定义一次：其他文档引用路径和 AC-*，不复制全文；
• PRODUCT.md 定义用户、产品承诺、范围和唯一 AC-*；STRATEGY.md 只解释已有项目为什么选择当前方向与下注；
• DESIGN.md、PLAN.md、STATUS.md、LAUNCH.md 分别保存体验合同、技术合同、当前证据和发布学习，不反向复制产品或战略内容；
• 原地更新并删除过时计划、已解决 Unknown 和 blocker，不创建 v2、日期副本或阶段报告；
• 小 Bug 或边界明确的小功能可以只用内联成功契约，不强制建立文档集；
• 原始研究、聊天记录、普通命令日志、临时进度和秘密不进入长期文档；
• 已有 .indie/PROJECT.md 继续作为旧项目事实源，直到一次授权迁移能拆分并删除重叠内容，禁止双轨维护。

安装方式

1. OMP/Pi：npm 安装（推荐）

omp install npm:@0xfig/indie

更新与卸载：

omp plugin uninstall @0xfig/indie
omp install npm:@0xfig/indie@latest

2. OMP Marketplace：从 GitHub 安装

omp plugin marketplace add 0xfig-labs/indie
omp plugin install --scope user indie@indie

本地开发仓库：

omp plugin marketplace add "$PWD"
omp plugin install --scope user indie@indie

3. 通用 Agent Skills

全局安装到常用宿主：

npx skills add 0xfig-labs/indie -a codex claude-code cursor opencode -g -y

项目级安装：

npx skills add 0xfig-labs/indie -a codex -y

这会安装：

indie-think
indie-strategy
indie-design
indie-plan
indie-mission
indie-build
indie-fix
indie-proof
indie-launch

indie- 前缀避免与宿主或其他 Skill 包中的通用名称冲突。已实际验证 OMP npm 安装与 slash command、Pi 的 manifest/Skills 安装路径、以及 Codex 的 npx skills 安装；Pi 运行时、Claude Code、Cursor、OpenCode 的发现机制保留为兼容目标，尚未做端到端验证。

设计原则

• **确定性路由：**显式 /indie:* 是主入口；自然语言触发只是便利功能。
• **用户意图不脑补：**九个工作流都先区分可查事实、可逆默认与用户专属决定；会改变用户、方向、范围、平台、数据边界、商业模式、预算、授权或成功标准的选择先集中询问。
• **职责隔离：**Think/Design/Plan 不写正式产品代码；Build/Fix 不自称独立验收；Proof 默认只读。
• **证据优先：**事实、推断、假设、未知分开；当前代码、测试和运行证据高于旧文档与记忆。
• **Source-first：**先查现有代码、平台/框架、已装依赖和官方示例；复杂或反复失败的问题再研究 2–3 个成熟开源实现，最后才自研。
• **安装纪律：**依赖按当前官方文档用项目包管理器/官方 CLI 分步安装，每步检查 source/config/lockfile diff；业务与集成代码尽量手写，不重造成熟库。
• **最小交付：**复用现有公共 seam；纵向切片优于数据库/后端/前端分层排期。
• **安全并行：**只并行文件所有权独立、合同已冻结的工作；共享 Schema/API 由集成 Agent 串行控制。
• 授权不过期：build、fix 不默认授权 commit、push、publish、deploy 或生产数据操作。
• **有界重试：**相同失败不原样重跑；确定性能力缺失只做一次直接探测和一个不同替代，记录 retry only when 后停止。
• **验证分层：**UI 不能用 build-only 证明，发布不能用 source-only 证明，安全与性能必须有对应边界证据。
• **宿主契约：**Skill/插件交付必须证明广告命令在干净安装后加载了正确 Skill；像正确的回答不能替代路由、引用和交互证据。

开发与验证

npm test                 # 结构、菜单和评测门
npm run release:smoke    # npm 打包 + OMP marketplace 安装层
npm run e2e:commands     # 九个 /indie:* 命令，需要可写且已认证的 OMP HOME
npm run e2e:generic      # npx skills 安装与发现
npm run eval:run         # 生成当前隔离行为响应；随后按 rubric 评分并更新 summary
npm pack --dry-run
sh -n scripts/*.sh

评测响应、摘要和 Skill/案例/rubric/runner hash 必须一致；提示词或案例变化后，旧分数会被 validator 拒绝。发布门要求关键场景全部通过、无 0 分、平均分不低于 1.8。评测定义见 evals/cases.jsonl，评分规则见 evals/rubric.md。

安全与发布

安全问题请遵循 SECURITY.md，不要在公开 Issue 中提交凭据、个人数据或可直接利用的漏洞细节。

源码、打包内容、安装层和远程发布是不同证据层；通过本地测试不等于 npm/GitHub 发布成功。发布由 prepack 强制运行核心测试；后续可在 npm Trusted Publishing 配置完成后使用仓库内 release workflow 生成 provenance。

License

MIT