pi: Instructions file for Codex

Development Rules

Conversational Style

• Keep answers short and concise
• No emojis in commits, issues, PR comments, or code
• No fluff or cheerful filler text (e.g., "Thanks @user" not "Thanks so much @user!")
• Technical prose only, be direct
• Use concise, clear, simple language. Define unavoidable jargon before using it.
• Explain non-trivial designs and problems as: problem, concrete example or short trace, then solution. State why the solution is necessary and distinguish it from optional complexity.
• Prefer concrete behavior and small illustrations over abstract summaries, dense terminology, or unexplained lists of changes.
• When the user asks a question, answer it first before making edits or running implementation commands.
• When responding to user feedback or an analysis, explicitly say whether you agree or disagree before saying what you changed.

Code Quality

• Read files in full before wide-ranging changes, before editing files you have not fully inspected, and when asked to investigate or audit. Do not rely on search snippets for broad changes.
• No any unless absolutely necessary.
• Inline single-line helpers that have only one call site.
• Check node_modules for external API types; don't guess.
• No inline imports (await import(), import("pkg").Type, dynamic type imports). Top-level imports only.
• In packages/coding-agent, resolve package assets through helpers in src/config.ts. Do not use __dirname directly; the helpers account for source checkouts, npm installations, and standalone binaries.
• Never remove or downgrade code to fix type errors from outdated deps; upgrade the dep instead.
• Use only erasable TypeScript syntax (Node strip-only mode) in code checked by the root config (packages/*/src, packages/*/test, packages/coding-agent/examples): no parameter properties, enum, namespace/module, import =, export =, or other constructs needing JS emit. Use explicit fields with constructor assignments.
• Always ask before removing functionality or code that appears intentional.
• Do not preserve backward compatibility unless the user asks for it.
• Never hardcode key checks (e.g. matchesKey(keyData, "ctrl+x")). Add defaults to DEFAULT_EDITOR_KEYBINDINGS or DEFAULT_APP_KEYBINDINGS so they stay configurable.
• Never modify packages/ai/src/models.generated.ts directly; update packages/ai/scripts/generate-models.ts instead, then regenerate. Including the resulting models.generated.ts diff is always OK, even if regeneration includes unrelated upstream model metadata changes. The generated model data in packages/ai/src/providers/data/ is gitignored: never stage it, and don't look for it in git history.