Prefer to try it now?
Why this beats browser-first issue work
Works with the git workflow you already trust
Pull issue context into the repo, inspect it with grep and diffs, and keep working where the code lives instead of switching into a separate browser ritual.
Keeps Jira and GitHub in sync
Use markdown as the working surface, then push the update back so the system of record stays current without making the browser your main workspace.
Handles conflicts like normal code work
If both sides changed, imdone merge gives you an understandable exception path instead of a hidden sync mess.
Why developers start here
Stop hunting through Jira tabs for context
Pull issue content, comments, and attachments into the repo so you can inspect the whole story where you already work.
Update issues without breaking coding flow
Use your editor, grep, diffs, and git workflow instead of splitting one update across browser forms, chat, and notes.
Handle issue sync the same way you handle code work
Push one markdown update back to Jira or GitHub and keep the shared issue aligned without turning status updates into a second job.
The 5-minute workflow
Install and connect
Run these first, then point the repo at Jira or GitHub.
npm install -g imdone-cli
imdone initPull one real issue
Runimdone pullThen inspect one issue folder locally instead of reading it in the browser.
Edit and push one change
Make one markdown change, then runimdone pushIf the issue changed in two places, useimdone merge
What this should feel like after one real issue
You can see the whole story without a tab hunt
The issue, notes, comments, and attachments are in the repo instead of scattered behind another UI.
One markdown edit updates the shared issue cleanly
A small local change becomes one clean shared update after imdone push, without rewriting the same thought in two places.
If both sides changed, the exception path still makes sense
If both sides changed, the merge path feels familiar enough to trust instead of behaving like a hidden sync system.