Trellis 是放进代码仓库里的 AI 编码工程框架。它把团队规范、任务上下文和工作记录分别放进 .trellis/spec、.trellis/tasks 与 .trellis/workspace，并为不同编码代理生成对应的命令、skill 和 hook 配置。它解决的是跨会话、跨工具的工程约束问题，不是代码补全模型。
来源：github.com/mindfold-ai/Trellis 查看 GitHub 仓库 → 📘 使用教程 →同一项目在多个编码代理之间切换时，规范和任务记录容易散落。Trellis 把这些内容版本化到仓库，并给出 Plan、Implement、Verify、Finish 四阶段流程，正好对应长任务里常见的上下文丢失和验收困难。这些数字只用于判断持续关注，不能当成独立访客数。
来源：github.com/mindfold-ai/Trellis规范放在 .trellis/spec，PRD、实现与审查上下文放在 .trellis/tasks，个人工作记录放在 .trellis/workspace，避免把全部规则塞进一个入口文件。
来源：github.com/mindfold-ai/Trellis官方 README 把流程拆成 Plan、Implement、Verify 和 Finish；验证阶段会按项目规范检查 diff，并调用 lint、类型检查和测试。
来源：github.com/mindfold-ai/Trellistrellis init 可以显式选择 Claude Code、Cursor、OpenCode、Codex、Gemini 等平台，官方文档当前列出 22 个配置目标。
来源：github.com/mindfold-ai/docs/blob/main/beta/start/install-and-first-ta…CLI 升级与仓库模板同步分开进行；官方文档分别给出 trellis upgrade 和 trellis update。README 还说明 ablate/restore 可用于临时移除和恢复 Trellis 管理的项目文件。
来源：github.com/mindfold-ai/docs/blob/main/beta/start/install-and-first-ta…全局安装的 TypeScript/Node CLI 负责初始化和更新；仓库里的 .trellis 目录保存规范、任务与个人工作区；各平台目录保存该代理能识别的 commands、skills、agents 或 hooks。代理在会话开始时读取或接收相关上下文，任务结束后再把可复用结论写回规范和 journal。
来源：github.com/mindfold-ai/Trellis；https://github.com/mindfold-ai/docs/bl…commanderinquirergigetzodundici适合需要长期维护规范、任务交接和审查记录的个人或团队，也适合在多个编码代理之间保留同一套项目约束。一次性的小脚本、已有成熟任务系统且不准备维护仓库内规范的团队，收益可能有限。
来源：github.com/mindfold-ai/Trellis2026-09-23 核对时，GitHub Releases 页面显示没有 release；主分支 packages/cli/package.json 的版本是 0.6.17。根 README 用 @latest 安装，官方 beta 文档用 @beta，页面因此不把 0.6.17 写成最新正式发布，只把它记录为当前主分支清单版本。
来源：github.com/mindfold-ai/Trellis/releases；https://github.com/mindfold-a…status: docs_only_official_sources_checked_not_installed | checked_at: 2026-09-23 | environment: 只阅读 mindfold-ai/Trellis 官方 README、官方 docs 仓库、CLI package.json 与 GitHub Releases 页面；未安装 npm 包，也未在真实仓库运行 init | limitations: 没有验证 npm registry 当前 dist-tag、初始化生成文件、各代理 hook、四阶段流程、升级和 ablate/restore；所有命令效果仍需在临时仓库实测。 | observed_output: 官方根 README 当前要求 Node.js 18+、Python 3.9+，安装命令使用 @latest；CLI package.json 当前版本为 0.6.17、Node engine 为 >=18.17.0；GitHub Releases 页面没有发布记录。
来源：github.com/mindfold-ai/Trellis；https://github.com/mindfold-ai/Trellis…相比 GitHub Spec Kit，Trellis 更强调常驻仓库的规范、任务、个人 journal 和多代理生成配置；Spec Kit 官方定位是让编码代理按结构化流程完成规格驱动开发、修复或想法评估，并以 specify CLI、模板和脚本为核心。前者更像长期项目工作台，后者更适合从具体流程入口生成可审查的规格产物。两者都不能替代代码审查和测试。
来源：github.com/mindfold-ai/Trellis；https://github.com/github/spec-kit/blo…Trellis 值得用临时仓库试一次，观察初始化 diff、上下文注入和验证阶段是否真的符合现有流程。它的价值来自可维护的规范与任务记录，不来自安装命令本身。正式接入前要先确定谁维护 spec、哪些 workspace 文件可提交，以及 AGPL-3.0-only 对使用场景的影响。
来源：github.com/mindfold-ai/Trellis；https://github.com/mindfold-ai/Trellis…根 README 当前使用 @latest，官方 beta 文档使用 @beta。想减少变动应按根 README 安装 @latest；只有明确要试预览功能时才选 @beta，并记录实际的 trellis 版本。
核心内容在 .trellis 下，包括 spec、tasks 和个人 workspace；它还会按所选平台写入 commands、skills、agents 或 hooks。提交前应先看 git diff，确认没有把个人记录或敏感上下文带入共享仓库。
官方 beta 文档写明，Codex 需要支持 hooks 的版本、在配置中启用 hooks，并在 /hooks 界面完成一次审核。未启用时仍可通过 AGENTS.md 提示手动读取 trellis-start skill，但 slash command 和自动注入不会完整工作。
2026-09-23 核对时 GitHub Releases 页面为空。主分支 CLI package.json 是 0.6.17，但真正安装到机器上的版本仍应以包管理器和 trellis 自身输出为准。