Is Trellis Stronger Than Superpowers? A Source‑Code Comparison

Core conclusion: different abstraction tracks

Trellis positions itself as an engineering framework for AI‑assisted coding, while superpowers describes itself as a complete software‑development methodology built on composable skills. The two projects operate on distinct abstraction layers, so direct “stronger” claims require a scenario‑by‑scenario comparison.

What is Trellis? Unpacking .trellis/

Six asset types in one directory

.trellis/
├── workflow.md          # 708‑line workflow "constitution"
├── config.yaml          # project‑level configuration
├── spec/                # package/layer specifications (human + AI co‑written)
├── tasks/               # one directory per task: prd.md / design.md / implement.md / *.jsonl
├── workspace/           # per‑developer session logs (journal‑N.md)
├── agents/              # sub‑agents: architect / check / implement / plan / research
└── scripts/             # Python scripts: task.py, get_context.py, add_session.py

These seven categories constitute Trellis’s core difference from superpowers: Trellis persists specifications, tasks, and memory in the repository, whereas superpowers leaves no trace after execution.

The 708‑line workflow.md

workflow.md

defines a three‑phase state machine:

Phase 1: Plan    → classify request, obtain permission, produce planning artefacts
Phase 2: Execute → start coding after <code>task.py start</code>
Phase 3: Finish  → verify, write back spec, submit, archive

The public README mentions a four‑stage loop (Plan → Implement → Verify → Finish), but the actual runtime state machine lives in workflow.md and is driven by task.py start and task.py archive. Each dialogue round receives a [workflow-state:STATUS] breadcrumb injected by a hook; this is the only signal source for the AI during execution.

⚠️ Pitfall: The breadcrumb protocol depends entirely on hook injection. Platforms that do not support hooks (e.g., Antigravity) will break the workflow.

Underrated subsystems: mem and channel

mem subsystem – cross‑session memory retrieval, implemented via phase.ts, filter.ts, dialogue.ts and a CLI exposing trellis mem list / search / context / extract / projects.

channel subsystem – multi‑worker collaboration via trellis channel spawn, with OOM protection parameters idle_timeout: 5m and max_live_workers: 6 in config.yaml.

superpowers provides no equivalents for these subsystems.

Twenty configurators for multi‑platform reuse

Under packages/cli/src/configurators/ there are exactly 20 files (e.g., antigravity, claude, codebuddy, codex, cursor, etc.) that translate the single .trellis/ structure into platform‑specific hooks, commands, and agents. This implements Trellis’s claim to support “16 platforms” (the repository actually contains 20 configurators).

What is superpowers? 14 skills + 1 hook

Skill list (v6.1.1)

brainstorming               # Socratic design refinement, HARD‑GATE: must draw diagram before code
writing-plans               # split design into 2‑5 min executable tasks
executing-plans              # batch execution with human checkpoints
subagent-driven-development  # fresh sub‑agent per task + two‑stage review
dispatching-parallel-agents  # concurrent sub‑agent workflows
using‑git‑worktrees          # isolated work‑tree development
test-driven-development      # RED‑GREEN‑REFACTOR
systematic-debugging         # 4‑stage root‑cause analysis
verification-before-completion # mandatory verification before claiming completion
requesting-code-review       # pre‑review checklist
receiving-code-review        # post‑review response discipline
finishing-a-development-branch # merge / PR / discard decision
writing-skills               # guidelines for writing new skills
using-superpowers           # bootstrap meta‑skill injected at startup

Trigger mechanism

superpowers registers a single hook ( hooks/hooks.json) that triggers the using-superpowers skill at session start. All other skills are activated purely by AI reading the strong imperative language in each SKILL.md description, e.g.:

YOU ABSOLUTELY MUST invoke the skill.
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE.

This “behavior‑constraint” approach means no runtime scripts or persistent files are added to the repository; the plugin is installed once and then disappears.

SDD rewrite in v6.0

Version 6.0 (2026‑06‑16) rewrote the sub‑agent‑driven‑development (SDD) subsystem, claiming roughly double speed and 50 % token savings in internal evals (Claude Code and Codex). The official release notes state “speed ~2×, token ~50 %”.

Read plan → build global TODO list.

Dispatch a fresh implementer sub‑agent for each task.

Implementer self‑evaluates and writes a diff.

Dispatch a task reviewer for spec compliance and code quality.

If review fails, dispatch a fix sub‑agent and repeat.

After all tasks finish, dispatch a final code reviewer for branch‑wide review.

Enter finishing-a-development-branch to decide merge/PR/discard.

The key design is continuous execution : tasks run unattended unless blocked or fully completed.

v6.1.0 (2026‑06‑30) trimmed the using-superpowers bootstrap (removed Graphviz, folded the Instruction‑Priority section, dropped the Gemini CLI). v6.1.1 (2026‑07‑02) fixed a regression where the Codex hook fell back incorrectly.

Where “stronger” actually applies

Project‑level memory (hard evidence)

superpowers never mentions memory. Trellis stores session journals ( workspace/journal‑N.md) and a structured, searchable mem SDK ( packages/core/src/mem/), enabling cross‑developer, cross‑session recall.

Suitable scenario: long‑term projects with multiple collaborators needing continuity.

Specification injection vs. behavioral constraint

superpowers: skills enforce behavior via imperative descriptions; AI must voluntarily obey.

Trellis: spec files under .trellis/spec/ are physically injected into sub‑agent prompts by hooks, guaranteeing execution without relying on AI memory.

Physical injection offers higher engineering reliability at the cost of added repository complexity.

Persistent task/PRD lifecycle

Trellis’s task.py implements a state machine (planning → in_progress → completed → archived) and maintains implement.jsonl / check.jsonl lists that survive across sessions and platforms.

superpowers’ writing-plans produces a document but provides no runtime tracking.

Ideal for: multi‑day, multi‑session tasks that require hand‑off.

Multi‑platform configuration reuse

Trellis’s 20 configurators translate a single .trellis/ layout into platform‑specific hooks, benefiting teams that mix Claude, Cursor, Codex, etc. If only one platform is used, the advantage diminishes.

Where the “stronger” claim breaks down

Learning & deployment cost

Trellis requires Node ≥18, Python ≥3.9, global npm installation, and team consensus to commit .trellis/ to Git. superpowers installs with a single /plugin install command and leaves the repository untouched.

For individual developers or quick prototypes, superpowers wins decisively.

TDD & debugging discipline

superpowers ships dedicated skills test-driven-development and systematic-debugging, enforcing a strict RED‑GREEN‑REFACTOR loop.

Trellis’s trellis‑check runs lint/tests but its workflow.md only says “run if possible”, lacking enforced TDD.

SDD engineering maturity

superpowers provides fully documented prompts ( implementer-prompt.md, task-reviewer-prompt.md, code-reviewer.md) and a public superpowers‑evals suite.

Trellis defines agents in .trellis/agents/*.md but lacks public evaluation data.

License friendliness

Trellis is AGPL‑3.0, which obliges source disclosure for network use—often a legal blocker for enterprises.

superpowers is MIT, allowing unrestricted commercial modification.

Ecosystem & author credibility

superpowers author Jesse Vincent is a veteran of the Perl community and RT, with extensive release notes, contribution guidelines, eval framework, and commercial support.

Trellis is backed by Mindfold, a newer company with a product‑focused model and less mature community history.

Dimension‑based conclusions: choose by scenario

AI long‑term memory: Trellis (very strong – mem SDK vs none) – long‑term projects, team collaboration.

Spec & team sharing: Trellis (very strong – spec in Git vs plugin directory) – team engineering.

Task/PRD full lifecycle: Trellis (strong – state‑machine vs no tracking) – multi‑day, multi‑session tasks.

Multi‑platform config reuse: Trellis (strong – 20 configurators vs per‑platform plugin) – teams mixing multiple AI assistants.

Learning/deployment cost: superpowers (strong – one‑line install vs init + team consensus) – individual or temporary projects.

TDD / debug discipline: superpowers (medium – dedicated skills vs optional check) – TDD‑focused developers.

Agent review engineering: superpowers (medium – public evals vs internal agents) – quality‑metric seekers.

License friendliness: superpowers (very strong – MIT vs AGPL‑3.0) – enterprise or closed‑source use.

Ecosystem / author credibility: superpowers (medium – long history & commercial support vs newer) – risk‑averse adopters.

Repository invasiveness: superpowers (strong – zero‑invasion vs .trellis/ directory) – repository‑cleanliness enthusiasts.

Practical takeaways

Individual developers, short‑lived projects, TDD believers: choose superpowers – lightweight, strict discipline, MIT license.

Team engineering, long‑term projects, multi‑platform toolchains: choose Trellis – persistent memory, spec sharing, robust task state machine.

Enterprise adoption with legal review: verify AGPL compliance for Trellis; otherwise superpowers offers a safer MIT path.

Both together: install superpowers in personal IDE for habit enforcement, run Trellis in the shared repository for engineering scaffolding – they are not mutually exclusive.