This note is a memorization bank for practical English sentences that can be pasted into Codex requests. It is not mainly about prompt theory. It is about reusable developer English: sentences that tell Codex what work to do, what to inspect, what boundaries to respect, and how to report the result.
For the conceptual explanation of why these sentences work, see Codex Work Sentences.
The useful way to memorize these sentences is not to treat them as translations from Korean. Memorize each sentence with the work move it performs.
The Core Definition
A Codex request sentence is a developer work instruction in English. At first, it is better to save common sentences as reusable chunks and swap in the task-specific details than to invent every sentence from scratch.
The sentence usually controls one of four things:
- the task Codex should perform
- the context Codex should inspect
- the boundary Codex should not cross
- the verification or summary Codex should provide
Memorize These First
These five sentences are the default skeleton.
| Sentence | Use |
|---|---|
Read AGENTS.md first and follow the repository policy. | Use this at the start when repository rules matter. |
Do not edit files yet. | Use this when you want analysis before file changes. |
First, review the relevant files and propose a plan. | Use this when the task may have hidden context. |
Do not change unrelated files. | Use this when scope control matters. |
Summarize what changed and why. | Use this when you want a reviewable final answer. |
The practical pattern is:
Read the local rules. Inspect the relevant context. Keep the change narrow. Explain the result.
Basic Work Sentences
| Sentence | Use |
|---|---|
Read AGENTS.md first and follow the repository policy. | Start from the repository’s local instructions instead of generic assumptions. |
Do not edit files yet. | Stop Codex from making changes before the problem is understood. |
First, review the relevant files and propose a plan. | Create a checkpoint before editing. |
Find the relevant files for this task. | Use when you know the task but not the file location. |
Explain how this file works. | Ask for a file-level explanation. |
Trace the code path step by step. | Follow behavior across functions, files, or layers. |
Identify the most likely cause. | Move from symptom to likely cause. |
Fix this with the smallest reasonable change. | Ask for a narrow fix without forbidding necessary judgment. |
Do not change unrelated files. | Protect reviewability and scope. |
Preserve the existing behavior. | Make clear that current external behavior should remain stable. |
Do not redesign the structure unnecessarily. | Prevent a task from turning into a broad redesign. |
Run or update the relevant tests if needed. | Tie the work to verification. |
Explain why each change is needed. | Ask for change-by-change reasoning. |
Keep the diff easy to review. | Keep the final change focused and understandable. |
Keep the change narrow and focused. | Avoid expanding the task beyond the original need. |
Revise this document for clarity. | Ask for clearer writing without necessarily changing the meaning. |
Prioritize precision over style. | Prefer exactness over polished wording. |
Preserve the beginner's likely confusion. | Keep the learning path instead of hiding the hard part. |
Verify that the result satisfies the requirement. | Ask Codex to compare the result against the goal. |
Summarize what changed and why. | End with a short review summary. |
Reading Code
Use these when the goal is understanding, not immediate editing.
| Sentence | Use |
|---|---|
Explain the responsibility of this file. | Identify what role the file plays in the system. |
Explain what this class is responsible for. | Clarify the class boundary. |
Explain what this method does. | Ask for method-level behavior. |
Explain the overall flow step by step. | Turn a broad behavior into an ordered explanation. |
Explain where this flow starts and where it ends. | Locate the entry point and exit point. |
Find the files that are involved in this flow. | Discover the connected files. |
Identify the important decision points in this logic. | Find the branches that change behavior. |
Point out any risky or confusing parts. | Ask for hazards and likely misunderstandings. |
Explain what input this code handles. | Clarify the accepted input or trigger. |
Explain what output or side effect this code produces. | Clarify the result, mutation, write, network call, or visible behavior. |
Analysis Before Editing
These sentences are useful when a fast edit would be risky.
| Sentence | Use |
|---|---|
Do not edit files yet. Analyze the problem first. | Make diagnosis the first task. |
First, identify the relevant files. | Find the likely surface area before proposing changes. |
Show me the proposed plan before making changes. | Require a plan checkpoint. |
List the files you expect to change. | Make the likely diff surface visible. |
Explain why each file needs to change. | Force the plan to justify each touched file. |
State any assumptions you are making. | Expose guesses before they become edits. |
Point out the risks before editing. | Identify possible side effects first. |
Compare the possible approaches before choosing one. | Use when there are multiple plausible fixes. |
Propose the smallest reasonable fix. | Ask for a narrow option before implementation. |
Summarize your understanding of the task before editing. | Check whether Codex understood the task correctly. |
Implementation Requests
Use these when you are ready for Codex to change code.
| Sentence | Use |
|---|---|
Implement this requirement. | Ask for the requirement to be applied. |
Modify this file so that it handles this case. | Target one file and one case. |
Add handling for this condition. | Add a missing branch or behavior. |
Handle this edge case. | Cover a boundary condition. |
Make sure the existing behavior is not affected. | Protect current behavior while adding support. |
Keep the implementation as small as possible. | Prefer the smallest implementation that still works. |
Change only what is necessary. | Avoid unrelated cleanup. |
Remove unnecessary duplication. | Reduce duplication when it is genuinely unnecessary. |
Make the code easier to read. | Ask for readability improvement. |
Rename this to make its purpose clearer. | Improve naming around intent. |
Reduce unnecessary complexity. | Simplify only complexity that does not carry real value. |
Extract this logic into a separate method. | Move a coherent block into a named method. |
Keep the existing method signature. | Preserve callers and contracts. |
Do not change the public API. | Keep external contracts stable. |
Keep the external behavior unchanged. | Allow internal edits while preserving visible behavior. |
Bug Diagnosis
Use these when a symptom is visible but the cause is not yet clear.
| Sentence | Use |
|---|---|
Investigate why this problem happens. | Begin with diagnosis. |
Find the path that reproduces this issue. | Find a concrete failure path. |
Identify the most likely root cause. | Separate root cause from symptom. |
Use the log output as the starting point. | Anchor the investigation in logs. |
Trace the issue from the error message. | Start from the visible error and follow backward. |
Find where the value becomes incorrect. | Track the first point where data goes wrong. |
Explain under what condition this fails. | Identify the failing condition. |
Pinpoint the failing point. | Locate the exact breakage. |
Fix the root cause, not just the symptom. | Avoid a superficial patch. |
Explain the cause before applying a fix. | Require understanding before editing. |
Tests
Use these when correctness should be protected by tests.
| Sentence | Use |
|---|---|
Find the relevant tests for this behavior. | Locate existing verification first. |
Add tests for this behavior. | Add coverage for the intended behavior. |
Update the existing tests if needed. | Adjust tests when the intended behavior changed. |
Add a test for the failure case. | Preserve a bug reproduction as a test. |
Cover the edge case in a test. | Make a boundary case explicit. |
Avoid making the test too tightly coupled to the implementation. | Test behavior rather than private structure when possible. |
Use a clear test name that describes the behavior. | Make the test’s purpose readable. |
Verify that the relevant tests pass. | Run focused verification. |
Run the relevant tests first. | Start with the narrow test set before broader checks. |
If you do not add tests, explain why. | Make a no-test decision explicit. |
Documentation And Vault Writing
These are especially useful for documentation, README files, and Insight Vault notes.
| Sentence | Use |
|---|---|
Revise this document for clarity. | Improve explanation without changing the core meaning. |
Do not rewrite the whole document unnecessarily. | Avoid broad rewriting. |
Preserve the existing structure. | Keep the current organization unless it is the problem. |
Make the definition more precise. | Tighten the main concept. |
Explain the point where beginners are likely to get confused. | Preserve the likely confusion instead of skipping it. |
Add a clearer distinction from nearby concepts. | Separate similar ideas that may be confused. |
Add one concrete example. | Add a single clarifying example. |
Explain what the example reveals. | State the lesson carried by the example. |
Explain what the example does not cover. | Avoid overextending the example. |
Make the final takeaway more durable. | Strengthen the closing insight. |
Remove hype or overly broad claims. | Keep claims accurate and bounded. |
Prioritize clear explanation over a polished blog tone. | Favor understanding over style. |
Make this read as a standalone note. | Make the document usable without source context. |
Make the heading more precise. | Improve navigation and scope. |
Improve the transitions between sections. | Make the reasoning path easier to follow. |
Constraints And Boundaries
These sentences are negative constraints. They tell Codex what not to do.
| Sentence | Use |
|---|---|
Do not perform unrelated refactoring. | Prevent cleanup that is outside the task. |
Do not change the file structure. | Keep files and folders in place. |
Do not rename things broadly. | Avoid wide naming churn. |
Do not add new dependencies. | Avoid new library or package costs. |
Do not modify configuration files unless necessary. | Protect settings from incidental edits. |
Do not change public interfaces. | Preserve contracts for callers and users. |
Do not remove existing tests. | Protect current verification. |
Do not make large changes without explaining why. | Require justification for broad edits. |
Do not over-polish the writing. | Prevent style work from erasing useful meaning. |
Do not change the original intent. | Preserve the source meaning. |
When The Change Is Too Broad
Use these after Codex has expanded the work too much.
| Sentence | Use |
|---|---|
This change is too broad. | Name the scope problem directly. |
Keep only the changes needed for the original task. | Return to the original scope. |
Revert the unrelated edits. | Remove changes outside the task. |
Make the diff smaller and easier to review. | Reduce review burden. |
Remove the refactoring from this change. | Separate refactoring from the requested work. |
Do not mix behavior changes with documentation changes. | Keep change types separate when mixing would obscure review. |
For this pass, make only the minimal fix. | Narrow the next iteration. |
Do not modify this file. | Protect a specific file. |
Keep only this part of the previous change. | Preserve one useful piece. |
Restore the rest to the original version. | Undo the remaining unwanted edits. |
Reviewing The Result
Use these after Codex has made or proposed changes.
| Sentence | Use |
|---|---|
Summarize the changes you made. | Get a concise diff-level summary. |
Explain why you made these changes. | Get reasoning behind the edits. |
Check whether the result matches the requirement. | Compare implementation against the request. |
Check if anything is missing. | Look for incomplete work. |
Point out any possible side effects. | Surface risk. |
Review this from a code reviewer's perspective. | Ask for review-oriented judgment. |
Check if there is a simpler approach. | Look for a smaller or clearer solution. |
Check whether this change is larger than necessary. | Evaluate scope. |
Point out any test coverage gaps. | Identify missing verification. |
Tell me how to verify this change. | Get a practical verification checklist. |
Using Korean Context
Use these when Korean text explains the intent but the final output should be natural English.
| Sentence | Use |
|---|---|
The Korean context below explains the core intent. | Tell Codex that the Korean text is source context. |
Preserve this nuance in the final result. | Protect a subtle meaning. |
Do not translate it literally; reflect the meaning accurately. | Avoid word-for-word translation. |
Keep the final document in English. | Set the output language. |
Use the Korean explanation only as context. | Prevent the Korean text from appearing directly in the result. |
The main point I want to express is this. | Identify the key claim. |
Make sure this part is not misunderstood. | Protect a fragile or easily misread point. |
Make sure this distinction does not become blurry. | Preserve a conceptual boundary. |
Preserve the intent of the Korean source text. | Keep the source meaning. |
Convert this into natural developer English. | Rewrite the meaning as practical work English. |
Complete Request Templates
These templates combine several work sentences into one usable request.
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.
Use this when you want Codex to inspect and explain before editing.
Bug Fix
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.
Use this when the problem is visible but the cause still needs investigation.
Documentation 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.
Use this when the document should become clearer without losing the learning path.
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.
Use this when Codex expanded the task beyond the original request.
Korean Context Into English Output
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.
Use this when Korean source material carries the meaning, but the final artifact should be English.
Practical Rule
The goal is not to create new English from scratch every time. The goal is to memorize reusable Codex work sentences as chunks, then attach the task-specific detail.
A strong Codex request usually says:
- what to do
- what to inspect first
- what not to change
- how to verify or summarize the result
When a request sentence answers those questions, it becomes easier for both the human and Codex to know whether the work was done correctly.