Implementation workflow

Delegate a bounded change. Inspect it before it ships.

Hand a bounded coding task to your selected coding engine throughtriss coder run. The run happens in an isolated Git worktree; the printed envelope and the worktree are what you inspect before anything is accepted.

Prerequisites

A Git project.
A working coding engine and provider you selected — see thecoder reference andsetup. Triss does not choose the engine for you and does not require one specific model.
Concrete acceptance criteria for the change, decided before the run.

Define the task

State, before running anything:

the goal of the change;
the allowed scope — which files or areas may change;
the project's check commands the run should execute;
what must not change.

Example task

"Add retries with exponential backoff to the HTTP client insrc/http/client.js. Do not change the public function signatures. Run the project's HTTP test suite and report the results. Do not touch files outside src/http/."

This is an example task you write and adapt — this page shows no fabricated execution transcript.

Run

The whole task travels in the quoted prompt — the engine starts with no memory of this page or of anything you defined before the command, and the session name is only a label, not context. This example embeds the Example task from above; replace the quoted text with your own complete task:

triss coder run --isolate --session bounded-change "Add retries with exponential backoff to the HTTP client in src/http/client.js. Do not change the public function signatures. Run the project's HTTP test suite and report the results. Do not touch files outside src/http/. Report the changes, checks, and remaining limitations."

--isolate runs the task in a disposable Git worktree under.triss/wt/<slug>; --session gives the run a Triss-side session slug you can refer to later. The command prints a JSON envelope to stdout.

The natural-language prompt defines the task — it does not create a sandbox policy. A Git worktree separates changes; it is not an operating-system sandbox. If you have explicit protection requirements, do not silently replace them with best effort: isolated runs that cannot enforce isolation fail before spawn unless you explicitly opt into a downgrade.

Locate the result

Read the JSON envelope the run actually printed — it reports the session, the worktree, execution details, and capability warnings. For retained artifacts and sessions, use the inventory commands:

triss coder result list
triss coder session list --engine opencode

The second command is an example for the OpenCode engine — pass the engine of your actual run (opencode, opencode2,crush, or omp).

Retention is conditional: a successful run does not guarantee a retained result artifact. A result you cannot locate is an unknown, not a success.

Inspect the actual worktree

From your project root, save it and assign $WORKTREE to the path your real run reported, then look at what actually changed — staged, unstaged, and untracked:

PROJECT="$PWD"
WORKTREE="<path reported by your run>"
git -C "$WORKTREE" status --short
git -C "$WORKTREE" diff --cached
git -C "$WORKTREE" diff
git -C "$WORKTREE" ls-files --others --exclude-standard

$WORKTREE is assigned to the actual path before running — it is not copied from this demo. <...> placeholders on this page are replaceable values, not literals to paste. $PROJECT keeps your original directory for the steps below.

Do not stop at git diff: the run may stage its deliverables, so check the staged diff and the untracked files as well. A diffstat or a files-changed count does not replace reading the content.

Verify

Change into the actual worktree and run the focused checks specified in the task — the real commands, not a recap of what the engine reported about itself — then return to your project:

cd "$WORKTREE"
# run your project's focused checks exactly as specified in the task
cd "$PROJECT"

An exit code of 0 does not prove the result is correct. Verification is reading the diff and running the checks yourself. Return to$PROJECT before any inventory or cleanup command: Triss resolves project state from the current directory, and run from inside the worktree those commands would look at the worktree's own state instead of your project's.

Accept

After verification, accept the work through your normal Git process: review the changes, make a deliberate commit or open a pull request, and have it reviewed. Triss does not merge automatically, and there is no accept subcommand — acceptance is your decision, recorded in your repository.

Reject and clean up

Do not delete a diff you have not reviewed. After an explicit decision to reject, run the targeted cleanup from your project root (cd "$PROJECT" if you are still in the worktree) and remove the specific retained result or the specific inactive session:

cd "$PROJECT"
triss coder result clean <run-id>
triss coder session clean <slug> --engine <actual-engine>

Take <run-id>, <slug>, and<actual-engine> from your real inventory (triss coder result list, triss coder session list) — they are replaceable values, not ready-made literals for a copy button.

Result cleanup removes a retained result artifact; it does not delete the persistent session.
triss coder clean only removes finished isolation worktrees whose branches have no diff against the default branch — it is not a universal reject.
--all and --recover-live are force paths for specific situations, not the normal cleanup route.

Limits

Read the engine's execution and capability warnings in the envelope — they describe what the run actually enforced.
A worktree separates changes; it does not confine access to your filesystem. See security.
A completed run is not proof that the task is correct. The full retention, cleanup, and isolation contract is documented in thereliable delegation contractand the coder reference.