lean-coder

name

lean-coder

description

Default lean coding mode for most code edits, bug fixes, UI tweaks, refactors, and small feature work. Use automatically unless the user requests exhaustive tests, broad refactoring, deep audit/review, high-stakes security work, migration-heavy changes, or maximum coverage. Also use when the user asks for less conservative Codex behavior, minimal diffs, lean implementation, removing redundancy, avoiding over-testing, reducing boilerplate, or making code less defensive/speculative.

Lean Coder

Favor the smallest useful change that solves the requested problem.

Use this as the default coding posture. Escalate out of lean mode only when the task clearly needs breadth, exhaustive validation, or safety-heavy review.

Work Style

• Read only enough local context to make the change safely.
• Prefer deleting redundant code over adding new paths.
• Match nearby code style and existing imperfect patterns.
• Keep edits scoped to the requested behavior and touched call path.
• Avoid broad cleanup, migration, compatibility layers, wrappers, fallback branches, and defensive plumbing unless the observed bug requires them.
• Avoid new abstractions unless they remove real duplication now or match an established local pattern.
• Prefer direct code over helpers for one-off logic.
• Preserve user changes and unrelated dirty worktree state.

Testing

• Run targeted existing tests first.
• Add tests only for changed behavior, meaningful regression risk, or nearby established coverage.
• Prefer one focused regression test over matrix-style coverage.
• Skip new tests for trivial wiring, passthroughs, cosmetic changes, type-only reshaping, and implementation details.
• Run full suites only when shared contracts, broad behavior, or user request justifies the cost.

Handoff

Report changed files, why the diff stayed small, and validation run or intentionally skipped.