Trellis Review 2026: Workflow Layer for Claude Code, Codex, Cursor, and Agent Teams

Trellis is not another model, IDE, or terminal coding agent. It is a workflow layer for developers who already use tools like Claude Code, Codex, Cursor, OpenCode, Kiro, Gemini CLI, Qoder, or GitHub Copilot and want those agents to follow the same project standards instead of improvising from a blank session.

That distinction matters for search intent. People searching for "Trellis Claude Code", "Trellis Codex", or "Trellis AI coding framework" usually do not need another generic agent ranking. They need to know whether Trellis is worth adding to an existing agent workflow, how it installs, what it changes, and where the friction appears.

Short answer: Trellis is worth evaluating when your agent work has moved beyond one-shot prompts and now needs specs, task boundaries, memory, and repeatable checks across multiple tools. It is overkill if you only use one assistant for small ad hoc edits.

Quick Verdict

Question	Trellis answer
Best for	Teams and serious solo developers standardizing work across Claude Code, Codex, Cursor, OpenCode, Gemini CLI, and similar agents
Not ideal for	Simple one-off chats, autocomplete-only workflows, or teams unwilling to maintain specs and task files
Official docs	docs.trytrellis.app
GitHub	mindfold-ai/Trellis
npm package	@mindfoldhq/trellis
Current version checked	v0.6.5 on npm and GitHub tags when checked on July 6, 2026
Runtime requirements	Node.js 18+ and Python 3.9+ according to the install docs
License	AGPL-3.0 on GitHub; npm metadata reports AGPL-3.0-only
Public signal checked	About 11.8k GitHub stars and 665 forks when checked on July 6, 2026
Pricing	Free open source; upstream agent, model, API, and subscription costs remain separate
Closest alternatives	Spec Kit, SuperClaude, custom AGENTS.md or CLAUDE.md workflows, OpenViking, context-mode

What Is Trellis?

Trellis is an open-source AI coding workflow framework. Its core idea is simple: put durable project context in your repository, then make supported coding agents load that context in a structured way.

The official docs describe Trellis around a few core pieces:

• specs under .trellis/spec/ for coding standards and project rules;
• tasks under .trellis/tasks/ for PRDs, implementation context, check context, and task status;
• workspace journals under .trellis/workspace/ for cross-session memory;
• platform-specific files for tools such as Claude Code, Cursor, OpenCode, Codex, Kiro, Gemini CLI, Qoder, CodeBuddy, Copilot, Droid, Pi Agent, Antigravity, Devin, Kilo, Reasonix, and ZCode;
• shared .agents/skills/ output for agents that understand the Agent Skills standard.

That makes Trellis closer to engineering process infrastructure than to a coding assistant. It does not replace Claude Code or Codex. It tries to make them less forgetful, less inconsistent, and easier to review.

Why Developers Search for Trellis With Claude Code and Codex

Freeform agent work is fast until it becomes hard to govern. A single prompt can produce a useful patch, but larger projects quickly run into repeat problems:

• the agent forgets coding conventions between sessions;
• requirements live in chat instead of reviewable files;
• every tool wants its own instruction format;
• parallel agent work collides in branches or worktrees;
• review becomes harder because intent, specs, and implementation drift apart;
• team practices get copied manually into AGENTS.md, CLAUDE.md, .cursorrules, and other files.

Trellis exists for that moment. It gives the project one structured layer of specs, tasks, workflow rules, and journals, then generates the platform files each agent needs.

For Claude Code users, that means Trellis can write Claude-specific commands, skills, agents, and hooks. For Codex users, the docs say the setup uses .codex/ files plus a root AGENTS.md, with hook support when enabled in Codex. For Cursor and OpenCode, Trellis writes their own command, agent, skill, rule, or plugin directories.

The useful question is not "is Trellis better than Claude Code?" That framing is wrong. The better question is: does your Claude Code, Codex, or Cursor workflow need a shared project operating system underneath it?

Installation Reality

The official install path is npm:

npm install -g @mindfoldhq/trellis@latest
cd your-project
trellis init -u your-name

You can also initialize selected platforms explicitly:

trellis init -u your-name --claude
trellis init -u your-name --codex --gemini
trellis init -u your-name --claude --cursor --opencode

The docs list Node.js 18+ and Python 3.9+ as requirements. That is a real adoption detail. Trellis is not just a Markdown template pack; it ships CLI behavior, platform scaffolding, hooks, Python scripts, and workflow files.

For upgrades, Trellis separates the global CLI package from the project templates. The docs describe trellis upgrade for the CLI and trellis update inside each project to sync .trellis/ and platform files. That separation is sensible, but it also means teams need an upgrade habit. If your repo treats generated workflow files as untouchable magic, Trellis will eventually drift.

Where Trellis Looks Strong

It Solves a Real Multi-Agent Problem

Many developers now use more than one AI coding surface: Claude Code for deep terminal work, Codex for repo tasks, Cursor for editor-native iteration, Gemini CLI or OpenCode for other contexts. Without a shared layer, each tool gets its own partial memory and conventions.

Trellis is strongest when it becomes the common layer. Specs and tasks live in the repository. Platform files are generated around them. That is more maintainable than rewriting the same instructions for every assistant.

Specs and Tasks Are Reviewable

The best part of Trellis is not the CLI command. It is the decision to move important context out of chat and into files. A PRD, implementation context file, check context file, and project spec can be reviewed, versioned, tightened, and reused. Chat-only workflows rarely age that well.

This is especially useful for teams. A lead can review the rule itself instead of guessing which prompt the agent saw during a session.

Workspace Journals Fit Long-Running Work

The docs describe workspace journals that preserve what happened in prior sessions. That is useful because agent work often spans multiple windows, compacted conversations, or interrupted runs. A journal is not a substitute for git history or issue tracking, but it gives the next session a better starting point than "read the repo again."

Public Signal Is Now Meaningful

When checked on July 6, 2026, the public GitHub repository showed about 11.8k stars, 665 forks, AGPL-3.0 licensing, and recent activity. The npm registry showed @mindfoldhq/trellis v0.6.5 published on June 25, 2026, with trellis and tl binaries.

Those numbers do not prove Trellis is right for your team. They do make it more credible than a small prompt-file experiment with no adoption signal.

Pricing and Licensing Reality

Trellis is free open source software, but "free" is not the whole cost story.

Your agent costs remain separate. Claude Code, Codex, Cursor, Gemini, OpenCode, model APIs, and hosted platforms each have their own billing or subscription reality. Trellis organizes the workflow around those tools; it does not make model usage free.

The license also matters. GitHub displays AGPL-3.0 licensing, and npm metadata reports AGPL-3.0-only. For many internal development workflows, that may be acceptable. For companies building hosted developer tooling, distributing modified versions, or embedding Trellis in a commercial platform, legal review is the responsible move. Do not treat AGPL like MIT just because the repository is public.

Tradeoffs and Risks

Trellis adds process. That is its value and its cost.

First, it will feel heavy if your current workflow is only small prompts and quick edits. Specs, task directories, platform files, journals, and finish commands are useful only when the work is big enough to justify them.

Second, Trellis depends on maintenance discipline. If the specs become stale or the task files are ignored, the workflow layer turns into another pile of ceremony.

Third, platform support is not identical across tools. Claude Code, Codex, Cursor, OpenCode, and Gemini CLI expose different hooks, commands, skills, and configuration surfaces. Trellis abstracts a lot, but it cannot make every agent client behave the same.

Fourth, generated project files can create review noise. Teams should be clear about which .trellis/, .codex/, .claude/, .cursor/, and related files belong in source control and how updates get reviewed.

Finally, Trellis does not fix weak requirements. If the product ask is vague, the tests are absent, or nobody reviews the generated code, a workflow framework will only organize the confusion.

Trellis Alternatives

Spec Kit: Compare Spec Kit when your main need is spec-driven development structure. Trellis is broader around multi-platform agent workflow, workspace memory, and platform scaffolding.

SuperClaude: Compare SuperClaude if you are primarily improving Claude Code behavior through commands and persona-style workflows. Trellis is a better fit when you also need Codex, Cursor, OpenCode, Gemini CLI, or shared team specs.

Custom AGENTS.md, CLAUDE.md, and .cursorrules: Hand-written instruction files are enough for many projects. Trellis becomes attractive when those files grow monolithic, diverge by tool, or stop matching actual team practice.

OpenViking: Compare OpenViking when you are thinking about agent memory and context databases more broadly. Trellis is more opinionated around coding workflow, tasks, and platform setup.

context-mode: Compare context-mode when the main problem is keeping raw tool output out of the model context window. Trellis is more about project specs, tasks, and workflow state.

Who Should Use Trellis?

Use Trellis if:

• your team uses multiple coding agents and wants one shared workflow layer;
• Claude Code, Codex, Cursor, or OpenCode sessions keep losing project context;
• you want PRDs, specs, and task context to be reviewable files;
• you run parallel agent tasks and need clearer boundaries;
• you are comfortable committing and maintaining workflow scaffolding;
• AGPL-3.0 is acceptable for your use case.

Skip Trellis if:

• you only need autocomplete or quick one-off edits;
• your team will not maintain specs after the first week;
• you want a hosted dashboard instead of repo-local workflow files;
• your legal policy avoids AGPL software;
• one simple AGENTS.md already works well enough;
• your real issue is missing tests, unclear requirements, or poor review habits.

Bottom Line

Trellis is a serious workflow layer for agentic coding teams, not a magic productivity button. Its strongest idea is practical: keep project standards, tasks, memory, and workflow checks in the repository, then make different AI coding tools work from that shared structure.

That is valuable when your workflow spans Claude Code, Codex, Cursor, OpenCode, Gemini CLI, or several developer machines. It is too much ceremony when you only need a small assistant for occasional edits.

Start with the Trellis tool profile, verify the official docs, inspect the GitHub repository, and check the npm package before adding it to a production repo.