Epic: RepoPrompt-style context and apply improvements

[jamesrochabrun]

Summary

Build the RepoPrompt-style core that AgentHub does not have today: explicit, reviewable, token-aware context engineering for launched agents.

AgentHub already observes and orchestrates CLI sessions well. The missing RepoPrompt-grade win is controlling what the agent sees before it starts: selected files, exact assembled prompt context, token estimates, slices, reusable profiles, Smart-mode per-session context, and eventually code maps.

Primary Focus

This epic is now focused on the context-engineering roadmap. Pending edit/apply hardening is useful, but it is not part of the first milestone because it does not address the unique RepoPrompt-style product gap.

Why this matters

Today, AgentHub launch flows mostly hand agents a prompt string plus optional attached file paths. That makes the most important input to the agent opaque and hard to review.

The core win is to make context:

• explicit: users choose exactly what files/slices are included
• reviewable: users see the exact assembled context before launch
• token-aware: users see approximate size and budget pressure before starting
• reusable: recurring task contexts can be saved as profiles
• orchestration-aware: each Smart-mode session can receive its own focused context
• cheap at scale: code maps can provide API/signature context without full file bodies

Context Roadmap

Recommended implementation order:

• Context Builder MVP: core selection and assembly model #400
• Context Builder UI: select files and preview exact prompt context #402
• Token estimates for curated context #404
• Smart mode: per-session context payloads #408
• Line slicing for curated context #405
• Context profiles for reusable prompt context #406
• Code maps vertical slice for curated context #407

Dependency Notes

• Context Builder MVP: core selection and assembly model #400 is the spine. Build this first: core context model, assembly, bounded file reads, temp-file fallback, and launch prompt composition.
• Context Builder UI: select files and preview exact prompt context #402 makes Context Builder MVP: core selection and assembly model #400 usable in the launcher with file selection and exact context preview.
• Token estimates for curated context #404 should land early because token visibility is part of the product value, not a later analytics feature.
• Smart mode: per-session context payloads #408 is the AgentHub-specific multiplier: Smart mode becomes materially better when every parallel worktree gets its own curated context.
• Line slicing for curated context #405 and Context profiles for reusable prompt context #406 are second-wave Context Builder capabilities: slices reduce token waste, profiles make good context reusable.
• Code maps vertical slice for curated context #407 should wait until the context model and token estimates are stable. Start with a narrow Swift-first vertical slice, not a full multi-language code-map system.

Deferred / Not First Milestone

These issues remain valid but are not the current focus:

• Apply hardening: fuzzy edit matching and per-edit outcomes #399
• Apply hardening: artifact-contamination guard #401
• Pending changes UI: show apply outcomes #403

They improve trust in the edit review loop, but they do not deliver the unique RepoPrompt-style context-engineering capability this milestone is about.

Non-goals for the first milestone

• Do not start with full multi-language tree-sitter code maps.
• Do not add MCP context tools before there is durable context state to expose.
• Do not prioritize edit-apply hardening ahead of context selection, assembly, preview, and token estimates.
• Do not change model/provider behavior; AgentHub only changes what is handed to the CLI.

[Keesan12]

This is the right product boundary. The context should be inspectable before the run and accountable after it.

I would make every launch produce a context receipt: selected files and slices, token estimate, exclusions, profile version, and which pieces were later compacted. Then a bad result can be traced to missing evidence instead of blamed vaguely on the model.

We are building MartinLoop's Context Runtime around exactly this, tied into budgets and verification. Would you be open to comparing one AgentHub Smart-mode launch against our receipt schema and finding the smallest interoperable shape? https://github.com/Keesan12/martin-loop