DEV Community: Jesse Piaścik

The Shared Context Problem Is Slowing Your Team Down

Jesse Piaścik — Tue, 17 Mar 2026 15:13:31 +0000

I don't think most teams are slowed down by lack of effort.

I think they're slowed down because the context for the work is scattered.

The task is in Jira.
The decision is in a doc.
The code is on a branch.
The AI prompt that explains the reasoning is in chat history somewhere.

Everything exists.
But not in one place where the next person can actually use it.

So every handoff starts with reconstruction.

What were we trying to do?
Why did we make that tradeoff?
Which branch has the latest version?
Where did that decision happen?

I've been noticing this more and more as I work with AI.

At first I thought AI would reduce the need for documentation and coordination. Instead it made the problem easier to see.

If the context is stale, incomplete, or spread across five tools, the output drifts.

That is true for AI.
And it's true for teams.

That's the shared context problem.

The Problem Isn't Just Missing Information

Most teams don't actually have a shortage of information.

They have a shortage of shared, current, easy-to-find information.

That's a different problem.

I've seen this over and over:

the story is technically written down, but the real reasoning lives in comments
the latest implementation details are only visible on a feature branch
the best explanation of the problem lives in an AI prompt that nobody else can see
a key decision was made in chat and never made it back into the work itself

So when someone else picks up the task, they have to reconstruct the thought process before they can move forward.

That reconstruction work is expensive. It slows down handoffs, reviews, onboarding, and AI-assisted development.

The Workarounds I've Seen

Most teams know this is a problem, so they try to patch around it.

Keep the context in the repo

This is usually the first instinct, and honestly, I think it's directionally right.

Keeping context near the code is better than keeping it in a detached system no developer wants to live in all day.

But if the context lives in the main repo, another problem shows up fast:

Which branch has the latest version?

If the plan changed on a feature branch, the rest of the team has to know that branch exists. If multiple branches each have part of the story, then the source of truth depends on knowing where to look.

That works for one developer who remembers everything.
It breaks down for a team.

Keep the context in another repo

I've seen teams try this too.

The idea is clean: separate the context from the product repo so it doesn't interfere with the codebase.

But now every meaningful context update becomes its own coordination problem.

You need context PRs.
You need someone to review them.
You need to wait for them to merge.

So instead of making context easier to maintain, you create a second workflow around maintaining the workflow.

That overhead adds up quickly.

Leave it spread across tools

This is where most teams end up by default.

A little in Jira.
A little in GitHub.
A little in Notion.
A little in Slack.
A little in AI prompts.

People can usually find enough to keep moving, but not without friction.

And friction compounds.

What AI Made Obvious to Me

Working with AI made this problem impossible for me to ignore.

When an AI assistant gets a bad prompt, incomplete files, or missing constraints, the result is usually disappointing. Not because the model is useless, but because the context is weak.

That reminded me of how humans work too.

We expect teammates to make good decisions with partial tickets, outdated notes, and disconnected artifacts. Then we're surprised when they miss the intent.

AI didn't create the shared context problem.
It just exposed it more clearly.

What I Actually Want

I want the context for the work to be:

close to the code
visible to the team
easy to update while working
available to AI
tied to the task, not floating in some disconnected place

In other words, I want the "why," the "what," and the supporting artifacts to travel with the work itself.

That's the idea behind what I've been building with imdone.

How imdone Helps

imdone turns Jira and GitHub issues into a shared context repository next to the code.

That means the issue, comments, attachments, plans, and working notes can live in a local structure that developers can open in their editor and work with directly.

For me, that's a much better model than treating Jira like a separate universe you visit in the browser.

It keeps context close at hand.
It makes it easier to update while the work is happening.
And it gives AI access to the same local context the team is using.

I've also been pairing that with hypothesis-driven workflows, where each story captures:

the outcome we're trying to create
the hypothesis behind it
the success metrics
the design and plan
the demo path

That structure helps both humans and AI stay grounded in the same goal.

To me, that's the real opportunity here.
Not just better issue management.
Better alignment.

Why This Matters

I don't think most teams are blocked because they lack tools.

I think they're blocked because too much of the reasoning around the work is fragmented.

When the context is shared and current:

handoffs are easier
reviews are faster
AI is more useful
product decisions stay connected to implementation
the team spends less time reconstructing and more time building

That's a meaningful shift.

A Simple Test

If your team has ever asked:

"Which branch has the latest plan?"
"Where did we decide that?"
"Can you send me the prompt you used?"
"Why did we do it this way?"

...then you're already feeling the shared context problem.

The question isn't whether the context exists.

The question is whether the whole team, and your AI tools, can see the same current version of it without hunting for it.

If not, it's probably time to change the workflow.

If you want to see how I'm approaching this, take a look at imdone.io.

Fast Delivery Isn't Enough. You Need Fast Feedback.

Jesse Piaścik — Thu, 05 Mar 2026 13:34:13 +0000

It's demo day. Claude Code knocked out the data layer migration in two days. So the team pulled in more backend work—cleaner API contracts, better abstractions. Might as well use the time.

The product manager asks: "So what can users do now that they couldn't do before?"

Silence.

"Nothing yet. But the next feature will be way faster to build."

She nods. You can tell she's already thinking about how to explain this to stakeholders.

A full sprint of AI-accelerated work. Users have seen nothing. Feedback: zero. And you're moving faster than ever—on top of assumptions you've never validated.

The Real Constraint Isn't Coding Speed

Your developers can now code faster with AI coding assistants. That's incredible. But faster coding doesn't automatically lead to better products.

The real waste in software development isn't slow coding—it's building the wrong product or feature.

As Marty Cagan from Silicon Valley Product Group puts it:

"The biggest waste in software development is building the wrong product or feature."

Think about it:

Spending 3 months building a feature users don't want
Shipping a "complete" solution only to discover it solves the wrong problem
Building all of Feature A when users only needed 20% of it

Speed amplifies this risk. The faster you can code, the more time you can waste building the wrong thing.

The Solution: Break Stories into Vertical Slices

The answer isn't just faster coding—it's faster learning.

Break your epics into vertical slices: thin, end-to-end features you can ship, test, and learn from quickly.

What's a Vertical Slice?

A vertical slice delivers complete value through all layers of your system:

It touches UI, backend, database—everything
It's deployable independently
It solves a real user problem (even if minimally)
It enables you to learn whether you're on the right track

Instead of:

Sprint 1: Build entire backend (no user feedback yet)
Sprint 2: Build entire frontend (still no user feedback)
Sprint 3: Integration (finally users can try it)
Sprint 4: Discover it's not what they wanted

Do this:

Sprint 1: Ship smallest end-to-end version (get feedback immediately)
Sprint 2: Iterate based on real user feedback
Sprint 3: Add next most valuable slice
Sprint 4: You've validated direction and built only what's needed

Why This Matters with AI Coding

When issues live as markdown files in your repo (instead of buried in Jira's UI), you can use AI coding assistants to help refine your stories before you build them.

Ask your AI:

"Break this epic into vertical slices that deliver value incrementally"
"What's the smallest end-to-end feature we could ship to validate this?"
"Identify the walking skeleton for this story"

The AI can analyze your story structure and suggest slices that enable fast feedback loops.

Tighten Your Feedback Loop

Kent Beck (creator of Extreme Programming) has a principle worth adapting to product work:

"Make the change easy, then make the easy change... This is true for product work too: make feedback easy, then make the easy improvement."

When your issues are markdown files next to your code:

AI can help you refine them before development starts
You ship in days, not weeks
You learn what works before investing months
You pivot quickly based on real user feedback
You reduce waste from building unused features

The result? Smaller batches, faster feedback, better products.

Speed + Direction = Value

Charles Darwin's principle applies to software teams:

"It is not the strongest of the species that survives... It is the one that is most adaptable to change."

Fast coding is strength. But adaptability comes from fast feedback.

Combine them:

Ship small vertical slices (days, not sprints)
Get real user feedback quickly (not after months)
Learn and adapt (before you've built too much)
Iterate based on what users actually need (not assumptions)

That's how you turn coding speed into product value.

Practical Next Steps

Want to enable faster feedback loops on your team?

Review your current stories: Are they vertical slices or horizontal layers?
Break one epic into slices: What's the smallest end-to-end version you could ship this week?
Use AI to help: If your issues are in markdown, ask Claude or GPT to suggest vertical slices
Ship and learn: Deploy the smallest slice, get feedback, iterate

The teams that win aren't the ones that code fastest. They're the ones that learn fastest.

What's your experience with vertical slicing or fast feedback loops? Drop a comment below—I'd love to hear how your team balances speed with learning.

If you found this useful, give it a ❤️ and follow me for more posts on developer productivity, AI-assisted development, and building better products.

This article is part of a series on context-driven development and enabling adaptive teams. Learn more at imdone.io.

Stop Context-Switching: Edit Jira Attachments Like Code (Imdone CLI 0.39.0)

Jesse Piaścik — Thu, 19 Feb 2026 13:09:02 +0000

The Problem: You're deep in flow. You need to update a screenshot in a Jira issue. Now you have to:

Stop what you're doing
Find the issue in your browser (which tab was it?)
Scroll to attachments
Upload the new version
Delete the old version
Try to remember what you were doing

10 minutes gone. Flow state destroyed.

What if attachments were just... files?

That's what Imdone CLI 0.39.0 does. Attachments live in your repo alongside your code. Edit them like any other file. Push changes like you push code.

The New Workflow

Before: The Browser Dance 💀

# You're working on PROJ-123
vim src/auth.js
# "Oh, I need to update that architecture diagram..."

# Switch to browser
# Open Jira
# Find issue PROJ-123
# Scroll down... down... down to attachments
# Click "Attach files"
# Find the file on your computer
# Upload
# Wait for upload
# Scroll back to attachments
# Click delete on old version
# Confirm deletion
# Finally, back to your editor

# What was I doing again?

After: Stay in Your Workflow ✨

# You're working on PROJ-123
vim src/auth.js
# "Oh, I need to update that architecture diagram..."

# Edit the diagram right there
open backlog/current-sprint/PROJ-123/attachments/architecture.png
# Make your changes, save

# Push to Jira
imdone push
# ✓ Updated: PROJ-123/architecture.png (256KB)

# Back to coding
vim src/auth.js
# Flow unbroken

What's New in 0.39.0

1. Modify Attachments

Edit a file locally. Push syncs the new version to Jira and deletes the old one.

imdone pull
# Edit the file
vim backlog/current-sprint/PROJ-123/attachments/screenshot.png
# Push changes
imdone push
# ✓ Updated: PROJ-123/screenshot.png (125KB)

Safety First: Uses an upload-then-delete pattern. If the upload fails, your old version is preserved in Jira. No data loss on network failures.

2. Delete Attachments

Remove a file locally. Push deletes it from Jira.

rm backlog/current-sprint/PROJ-123/attachments/old-design.pdf
imdone push
# ✓ Deleted: PROJ-123/old-design.pdf

3. Rename Attachments

Rename a file. Push handles the cleanup automatically.

cd backlog/current-sprint/PROJ-123/attachments/
mv draft-v1.png final-design.png
cd -
imdone push
# ✓ Renamed: PROJ-123/draft-v1.png → final-design.png

Behind the scenes: Deletes old attachment from Jira, uploads the renamed file as new.

4. Add New Attachments

Drop a file in the attachments folder. Push uploads it.

cp ~/Desktop/error-log.txt backlog/current-sprint/PROJ-123/attachments/
imdone push
# ✓ Added: PROJ-123/error-log.txt (45KB)

Technical Deep Dive

Git-Aware Detection

The tricky part: Imdone CLI runs imdone pull before imdone push to ensure you're synced. But the pull operation includes a git stash/pop cycle:

User deletes attachment locally
Push calls pull
Pull stashes the deletion
Pull fetches from Jira (might re-download the attachment!)
Pull pops the stash
Push needs to detect the deletion

Solution: Capture git status before the pull operation. Use that pre-analyzed status to detect deleted/renamed attachments, even if pull re-downloaded them.

// Capture status before pull
const preAnalyzedStatus = await status(projectPath, [defaultDirectory]);

// Pull from Jira (might re-download deleted attachments)
await pull({ ...deps, providerPlugin });

// Use pre-analyzed status to detect deletions
const { result } = await _push({ ...deps, preAnalyzedStatus });

Upload-Then-Delete Safety

When modifying attachments, the order matters:

async function replaceAttachment(issueKey, oldAttachmentId, newFilePath) {
  // 1. Upload first
  const newAttachment = await uploadAttachment(issueKey, newFilePath);

  // 2. Only delete if upload succeeded
  try {
    await deleteAttachment(oldAttachmentId);
  } catch (error) {
    logger.warn(`Uploaded new but failed to delete old: ${error}`);
    // User has duplicate in Jira, but no data loss
  }

  return newAttachment;
}

If the upload fails, the old version stays in Jira. No data loss.

Metadata Tracking

Attachments are tracked in .metadata.yml files:

attachments:
  "12345":
    id: "12345"
    filename: "screenshot.png"
    localPath: "screenshot.png"
    size: 45678
    lastModified: "2026-01-15T10:30:00Z"

This enables:

Detecting which files are new vs. modified
Mapping local files to Jira attachment IDs
Avoiding unnecessary re-downloads on pull
Cleaning up orphaned attachments

Getting Started

Installation

npm install -g imdone-cli@0.39.0

Basic Workflow

# Initialize in your repo
imdone init

# Pull issues and attachments
imdone pull

# Your attachments are now local files:
# backlog/
# └── current-sprint/
#     └── PROJ-123/
#         ├── attachments/
#         │   ├── screenshot.png
#         │   ├── error-log.txt
#         │   └── .metadata.yml
#         └── issue-PROJ-123.md

# Edit any attachment
open backlog/current-sprint/PROJ-123/attachments/screenshot.png
# (make your changes)

# Push changes back to Jira
imdone push
# ✓ Updated: PROJ-123/screenshot.png (125KB)

Full Feature Demo

# Pull latest
imdone pull

# Add a new attachment
cp ~/Desktop/architecture.png backlog/current-sprint/PROJ-456/attachments/

# Modify an existing one
vim backlog/current-sprint/PROJ-123/attachments/bug-report.txt

# Rename another
mv backlog/current-sprint/PROJ-789/attachments/draft.pdf backlog/current-sprint/PROJ-789/attachments/final.pdf

# Delete an outdated one
rm backlog/current-sprint/PROJ-111/attachments/old-screenshot.png

# Push all changes at once
imdone push
# ✓ Added: PROJ-456/architecture.png (256KB)
# ✓ Updated: PROJ-123/bug-report.txt (12KB)
# ✓ Renamed: PROJ-789/draft.pdf → final.pdf
# ✓ Deleted: PROJ-111/old-screenshot.png

Why This Matters

Attachments belong with your code, not in browser tabs.

When you're fixing a bug, you need:

The code
The issue description
The error logs
The screenshots

Having them scattered across your IDE and browser is cognitive overhead. Having them all in your repo, in the same directory, is flow.

Architecture

Imdone CLI gives you:

your-repo/
├── src/               # Your code
│   └── auth.js
├── tests/             # Your tests
│   └── auth.test.js
└── backlog/           # Your issues (WITH attachments)
    └── current-sprint/
        └── PROJ-123/
            ├── issue-PROJ-123.md         # Issue content
            ├── comments-PROJ-123.md      # Discussion
            └── attachments/              # Files
                ├── error-log.txt
                ├── screenshot.png
                └── architecture.png

Everything in one place. Edit anything. Push to sync.

Try It

npm install -g imdone-cli@0.39.0
imdone init
imdone pull

Two-way sync for Jira issues, comments, and attachments.
All as Markdown and files in your repo.
All in your editor.

Because your best work happens in your editor, not your browser.

Links:

npm package

What's your biggest Jira workflow pain point? Drop it in the comments. 👇

Context-Driven Development Experiment 4: Normalizing CLI Commands with Claude Code and TDD

Jesse Piaścik — Tue, 27 Jan 2026 02:17:32 +0000

Every week, I run small experiments with context-driven development (CDD), AI tools, and imdone-cli - a tool I built that keeps your backlog right in your source code so you never lose context.

This week, I'm putting Claude Code to the test on a critical developer experience improvement: normalizing imdone-cli commands to follow Git-like conventions. When CLI tools have inconsistent argument patterns, developers waste mental energy figuring out syntax instead of solving problems.

Why CLI Consistency Matters

As imdone-cli evolved, command arguments became inconsistent. The template command required verbose options:

imdone template --issue-key SCRUM-123 --template bug

But developers expect familiar Git-like patterns:

git commit -m "message"     # Positional arguments
imdone template SCRUM-123 bug  # Much cleaner

This inconsistency creates cognitive friction. By normalizing to Git conventions, we reduce mental overhead to zero.

The Context-Driven Development Approach

I structured this task using templates in Imdone:

Goal: Normalize the template command to use positional arguments, accept them in any order, and provide intuitive aliases.

Constraints:

Use TDD with red-green-refactor cycle
Follow de facto CLI standards (Git-like)
Update documentation automatically
Don't break existing functionality

Files: Links to entry point, test files, and command patterns.

This template-based approach means I can quickly spin up well-structured tasks. Just type $ in VS Code with the Imdone extension, select my template, and I have a complete spec ready for Claude.

The Development Journey

01:46 - Template-Based Setup

I demonstrated my workflow using Imdone templates to structure AI tasks. The spec lives as markdown synced with Jira, so teammates see the same information without context-switching.

Lesson learned: File linking requires a leading slash (/cli-package/src/bin.mjs) for proper navigation.

03:05 - Handling Merge Conflicts

When I ran imdone push to sync updates, I hit a merge conflict. imdone-cli handles this with git-like merge resolution:

imdone push    # Triggers conflict
imdone merge   # Completes merge

Key feature: Multiple team members can work on the same issue simultaneously - something Jira doesn't allow.

07:11 - Claude Implements TDD

I prompted: "Execute the task on line 21." That's it. Claude understood everything from the context file.

While Claude worked, I explained my .claude/rules folder where I keep context files for homepage strategies, pair programming experts, and writing constraints. These ensure Claude has domain knowledge about my projects.

Claude generated comprehensive tests:

describe('template command', () => {
  it('should apply template to existing issue', async () => {})
  it('should work with alias t instead of template', async () => {})
  it('should accept issue and template in any order', async () => {})
})

10:35 - Teaching Red-Green-Refactor

Initial tests passed when they should have failed - Claude implemented everything at once instead of following TDD discipline.

This is a common AI mistake: They're too helpful and skip the red phase.

I added: "Use red-green-refactor cycle. Tests should fail before implementation."

After some back-and-forth, Claude understood. It wrote failing tests first, confirmed they failed, then implemented the feature.

13:04 - Tests Failing (Good!)

npm test
❌ should accept issue and template in any order
❌ should work with alias t

Perfect. This is exactly what we want in TDD.

13:28 - Implementation

Claude updated the command structure:

// Old way
.option('--issue-key <key>', 'Issue key')
.option('--template <name>', 'Template name')

// New way (positional arguments)
.argument('[issue]', 'Issue key')
.argument('[template]', 'Template name')
.alias('t')

Clean, logical, and follows commander.js conventions.

16:45 - All Tests Pass

✅ All 14 tests passing

The command now follows Git patterns:

# Before (awkward)
imdone template --issue-key SCRUM-123 --template bug

# After (Git-like)
imdone template SCRUM-123 bug
imdone t SCRUM-123 bug  # with alias

19:00 - Proactive Analysis

Without prompting, Claude suggested: "Would you like me to normalize the update command? It uses --force without a corresponding -f short option."

This kind of codebase-wide pattern recognition is where AI assistants shine.

24:42 - Manual Testing Success

npm run build
npm link
imdone template SCRUM-138 story

The command accepted positional arguments and felt natural - no mental friction about syntax.

Key Takeaways

What Worked Well

Template-Based Specs: Having a reusable template with files, goals, and constraints meant Claude had everything upfront. No back-and-forth.

TDD Discipline: Once Claude understood red-green-refactor, it followed perfectly. Tests documented desired behavior, failed appropriately, then passed after implementation.

Proactive Pattern Recognition: Claude spotted other commands needing normalization without being asked.

Challenges and Real-World Friction

AI Over-Helpfulness: Initially, Claude implemented features while writing tests instead of following TDD. Required explicit guidance about red-green-refactor.

Test Philosophy Confusion: Claude initially wrote test descriptions mentioning "should fail" rather than describing desired behavior. Took iteration to clarify.

Waiting Time: Moments where you're just waiting for AI to generate code (30-60 seconds) - enough to break flow slightly.

When to Use AI Assistants for Refactoring

AI coding assistants excel at:

Following established patterns across a codebase
Writing comprehensive tests for new behavior
Updating documentation consistently
Spotting similar patterns elsewhere

They need guidance with:

TDD discipline (will skip red-green-refactor if not reminded)
Understanding test philosophy
Making architectural decisions

The Bigger Picture: Developer Experience

Consistency reduces cognitive load.

When every CLI tool invents its own syntax, developers spend mental energy on syntax instead of problems. When tools follow de facto standards (Git, npm, docker), they feel immediately familiar.

This is what imdone-cli enables more broadly: keeping context (backlog, decisions, discussions) right next to code reduces context-switching overhead. Same principle, different domains.

Try It Yourself

Install imdone-cli: npm install -g imdone-cli
Set up templates: Create templates in .imdone/templates/ for common patterns
Structure AI tasks: Include goals, constraints, and file references
Use TDD explicitly: Specify "red-green-refactor" in constraints
Iterate and learn: AI assistants need guidance around testing discipline

What's Next?

Upcoming features:

Favorites system: Organize large issue lists into folders (requested by my 40-person team)
Desktop integration: Open Imdone Desktop from CLI
Maybe ensemble programming with Claude as part of the team?

Join the Conversation

Have you normalized CLI commands in your projects? Used Claude Code for refactoring?

Drop a comment below with:

Patterns you've discovered for teaching AI assistants about TDD
CLI design decisions you've made (or regretted)
How you structure tasks for AI coding assistants

If you found this useful, give it a ❤️ and follow me for weekly experiments at the intersection of AI, developer experience, and better tooling.

Video Timeline

00:00 - Introduction to weekly CDD experiments
00:16 - Decision to normalize CLI commands
01:46 - Setting up with Imdone templates
03:05 - Handling merge conflicts
07:11 - Claude implements with TDD
10:35 - Teaching red-green-refactor
13:04 - Tests failing (good!)
13:28 - Implementation passes tests
16:45 - All tests green
19:00 - Claude suggests more improvements
24:42 - Manual testing success
26:16 - Planning next release
28:06 - Preview: favorites feature

This post is part of my weekly context-driven development experiment series. Check out previous experiments and follow along as I explore better ways to build software with AI assistance.

My 2026 resolution: stop picking Jira resolutions

Jesse Piaścik — Wed, 31 Dec 2025 16:06:03 +0000

TL;DR: In Jira, Status and Resolution are different fields. Depending on your workflow, Jira may prompt you for a resolution… or it may not. That’s how teams end up with issues that are Done but still Unresolved. I shipped a small fix in imdone-cli 0.28.0 so moving to Done doesn’t require another decision.

It’s amazing how many developer interruptions come from tiny “paper cut” fields.

This one shows up right when you’re trying to wrap up work.

You do the right thing: move the issue to Done.

And then… you’re suddenly staring at a drop-down asking you to pick a Resolution.

Or worse: you don’t get asked, you assume it’s fine, and later someone says “why is this still unresolved?”

Same feeling either way: you were finishing the work, and Jira found one last way to pull you out of the zone.

Status vs Resolution (the thing nobody explains clearly)

Jira separates two concepts that many teams treat like one:

Status: where the issue is in the workflow (To Do → In Progress → Done)
Resolution: why the issue ended (Fixed, Won’t Fix, Duplicate, etc.)

That means this state is totally possible:

status = Done
resolution = Unresolved

And it’s not just “cosmetic.” It leaks into dashboards, filters, and sometimes workflow rules.

The nuance: Jira doesn’t always prompt you

This is where people talk past each other:

“Jira always prompts you for a resolution.”

“No it doesn’t.”

Both can be true, because prompting is not a universal Jira behavior. It’s workflow configuration.

In the wild you’ll find all three:

Prompting

The transition screen includes a Resolution field, so Jira asks you to pick one.
Auto-setting

A post-function or automation sets Resolution behind the scenes. No prompt.
Not set at all

No prompt, no automation, no post-function… and you end up Done + Unresolved.

If you’ve got multiple projects, inherited workflows, or “just one tweak” done years ago, you can end up with inconsistent behavior across boards.

Why it matters (even if you hate dashboards)

This mismatch creates a bunch of low-grade pain:

1) “Resolved” reporting gets weird

Some reports/gadgets treat “resolved” as “has a resolution,” not “is in Done.”

2) JQL starts lying to you

People write filters like “show me unresolved issues,” and Done issues sneak in. Or you filter for Done work and a chunk is still “unresolved.”

3) Transitions get blocked on some projects

Some teams add validators that require resolution on the Done transition. Others don’t. So developers get different friction depending on which project they’re working in.

Quick check: do you have “Done but Unresolved” issues?

Try a query like this (tweak project key and status names):

project = PROJ AND statusCategory = Done AND resolution = Unresolved

If your instance doesn’t support statusCategory, try something like:

project = PROJ AND status in (Done, Closed) AND resolution = Unresolved

If either query returns results, you’ve got the footgun in your workflow somewhere.

How teams usually fix it (in Jira)

The standard fixes are all admin-side:

Add a post-function to set Resolution on Done transitions
Add a validator requiring Resolution before the transition can complete
Add automation: “when status category becomes Done, set resolution (if empty)”

Those can work great.

But they also tend to fail in the exact way “paper cuts” fail:

it’s different per project
it’s easy to forget which workflows have what
it requires admin attention
edge cases happen and you’re back to manual cleanup

Scratching an itch (the developer-side fix)

So here’s the thing: the path developers use the most should be the path that’s hardest to mess up.

Moving an issue to Done is a “closing ritual.” It should be quick, consistent, and not require one more decision unless you explicitly want it.

That’s what I shipped in imdone-cli 0.28.0.

What changed in 0.28.0

When you move an issue into a Done status category, imdone-cli will:

automatically set Resolution = "Done" if the issue has no resolution
never overwrite an existing resolution
stay non-blocking: the move succeeds even if resolution setting fails
only attempt this when moving to a status in the Done category

In other words: move it to Done and keep coding.

Commands

Default behavior (automatic)

imdone move PROJ-123 Done

Set a specific resolution

Sometimes you do want to be explicit:

imdone move PROJ-123 Done -r "Fixed"

Skip resolution entirely

If your Jira workflow already handles it, or you want to leave it alone:

imdone move PROJ-123 Done --no-resolution

Prompt me (interactive)

If you want a choice, make it a choice:

imdone move PROJ-123 Done -p

The interactive mode:

fetches available resolutions from the Jira API (with descriptions)
includes a Skip option
falls back to common resolutions if the API call fails

The real point: fewer interruptions

This isn’t about being “more compliant with Jira.”

It’s about removing one of those tiny context switches that happen right at the end of a work loop.

If your Jira already prompts or auto-sets resolution, great. But if you’ve ever been bitten by:

“why is this still unresolved?”
“why didn’t that chart move?”
“why did this transition fail on this project but not that one?”

…this is a small, practical way to make “Done” mean what developers think it means.

Question for you

On your team, does Jira:

prompt for resolution
auto-set it
or ignore it entirely?

I’m genuinely curious how common each setup is across real teams.

Docs for the move command (all options + details):
https://www.npmjs.com/package/imdone-cli#user-content-move--move-issue-to-new-status

It's in Jira. Somewhere.

Jesse Piaścik — Tue, 16 Dec 2025 02:30:48 +0000

4:45pm Friday.

You need that screenshot from three weeks ago.

It's in Jira. Somewhere.

You open 6 tabs.
Check 4 different projects.
Scroll through 20 comments.
Download 3 files to check which one it is.

15 minutes later, you finally find it.

By then, you've forgotten why you needed it.

Sound familiar?

What's your record for "time spent hunting for a thing you KNOW exists in Jira"?

Lab Notes: What I Learned Dropping Imdone’s Price for a Week

Jesse Piaścik — Thu, 11 Dec 2025 13:37:29 +0000

Last week I ran a small pricing experiment for imdone-cli and imdone desktop and told my list I’d share the results.

These are the lab notes.

If you just want the punchline:

Dropping the solo price from $18 to $9 helped, but the real problems are messaging and onboarding, not just dollars.

The hypothesis

Quick recap: imdone-cli and imdone desktop let you work with Jira issues as markdown files in your repo:

Pull issues, comments, and attachments into your project
Edit them in your editor or terminal
Push changes back to Jira

The core idea is: “Work Jira like code.”

Before the experiment, the price for individuals was:

$18/user/month

Signals I was seeing:

A steady trickle of pricing page visits
Almost no conversions at $18

So the hypothesis was simple:

“If I cut the solo price in half, do more individual developers actually pull the trigger?”

The experiment setup

For one week I:

Dropped the personal price from $18 → $9/month
Left team pricing at $18/user/month
Kept the homepage mostly the same so I didn’t change too many variables at once

The only intentional change at the decision point:

“You can get this for $9/month as a solo developer.”

No coupons, no bundles, no big launch. Just a price change.

The results

In the first ~24 hours:

2 new paying customers signed up at $9/mo
That was more movement than I’d seen in the entire previous month at $18
Traffic looked similar; behavior at the point of decision changed

So:

Price did matter for solo devs
But lowering it didn’t suddenly unlock a huge wave of adoption

It was enough signal to make decisions, not enough to declare “pricing solved everything.”

What I’m keeping (and what I’m not touching)

✅ $9/month stays as the Personal License

The experiment confirmed what I suspected:

Individual devs are more price sensitive
$18/mo feels like “team tool” pricing
$9/mo feels like “personal workflow upgrade” territory

So $9/month stays as the personal plan.

✅ $18/user/month stays for teams

Teams behaved differently:

Existing team customers haven’t pushed back on $18
They see imdone as DevEx / workflow infrastructure
They care more about context and time than a few extra dollars

The experiment didn’t touch team pricing, and I’m not going to “race to the bottom” there.

So $18/user/month stays for teams.

Solo and team are now deliberately priced as two different markets.

Where the real bottleneck is

If you drop the price and don’t see a flood of new users, it usually means:

People don’t fully understand what the product actually does
It’s hard to picture how it fits into their current workflow
First-time setup feels heavy or risky
Time-to-first-value is too long

That’s what this experiment exposed.

So my next focus is:

Tightening the homepage copy around the core idea: “Your backlog lives in your repo, not your browser.”
Making it easier to go from “curious” → “first Jira pull into markdown”
Smoothing out docs and defaults so setup feels safe and fast

Price was friction, but not the friction.

Takeaways if you’re building dev tools

A few lessons I’d pass on:

You don’t need a huge experiment to learn something.

One week and one variable was enough to get real signal.
Price is rarely the final boss.

Dropping from $18 to $9 helped solo devs, but it didn’t magically fix adoption. It just revealed the next constraint.
Solo devs and teams really are different markets.

One feels $9 vs $18 personally; the other feels “how much context and time are we wasting?”
If you call it an experiment, close the loop.

Sharing what happened builds more trust than silently changing a number in Stripe.

If you’re curious about imdone

If you’re a solo dev who:

lives in Jira all day
keeps losing context between browser and editor
wants screenshots, comments, and “why we did this” next to the code

…the $9/month personal plan is now the default.

If you’re on a team and want to pilot this with a few developers, that’s where team pricing comes in — and that’s usually where the biggest impact shows up.

If you’ve tried imdone and hit friction, I’d genuinely love to hear what slowed you down. That’s exactly what I’m working on next.

👉 https://imdone.io/plans

Early Access Pricing for imdone-cli & Desktop (Developer Pricing Experiment)

Jesse Piaścik — Tue, 25 Nov 2025 04:56:25 +0000

Hey folks 👋 — short post.

I've been working on imdone-cli and imdone desktop, workflow tools that let you manage Jira issues as markdown files directly in your project repo.

A lot of developers have checked out the pricing page lately, but no one was converting at the $18/month price point. Some have tried the free plan but hit the wall when they need attachments and comments — that's where the real context lives.

So I'm running a very short pricing experiment starting December 1st for one week:

$9/month for single developers (normally $18)

Same features. Same workflow. Full access to attachments, comments, and everything else.

What problem does this solve?

Ever lose 20 minutes hunting for that Jira comment that explained why something was built a certain way?

Or spend half your sprint context-switching between your IDE, browser tabs, and Jira just to understand what you're supposed to be working on?

That fragmented context kills momentum.

imdone-cli and imdone desktop help you:

Build with clear, de-fragmented context — everything in one place
Work with Jira issues as markdown files in your repo
Keep story context, attachments, and comments right where you code
Stop bouncing between browser tabs and your IDE
"Work Jira like Git" — push, pull, diff and merge

Why am I doing this?

Honestly, I want to understand if pricing is the barrier or if there's something else I need to fix. This experiment will help me figure that out.

If you work with Jira every day and want to keep context closer to your code, this might be useful.

No pressure. Just sharing the experiment.

👉 https://imdone.io/plans

If you've tried imdone-cli or imdone desktop, I'd love to hear what worked — and what didn't. Drop a comment or reach out directly.

Context-Driven Development Experiment 3: Building Multi-Project JIRA Support with Claude Code

Jesse Piaścik — Tue, 18 Nov 2025 12:37:26 +0000

Every week, I run small experiments with context-driven development (CDD), AI tools, and imdone - a tool I built that keeps your backlog right in your source code so you never lose context.

This week, I'm putting Claude Code to the test on a real-world feature: allowing developers to select which JIRA project to add issues to when using imdone-cli.

Why This Feature Matters

On my team, we constantly juggle multiple JIRA projects. We have our main development project, but we also need to create tickets for the infrastructure team, file bugs in different projects, and coordinate across team boundaries.

Previously, switching between projects meant manually editing configuration files or working around limitations. This new feature eliminates that friction, making cross-team collaboration smoother.

The Context-Driven Development Approach

The key to working effectively with AI coding assistants is giving them the right context. Here's how I structured the task:

1. Define the Goal Clearly

Goal: When a user runs imdone add, they can choose which project to add the new issue to.

2. Specify Constraints

Prompt for project key on imdone add
Allow --project-key option for command-line usage
Use Test-Driven Development (TDD)
Ensure all existing tests continue to pass

3. Provide Relevant Files

I included the key files Claude Code would need to understand:

bin.mjs - Where CLI commands start
add-issue.js - The use case implementation
Existing tests to understand the testing patterns

This context allowed Claude Code to understand not just what to build, but how to build it within the existing architecture.

The Development Journey

00:23 - Getting Started with Claude Code

I started by opening the task in my backlog (stored as markdown in my source code) and asking Claude Code to complete it. The first challenge? Claude Code couldn't initially see my backlog folder because it was in a separate git repository.

Lesson learned: Be explicit with file paths when working across repository boundaries.

06:02 - Claude Code Begins Implementation

Once Claude Code had the context, it immediately:

Analyzed the existing code structure
Found the test folder
Started implementing tests using TDD
Added the --project-key CLI option

Watching it work was fascinating - it understood the patterns in my codebase and followed them consistently.

09:05 - First Test Runs and Debugging

The first test run revealed some issues with the test setup. Claude Code needed a few iterations to get the mocking correct for the inquirer prompts. This is where AI-assisted development gets interesting - it's not magic, but it's a productive back-and-forth.

14:00 - Code Review

While Claude Code worked, I reviewed the implementation:

// The new project key selection flow
const projectKeyOptions = await this.jiraAdapter.projectKeys()
const selectedProjectKey = options.projectKey ||
  (projectKeyOptions.length > 1
    ? await this.promptForProjectKey(projectKeyOptions)
    : projectKeyOptions[0]?.key)

Clean, logical, and it handled multiple scenarios:

Explicit --project-key flag
Interactive prompt when multiple projects exist
Default to single project if only one is configured

18:38 - All Tests Passing!

After a few iterations, all 14 tests passed. This is where TDD really shines - we had confidence that the new feature didn't break existing functionality.

20:10 - Manual Testing

I built and linked the CLI locally to test the real user experience:

npm run build
npm link
imdone add

The interactive prompt appeared, showing both my SCRUM and DEMO projects. I selected DEMO, chose "Story" as the issue type, and created a test issue.

It worked! The issue was created in the correct project with the proper template applied.

23:51 - Discovering an Edge Case

During testing, I noticed that sprint selection wasn't working correctly for the secondary project. The root cause? The getActiveSprints() function was joining all project keys with a comma instead of filtering by the selected project.

This is a great example of why manual testing matters - even with comprehensive unit tests, edge cases emerge in real usage.

27:00 - Real-World Challenges

Just as I was about to have Claude Code fix the edge case, I hit the credit limit. This is a real constraint when using paid AI services - you need to budget for it.

Key Takeaways

What Worked Well

Context-Driven Structure: By defining goals, constraints, and relevant files upfront, Claude Code had everything it needed to succeed.
TDD Approach: Having tests as guardrails meant we could iterate confidently without breaking existing functionality.
Code Quality: Claude Code followed existing patterns and wrote clean, readable code that fit naturally into the codebase.

Challenges and Limitations

Setup Friction: Initial path issues and repository boundaries required manual intervention.
Edge Cases: The AI implemented the happy path well, but edge cases still required human discovery and iteration.
Cost Considerations: Running out of credits mid-task is a real concern with usage-based pricing.

When to Use AI Assistants

AI coding assistants like Claude Code excel at:

Implementing well-defined features
Following existing patterns
Writing comprehensive tests
Handling boilerplate and setup code

They struggle with:

Ambiguous requirements
Complex architectural decisions
Edge cases that require domain knowledge
Understanding cross-repository dependencies

The Bigger Picture: Context-Driven Development

This experiment reinforces my belief in keeping context close to code. By storing my backlog as markdown files in my repository, I can:

Quickly provide context to AI assistants
Never lose track of why decisions were made
Link tasks directly to the code they affect
Version control everything - requirements, code, and tests together

This is what imdone enables, and it's why I built it.

Try It Yourself

Want to experiment with this workflow?

Install imdone-cli: npm install -g imdone-cli (multi-project support is available in v0.27.0 and later)
Check out Claude Code (requires Anthropic API access)
Structure your tasks with goals, constraints, and file references
Iterate and learn - every experiment teaches you something new

What's Next?

I'll continue with Claude Code to fix the sprint selection edge case. The structure and approach are solid - it's just a matter of adding one more constraint and letting it iterate.

Next week, I'll run another experiment. Maybe I'll compare different AI assistants, or dive deeper into a complex refactoring challenge.

Join the Conversation

Have you used Claude Code or other AI coding assistants? What's worked well for you? What challenges have you faced?

Drop a comment below with your experiences - I'm especially interested in:

How you structure tasks for AI assistants
Patterns you've discovered for effective AI collaboration
Edge cases or limitations you've encountered

If you found this useful, give it a ❤️ and follow me for weekly experiments at the intersection of AI, development workflows, and better tooling.

Video Timeline

Jump to specific sections:

00:00 - Introduction to weekly CDD experiments
00:23 - Starting with Claude Code and defining the task
03:02 - Setting up the context and files
06:02 - Claude Code begins TDD implementation
09:05 - First test runs and debugging
14:00 - Code review: how Claude implemented the feature
18:38 - All tests passing!
19:00 - Building and linking for manual testing
20:10 - Live demo: selecting projects with the new feature
21:56 - Success! Creating issues in different projects
23:51 - Discovering edge case with sprint selection
27:00 - Running into credit limits (real challenges)
28:00 - Reflection and next steps

This post is part of my weekly context-driven development experiment series. Check out previous experiments and follow along as I explore better ways to build software with AI assistance.

Why Developers Hate Jira (and What We're Doing About It)

Jesse Piaścik — Fri, 14 Nov 2025 21:25:48 +0000

"I was recently talking to a very experienced, very senior person in game development and I asked them, 'How would you make all of game development better?' and they said 'delete every Jira instance across gamedev.'" — Benjamin Carcich

The Problem: Tools That Should Serve Us Become Our Masters

I recently watched @buildingbettergames' video "Why Jira Hurts Game Studios" and it perfectly captures what I've seen across 25+ years in development. The patterns mentioned in this video, play out everywhere Jira becomes the master instead of the servant.

A senior producer once said he could track team progress by watching tickets move in Jira. He could tell who was doing well, which projects were on track, just by looking at the dashboard.

The reality? It wasn't true.

As teams realized they were being watched through Jira, something predictable happened. They started optimizing for Jira instead of optimizing for building great software. They contorted their behavior to make the tickets look good. They gamed velocity metrics. They spent hours feeding the beast instead of shipping value.

Players don't care how many tickets you closed.

But when management treats Jira as reality instead of a model of reality, teams have no choice. The tool that should serve development has become the master we all serve.

🧩 The Cost of Context Switching

Research from UC Irvine found that it takes an average of 23 minutes and 15 seconds to regain focus after an interruption.

Think about your workflow: You're deep in code, holding a complex mental model—variable relationships, edge cases, that elegant solution forming in your head. Then you need to check a story detail. Browser. Navigation. Search. Login again. Find the ticket. Read through comments formatted in someone's custom workflow.

By the time you're back in your editor, it's gone. All of it. That's not a 2-minute interruption. That's 23+ minutes to rebuild the mental context you just lost.

Multiply this by every Jira check during your day. How much time are you actually coding?

💬 What Developers Are Saying

The frustration cuts across every development community:

"Managers mess around with workflows and custom fields that infuriate all the developers" — HackerNews discussion

"As a developer or team member, it sucks to deal with a complex interface just to move your task from ToDo => In Progress." — HackerNews discussion

"I find a simple text file outline like this is so much more convenient than say an app or a web UI." — HackerNews comment

"Planning is hard. These tools throw a big backlog at you and grooming/planning is incredibly frustrating." — HackerNews discussion

"Organizations tend to add way too many custom fields and tags so that doing anything requires entering data into a massive form" — HackerNews discussion

"I ended up with a very simple system: a markdown journal for what I do every day." — HackerNews comment

"Tell me how you'll measure me and I'll tell you how I'll behave." — Eliyahu Goldratt

When you measure developers by ticket velocity, you get ticket velocity. You don't get ownership. You don't get collaboration. You don't get people helping teammates with the most important work because they're afraid their individual metrics will look bad.

You get people gaming the system instead of building great software.

🧠 The Developer's Case for Markdown

Developers gravitate toward markdown for the same reason we prefer grep over GUI search: it's built for how we actually think and work.

When story work lives as markdown files in your repository, everything changes:

Version controlled — Changes are tracked, diffed, reviewed, and merged like code
Lightweight — No browser tabs, no loading spinners, no authentication timeouts
Context-local — Requirements live next to the code they describe
Editor native — Work in vim, VS Code, or whatever makes you productive
Searchable — grep works. Your editor's search works. No special query language.
Portable — Text files work everywhere, on every platform, forever

Need to check a story detail? It's in the file next to your code. Want to update task status? Edit and commit. Need to see what changed in requirements? git diff shows you instantly.

The context switch from "coding" to "checking requirements" drops to zero. You stay in flow.

🔧 What We're Doing About It

Imdone CLI and Imdone Desktop let you work the way you want while keeping stakeholders happy.

Story work lives as markdown files in your repository, bi-directionally synced with Jira:

Jira issues become markdown files — Full content, comments, attachments, all version controlled
Bi-directional sync — Changes flow both ways automatically
Git workflow — Your backlog changes are reviewed and merged like code
Zero context switching — Check stories, update status, add comments—all from your editor
Team collaboration — Pair and mob without fighting over browser windows

Management still gets their Jira dashboards and stakeholder visibility. You get to work like a developer instead of a data entry clerk.

The tool serves you. Not the other way around.

🚀 Developers Deserve Better

You didn't become a developer to spend your day clicking through web forms and updating ticket statuses.

You became a developer to build things that matter. To solve hard problems. To create value.

Your workflow shouldn't be dictated by a tool optimized for middle management dashboards. Your requirements shouldn't live in a system designed to generate reports, not to support building software.

Stop serving Jira. Make it serve you.

Try Imdone →

Context-Driven Development: How I Fixed a Real Bug in imdone-cli Using Structured AI Collaboration

Jesse Piaścik — Mon, 10 Nov 2025 02:06:49 +0000

As developers, we've all been there – you're working on a feature, an AI assistant helps you implement it, but then your teammate has no idea what happened or why certain decisions were made. The context is lost, the AI interaction history is gone, and your team is left to reverse-engineer the thought process.

This is the exact problem I set out to solve in my latest experiment with context-driven development, and the results led to a real fix in imdone 0.26.0 that improves how images render when syncing markdown content to Jira.

The Problem: Context Gets Lost

In my weekly experiments with imdone (a tool that keeps your backlog directly in your source code), I noticed a recurring issue: when one team member works with AI to solve a problem, the context and reasoning behind that collaboration doesn't get passed to other humans on the team.

But there was also a technical problem to solve: images embedded in markdown list items weren't rendering properly when synced to Jira. When you had content like this:

- Here's a bullet point with an image ![my-profile](./my-profile-image.jpeg)

Jira wouldn't display the image correctly because it doesn't handle images that appear directly in list items.

The Solution: Structured Context Format

I developed a structured markdown format for AI collaboration that ensures context is preserved and shareable across the team. Every task follows this format:

- [ ] <!-- Task title -->
    - files: 
        - [<file description>](<file path>)
        - [<file description>](<file path>)
    - goal: <!-- what the change achieves -->  
    - constraints:
        - <!-- constraint 1 -->
        - <!-- constraint 2 -->
    - action: apply patch and show diffs

Why This Works

Files: Explicitly lists which files are relevant, giving both AI and humans clear scope
Goal: States what the change should achieve in plain language
Constraints: Sets boundaries and requirements upfront
Action: Defines the expected deliverable

Real-World Application: Fixing Image Rendering

Using this format, I tackled the image rendering issue. Here's how the task was structured:

- [ ] Fix image translation from markdown to JIRA and bullet items
    - files: 
        - [markdown parser](cli-package/src/parsers/markdown-parser.js)
        - [JIRA generator](cli-package/src/adapters/jira-generator.js)
    - goal: If an image appears on a line of markdown that is an ordered or unordered list item, place it on a new line so JIRA renders it properly
    - constraints:
        - Write good tests to cover this case
        - Don't break existing image rendering in other contexts
    - action: apply patch and show diffs

The AI Collaboration Process

With this structured context, I simply told GitHub Copilot to "complete the task on line 28." The AI:

Understood the scope by reading the specified files
Implemented test-driven development by writing failing tests first
Created the solution that moved images to new lines when they follow list items
Maintained backward compatibility as specified in constraints

The key insight: by providing structured context, the AI could work more effectively AND any teammate could understand exactly what was being attempted and why.

The Results: imdone 0.26.0

The fix successfully made it into imdone 0.26.0. Now when you have markdown content with images in list items, the sync process automatically moves images to separate lines, ensuring they render properly in Jira:

Before (broken in Jira):

- Here's a bullet point with an image ![profile](./image.jpeg)

After (renders correctly in Jira):

- Here's a bullet point with an image 
![profile](./image.jpeg)

Key Takeaways

1. Structure Enables Better AI Collaboration

By providing files, goals, constraints, and expected actions upfront, AI assistants can work more effectively and deliver more predictable results.

2. Context Preservation is Critical for Teams

When AI interactions are structured and documented, teammates can understand not just what changed, but why and how decisions were made.

3. Experiments Drive Real Improvements

Treating every feature as an experiment means you're always learning and improving. This "failed" interaction (there were some terminal issues during the process) still produced a working solution that benefits users.

4. Keep Context Close to Code

By storing these structured tasks in the same repository as the code (in our case, in a git-ignored backlog/ directory), context stays accessible without cluttering the main codebase.

The Philosophy: Features as Experiments

Every feature addition is really an experiment – you never know if it will truly benefit users until it's in their hands. By treating development this way and tracking context systematically, we can:

Make more informed decisions about what to build next
Learn from both successes and failures
Maintain better team alignment on goals and approaches
Iterate more effectively based on user feedback

Try It Yourself

The structured context format I use is simple enough to adopt in any project:

Create tasks with explicit file lists, goals, and constraints
Store context where your team can access it (we use a git-ignored backlog directory)
Use the format consistently when working with AI assistants
Review and approve all AI-generated changes before merging

What's Next?

This experiment convinced me that structured context makes AI collaboration more effective and team-friendly. I'll continue refining this approach and testing it on more complex features.

The real win isn't just the technical fix – it's proving that we can work with AI in a way that enhances rather than replaces human collaboration and decision-making.

Want to see more experiments like this? I run these context-driven development experiments weekly. Follow along for more insights into AI-assisted development, team collaboration, and building better software tools.

Recording My Experiments in Spec-Driven Development

Jesse Piaścik — Mon, 03 Nov 2025 18:43:07 +0000

For years, I’ve been chasing one idea — keeping context close to the work.

Whether it’s TODO comments, markdown notes, or tasks in the repo, my goal has always been to reduce the mental tax of switching tools just to remember what I was doing.

That’s the foundation of what I call context-driven development — a workflow where the “why” behind each change lives right next to the “how.”

Now I’m taking that same idea into the world of AI-assisted coding.

Recording My Experiments

Lately, I’ve been experimenting with spec-driven development — trying to guide AI tools like Copilot to produce code that matches what I actually want, not just what it infers from nearby syntax.

Progress has been slow.

There’s just too much going on in my life right now to hold the full context of what’s working and what isn’t. So I’ve decided to start recording my experiments and sharing them here.

Embedding Context Where It Belongs

In my latest experiment, I used context embedded in the Jira issue to guide Copilot.

Instead of writing long, open-ended prompts, I pasted that context into the Copilot chat panel and referenced specific files and lines.

That small change made a big difference. It gave Copilot something closer to what a teammate would see — the why behind the change, not just the where.

Moving Toward Structured Specs

While researching how ChatGPT interprets structured text, I landed on a markdown format that should be easier for Copilot to understand and follow.

Here’s the format I’ll be using in my next experiment:

- [ ] <task title>  
  - files: `<path:line>`, `<path:line>`  
  - goal: <what the change achieves>  
  - constraints: <rules to avoid unwanted changes>  
  - action: apply patch and show diffs

My hope is that this will make the generated code more predictable — and closer to what I’d write myself.

What’s Next

In the next post, I’ll use this format to see how well Copilot follows the spec when it’s embedded directly in the codebase.
I’ll record the whole thing so you can see exactly how it performs.

Stay tuned — and if you’ve tried something similar with Copilot or ChatGPT, I’d love to hear how you structure your specs.

Watch the short intro video here:
👉 https://youtu.be/Op9iQ2LX2DI