# Project working rules — public starter This complete, anonymized template is based on the current `starter/project/AGENTS.md` in the Codex Engineering System. It preserves its structure and rules. The `WHY` notes explain the role of each section; fields in square brackets must be completed only from the actual project. This is a framework to complete before use. Replace fields in square brackets using actual project files and team decisions. Do not enter access credentials. Keep this file as a short contract and map of sources. Do not add the current status, further checkpoints, a full decision history, or test results here. Record them in one plan, decision register, or evidence record and link to them. After a larger change, check the file size and, in a fresh session, ask Codex to identify the instructions it read. The default combined project-instruction limit is 32 KiB; increasing it does not fix poorly separated knowledge. ## Goal and sources - Project goal: [agreed goal]. - Requirements and expected behavior: [existing file or link]. - Solution design and important decisions: [existing source]. - One current task plan: [record location]. - Code and settings show the current state. Report a mismatch with requirements instead of silently changing expectations. ## Execution and acceptance - Running the project: [verified command or explicit absence]. - Tests and other checks: [verified commands or explicit absences]. - Work path: [feature being prepared for technical acceptance / own project]. - Before changing a company or shared environment, describe one approved work package: intended outcome, known files or areas, checks, material risks, and expected blast radius. Unless the project contract narrows it, that approval covers implementation, ordinary fixes, tests, regressions, independent review, affected source documentation, and reversible updates to an already approved local demo. It does not automatically authorize commits, pushes, publication, or another external action. - Complete an approved package through a meaningful stage. Ask again only if its goal, scope, acceptance criteria, or material risk changes, or a separate Human Gate applies. Name a host, sandbox, account, tool, or policy block as such; never portray it as a general need to reapprove ordinary repairs. - A feature prepared by a person without programming experience requires acceptance by an authorized technical person. The agent can prepare a review, but does not replace a human. Until then, the status is awaiting CR. - Technical acceptance covers secrets, security, data, permissions, and compliance with project rules. Do not put secret values in the report. - Completion conditions: agreed result, required checks, independent review, closed required fixes and decisions, current knowledge, and disclosed limits. - Record evidence for the assessed version and the next step in the existing plan. ## Team rules - Permitted scope of independent work: [agreed scope]. - Decisions and actions requiring approval: [boundaries set by the team]. - Person or role accepting the result: [agreed responsibility]. - Do not change the goal or team standards without the appropriate approval. - When working in parallel, agree the change areas and how they will be combined. - Information and the plan remain shared regardless of the assistant in use. - Do not copy account settings or a single person's preferences here. - A repair to code that checks existing permissions or already supplied credentials can be ordinary work in an approved package. A new or broader grant, changed or exposed secret, weaker control, account switch, or production identity-policy change needs the applicable Human Gate. ## Area instructions and Skills - Put a rule that concerns only one area in that area's nearest instruction, and state here only the condition for reading it. - Put a repeatable specialist process in a Skill. For Codex, a project Skill should be located at `.agents/skills//SKILL.md`. - If the team synchronizes Skills to several tools, name one source, every supported directory, a manifest of managed files, and a command that detects a missing file, changed content, an extra file, and an old copy. - A synchronization mechanism may remove only files it previously marked as managed. It must reject names and paths outside the allowed directory and preserve independently installed Skills. When a target file exists outside the manifest, stop work; do not overwrite it or take it into the manifest without an explicit decision. - After a change, verify discovery of rules and Skills in a fresh session of every tool in use. A file's presence does not prove that a tool reads it. ## Access protection and technology alignment - Never ask for login details, passwords, one-time codes, or private keys in a conversation. Do not read or disclose secret values. - Do not disable the sandbox or expand permissions to bypass a block. - Never suppress or work around an automatic security control. - Identify existing technologies and confirm the team standard. New technologies or providers require agreement before implementation. ## Technology and interface - Technical contract in the current plan: [link or explicit absence]. - Frontend: [required or selected standard and version]. - Backend, database, and authentication: [standards and versions]. - Tests, hosting, and deployment: [standards and verified commands]. - Required / preferred / prohibited / undecided elements: [decision source]. - Interface contract in the current plan: [link or not applicable]. - Component library and design system: [standard and version or explicit absence]. - Brand book or other visual source: [link or explicit absence]. - Component catalog and reference screens: [link or explicit absence]. - Phone, accessibility, and shared interface states: [agreed requirements]. - Do not choose an undecided technology independently. Present a recommendation, cost, limits, and at most one alternative; obtain a decision before installing. - Before building new screens, use the existing standard. If none exists, propose at most three libraries compatible with the frontend and one direction. After selection, use the contract instead of designing every view from scratch. ## Reporting progress and the next step - After every task, state the result, completed checks, limits, and the current stage from the plan. Distinguish execution, verification, and required acceptance; do not label a pending human review as completed acceptance. - End the report with “Next step: …”, naming the specific action from the plan and its executor or decision-maker. Name required approvals and blockers. - After a stage is complete, update the existing plan within the approved scope, identify the completed and next stage, and state progress over the whole planned scope. If the update is not allowed, report the pending update. - Calculate progress from the current plan: state its source, numerator, and denominator, for example “6 of 20 tasks accepted — 30% of task count; 2 of 8 stages complete”. Do not equate the task count with time, effort, or product readiness. Do not count partial tasks as accepted or count subtasks twice. - If the plan uses agreed weights, state the calculation. Do not invent weights or a percentage. When the scope changes, explain the changed calculation base. When there is no complete plan, state the known status without a percentage and without inventing stages. - Use one existing plan; do not create a separate progress document. Naming a next step does not expand authorization to work. If further work is assigned and permitted, report and continue without an unnecessary stop. - When the whole agreed scope is complete, say so. Do not add tasks merely to have a next step; state the pending acceptance, if applicable, or that no further work remains in the agreed scope. ## Live Demo session - After a meaningful stage, prepare a credible demonstration and begin a Live Demo Session: name the project and stage and explain “I show it, you comment, I fix it quickly; the target implementation with all technical requirements follows demo acceptance.” Use visible Computer Use and an active voice conversation; when voice is unavailable, say so and use brief text. - Lead one view at a time: “Do you accept this view?” Yes → next view; no → “What should change?” Implement direct comments without another question. Small change → risk-appropriate check → the same refreshed preview. Do not interrupt a series of comments with full tests, broad cleanup, or updates to all documentation after every visual correction. Check risky changes at once. A checkpoint verifies technical state but does not end the session. - Suggest more feedback or closing the session. The end of feedback is not acceptance. After showing every requested change, separately ask for acceptance of the named-stage demo and the start of target implementation. A natural, unambiguous response is sufficient; do not require commands or renewed approval. Clarify ambiguities. Acceptance of one view, silence, and “OK” after one small correction do not accept the whole result. - A break without acceptance pauses the session. Record the state, decisions, rejected variants, open feedback, and accepted version in one existing plan. Do not create a new worktree or journal for every comment. Before switching projects, record the state; on return, confirm the correct context. - After acceptance, bring the entire change up to architecture, testing, security, and project-integration requirements, remove provisional work, and perform mandatory checks before acceptance. A change to accepted behavior goes back to the demo. Demo acceptance does not replace technical acceptance or approval to merge or release. - Use a safe preview and fictional data; preserve secret protection, account boundaries, and required approvals. For a stage without an interface, show the artifact and verification evidence. When blocked, state the reason and “demo pending” in the existing plan. Do not claim a demonstration that did not occur. After the session, state the stage status and next step.