estatewise-codex-support

# EstateWise Codex Support Use this skill when the task is about Codex itself in this repository rather than product code. ## Codex Extension Surfaces In This Repo - Root guidance: `AGENTS.md` - Nested guidance: package-level `AGENTS.md` files under repo subdirectories - Codex skills: `.agents/skills/` - Codex config: `.codex/config.toml` - Codex multi-agent role configs: `.codex/agents/*.toml` - Codex rules: `.codex/rules/*.rules` Read `references/codex-extension-checklist.md` when the change spans more than one of these surfaces. ## Design Rules 1. Keep root `AGENTS.md` repository-wide and stable. 2. Put subsystem-specific guidance into nested `AGENTS.md` files close to the owning package. 3. Keep each skill focused on one job with a sharp description that clearly states when it should and should not trigger. 4. Use `agents/openai.yaml` for UI metadata and invocation policy rather than bloating `SKILL.md`. 5. Prefer concise metadata and concise skill bodies; move heavier material into `references/`. 6. Only add rules for command families that are genuinely risky or repeatedly worth controlling. 7. Use the OpenAI Developers docs MCP server when verifying current Codex behavior instead of relying on memory. ## Skill Creation Checklist For each new or updated skill: 1. Keep frontmatter to `name` and `description` only. 2. Make the description explicit about trigger scope and non-goals. 3. Keep the body imperative and procedural. 4. Add `agents/openai.yaml` with: - `interface.display_name` - `interface.short_description` - `interface.default_prompt` - `policy.allow_implicit_invocation` 5. Add `references/` only when the extra material is genuinely needed later. 6. Do not add README or changelog files inside the skill directory. ## AGENTS Layering Checklist When adding nested `AGENTS.md` files: 1. Keep them narrower than the root file. 2. Focus on package ownership, high-risk files, contract edges, and validation commands. 3. Avoid restating large portions of the root instructions. 4. Place overrides as close to specialized work as possible. ## Rules Checklist When adding `.codex/rules/*.rules`: 1. Use `prompt` for risky command families with legitimate uses. 2. Use `forbidden` only when the alternative is clear and the project truly never wants the command. 3. Add `match` and `not_match` examples to catch mistakes. 4. Prefer exact prefixes over broad wrappers like `bash -lc`. ## Validation After editing Codex support files: - Re-read affected `AGENTS.md`, skill, config, and rules files for conflicts. - Validate TOML/JSON syntax where relevant. - Run `git diff --check`. - If you added or changed rules, sanity-check the rule shapes and examples carefully. ## Documentation Update these when Codex support changes: - `.agents/README.md` - `.codex/README.md` - root `README.md` only if repository-wide contributor workflow materially changed