# Request

Correct this sentence without changing its meaning: She don't like cold coffee.

# File AGENTS.md

# Task rules

Follow the user's request and higher-priority instructions. Keep private information out of shared examples. Do not invent facts or claim checks that were not performed.

Choose the task before reading detailed rules. Read the matching files below, then apply them to the answer. These paths are ordinary references, not automatic imports.

- For writing, grammar or word choice, read rules/writing.md.
- For code changes or debugging, read rules/code.md.
- For everyday plans and practical questions, read rules/everyday.md.
- For investment questions, read rules/investing.md.

For mixed tasks, read every relevant file. If no topic matches, use these basic rules. Do not read unrelated files just because they are listed. If a required file cannot be read, say so instead of pretending its rules were applied.

# File rules/writing.md

# Writing rules

Preserve the meaning, names, dates and amounts in the supplied text. Correct grammar and unclear wording without adding new claims. Use common English words and direct sentences. Keep the tone suitable for the intended reader.

For a request to correct one sentence, return the corrected sentence. Do not turn it into a long lesson unless the user asks for an explanation. For an email, keep the requested level of formality. Ask about an unclear meaning if correcting it would require guessing.

Do not replace a cautious claim with a confident promise. If a passage includes technical claims, load the relevant subject rules too rather than treating factual changes as grammar corrections.

# File rules/code.md

# Code rules

Read the relevant source before changing it. Identify the reported behavior and the expected result. Make the smallest useful change that addresses the cause. Keep public interfaces and file formats compatible unless a change is requested.

Use checks suited to the change. For a bug fix, try to reproduce the failure, then confirm the corrected behavior. For changes to calculations or parsing, check boundary inputs as well as the example that failed. Report checks that could not be run.

Do not add dependencies without a clear need. Do not include secrets in logs or examples. Never describe code as tested when it was only read. Review generated code before running it and follow the workspace's actual execution permissions.

# File rules/everyday.md

# Everyday rules

Use the practical constraints the user gives. For planning, keep the available time and location in view. If a detail can change, such as an opening time or a train departure, check a current source when that detail matters.

Separate a suggestion from a confirmed booking or action. Do not claim a reservation exists when the task only produced an idea. Use a simple plan that fits the user's stated budget and preferences rather than a long list of unrelated alternatives.

If the request lacks a necessary detail, ask a short question. Otherwise make a reasonable assumption and state it where it affects the answer. Treat examples about health or safety with the appropriate care and verify material claims.

# File rules/investing.md

# Investment rules

Separate reported facts, assumptions and opinions. Check the date, currency and reporting period of each financial figure. Use current primary sources for facts that could have changed. Compare figures only when their definitions and periods match.

Revenue is not profit. A share price change is not proof of what caused it. An annualized revenue pace is not the same as sales already earned during a completed year. State uncertainty rather than filling missing figures with a confident guess.

Do not promise returns or assume that a company with a useful product is a suitable investment for a particular person. Explain what evidence is missing from a comparison. For hypothetical calculations, label the assumptions and show enough arithmetic for the result to be checked.
