English Request Sentences for Codex Collaboration

This note is a sentence bank for someone who wants ready-to-use English requests for working with Codex in a repository.

The goal is not to learn prompt theory first. The goal is to keep useful developer work sentences in one place, copy them whole at first, and later swap in the file, behavior, constraint, or document that matters.

Use these sentences when you want Codex to read code, analyze before editing, make a narrow change, preserve repository rules, review the result, or turn Korean intent into natural developer English.

Core Sentences to Learn First

These sentences cover many ordinary Codex requests.

• Read AGENTS.md first and follow the repository policy.
• Do not edit files yet.
• First, review the relevant files and propose a plan.
• Find the relevant files for this task.
• Explain how this file works.
• Trace the code path step by step.
• Identify the most likely cause.
• Fix this with the smallest reasonable change.
• Do not change unrelated files.
• Preserve the existing behavior.
• Do not redesign the structure unnecessarily.
• Run or update the relevant tests if needed.
• Explain why each change is needed.
• Keep the diff easy to review.
• Keep the change narrow and focused.
• Revise this document for clarity.
• Prioritize precision over style.
• Preserve the beginner's likely confusion.
• Verify that the result satisfies the requirement.
• Summarize what changed and why.

Reading Code

Use these when you want Codex to explain code before changing it.

• Explain the responsibility of this file.
• Explain what this class is responsible for.
• Explain what this method does.
• Explain the overall flow step by step.
• Explain where this flow starts and where it ends.
• Find the files that are involved in this flow.
• Identify the important decision points in this logic.
• Point out any risky or confusing parts.
• Explain what input this code handles.
• Explain what output or side effect this code produces.

Analyzing Before Editing

Use these when you want Codex to slow down and understand the task before it edits files.

• Do not edit files yet. Analyze the problem first.
• First, identify the relevant files.
• Show me the proposed plan before making changes.
• List the files you expect to change.
• Explain why each file needs to change.
• State any assumptions you are making.
• Point out the risks before editing.
• Compare the possible approaches before choosing one.
• Propose the smallest reasonable fix.
• Summarize your understanding of the task before editing.

Requesting Code Changes

Use these when the desired change is clear enough for Codex to implement.

• Implement this requirement.
• Modify this file so that it handles this case.
• Add handling for this condition.
• Handle this edge case.
• Make sure the existing behavior is not affected.
• Keep the implementation as small as possible.
• Change only what is necessary.
• Remove unnecessary duplication.
• Make the code easier to read.
• Rename this to make its purpose clearer.
• Reduce unnecessary complexity.
• Extract this logic into a separate method.
• Keep the existing method signature.
• Do not change the public API.
• Keep the external behavior unchanged.

Debugging

Use these when the important task is finding the cause of a failure.

• Investigate why this problem happens.
• Find the path that reproduces this issue.
• Identify the most likely root cause.
• Use the log output as the starting point.
• Trace the issue from the error message.
• Find where the value becomes incorrect.
• Explain under what condition this fails.
• Pinpoint the failing point.
• Fix the root cause, not just the symptom.
• Explain the cause before applying a fix.

Testing

Use these when the change needs test discovery, new tests, or test verification.

• Find the relevant tests for this behavior.
• Add tests for this behavior.
• Update the existing tests if needed.
• Add a test for the failure case.
• Cover the edge case in a test.
• Avoid making the test too tightly coupled to the implementation.
• Use a clear test name that describes the behavior.
• Verify that the relevant tests pass.
• Run the relevant tests first.
• If you do not add tests, explain why.

Revising Insight Vault Documents

Use these when asking Codex to edit notes, MOCs, README files, or other repository documents.

• Revise this document for clarity.
• Do not rewrite the whole document unnecessarily.
• Preserve the existing structure.
• Make the definition more precise.
• Explain the point where beginners are likely to get confused.
• Add a clearer distinction from nearby concepts.
• Add one concrete example.
• Explain what the example reveals.
• Explain what the example does not cover.
• Make the final takeaway more durable.
• Remove hype or overly broad claims.
• Prioritize clear explanation over a polished blog tone.
• Make this read as a standalone note.
• Make the heading more precise.
• Improve the transitions between sections.

Constraints and Boundaries

Use these when you need to tell Codex what not to change.

• Do not perform unrelated refactoring.
• Do not change the file structure.
• Do not rename things broadly.
• Do not add new dependencies.
• Do not modify configuration files unless necessary.
• Do not change public interfaces.
• Do not remove existing tests.
• Do not make large changes without explaining why.
• Do not over-polish the writing.
• Do not change the original intent.

When a Change Is Too Broad

Use these when Codex changed more than the original task required.

• This change is too broad.
• Keep only the changes needed for the original task.
• Revert the unrelated edits.
• Make the diff smaller and easier to review.
• Remove the refactoring from this change.
• Do not mix behavior changes with documentation changes.
• For this pass, make only the minimal fix.
• Do not modify this file.
• Keep only this part of the previous change.
• Restore the rest to the original version.

Reviewing the Result

Use these after Codex has analyzed or changed something.

• Summarize the changes you made.
• Explain why you made these changes.
• Check whether the result matches the requirement.
• Check if anything is missing.
• Point out any possible side effects.
• Review this from a code reviewer's perspective.
• Check if there is a simpler approach.
• Check whether this change is larger than necessary.
• Point out any test coverage gaps.
• Tell me how to verify this change.

Preserving Korean Intent

Use these when the English output should reflect Korean source meaning without becoming a literal translation.

• The Korean context below explains the core intent.
• Preserve this nuance in the final result.
• Do not translate it literally; reflect the meaning accurately.
• Keep the final document in English.
• Use the Korean explanation only as context.
• The main point I want to express is this.
• Make sure this part is not misunderstood.
• Make sure this distinction does not become blurry.
• Preserve the intent of the Korean source text.
• Convert this into natural developer English.

Complete Request Examples

Use these when you want to send a fuller request instead of a single sentence.

Code analysis:

Read AGENTS.md first and follow the repository policy. Do not edit files yet. Find the relevant files for this flow and explain how the code works step by step. Point out any risky or confusing parts.

Bug fixing:

Read AGENTS.md first and follow the repository policy. Investigate why this problem happens. Identify the most likely root cause first, then propose the smallest reasonable fix. Do not change unrelated files.

Document revision:

Read AGENTS.md first and follow the repository policy. Revise this document for clarity. Make the definition more precise, preserve the beginner's likely confusion, and add a clearer distinction from nearby concepts. Do not rewrite unrelated sections.

When Codex changed too much:

This change is too broad. Keep only the changes needed for the original task. Revert unrelated edits and make the diff smaller and easier to review.

When Korean intent matters:

Use the Korean explanation below only as context. Do not translate it literally. Preserve the meaning and write the final document in clear, natural English.

Starter Set

At first, memorize these five sentences as reusable building blocks.

1. Read AGENTS.md first and follow the repository policy.
2. Do not edit files yet.
3. First, review the relevant files and propose a plan.
4. Do not change unrelated files.
5. Summarize what changed and why.

Most Codex requests can start with one or two of these sentences, then add the specific file, behavior, document, or constraint that matters.