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 exposefinish-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:
- Published — the latest version on npm
- Local CLI — your globally installed
trellisbinary - Project — the
.trellis/templates inside your repo
trellis upgraderaises ② → ① (upgrades the global CLI itself)trellis updateraises ③ → ② (syncs the current project to your local CLI’s version)
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.
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:
- Read
.trellis/workflow.mdso the AI knows the workflow contract. - Run
get_context.pyto surface developer identity, git status, active tasks. - Read spec indexes (per relevant package in a monorepo).
- Report context and ask what you want to work on.
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:
- Run
get_context.py --mode recordto 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. 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.- Archive the active task with
task.py archive <name>(produces achore(task): archive ...commit). If Step 1 surfaced other completed tasks and the user confirmed cleanup, archive those too in the same round. - Append a session entry with
add_session.py --title … --commit …(produces achore: record journalcommit).
<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:
- 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-brainstormcreates the task and draftsprd.md. - Once
prd.mdlooks right, typecontinue→ it decides whether the task is lightweight or needsdesign.mdandimplement.md. - After planning artifacts are reviewed, type
continue→ it starts the task and moves into implement/check. Sub-agent mode also curatesimplement.jsonl/check.jsonl; inline mode reads artifacts/specs directly. - When the sub-agents finish, type
continue→ it routes totrellis-update-spec, and finallyfinish-work.
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 createwhen needed. - Drafts and iterates
prd.mdwith requirements and acceptance criteria. - Asks one question at a time, including the recommended answer.
- For complex tasks, adds
design.mdandimplement.mdbefore 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:
git diff --name-only HEADto find what changed.- Discover which spec layers apply.
- Compare the diff against the quality checklist in each layer’s index.
- Run
pnpm lint/pnpm typecheck/pnpm test(or equivalent) for affected packages. - Self-fix violations in a bounded loop, then report what was fixed and what’s left.
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:
- Root-cause classification (missing spec / contract violation / change propagation / test gap / implicit assumption).
- Why earlier fix attempts failed.
- Prevention mechanisms (spec update, type constraints, lint rule, test, review checklist, doc).
- Systematic expansion: other places with the same pattern.
- 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’sresearch/ 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 ownprd.md, JSONL files, and status. The parent just references them for grouping.
task.json:
- Parent’s
children: [<child-dir-name>, ...]gets the child appended. - Child’s
parent: "<parent-dir-name>"gets set. task.py listrenders 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):
dev_type/scope/package→ set viatask.py set-scopeor by editingtask.jsondirectly; no automatic setter existsbranch→ set viatask.py set-branchstatus→ transitionsplanning → in_progress → completedcompletedAt→ set bytask.py archive(archive does NOT write the commit hash back)parent/children→ set viatask.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.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:
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):
- 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
- 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
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 ahooks 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
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:
- Install the
linearisCLI and setLINEAR_API_KEY - Create
.trellis/hooks.local.json(gitignored) with your team config:
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.
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):
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
3.3 What a Spec Should Look Like
Thetrellis-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:- Scope / Trigger — why this demands code-spec depth
- Signatures — command / API / DB signature(s)
- Contracts — request fields, response fields, env keys (name, type, constraint)
- Validation & Error Matrix —
<condition> → <error>table - Good / Base / Bad Cases — example inputs with expected outcome
- Tests Required — unit / integration / e2e with assertion points
- Wrong vs Correct — at least one explicit pair
3.3.4 Concrete contrast
A good Convention entry (backend/database-guidelines.md):
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.