Write-back

Linear, Jira and GitHub triggers can report back to the issue at three moments. In the trigger editor, Write back to the issue has one row per moment:

Row	When	Stored as
Run starts	Right after the run is created	onStart
Succeeds	The run finished with status succeeded	onSuccess
Fails	The run finished failed or cancelled	onFailure

Each row has a Comment toggle and a transition box. New tracker triggers have Comment on for all three rows and no transitions. Schedule and webhook triggers don’t write back.

Comments

The start comment is:

👋 Jimothy started run #42 (Feature: Plan → Build → Review → PR).

The success/failure comment is a run summary:

✅ Jimothy run #42 succeeded (Feature: Plan → Build → Review → PR) in 18m 4s · $1.37
Branch: jimothy/eng-123
PR #57: https://github.com/acme/web-app/pull/57

✓ Plan
✓ Implement
✓ Run tests
✓ Cross-model review
✓ Human approval
✓ Open pull request

• The first line uses ✅ for success, ⏹️ for cancelled and ❌ for failed, and includes duration and cost when known.
• Branch: appears if the run has a branch.
• One line per link Jimothy found in step outputs: GitHub pull requests (PR #57), GitLab merge requests (MR !12), Bitbucket pull requests, and *.vercel.app previews (Preview).
• One line per step: ✓ succeeded, ✗ failed (with the first 200 characters of the error), – skipped, ⏹ cancelled.

On Jira Cloud the text is converted to Atlassian Document Format; on Linear and GitHub it’s posted as Markdown.

Transitions

The transition box’s meaning depends on the platform:

Platform	Hint in the editor	What the value means
Linear	Move to status (e.g. In Review)	A workflow state name in the issue’s team, matched case-insensitively.
Jira	Move to status (e.g. In Review)	A transition name or target status name, matched case-insensitively against the transitions currently available for the issue.
GitHub	Close issue or add label (e.g. closed, jimothy:done)	closed closes the issue, open reopens it, anything else adds a label.

When a row has both, the comment is posted first, then the transition.

A typical setup

Row	Comment	Linear / Jira transition	GitHub transition
Run starts	on	In Progress	jimothy:running
Succeeds	on	In Review	jimothy:done
Fails	on	Todo (or leave empty)	jimothy:failed

Pair the start transition with a trigger filter that excludes the target state, so the issue leaves the filter as soon as work starts.

When write-back fails

Write-back never affects the run itself. If a comment or transition fails, the error is recorded on the trigger (the Triggers page shows it in red and the Dashboard marks the trigger error) and sent as a Trigger errors notification:

Write-back to ENG-123 failed: Linear workflow state "In Reveiw" not found
Write-back to WEB-45 failed: No Jira transition to "In Review" (available: In Progress, Done)
Write-back to web-app#42 failed: HTTP 403 Forbidden from api.github.com: …

Common causes:

• Typos in state names. Linear needs an existing state name in that issue’s team.
• Jira workflow rules. Only transitions valid from the issue’s current status are available. A transition that works from To Do may not exist from In Progress. The error lists what was available.
• Read-only credentials. Comments and transitions need write access: Linear key with Write, Jira Add comments / Transition issues, GitHub Issues: Read and write.
• The account was removed or changed platform. Triggers need an account of the same platform.

The next successful poll clears the error.

Write-back and “Run again when updated”

Comments and transitions update the issue, which changes its “updated” timestamp. With Run again when a processed issue is updated turned on, Jimothy’s own write-back can make an issue look updated and start another run after the previous one finishes. Use re-triggering only with filters the issue leaves after a run (for example a state or label change), or turn off comments.