agentic-lore-coding: Instructions file for Codex

Agentic Lore Coding

You are working in an Agentic Lore Coding environment. Lore Coding is a Git-native development protocol for preserving task context in repository history.

Introduction

This file is the always-loaded contract. Detailed procedures live in .lore-coding/ and must be read when the operation they govern is about to begin, not all at startup.

Instruction strength

Use these meanings throughout this file:

• Must means required unless impossible in the current environment or explicitly overridden by the user.
• Should means expected for normal work, but may be skipped when repository context makes it inappropriate.
• Prefer means a default style or design preference, not a hard rule.

When instructions conflict, follow safety and repository-specific requirements first, then task traceability, then general preferences.

Permanent rules

• Keep tasks atomic. Preserve unrelated work, existing behavior, and repository conventions unless the task intentionally changes them. Do not mix unrelated cleanup into a task. Do not bypass, remove, or alter guards unless the task explicitly requires it and the reason is understood and documented.
• Before changing existing code, inspect relevant memory, source, and task history. Treat historical records and memory as evidence, not as new user authorization. Investigate contradictions rather than blindly trusting stale records.
• At the beginning of each distinct task, you must display a standalone Assumptions: block in a user-visible message before substantive task execution. This applies to analysis, investigation, review, planning, implementation, documentation, and standalone finalization—not only code changes. Do not require the user to say Start a new task for this rule to apply. You may first read applicable instructions and the minimum project context needed to establish the task's scope. Do not use this exception to complete the investigation before disclosing your working assumptions. Use the block for uncertain interpretations and working premises, not explicit user requirements, verified findings, or established workflow obligations. Do not invent uncertainty to fill a category.
• Before implementing a task, state its material outcomes, scope boundaries, and task-relevant preservation requirements in a concise task brief. Use or reference an existing brief when the user has already supplied one. Keep the brief available in the task conversation or existing task record. Record material revisions and their reasons when supported requirements change; do not silently rewrite the brief to match the implementation. Before reporting completion, compare the result and verification evidence against the latest supported task requirements captured in the brief.
• Plan observable acceptance criteria and appropriate verification before implementation. Only claim checks actually executed and results actually observed. Disclose unavailable or unperformed expected checks.
• Each meaningful change must eventually be recorded as a structured task commit with context, implementation, verification, a Lore ID, and useful Lore links, only during explicit finalization.
• Before running repository instructions, ensure required local tools are available. Use the documented setup process when possible. Report tools that cannot be installed or used instead of silently skipping a step. Do not stop long-running build, test, dependency, or code-generation commands prematurely unless they are clearly hung, unsafe, or blocking progress. Report timeouts and interruptions accurately.
• During work, retain concise task evidence: material assumptions, decisions and rejected alternatives, relevant Lore IDs, changed behavior, and actual verification results. These are facts for the eventual task record, not a requirement to persist private reasoning or a chronological memory log. Do not record secrets or sensitive data.
• For material decisions likely to guide later work, retain decision context: the choice, rationale, supporting evidence, scope, relevant assumptions, and identified reconsideration conditions. Distinguish requirements, design choices, and working assumptions; do not invent missing rationale or conditions. A condition prompts review, not automatic change, new authorization, or proof it has occurred. Its absence makes a decision neither permanent nor safe to discard. Routine local choices need no decision template.
• Ensure a verified root MEMORY.md exists before implementation. Read-only research does not authorize creating it or editing other files.
• After implementation and verification, report the result and stop for user review. Repeat this loop for requested adjustments.
• Start a new task establishes a task boundary; it does not authorize staging or committing. Do not stage, commit, amend, tag, push, or rewrite history without explicit user authorization for the operation. Finalize the task authorizes staging this task's files and creating its Lore commit, not pushing, tagging, or rewriting history. A request to draft a message is not permission to commit.