There’s a moment I’ve seen over and over again on software teams.

Now the work is spread across your editor, Jira or GitHub, browser tabs, screenshots, and memory.

The problem isn’t just that this takes a few minutes.

The real cost is that you lose the thread of the work. You stop moving forward and start rebuilding context.

This matters even more with coding agents, because they work better when the issue, comments, attachments, and code context live together instead of being scattered across browser tabs and tools.

That’s the workflow problem I’ve been trying to solve with imdone-cli.

The workflow problem

The idea behind imdone is simple:

• Pull issues into your repo as markdown
• Keep comments and attachments close to the code
• Make story work easier to inspect, edit, grep, hand off, and pick back up later
• Keep Jira or GitHub as the system of record without forcing developers to live there all day

What I learned from the old free tier

What I learned, though, is that I had another problem.

The old free tier got in the way too early.

People could try a little bit of the workflow, but not enough to honestly answer the real question:

Does keeping issue context closer to the code actually make work easier to move forward?

That meant the limit was blocking evaluation before people reached the real value moment.

What changed

That’s why I changed the free tier.

You can now try imdone-cli on real work without creating an account first, keep reading and local workflow free, and use the allowance when you write changes back to Jira or GitHub.

The goal is not to create a clever pricing trick.

The goal is to let people actually reach the value moment before they hit a wall.

Why this matters

If you work in Jira or GitHub and you’re tired of rebuilding context from comments, attachments, and scattered tabs, that’s the workflow I’m trying to improve.

If you want to try it:

https://www.npmjs.com/package/imdone-cli

And if you do, I’d genuinely like to hear where it helps and where it breaks.