Operate
Codex editing workflows
Coordinate code edits so Codex handles file changes while Buffaly owns target selection, validation, and commits.
Role split
Keep responsibilities clear during coding work.
- Buffaly resolves the goal, repository root, files, constraints, and validation plan.
- Codex or the editing engine performs the bounded edit batch.
- Buffaly inspects the diff, runs validation, commits, and reports evidence.
Choose the right editing tool
Codex is a strong fit after Buffaly has clarified the target, goal, risks, and validation plan. A smaller patching tool can be better for tiny localized markdown, Razor, or configuration changes.
Use Codex for
- Source-code edits across related files.
- Refactors where local context matters.
- Documentation rewrites with consistent structure.
- HTML, CSS, JavaScript, and C# implementation changes.
Use a smaller tool for
- One-line or tightly localized content edits.
- Small configuration updates with obvious anchors.
- Planned changes where a full editing pass would add risk.
- Fixes that must avoid unrelated reformatting.
Batch size
Small coherent batches are easier to validate and review.
- Group related changes by page set, feature, or bug.
- Avoid mixing unrelated formatting, content, and behavior changes in one commit.
- Stop and validate when a batch changes enough that failures would be hard to diagnose.
Runbook
Use the same short loop for routine docs edits, bug fixes, and refactors.
- Start by naming the repository, target files, quality rules, and the validation command.
- Ask for the smallest coherent edit instead of a broad rewrite when the scope is unclear.
- Review the diff before validation so accidental formatting churn or unrelated files are caught early.
- Commit only the intentional files after validation passes, then report the command, result, and commit hash.
Validation
Every edit batch should end with direct evidence.
- Run the relevant build or tests before committing.
- Check generated pages or links when editing public docs.
- If validation fails, fix the root cause before starting another batch.
Good requests and common mistakes
Good requests
- "Inspect the current implementation first, then make the smallest safe edit."
- "Use Codex for the file changes, but validate with a build afterward."
- "Do not refactor unrelated files; commit only the intended batch."
- "If the contract is wrong, fix the authoritative contract instead of adding compatibility parsing."
Avoid
- Using Codex as a substitute for diagnosis.
- Starting one huge edit that mixes unrelated concerns.
- Mixing style cleanup with a bug fix that should be reviewed separately.
- Declaring the work complete without validation and a scoped commit.