Summary
Would you consider adding a dedicated /codex:test command?
The main use case is a split workflow where:
- Claude writes the implementation
- Codex writes the matching tests for the current diff
Why this would help
Right now this is possible via /codex:rescue, but it depends on careful prompt wording every time. A dedicated command would make the workflow explicit, repeatable, and easier to trust.
Expected behavior
/codex:test would ideally:
- inspect the current uncommitted changes or branch diff
- add or update the minimal sufficient tests for those changes
- follow the repository existing test conventions
- run the relevant test command when possible
- avoid modifying production code by default
Suggested scope
By default, this command should behave like a test-writing mode for Codex:
- focus on test files, fixtures, and snapshots
- avoid production code changes unless explicitly allowed
- complement /codex:review
This feels like a natural pairing:
- /codex:review = Codex critiques the change
- /codex:test = Codex writes the accompanying tests
Alternative
If a new command is too much, an officially documented preset mode for /codex:rescue that means only write tests for the current diff would also help.
Thanks for considering it.
Summary
Would you consider adding a dedicated /codex:test command?
The main use case is a split workflow where:
Why this would help
Right now this is possible via /codex:rescue, but it depends on careful prompt wording every time. A dedicated command would make the workflow explicit, repeatable, and easier to trust.
Expected behavior
/codex:test would ideally:
Suggested scope
By default, this command should behave like a test-writing mode for Codex:
This feels like a natural pairing:
Alternative
If a new command is too much, an officially documented preset mode for /codex:rescue that means only write tests for the current diff would also help.
Thanks for considering it.