The AI work was happening. The story wasn't capturing what we learned.

We went a whole day with people working on a story and almost no progress notes.

That isn't unusual on software teams.

Work happens.

People talk.

Someone starts another AI session.

Decisions get made.

Blockers get found.

A path changes.

But if the context doesn't land back in the story, the team has to reconstruct it later.

That was the problem that led to imdone ai.

Experiment log

• Trigger: a full day of real story work produced almost no progress notes.
• Hypothesis: a lighter AI entry point would capture more useful story context than asking every session to use the full HDD workflow.
• First evidence: after using the lighter path today, ORH-18 had 18 progress notes: 8 substantive work or decision notes, plus 10 auto-captured hook events.
• Next test: see whether another teammate can resume the story faster from the captured notes.

The moment that triggered it

I noticed there had been a full day of work on a story with no progress notes.

I knew people were working on it.

One teammate said he had started another "plate spinning" AI session on the story.

That phrase caught the problem perfectly.

AI sessions are easy to start. They are also easy to leave behind.

If the useful parts of that session stay in chat history, the next person has to rediscover them.

So I asked:

What if there was a lightweight version of imdone hdd?

Why not just use imdone hdd?

imdone hdd is the deeper workflow.

It is for problem framing, hypotheses, vertical slices, acceptance criteria, design, plans, implementation, measurement, and retrospective.

That structure matters when the team needs to define or prove an outcome.

But not every AI-assisted work session needs the full workflow.

Sometimes the developer already knows the story and just wants help from an agent without losing the thread.

That is the gap imdone ai fills.

What it does and doesn't do

imdone ai does:

• resolve or prompt for a local story
• save that story as active
• launch the selected coding agent when one is available
• tell the agent to read the local issue, comments, attachments, and progress notes
• give the session a clear path to record meaningful progress with imdone note

imdone ai doesn't:

• replace imdone hdd
• require the story to use the HDD template
• silently invent progress notes
• sync changes to Jira or GitHub without an explicit imdone push
• turn private chat history into a source of truth

The lightweight path

The command looks like this:

imdone ai SCRUM-371

It resolves the story, saves it as the active story, and starts the selected coding agent with instructions to read:

• the local issue file
• comments
• attachments
• attachments/progress-notes.md

When meaningful work happens, the session records it with:

imdone note SCRUM-371 "..."

That note goes into the story's progress notes, not into a private chat memory.

Those notes remain local until the team deliberately syncs them.

Why progress notes matter

Progress notes are where lightweight story context becomes durable.

The useful entries are usually small:

• a correction from the user
• a blocker
• a design decision
• a test result
• a completed slice
• a next step

If that context stays in the chat, the next session has to rediscover it.

If it lands in attachments/progress-notes.md, the story becomes easier to resume.

That helps the next human.

It also helps the next agent.

The story becomes the shared context surface instead of the chat transcript becoming another place to hunt.

The result

We started using imdone ai today on ORH-18.

The story had 18 progress notes dated today.

8 were substantive work or decision notes:

• Slice 7 feedback mechanism work landing complete
• Slice 8 plan reconciliation
• Section 508 acceptance criteria closure
• a dev-setup fix with npm run bootstrap
• code review findings and guardrail gaps

10 were auto-captured hook events.

That is the first signal.

Not "we launched an agent from a CLI."

The learning is more specific: a lighter entry point made it more likely that useful AI-session context was captured while the work was happening, and the hook events made gaps visible instead of invisible.

Now the next test is whether the next teammate can resume faster because the decisions, blockers, and corrections are already attached to the story.

That is the workflow I want more of:

• Jira or GitHub can stay the system of record
• the repo stays where developers work
• progress notes become the durable handoff trail
• AI sessions strengthen shared context instead of fragmenting it

The deeper lesson is simple:

AI can make coding faster, but teams still need shared context to make the work recoverable.

Launching an agent is easy.

Keeping the story current is what makes the session useful after the chat window closes.

Try the one-story experiment

If you want to test this on your own team, try it on one active Jira or GitHub story:

imdone ai YOUR-ISSUE-KEY

Then, tomorrow, open attachments/progress-notes.md and ask: could another teammate resume the work from this?

Try imdone CLI on one active story.