davidgasquez.com
🔧 Where my dotfiles lives in harmony and peace, most of the time
♻️ Simplify Codex agent defaults
+26
-52
+25
-39
agents/AGENTS.md
+25
-39
agents/AGENTS.md
···
1
1
# Rules
2
2
3
-
- Agentic, proactive (run commands, read docs, ...), concise, direct, and technical
4
-
- Explicit is better than implicit
5
-
- Flat is better than nested
6
-
- Practicality beats purity
7
-
- Follow the UNIX Philosophy (do one thing and do it well)
8
-
- Aim for fast, deterministic feedback loops (tests, linters, type checks, hooks)
9
-
- Embrace simplicity and immutability
10
-
- Do the simplest thing that could work (KISS, don't over-engineer)
11
-
- Write functional code with small, composable and modular functions/modules/components with explicit interfaces
12
-
- Functions over clever abstractions, clarity over magic
13
-
- When unsure, don't guess, read more code and gather more context (search, ask, list explicit trade-offs, ...)
14
-
- Call out bad ideas, unreasonable expectations, mistakes, ...
15
-
- After applying changes, verify they work (run code, lint, tests, ...)
16
-
- Make debugging easy yourself with concise/clear logs and assertions that help debugging without noise
17
-
- Keep files small (<~500 LOC) and split/refactor as needed
18
-
- Write clean, modular code with modern syntax and type annotations
19
-
- Don't code defensively
20
-
- Fail-fast behavior with actionable, structured error messages
21
-
- Fail early and often. No need to try-catch
22
-
- Failures should be visible and actionable
23
-
- Check conditions proactively rather than relying on exceptions for control flow
24
-
- The best code is no code (remove code that is not needed)
25
-
- Work in small, discrete, iterative steps
26
-
- Create temporary scripts to learn more about APIs, schemas and datasets shape/values
27
-
- Human-in-the-loop checkpoints for risky or high-impact changes
28
-
- Never run destructive git operations (e.g., `git reset --hard`, `rm`, `git checkout`/`git restore` to an older commit) unless the user gives an explicit, written instruction in a conversation.
29
-
- Rely on the build system (usually `Makefile`) commands for running, testing, linting, ...
30
-
- A single command should setup, run, test, lint, and format the project
31
-
- Use `tmux` for background jobs, async tasks, or anything you'll come back to it
32
-
- Run development servers, long running processes you need to audit, run tests in the background, tail logs
33
-
- Design workflows so they are observable without constant (blocking) babysitting (use tmux panes, logs, log-tail scripts, ...)
34
-
- No flowery language, em dashes (—), en dashes (–), or semicolons (;)
3
+
## General
4
+
5
+
- Be proactive
6
+
- Read code, run commands, inspect docs before answering
7
+
- Do not guess and gather context before making decisions
8
+
- Be concise, direct, and technical
9
+
- Call out bad ideas, incorrect assumptions, and trade-offs
10
+
11
+
## Code
12
+
13
+
- Prefer simple, explicit, practical solutions
14
+
- Small functions and modules with clear interfaces
15
+
- Keep files under ~500 LOC
16
+
- Remove unnecessary code
17
+
18
+
### Execution Model
19
+
20
+
- One path without fallbacks or legacy branches
21
+
- Fail fast with clear error messages
22
+
- Validate conditions explicitly rather than relying on exceptions
23
+
- After making changes, verify they work (run code, tests, lint)
35
24
36
25
## Git
37
26
38
27
- Commits
39
-
- Atomic commits (split changes into small, logical units)
40
-
- Short and clear descriptive messages
41
-
- Prepend a relevant emoji (🐛 Fix upsert logic)
28
+
- Atomic commits with short descriptive messages prefixed by a relevant emoji (🐛 Fix upsert logic)
42
29
- Pull Requests
43
-
- Concise and short description of the changes (no header/title)
44
-
- Prepend a relevant emoji to the PR title (🚀 Publish new version)
30
+
- Title should be short and prepended with a relevant emoji (🚀 Deploy new users flow)
31
+
- Concise and short description of the changes as the body
45
32
- Branches
46
-
- Clean and relevant name
47
-
- Use basic names (`fix-async-stream`, `add-users-model`)
33
+
- Simple descriptive names (`fix-async-stream`, `add-users-model`)
48
34
- Use `gh` CLI for PRs, reviews, issues, ...
+1
-13
agents/codex/config.toml
+1
-13
agents/codex/config.toml
···
1
1
model = "gpt-5.4"
2
2
model_reasoning_effort = "high"
3
-
approval_policy = "on-request"
4
-
sandbox_mode = "workspace-write"
5
-
web_search = "live"
6
-
suppress_unstable_features_warning = true
7
3
personality = "pragmatic"
8
4
service_tier = "fast"
9
-
10
-
[projects]
11
-
"/home/david" = { trust_level = "trusted" }
12
-
13
-
[sandbox_workspace_write]
14
-
network_access = true
15
-
16
-
[features]
17
-
multi_agent = true
5
+
check_for_update_on_startup = false