LMXF-specification/ChatGPT_1.md

Yes. For Codex, the closest equivalents are:

1. AGENTS.md for persistent project-wide instructions.
2. Codex Skills using SKILL.md for reusable workflows, very similar in spirit to the Claude Code file you linked.
3. Optionally PLANS.md / ExecPlan-style documents for long-running specification work.

The important correction is that Codex does now support Skills with SKILL.md, not just AGENTS.md. OpenAI’s Codex documentation says a skill is a directory containing a required SKILL.md file, with optional scripts/, references/, assets/, and related support files. Codex initially sees the skill name, description, and path, then loads the full SKILL.md only when it decides that skill applies. (OpenAI Developers)

So, yes: you can do essentially the same thing that thatSFguy is doing, but I would structure it slightly differently for LXMF.

Recommended Codex layout

For an LXMF specification repository, I would use something like:

lxmf-specification/
├── AGENTS.md
├── SPEC.md
├── NOTES.md
├── SOURCES.md
├── tools/
│   ├── extract_lxmf_constants.pl
│   ├── compare_upstream_lxmf.pl
│   ├── verify_examples.pl
│   └── make_test_vectors.pl
├── examples/
│   ├── lxmf_message_minimal.hex
│   ├── lxmf_message_signed.hex
│   └── lxmf_propagation_example.hex
├── references/
│   ├── lxmf_source_map.md
│   ├── rns_dependency_map.md
│   └── terminology.md
└── .agents/
    └── skills/
        └── lxmf-update/
            └── SKILL.md

Role of each file

AGENTS.md

Use this for always-on repository rules. Codex reads AGENTS.md before doing work, and the docs describe it as the mechanism for project-specific persistent guidance. (OpenAI Developers)

Example use:

# AGENTS.md

## Repository purpose

This repository attempts to define an implementation-derived specification for LXMF.

Do not treat upstream prose documentation as authoritative when it conflicts with observed source behavior. Prefer source code, test vectors, and reproducible traces.

## Required discipline

- Distinguish normative behavior from observed implementation behavior.
- Cite exact upstream files, functions, classes, constants, and version tags.
- Do not invent protocol rules.
- When behavior is unclear, mark it as "undetermined" rather than guessing.
- Prefer Perl tools for extraction, comparison, and report generation.
- Keep generated examples reproducible from scripts under tools/.

.agents/skills/lxmf-update/SKILL.md

Use this for the repeatable workflow: “check upstream LXMF/RNS, compare against our spec, update citations, run verifiers, propose diffs.”

That is the closest Codex analog to the Claude Code rns-update/SKILL.md you found.

A minimal Codex skill might look like:

---
name: lxmf-update
description: Check upstream LXMF and RNS implementations for changes affecting the LXMF specification, run local verifier tools, and propose spec updates with citations.
---

# LXMF update skill

Use this skill when asked to check whether the LXMF specification is current with upstream LXMF or RNS.

## Sources of truth

Prefer, in order:

1. Upstream LXMF source code at a pinned release or commit.
2. Upstream RNS source code where LXMF behavior depends on Reticulum behavior.
3. Reproducible local traces and test vectors.
4. Upstream prose documentation, only when consistent with source behavior.

## Required workflow

1. Determine the currently pinned upstream LXMF and RNS versions from `SOURCES.md`.
2. Check whether newer upstream releases or commits exist.
3. Identify changed files relevant to:
   - message packing
   - fields and flags
   - destination handling
   - identity/signature behavior
   - encryption behavior
   - propagation
   - delivery semantics
   - storage format if externally observable
4. Run the verifier tools in `tools/`.
5. Compare observed behavior against `SPEC.md`.
6. Produce a report with:
   - changed upstream files
   - affected specification sections
   - proposed edits
   - test-vector impact
   - unresolved ambiguities
7. Do not modify `SPEC.md` unless explicitly asked.

Codex supports skills in the CLI, IDE extension, and Codex app, and the documented repository skill location is .agents/skills under the current directory or repository root. (OpenAI Developers)

PLANS.md

For your use case, I would also add a planning document, because “derive a protocol specification from implementation” is not a one-shot coding task. OpenAI’s Codex cookbook describes using PLANS.md / ExecPlans for long-running, multi-stage work, with AGENTS.md telling Codex when to use it. (OpenAI Developers)

For LXMF, PLANS.md could define the required sections of each investigation:

# LXMF Specification Investigation Plan

Each investigation must include:

1. Question being answered.
2. Upstream files inspected.
3. Exact version or commit.
4. Relevant classes/functions/constants.
5. Observed behavior.
6. Whether behavior is normative, inferred, or unresolved.
7. Test vectors needed.
8. SPEC.md sections affected.
9. Open questions.

My recommendation

For your goal, I would not start by asking Codex to “write the LXMF specification.” That is too broad and likely to produce confident prose ahead of evidence.

I would instead give Codex narrow tasks such as:

Using the lxmf-update skill, inspect upstream LXMF and determine the exact serialized structure of an LXMessage. Do not edit SPEC.md. Produce a report listing every field, its source-code origin, and whether its behavior is confirmed by a test vector.

Then:

Create Perl tooling under tools/ that extracts or verifies the LXMF message packing behavior described in the report. Generate at least one reproducible test vector.

Then:

Update SPEC.md section "LXMessage Wire Format" using only behavior confirmed by source inspection or verifier output. Mark all unverified behavior as unresolved.

Bottom line

Yes, you can accomplish the same kind of workflow with Codex. In fact, Codex gives you both mechanisms:

AGENTS.md for standing repo rules, and SKILL.md under .agents/skills/... for a reusable “LXMF update / spec maintenance” workflow. OpenAI’s Codex docs explicitly describe customization as a combination of AGENTS.md, skills, MCP, memories, and subagents; for your use case, AGENTS.md plus a SKILL.md skill is the right starting point. (OpenAI Developers)