We are part of a team that is working on a large government effort to modernize the Medicare payment system. With this undertaking, it brings a particular kind of complexity—one that’s structural, not accidental. Rules, pricing logic, eligibility requirements, and policy interpretations are tightly interwoven, so even small changes to enhance its modernization can ripple outward in unexpected ways. Progress depends not just on code, but on shared understanding: why a rule exists, who signed off on it, and what downstream systems quietly rely on it. Every ticket carries an invisible payload: context. Who owns the validation? Which edge case broke last sprint? What constraint are we honoring that isn’t written anywhere?

Here’s what bothered me: I’d already learned it. Then three weeks later, I was re-deriving it. Slack archaeology. PR spelunking. Re-asking the same questions. Not because the work was new—but because the context didn’t travel.

So we changed the medium.

We shifted to using the imdone ecosystem so the ticket itself could tell the story. Each issue lives as repo-native markdown, right alongside the code it relates to, and syncs cleanly with Jira. Instead of abstract tasks floating elsewhere, the context stays close: the constraints, the decisions, the why behind the work. You write it locally, where you’re already thinking, and it flows back automatically. One story, grounded in the code, visible in two places.

The day got quieter. Context switches cost less. Fewer “which ticket is this?” moments. Fewer parallel scavenger hunts. Decisions stopped evaporating because they were captured at the moment they became true. Reviews got cleaner because intent wasn’t inferred—it was attached. AI fits naturally into this. Models don’t remember last week, files do. When the issue file is the shared medium, new sessions inherit continuity without someone narrating history. That’s what makes quality ensemble work possible.

Adaptive Ensembling isn’t heroics. It’s shared cognition: multiple people (and tools) solving the same problem from the same ground truth. Same file, same constraints, same decision history. No “I thought we decided…”. No re-explaining last week.

Team effectiveness isn’t individual output. It’s whether knowledge compounds.

The Problem

Today's learnings are tomorrow's transfer. That's the design constraint—not an afterthought.

Every team has the same failure mode: knowledge lives in Slack scrollback, tribal memory, or "someone should write this down." When you context-switch between tickets, you re-learn what you already knew. The problem isn't documentation, the problem is retrieval.

The Hypothesis

If we capture team learnings in a Unified Context and provide an adaptive learning environment with small, targeted Knowledge Checks, then transfer improves: fewer repeated questions, better execution quality, less context lost between sessions.

This is a memory problem disguised as a process problem—for both humans and AI.

For the human brain: We store by similarity, but we retrieve by difference. Your brain files new information into a network of related stuff. When you try to recall it, your brain doesn't search by "same"—it searches by what makes this thing *unique*.

For the AI model: Context is everything. A model with a focused, relevant context window produces better output than one drowning in tangential information. The same principle applies: what makes *this* task different from a generic request?

That uniqueness is the lever—for both.

  The Experiment: /imdoneWe built a Claude Code slash command — a prompt-chaining workflow that serves as an interface for ticket-locked delivery, where the story file becomes the shared context for both the ensemble and the model.

Simple in concept. Strict in execution.

Core Mechanics

Unified Context: The story you're working on is the "single room" everything happens inside. After you pull a ticket, that issue file is your only workspace. Not the whole backlog. Not adjacent tickets. Just this one.

Knowledge Check: The tool asks questions pulled from that same unified context. Not generic questions—questions from *this* ticket's acceptance criteria.

The question types surface different retrieval patterns:

Knowledge Check Question Types

• PREDICT: “What happens when [edge case]?”

• EDGE: “What’s the boundary condition?”

• LOCATE: “Where does this logic live?”

• SEQUENCE: “What runs before this step?”

Dual Feedback Loop

Both sides learn:

• Human: you answer → you reconstruct the mental model (retrieval practice).

• AI: it sees your answers → it adapts to your session’s context.

Critical Attributes

The questions force the key move: naming what makes this ticket different from the others. That’s the retrieval cue.

The Mental Model

Most “knowledge transfer” is a library dump: “read the docs, ask questions.”

But a library dump doesn’t teach you what to look for.

This hands you a map and points to landmarks. The human learns what they don’t know. The AI learns what matters for this task.

The Living Document

The issue file grows as you work.

Reflections after reflect. Approach decisions after options. Test intent before red. Discoveries after green. By the end, the file contains the whole story — not just what shipped, but why it shipped that way.

For humans: you return after a week, skim, and you’re back in context.

For AI: new session starts, it reads the same file, and the background is already there.

The file pre-loads context for both. One artifact, two readers, same understanding.

Working Memory Guard

We avoid context overload.

Humans: working memory is limited.

AI: context windows are limited.

So the system loads only what’s needed for the phase:

What Loads Per Phase

• Pull: Project context only

• Reflect: Just the issue file

• Plan: Agent + Context files

• Options: Context + patterns

• Red: Testing guide + patterns

• Green: Context + patterns

• Verify: Just the issue file

Not everything. Just enough.

The Structure

This wasn’t built in a vacuum. It’s infused with:

Reflect + TDD workflow

Operational, not inspirational. Every step produces an artifact.

pull → reflect → plan → options → red → green → verify → done

Ensemble learnings

Real teams ship through shared cognition, not heroics. The trust model is explicit:What AI Does vs What Humans Do

AI is good at:

• Generate options

• Write first draft

• Spot patterns

• Remember syntax

• Provide commands

Humans are responsible for:

• Choose direction

• Validate accuracy

• Apply judgment

• Know the business

• Run verification

Own the outcome.

AI proposes. Human disposes. The file remembers.

The Decision

We’re testing /imdone as onboarding: a Claude Code slash command that turns each ticket into a prompt-chained, repo-native learning loop for engineers.

Not as a "cool AI feature." As an operational training loop.

The goal isn't "use AI more." It's create a transfer ecosystem**.

Early Observations

We're still collecting feedback from beta testers, but a few patterns are emerging.

Better prompting through constraints: The tool doesn't just answer; it coaches how to ask. Four capabilities keep surfacing:

“Own the Outcome” Capabilities

Delegation (options)

• Now transferable: When to look up vs. figure out

• Already in you: Any tool, any prompt

Description (red)

• Now transferable: Naming with clarity

• Already in you: Requirements, Slack

Discernment (green)

• Now transferable: Reading your own work tomorrow

• Already in you: AI output, any doc

Diligence (verify)

• Now transferable: The pause before you push

• Already in you: Deploys, approvals

Reusable context — today becomes tomorrow’s starting point.

Fewer false starts — when critical attributes are explicit, direction gets cleaner.

The Philosophy

“The why travels with the how.”

Tests, commits, and decisions embed intent directly in the artifact. Reviewers see rationale next to diffs. Teammates inherit clarity. The next AI session starts with the context that matters.

That’s Transfer

Today’s learnings are tomorrow’s transfer — so capture them like you plan to rely on them.

If it’s worth transferring, it’s worth transferring well.

Paul Kiat is a Full Stack Software Engineer at Systone, supporting large-scale modernization efforts. His work focuses on building evolvable, human-centered systems that improve decision-making and maintain long-term clarity as complexity grows. As a dad, he brings an added appreciation for solutions that are practical, dependable, and easy to use.