npx thrunt-god@latest

我为什么做这个

我是独立开发者。我不写代码，Claude Code 写。

市面上已经有其他规格驱动开发工具，比如 BMAD、Speckit……但它们要么把事情搞得比必要的复杂得多了些（冲刺仪式、故事点、利益相关方同步、复盘、Jira 流程），要么根本缺少对你到底在构建什么的整体理解。我不是一家 50 人的软件公司。我不想演企业流程。我只是个想把好东西真正做出来的创作者。

所以我做了 THRUNT。复杂性在系统内部，不在你的工作流里。幕后是上下文工程、XML 提示格式、子代理编排、状态管理；你看到的是几个真能工作的命令。

这套系统会把 Claude 完成工作 以及 验证结果所需的一切上下文都准备好。我信任这个工作流，因为它确实能把事情做好。

这就是它。没有企业角色扮演式的废话，只有一套非常有效、能让你持续用 Claude Code 构建酷东西的系统。

— TÂCHES

Vibecoding 的名声不算好。你描述需求，AI 生成代码，结果往往是质量不稳定、规模一上来就散架的垃圾。

THRUNT 解决的就是这个问题。它是让 Claude Code 变得可靠的上下文工程层。你只要描述想法，系统会自动提取它需要知道的一切，然后让 Claude Code 去干活。

适合谁用

适合那些想把自己的需求说明白，然后让系统正确构建出来的人，而不是假装自己在运营一个 50 人工程组织的人。

快速开始

npx thrunt-god@latest

安装器会提示你选择：

1. 运行时：Claude Code、OpenCode、Gemini、Codex、Copilot、Cursor、Antigravity，或全部
2. 安装位置：全局（所有项目）或本地（仅当前项目）

安装后可这样验证：

• Claude Code / Gemini：/thrunt:help
• OpenCode：/thrunt-help
• Codex：$thrunt-help
• Copilot：/thrunt:help
• Antigravity：/thrunt:help

[!NOTE] Codex 安装走的是 skill 机制（skills/thrunt-*/SKILL.md），不是自定义 prompt。

保持更新

THRUNT 迭代很快，建议定期更新：

npx thrunt-god@latest

# Claude Code
npx thrunt-god --claude --global   # 安装到 ~/.claude/
npx thrunt-god --claude --local    # 安装到 ./.claude/

# OpenCode（开源，可用免费模型）
npx thrunt-god --opencode --global # 安装到 ~/.config/opencode/

# Gemini CLI
npx thrunt-god --gemini --global   # 安装到 ~/.gemini/

# Codex（以 skills 为主）
npx thrunt-god --codex --global    # 安装到 ~/.codex/
npx thrunt-god --codex --local     # 安装到 ./.codex/

# Copilot（GitHub Copilot CLI）
npx thrunt-god --copilot --global  # 安装到 ~/.github/
npx thrunt-god --copilot --local   # 安装到 ./.github/

# Cursor CLI
npx thrunt-god --cursor --global   # 安装到 ~/.cursor/
npx thrunt-god --cursor --local    # 安装到 ./.cursor/

# Antigravity（Google，以 skills 为主，基于 Gemini）
npx thrunt-god --antigravity --global # 安装到 ~/.gemini/antigravity/
npx thrunt-god --antigravity --local  # 安装到 ./.agent/

# 所有运行时
npx thrunt-god --all --global      # 安装到所有目录

git clone https://github.com/thrunt-build/thrunt-god.git
cd thrunt-god
node bin/install.js --claude --local

推荐：跳过权限确认模式

THRUNT 的设计目标是无摩擦自动化。运行 Claude Code 时建议使用：

claude --dangerously-skip-permissions

[!TIP] 这才是 THRUNT 的预期用法。连 date 和 git commit 都要来回确认 50 次，整个体验就废了。

{
  "permissions": {
    "allow": [
      "Bash(date:*)",
      "Bash(echo:*)",
      "Bash(cat:*)",
      "Bash(ls:*)",
      "Bash(mkdir:*)",
      "Bash(wc:*)",
      "Bash(head:*)",
      "Bash(tail:*)",
      "Bash(sort:*)",
      "Bash(grep:*)",
      "Bash(tr:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(git tag:*)"
    ]
  }
}

它是怎么工作的

已经有现成代码库？ 先运行 /hunt:map-environment。它会并行拉起多个代理分析你的技术栈、架构、约定和风险点。之后 /hunt:new-program 就会真正“理解”你的代码库，提问会聚焦在你打算新增的部分，规划时也会自动加载你的现有模式。

1. 初始化项目

/hunt:new-program

一个命令，一条完整流程。系统会：

1. 提问：一直问到它彻底理解你的想法（目标、约束、技术偏好、边界情况）
2. 研究：并行拉起代理调研领域知识（可选，但强烈建议）
3. 需求梳理：提取哪些属于 v1、v2，哪些不在范围内
4. 路线图：创建与需求映射的阶段规划

你审核并批准路线图后，就可以开始构建。

生成： MISSION.md、HYPOTHESES.md、HUNTMAP.md、STATE.md、.planning/research/

2. 讨论阶段

/hunt:shape-hypothesis 1

这是你塑造实现方式的地方。

你的路线图里，每个阶段通常只有一两句话。这点信息不足以让系统按 你脑中的样子 把东西做出来。这一步的作用，就是在研究和规划之前，把你的偏好先收进去。

系统会分析该阶段，并根据要构建的内容识别灰区：

• 视觉功能：布局、信息密度、交互、空状态
• API / CLI：返回格式、flags、错误处理、详细程度
• 内容系统：结构、语气、深度、流转方式
• 组织型任务：分组标准、命名、去重、例外情况

对每个你选择的区域，系统都会持续追问，直到你满意为止。最终产物 CONTEXT.md 会直接喂给后续两个步骤：

1. 研究代理会读取它：知道该研究哪些模式（例如“用户想要卡片布局” → 去研究卡片组件库）
2. 规划代理会读取它：知道哪些决策已经锁定（例如“已决定使用无限滚动” → 计划里就会包含滚动处理）

你在这里给出的信息越具体，系统越能构建出你真正想要的东西。跳过它，你拿到的是合理默认值；用好它，你拿到的是 你的 方案。

生成： {phase_num}-CONTEXT.md

3. 规划阶段

/hunt:plan 1

系统会：

1. 研究：结合你的 CONTEXT.md 决策，调研这一阶段该怎么实现
2. 制定计划：创建 2-3 份原子化任务计划，使用 XML 结构
3. 验证：将计划与需求对照检查，直到通过为止

每份计划都足够小，可以在一个全新的上下文窗口里执行。没有质量衰减，也不会出现“我接下来会更简洁一些”的退化状态。

生成： {phase_num}-RESEARCH.md、{phase_num}-{N}-PLAN.md

4. 执行阶段

/hunt:run 1

系统会：

1. 按 wave 执行计划：能并行的并行，有依赖的顺序执行
2. 每个计划使用新上下文：20 万 token 纯用于实现，零历史垃圾
3. 每个任务单独提交：每项任务都有自己的原子提交
4. 对照目标验证：检查代码库是否真的交付了该阶段承诺的内容

你可以离开，回来时看到的是已经完成的工作和干净的 git 历史。

Wave 执行方式：

计划会根据依赖关系被分组为不同的 “wave”。同一 wave 内并行执行，不同 wave 之间顺序推进。