Skip to content
coders.talk
Pi · claude-sonnet-4-20250514featureCLI & tooling17 files · +1984 −215

Add provider-specific context file loading extension for Pi coding agent

Session from pi-extensions-sessions on Hugging Face by thomasmustier · MIT · condensed by Coders Talk

2h 41msession
4interventions
by library · 2d
TypeScriptBashGitmermaidmarkdown
GOAL

Make Pi's project-context loading (AGENTS.md/CLAUDE.md) provider-aware so different models (Claude, Codex, Gemini) get different steering, then package this as a proper extension repo.

  1. Prompt · +0
    Pi always loads AGENTS.md over CLAUDE.md regardless of model; can we make context loading provider-aware?
  2. Agent did · +0m
    Explored pi-mono repo's system-prompt.ts and extension API, discovered 0.37.5 lets extensions query the active model, then designed a supplementing/dedup scheme for provider-specific context files (CLAUDE.md, CODEX.md, GEMINI.md) alongside core AGENTS.md.
  3. Break · 2h 27m away, not counted
  4. Agent did · +49m
    Implemented provider-context.ts extension, passed lint/type checks, moved it into a new ~/pi-extensions repo, committed and pushed.
  5. Intervention · +1h 1m
    Reviewed the paraphrased CODEX.md and asked for a near-verbatim lift-and-shift from steipete's AGENTS.md instead, only swapping personal details.
    Why: It reads totally generic. I wanted the real content adapted, not a generic rewrite that lost all the specific, useful guidance.
  6. Break · 7h 22m away, not counted
  7. Agent did · +1h 20m
    Tested the extension by invoking pi directly with different --provider/--model flags, fixed the openai vs openai-codex provider mismatch, and confirmed AGENTS.md plus the right provider file both load.
  8. Break · 30m away, not counted
  9. Intervention · +1h 28m
    Changed mind on the flat extensions/ layout and asked to restructure into one folder per extension (context files, setup script, README together) with better naming.
    Why: I changed my mind - grouping by extension with its own setup and README makes more sense than one shared setup.sh and a generic 'context' name.
  10. Intervention · +1h 42m
    After several mermaid diagram rewrites (simplified, colored, hierarchical), asked to revert back to the very first, simplest diagram.
    Why: I liked the original chart better - the newer ones got too complicated to read.
  11. Intervention · +2h 13m
    Questioned why AGENTS.md lived in the extension's templates at all, since Pi core already loads the user's own AGENTS.md; had it removed from templates and setup.sh.
    Why: Users already have their own AGENTS.md - it's not our job to provide or overwrite that, only the provider-specific files.
  12. Agent did · +2h 15m
    Worked through fresh-install edge cases: warned users when no AGENTS.md exists, offered to copy an existing CLAUDE.md into AGENTS.md, then added dedup logic in the extension itself to skip loading a provider file if its content is identical to AGENTS.md.
  13. Outcome · +2h 41m
    Final repo structure (agent-guidance, tab-status, arcade) cleaned up and pushed across ~10+ commits; all extensions and context files symlinked into ~/.pi/agent/ locally and verified working via live model switches.
VERDICT

Next time I'd open with the full picture up front - that I wanted a reusable, documented extension repo, not just a one-off fix - since a lot of turns went into restructuring folders and diagrams after I kept changing my mind. The correction that did the most real work was catching that AGENTS.md shouldn't live in our templates at all, since it's the user's own file; that reframing is what made the setup script and dedup logic in the extension actually correct.

I tried this · 0

Discussion · 0

How Builds work