I previously maintained Planning and Diagnosis as separate Skills. After using them for a while, I found that they behaved more like default execution discipline than specialized capabilities that needed to be installed and triggered independently.

Planning defines how a complex task should be divided and accepted. Diagnosis defines how failures should be investigated, how hypotheses should be tested, and when a root cause can be considered confirmed. Neither depends on a particular technology stack, script, or reference package. Instead of adding two more Skills for the agent to route, I moved their essential rules into my global AGENTS.md.

I now separate my working configuration into four layers:

Global AGENTS.md       = stable personal preferences and safety boundaries
Repository AGENTS.md   = project structure, commands, and delivery rules
Skill                  = a specialized capability with its own process or evidence
docs/ and .codex/      = durable documentation and local task artifacts

The goal is not to accumulate instructions. It is to state each rule once and keep it with the layer that owns it.

What belongs in the global file

My global configuration only keeps rules that remain useful across repositories:

Repository layout, build commands, domain structure, and specialized validation do not belong in the global file. They change more often and only become true inside a particular project, so the repository’s own AGENTS.md should own them.

Planning and Diagnosis can stay compact

The point of Planning is not to produce a long planning document. It is to make complex work executable. Each task item should identify what it owns, what it must not change, what it depends on, how it will be validated, and what evidence proves completion. Small tasks can proceed directly.

Diagnosis is not a fixed command sequence either. It defines the standard of proof: record the observed and expected behavior, establish the smallest practical reproduction, form falsifiable hypotheses from code, logs, and runtime evidence, and change as few variables as possible. When evidence is incomplete, uncertainty must remain visible. Permanent remediation begins only after the root cause is supported, followed by a rerun of the original failing path.

Codex can already plan and search code. That default capability does not define my acceptance criteria. The global rules do not try to teach the model how to think; they state which process and completion evidence I am willing to accept.

Model routing belongs in structured configuration

AGENTS.md defines behavioral boundaries; it should not also own model selection. The model, reasoning effort, Plan mode, and default subagent belong in ~/.codex/config.toml, while each specialized role keeps its model and permissions in its own Agent configuration. This separation prevents runtime settings and natural-language rules from contradicting each other when a model changes.

My current routing is:

Purpose Model and reasoning Why
Primary agent Sol Medium Owns requirement judgment, coordination, acceptance, and final delivery
Built-in Plan mode Sol High Handles complex planning decisions that can change implementation direction
Default subagent and Worker Terra Medium Implements well-bounded everyday work
Explorer Terra Medium Traces broader call chains and execution paths rather than doing mechanical search alone
Reviewer Sol High Independently checks correctness, regressions, and validation gaps
Planner Sol Medium Handles ambiguous, architectural, or cross-module planning
Batch Worker Luna High Handles explicit, repeatable, independently verifiable batch work after a same-session canary
Conditional Luna Explorer / Worker Luna High Handles specialist work only after the exact role passes a same-session canary

This is not a simple high, medium, and low ranking of the models. Model capability and reasoning effort are separate dimensions, and there is no reliable cross-model equivalence. My actual configuration uses Sol for the primary agent, planning, and independent review; Terra for the default subagent, Worker, and Explorer; and Luna only for high-effort batch work or conditional specialist work after a same-session canary. Representative tasks should decide the final configuration rather than assumptions that different models or reasoning levels are interchangeable.

The runtime defaults are conservative as well: ordinary tool calls require on-request approval, the default sandbox allows writes within the current workspace, and Explorer, Planner, and Reviewer use read-only sandboxes. Worker and conditional batch roles are the ones allowed to write. Concurrent threads are capped at three, and role TOML files remain defaults rather than a way to expand the current session’s authority.

The compact version I use

This is the core structure I currently use. Machine paths and tool choices are environment-specific and should be replaced when reused elsewhere.

# Personal Work Rules

## Scope And Precedence

- Explicit instructions in the current conversation take precedence; a nearer `AGENTS.md` or `AGENTS.override.md` overrides the global file.
- Keep only stable cross-repository preferences and safety boundaries in the global file. Put project commands, architecture, validation, and delivery contracts in project documentation; put structured model, reasoning, and sandbox settings in `~/.codex/config.toml`.

## Communication

- Keep ordinary answers direct and concise, retaining only necessary facts, judgments, results, risks, and next steps. Update long tasks only when their state materially changes.
- Analysis, decisions, research, and reviews do not assume the user's premise is correct. Check issues that would change the conclusion, distinguish verified facts, evidence-based inferences, and unverified items, and do not disagree for its own sake.
- Reviews list issues, impact, and locations first. When there are no findings, state validation gaps and residual risk.

## Workspace And Changes

- When no directory is specified, use the configured default workspace and read its entry document and effective `AGENTS.md`.
- Before repository work, confirm the real cwd, Git root, branch, status, effective instructions, and minimum necessary context; prefer `rg` and named files.
- Keep changes within the current task, protect unrelated uncommitted work, and preserve existing structure, toolchains, and contracts. Complete unblocked work before requesting authorization.

## Planning, Execution And Verification

- Complete simple linear tasks directly. For large or ambiguous work, resolve decisions that can change direction, then proceed through the smallest end-to-end verifiable slices.
- Delegate only independently acceptable work with a clear benefit. Use one suitable role by default, and parallelize only independent, unordered, non-overlapping tasks.
- For failures, record actual and expected behavior and establish the smallest reproduction. If a reproduction cannot be established, state the evidence gap and do not apply a permanent fix. After confirming the root cause, make the change and rerun the original path.
- Builds, static checks, and source scans prove only their covered scope; they do not replace runtime, browser, device, or production validation.
- When task artifacts are needed and the repository has no convention, use the Git-ignored `.codex/handoffs/`, `.codex/reviews/`, `.codex/artifacts/`, and `.codex/tmp/` directories.

## Git And External Actions

- Do not modify `main`, create pull requests, or push by default. Use repository-approved task branches.
- Stage only related files and inspect `git diff --cached` before committing. Preserve unrelated work and do not run destructive Git operations without explicit authorization.
- Use the host's built-in browser by default. External browsers, publishing, production operations, messages, comments, authorization, and other external writes require an explicit request.

How local configuration reaches the public article

My complete preferences, real paths, providers, permissions, and trusted-project details remain local. ~/.codex/AGENTS.md and structured configuration determine runtime behavior, while local documentation explains the complete design. The Blog publishes only the current sanitized, reusable version; it is not the runtime authority.

I do not synchronize every local adjustment to the Blog. I update the article only when a public principle, example, or explanation changes materially. The public copy is selected from the local source, stripped or generalized of machine-specific details, and then used to overwrite the current Chinese and English articles. I review the public diff, scan for sensitive information, and validate the site before deciding whether to commit and push.

The Blog does not keep a separate directory of workflow versions. The article always presents the current version, while Git history retains earlier revisions. The direction remains one-way: local rules may produce public prose, but public prose never overwrites local configuration.

There is also no need for a separate public workflow repository today. That boundary should change only if the public configuration becomes an independent product with downloads, installation, compatibility promises, issues, or releases.

How I handle additional preferences

I do not add a new section every time a new requirement appears. I first decide which layer owns it:

When a global rule accumulates exceptions, explanations, and multiple reference chains, it probably belongs somewhere else. The global file should remain quick to load, but it should not become short by deleting authorization boundaries, Git safety, dirty-worktree protection, or evidence standards.

For me, a good personal configuration does not describe every possible working method. It preserves the small set of boundaries that are easy to forget and costly to violate.