Keep the Context Where the Work Happens

The meme is exaggerated, but the workflow pain is not.

Two real requests from our own team shaped imdone-cli@0.73.0.

One came from people using imdone with AI coding agents.

The other came from someone trying to analyze Jira issue data in automation.

Different use cases. Same underlying problem: useful context still gets stuck in the wrong place.

Request 1: I want my agent skills from the repo root

A few teammates were using imdone with AI coding agents.

The imdone workflow skills lived under the backlog directory, which made sense from a local issue-management point of view. The backlog is where imdone stores Jira or GitHub issues as markdown files. It is also where the imdone-specific agent skills are installed.

But the people using those skills were often starting Claude or Codex from the software project root.

That is reasonable. The project root is where the rest of the codebase lives. It is where repo-local skills, scripts, tests, docs, and application context are most discoverable.

The problem was that starting the agent from inside backlog/ made imdone skills easy to find, but made other project-root skills harder to reach.

Starting the agent from the project root did the opposite.

That is the kind of friction that quietly kills a workflow. Nobody wants to remember which directory gives the agent which set of skills before they can start the actual work.

So 0.73.0 links imdone's AI workflow skills into the software project root for supported agents.

The canonical skill content still lives with the backlog. The project root gets symlinks under the agent skill directories, such as:

.codex/skills/
.claude/skills/

The goal is simple: start the agent where the code lives and still get the imdone workflow skills.

No duplicated skill content. No special launch ritual. No choosing between project skills and backlog skills.

Request 2: I want fresh Jira data without git

The second request came from a different direction.

A colleague wanted to use imdone in a Lambda to pull Jira issues and analyze them.

They were not trying to edit local issue files.

They were not trying to push changes back.

They did not need branch checks, stash/pop, commits, or merge-conflict protection.

They just needed fresh provider data for analysis.

Before this release, imdone pull assumed git coordination was part of the pull workflow. That is the right default for a local backlog workspace where people edit markdown files and sync changes back to Jira or GitHub.

But it is too much ceremony for a pull-only automation that only needs provider state.

So 0.73.0 adds:

imdone pull --no-git

That tells imdone: refresh provider-backed issue files, but intentionally skip the git coordination envelope for this run.

The command still runs the provider sync path. It still refreshes issues. It still makes the tradeoff visible in output.

What it does not do is pretend your local changes are protected by git while you are opting out of git coordination.

That explicitness matters.

--no-git is not a replacement for normal imdone pull.

Use normal imdone pull when you are in a local backlog workspace and want imdone to protect local issue-file changes with its usual git-safe workflow.

Use imdone pull --no-git when git is unavailable, unnecessary, or the wrong boundary for the job.

Why these belong in the same release

At first glance, repo-root skill discovery and imdone pull --no-git look unrelated.

One is about AI coding agents.

One is about provider refresh without git.

But they are both solving the same product problem:

Keep the context where the work happens.

For developers, the work often happens in the repo root, the editor, and the terminal.

For automation, the work may happen in a Lambda or scheduled process that wants issue data without becoming a full git-backed workspace.

Jira can remain the system of record.

Git can remain the coordination layer when people are editing local issue files.

But neither Jira nor git should be forced into workflows where they are not the active job.

What changed in 0.73.0

There are two practical changes in this release:

1. imdone links its bundled agent workflow skills into the software project root for supported agents.
2. imdone pull --no-git adds an explicit pull-only provider refresh path when you opt out of git coordination.

Both are small on purpose. They remove setup friction without changing the core idea: imdone keeps Jira or GitHub issue context available where developers and tools can actually use it.

What this looks like in practice

Start your agent from the project root

After setup or update, supported agent skill directories at the software project root can discover the imdone skills:

your-project/
├── .codex/
│   └── skills/
├── .claude/
│   └── skills/
├── backlog/
│   ├── .codex/
│   │   └── skills/
│   └── .claude/
│       └── skills/
└── src/

The root skill entries point back to the backlog-installed imdone skills.

That means the agent can start from the place where the code lives while still knowing how to work with imdone stories, issues, and workflow artifacts.

Pull provider data without git coordination

For pull-only jobs:

imdone pull --no-git

Use this when the job is to refresh provider issue data and git coordination is not the point.

Examples:

• scheduled analysis of Jira issues
• reporting jobs
• read-only automation
• environments where a git repository is unavailable or unnecessary

If you are editing local issue files or pushing updates back later, use normal imdone pull.

Upgrade

npm install -g imdone-cli

Then run the workflow that matches your job:

# Normal local backlog workflow
imdone pull

# Pull-only provider refresh without git coordination
imdone pull --no-git

Why I like this kind of release

Developer tools do not always need a huge feature to feel better.

Sometimes the useful thing is smaller:

• make the agent see the right skills from the place people already start it
• let automation pull provider data without pretending it is a full git workspace
• keep the warning and feedback path close to the command that creates the tradeoff

That is what 0.73.0 is about.

Jira and/or GitHub still gets to be the system of record.

The repo still gets to be where developers understand the work.

Automation still gets to consume issue data without dragging in coordination it does not need.

Try imdone-cli:
imdone.io/imdone-cli

If you use Jira or GitHub issues with AI coding agents, where does your issue context get stuck today?