Skip to main content

1. Commands & Skills Reference

Since 0.5.0, Trellis is skill-first: most capabilities are auto-trigger skills that the platform fires based on context — you don’t have to remember them. Only session-boundary entries remain. Agent-capable platforms expose finish-work and continue; platforms without automatic session injection also expose start.

1.1 Surface at a Glance

The user-facing command set is deliberately small: finish-work and continue everywhere they are useful, plus start on platforms that need a manual session entry point. Everything that used to be a phase command (/before-backend-dev, /check-backend, /record-session, /onboard, …) has either been folded into a skill/sub-agent or removed.

1.2 Commands

1.2.1 Three versions: upgrade vs update

Trellis tracks three separate versions. Knowing which is which explains why upgrading is two steps:
  1. Published — the latest version on npm
  2. Local CLI — your globally installed trellis binary
  3. Project — the .trellis/ templates inside your repo
  • trellis upgrade raises ② → ① (upgrades the global CLI itself)
  • trellis update raises ③ → ② (syncs the current project to your local CLI’s version)
So a full upgrade is trellis upgrade (CLI) then trellis update (project). trellis update can only raise the project as far as your local CLI — if the CLI is stale, upgrade it first.

1.2.2 trellis upgrade: Upgrade the CLI package

Use this when your globally installed Trellis CLI is behind the published package:
trellis upgrade was added in CLI 0.6.0. If your installed CLI is 0.5.x or older the command does not exist yet — raise the local CLI directly with npm install -g @mindfoldhq/trellis@latest, then trellis upgrade is available for every future bump.
trellis upgrade updates the global CLI package. It does not change files in the current project. After upgrading the CLI, run trellis update inside each Trellis project that needs its bundled workflow, hooks, skills, or platform files synced to the new CLI version.

1.2.3 trellis update: Sync the project to the CLI

Run this inside a Trellis project after upgrading the CLI. It syncs .trellis/ templates and platform files (hooks, skills, commands) to your local CLI’s version:
trellis update only touches files you haven’t modified — your customizations stay intact, and a timestamped backup is created before any change.
If the update output ends with MIGRATION REQUIRED (breaking changes between your project’s version and the CLI, e.g. 0.4.0 → 0.6.5), run trellis update --migrate. Without --migrate, files renamed or relocated by breaking releases are not moved — your project keeps the stale old paths alongside the new templates. Use --dry-run to preview what --migrate will do.

1.2.4 /trellis:start: Start a session

Run this at the beginning of a session if your platform does not auto-inject context. On hook-capable or extension-capable platforms (Claude Code, Cursor, OpenCode, Gemini, Qoder, CodeBuddy, Copilot, Droid, Pi Agent, plus Codex with features.hooks = true — legacy: codex_hooks = true), the SessionStart hook or extension does this automatically, so start is usually not installed as a user-facing command. What it does:
  1. Read .trellis/workflow.md so the AI knows the workflow contract.
  2. Run get_context.py to surface developer identity, git status, active tasks.
  3. Read spec indexes (per relevant package in a monorepo).
  4. Report context and ask what you want to work on.
Task classification the AI will apply: If the user rejects task creation for complex work, the AI should clarify scope or suggest a smaller split instead of doing broad inline implementation.

1.2.5 /trellis:finish-work: Wrap up + archive

Prerequisite: code is already committed. The AI drives a batched commit step in workflow Phase 3.4 (see .trellis/workflow.md) where it drafts commits from this session’s edits, learns the repo’s commit-message style from git log --oneline -5, presents the plan once for one-shot user confirmation, and runs git commit per batch. /finish-work itself focuses on archive + journal and refuses to run on a dirty working tree to keep bookkeeping commits ordered after work commits. Steps:
  1. Run get_context.py --mode record to print active tasks, git status, and recent commits. Use this to spot completed-but-unarchived tasks beyond the current one and to grab work-commit hashes for Step 4.
  2. git status --porcelain, excluding paths under .trellis/workspace/ and .trellis/tasks/ (managed by the script auto-commits). Bail out if anything else is dirty, redirecting the user back to Phase 3.4.
  3. Archive the active task with task.py archive <name> (produces a chore(task): archive ... commit). If Step 1 surfaced other completed tasks and the user confirmed cleanup, archive those too in the same round.
  4. Append a session entry with add_session.py --title … --commit … (produces a chore: record journal commit).
Final git log order: <work commits from 3.4>chore(task): archive ... (one or more) → chore: record journal. Spec sync (route a non-trivial learning to trellis-update-spec) belongs in workflow Phase 3.3 before commits, not in this skill.

1.2.6 /trellis:continue: Advance within the current task

continue is a within-task continue — not a cross-task one. The AI picks up where the active task left off using its task.json.status plus the workflow-state breadcrumb the hook injects each turn, consults workflow.md to locate the current phase/step, and advances to the next one. A typical task conversation:
  1. Describe the work in natural language → the AI classifies the request and asks for task-creation consent when Trellis is useful. After you agree, trellis-brainstorm creates the task and drafts prd.md.
  2. Once prd.md looks right, type continue → it decides whether the task is lightweight or needs design.md and implement.md.
  3. After planning artifacts are reviewed, type continue → it starts the task and moves into implement/check. Sub-agent mode also curates implement.jsonl / check.jsonl; inline mode reads artifacts/specs directly.
  4. When the sub-agents finish, type continue → it routes to trellis-update-spec, and finally finish-work.
Previously you had to learn the workflow yourself and remember which slash command belonged to each phase. With continue, the whole workflow falls out of an ordinary conversation — type continue to move on, and Trellis keeps the phases straight on your behalf.

1.3 Auto-trigger Skills

Skills run without an explicit command; the platform matches on the user’s intent. You can always trigger them manually (/skill trellis-brainstorm, etc.) if the auto-match misses.

1.3.1 trellis-brainstorm

Turns an approved planning request into concrete artifacts:
  • Inspects code, tests, configs, docs, existing specs, and task history before asking questions.
  • Proposes a task name and slug, then creates the task via task.py create when needed.
  • Drafts and iterates prd.md with requirements and acceptance criteria.
  • Asks one question at a time, including the recommended answer.
  • For complex tasks, adds design.md and implement.md before implementation starts.

1.3.2 trellis-before-dev

Runs before coding starts on a task. Reads the spec index for the affected package(s), then the specific guideline files referenced in the pre-development checklist. Ensures the AI knows the conventions before writing code, not after.

1.3.3 trellis-check

Runs after implementation:
  1. git diff --name-only HEAD to find what changed.
  2. Discover which spec layers apply.
  3. Compare the diff against the quality checklist in each layer’s index.
  4. Run pnpm lint / pnpm typecheck / pnpm test (or equivalent) for affected packages.
  5. Self-fix violations in a bounded loop, then report what was fixed and what’s left.
The trellis-check sub-agent wraps the skill — the main session just hands verification off to it. The sub-agent has its own retry loop, so there’s no need for an external Ralph Loop anymore.

1.3.4 trellis-update-spec

Captures a learning as an executable contract in .trellis/spec/. Used after debugging sessions, after hitting a gotcha, or after making a non-obvious design decision. Picks the right spec file, adds a focused update (decision / convention / pattern / anti-pattern / gotcha), updates the index if needed.

1.3.5 trellis-break-loop

Invoked after resolving a hard bug. Produces a 5-dimension analysis:
  1. Root-cause classification (missing spec / contract violation / change propagation / test gap / implicit assumption).
  2. Why earlier fix attempts failed.
  3. Prevention mechanisms (spec update, type constraints, lint rule, test, review checklist, doc).
  4. Systematic expansion: other places with the same pattern.
  5. Knowledge capture: route findings into trellis-update-spec.
The value of debugging is not fixing this bug; it’s making sure this class of bugs never happens again.

1.4 Sub-agents

Sub-agents are isolated AI sub-processes with their own prompt and (platform-specific) their own tool / hook wiring. Implementation and check agents receive stable spec/research context via JSONL files per task; research agents write findings into the task’s research/ directory. On Claude Code, Cursor, OpenCode, CodeBuddy, Droid, and Pi Agent, implementation and check sub-agents get the right JSONL context (implement.jsonl, check.jsonl) injected automatically before they start. Pi uses its extension rather than a Python hook. On the rest, the main session reads the JSONL files itself and passes the relevant content into sub-agent prompts. Research agents write durable findings under the task’s research/ directory.

2. Task Management Workflow

2.1 Task Lifecycle

task.py create starts the task in planning, creates a default prd.md, and best-effort points the current AI session at the new task. It also auto-seeds implement.jsonl + check.jsonl when a sub-agent-capable platform is installed (Claude / Cursor / Codex / Kiro / Pi / etc.); agent-less platforms (Kilo / Antigravity / Devin) skip this and load specs via the trellis-before-dev skill in Phase 2.

2.2 task.py Subcommands

2.2.1 Task Creation

2.2.2 Context Configuration

task.py add-context only writes to implement.jsonl / check.jsonl. Research findings belong in {TASK_DIR}/research/*.md; add those files to the implement/check manifests only when a later sub-agent must read them before working.

2.2.3 Task Control

2.2.4 Parent-child (subtasks)

A task can have children. Children are independent task directories on disk — they have their own prd.md, JSONL files, and status. The parent just references them for grouping.
Effects on task.json:
  • Parent’s children: [<child-dir-name>, ...] gets the child appended.
  • Child’s parent: "<parent-dir-name>" gets set.
  • task.py list renders children indented under their parent and shows [done/total done] so you can see progress at a glance.
Parent-child links use the parent and children fields. The subtasks field that also appears in task.json is unrelated — it’s a checklist of to-do items within a single task (name + status pairs), populated mainly by the bootstrap task. Don’t confuse the two.

2.2.5 Task Management

2.3 task.json Schema

The exact shape task.py create writes today (see .trellis/scripts/common/task_store.py):
Fields get populated over time:
  • dev_type / scope / package → set via task.py set-scope or by editing task.json directly; no automatic setter exists
  • branch → set via task.py set-branch
  • status → transitions planning → in_progress → completed
  • completedAt → set by task.py archive (archive does NOT write the commit hash back)
  • parent / children → set via task.py create --parent / add-subtask
worktree_path / commit / pr_url are schema placeholders only; no 0.5 script populates them. Store commit hashes or PR URLs under meta: {}, or write them back from an after_archive hook.
Older tasks created before a field existed may be missing some keys (e.g. tasks created pre-package support won’t have "package"); task.py treats missing fields as null, so nothing breaks. Status transitions:
planning / in_progress / completed align with the three phases in workflow.md. task.py start rewrites planning to in_progress automatically; non-planning statuses (in_progress, review, completed) are left untouched, so re-starting a task in review doesn’t clobber its state. task.py list --status also accepts review as a filter — add any custom statuses you need by writing a matching [workflow-state:<name>] block in workflow.md.

2.4 JSONL Context Configuration in Practice

2.4.1 Seeded on Create, AI Curates in Phase 1.3

On sub-agent-capable platforms, task.py create writes a single seed line into each jsonl:
This line is a fill-in hint for the AI. It has no file field, so every downstream consumer (hook, prelude, validate, list-context) skips it; the AI reads it, understands the format, then replaces it with real entries in Phase 1.3. Example curated implement.jsonl after AI review (dev_type=backend monorepo):
What belongs in the jsonl:
  • Spec files (.trellis/spec/<pkg>/<layer>/index.md + specific guideline files) that apply to this task’s domain
  • Research files ({TASK_DIR}/research/*.md) the sub-agent needs to consult
What does NOT belong:
  • Code files (src/**, packages/**/*.ts, etc.) — those are read by the sub-agent during implementation, not pre-registered here
  • Files you’re about to modify — same reason
On agent-less platforms (Kilo / Antigravity / Devin), task.py create skips seeding. Those platforms load specs via the trellis-before-dev skill in Phase 2.1 instead.

2.4.2 Adding Custom Context

2.5 Task Lifecycle Hooks

You can configure shell commands that run automatically when task lifecycle events occur. This enables integrations like syncing tasks to Linear, posting to Slack, or triggering CI pipelines.

2.5.1 Configuration

Add a hooks block to .trellis/config.yaml:
The default config.yaml ships with the hooks section commented out. Uncomment and edit to activate.

2.5.2 Supported Events

2.5.3 Environment Variables

Each hook receives: All other environment variables from the parent process are inherited.

2.5.4 Execution Behavior

  • Working directory: Repository root
  • Shell: Commands run through the system shell (shell=True)
  • Failures don’t block: A failing hook prints a [WARN] message to stderr but does not prevent the task operation from completing
  • Sequential: Multiple hooks per event execute in list order; a failure in one does not skip the rest
  • stdout captured: Hook stdout is not displayed to the user; use stderr for diagnostic output
The after_archive hook receives TASK_JSON_PATH pointing to the archived location (e.g., .trellis/tasks/archive/2026-03/task-name/task.json), not the original path.

2.5.5 Example: Linear Sync Hook

Trellis ships with an example hook at .trellis/scripts/hooks/linear_sync.py that syncs task lifecycle events to Linear. What it does: Prerequisites:
  1. Install the linearis CLI and set LINEAR_API_KEY
  2. Create .trellis/hooks.local.json (gitignored) with your team config:
The hook writes the Linear issue identifier back to task.json under meta.linear_issue (e.g., "ENG-123"), making subsequent events idempotent.

3. Writing Specs

3.1 Spec Directory Structure and Layering

3.1.1 Default layout from trellis init

trellis init writes a skeleton with frontend/ + backend/ + guides/, all filled with empty placeholder templates marked “(To be filled by the team)”. The templates are not ready to inject into sub-agents as-is.
Running trellis init also creates a bootstrap task (00-bootstrap-guidelines). In the first Trellis session, AI detects it, runs trellis-research to read your actual codebase, then fills the placeholders with specs grounded in the real project (tech stack, conventions, directory shape). Skip this task and you’ll be handing empty scaffolds to every sub-agent — don’t.

3.1.2 The layout is only a convention

frontend/ and backend/ are not special. Trellis discovers spec layers by scanning one level under .trellis/spec/ for any directory that contains an index.md. Name them after how your project actually splits — by runtime, by package, by responsibility — as long as each layer has its own index.md. Trellis itself uses a different shape (monorepo, per-package):
No frontend/ or backend/ at the top level, because the repo is structured by package. The only contract Trellis enforces is “a layer is a directory with index.md; everything else is up to your project.

3.2 From Empty Templates to Complete Specs

trellis init generates empty templates marked “(To be filled by the team)”. Here’s how to fill them: Step 1: Extract patterns from actual code
Step 2: Write down your conventions
Step 3: Add code examples
Step 4: Update index.md status

3.3 What a Spec Should Look Like

The trellis-update-spec skill writes specs as executable contracts, not principle text. Every entry sub-agents read at trellis-implement / trellis-check time has to tell them how to implement safely — concrete signatures, contracts, cases, tests. If what you’re writing is really “what to think about before coding”, it belongs in guides/.

3.3.1 Code-Spec vs Guide

If you’re writing “don’t forget to check X”, put it in a guide. If you’re writing “X accepts {field: type, ...} and returns {...}; here are the error cases and the required tests”, put it in a code-spec.

3.3.2 Pick the right update shape

trellis-update-spec ships several templates; pick the one that matches what you learned:

3.3.3 Mandatory 7-section form for infra / cross-layer work

When the change touches a command / API signature, a cross-layer request-response contract, a DB schema, or infra wiring (storage, queue, cache, secrets, env), the skill requires all seven sections:
  1. Scope / Trigger — why this demands code-spec depth
  2. Signatures — command / API / DB signature(s)
  3. Contracts — request fields, response fields, env keys (name, type, constraint)
  4. Validation & Error Matrix<condition> → <error> table
  5. Good / Base / Bad Cases — example inputs with expected outcome
  6. Tests Required — unit / integration / e2e with assertion points
  7. Wrong vs Correct — at least one explicit pair
Skip any of these and the skill prompts you to fill them; that’s the “executable contract” bar.

3.3.4 Concrete contrast

A good Convention entry (backend/database-guidelines.md):
A bad spec entry — no signature, no example, no why, no test point:
An over-specified spec — mechanical rules with no reasoning, stifles judgment:
The bar: specific, actionable, with a code example, with a stated why, and — for code-specs — with enough signature / contract detail that a sub-agent can act on it without asking follow-up questions.

3.4 Bootstrap Guided Initial Fill

trellis init also creates a bootstrap task (00-bootstrap-guidelines). In the first Trellis session, the AI recognizes it, runs trellis-research across your code, and fills the empty templates under frontend/ / backend/ / guides/ with specs grounded in your actual project — tech stack, conventions, directory shape, all pulled from the code.