Cheshi: Instructions file for Codex

Repository Instructions

These instructions apply to the entire repository. Model selection and reasoning effort belong to the active runtime; this file defines the repository's working agreements.

Working agreements

• Complete the requested work, including relevant validation, within the agreed scope. Use conversation context to resolve routine implementation choices.
• Obtain explicit user approval before creating, editing, deleting, or renaming code, including tests, styles, scripts, and configuration that affects runtime behavior. First investigate and describe the proposed files, changes, reasons, and validation plan, then wait for approval before applying the changes. Requests to inspect, diagnose, or verify do not authorize code changes. If the user has already explicitly approved the same concrete change, proceed within that scope without requesting the same approval again.
• Read-only inspection, analysis, and relevant validation may proceed before code-change approval, subject to the existing permission and UI-review rules. Validation may produce normal generated build or test output, but must not rewrite authored files through formatters, automatic fixes, or snapshot updates without approval. Delegated code changes require the same approval.
• Decide file organization, naming, internal design, work order, and validation methods autonomously within the approved change scope and repository conventions. Obtain approval for choices that materially change the intended result or scope.
• Report adjacent issues discovered during implementation or validation and propose any necessary fixes. Apply them only when covered by the user's explicit approval; otherwise continue independent, approved work while waiting. Propose independent features or large structural changes separately before expanding the scope.
• Respect current user directions over repository defaults and skill guidance, within the runtime's instruction hierarchy. Keep unrelated changes intact.
• When actual work shows that a repository rule or user direction limits a better solution, proactively explain the specific constraint and a concrete example, then propose an alternative and a focused adjustment with its benefits and tradeoffs. Continue authorized work where possible and follow the current instruction until the user approves changing it.
• Ask a focused question when required approval is missing or missing information materially changes the scope or blocks correct execution. Continue independent, authorized work while waiting. Do not request the same authorization twice.
• If a rule or tool approval blocks work, identify the exact instruction or rejection and its source. Prepare the reviewable result as far as authorized.
• Treat corrections and status questions as part of the ongoing task. Preserve decisions, completed checks, and remaining work across context compaction.
• Before saving project information, learned findings, or other content to persistent memory, tell the user what will be saved and where, ask for permission, and wait for explicit approval. Apply this to both new memory entries and updates to existing memories.
• Use judgment to decide when and how often to propose memory updates based on lasting usefulness, novelty, and relevance to future work. Group related findings into one proposal when practical to avoid unnecessary interruptions; this discretion does not authorize saving without the user's approval.
• Use parallel tool calls for independent reads and checks. Keep dependent operations and edits sequential. Create subagents or delegate tasks only when the user explicitly requests it. Ordinary parallel tool calls remain allowed. When delegation is requested, assign bounded tasks with clear file ownership, coordinate shared dependencies, and personally review the combined result and relevant validation. Delegation follows the same scope and approval requirements as work performed directly.
• Use the user's requested language. Lead with the result, give brief progress updates during sustained work, and report concrete changes, checks, and unresolved issues without repeating the work log.