Earlier I wrote about setting up a uv-first Python workflow for Claude Code and Codex.

I started from the same agent-side instructions that keep Python work inside uv, then added a subagent-backed Codex skill for Python repository health checks.

The idea is straightforward: instead of dumping full uv, ruff, pytest, and ty output into the main thread, the skill inspects how the repository is structured, reads pyproject.toml, checks the lockfile and CI setup, runs the core commands, and returns a short one-page report with clear pass, warn, and fail signals.

You can download the skill from this repository and install it in one of two ways:

• Globally: copy the skill folder into $CODEX_HOME/skills so it is available across all your Codex projects.
• Per project: copy the skill folder into .codex/skills inside a specific repository if you want it to be available only there.

I usually prefer the project-level setup when the skill is tightly coupled to one repository or workflow, and the global setup when I want the same skill available everywhere.

Using a subagent has several advantages:

• it keeps the main thread clean, so I am not burning context window on hundreds or thousands of lines of tool output
• it reduces the chance that the active session gets slowed down by context compaction or cleanup after a noisy run
• it isolates the repository health-check logic from whatever I am doing in the main thread, which matters when I am already in the middle of another coding task
• it gives me a cleaner review surface: I get the conclusions and the relevant evidence, not a terminal transcript I have to sift through
• it makes the check easier to delegate and repeat, because the workflow is written down once instead of being reconstructed from memory each time
• it creates a natural boundary between execution and interpretation: the worker runs the commands, the main thread reads the result and decides what matters
• it is easier to fail safely: if the subagent cannot run, the skill can stop immediately instead of half-running checks in the wrong place

For me, the real payoff is that “healthy” for my Python repos is now written down once: dependency policy, lockfile invariants, linting, test collection, typing posture, coverage expectations, and whether CI matches how we run things locally. What used to be a noisy manual sweep becomes something I can repeat, delegate, and skim during review.

If you want to see it in action, start Codex and run $python-repo-health-check in the Codex CLI. You should see something like this:

Rawls, the repo health checker is running the repo scan now

Rawls is just a platform-generated friendly name. That line is useful because it makes it obvious that the health-check run was actually delegated and started.