jlpoole/LMXF-specification
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

After accomplishing Task 2, see Codex_Response... for details.

Browse source
This commit is contained in:
John Poole 2026-06-06 09:41:48 -07:00
commit d483d40d5c
16 changed files with 888 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

174
ChatGPT_1.md Normal file
View file

@ -0,0 +1,174 @@
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][1])
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:
```text
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][2])
Example use:
```markdown
# 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:
```markdown
---
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][1])
### `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][3])
For LXMF, `PLANS.md` could define the required sections of each investigation:
```markdown
# 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:
```text
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:
```text
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:
```text
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][4])
[1]: https://developers.openai.com/codex/skills "Agent Skills – Codex | OpenAI Developers"
[2]: https://developers.openai.com/codex/guides/agents-md "Custom instructions with AGENTS.md – Codex | OpenAI Developers"
[3]: https://developers.openai.com/cookbook/articles/codex_exec_plans "Using PLANS.md for multi-hour problem solving"
[4]: https://developers.openai.com/codex/concepts/customization "Customization – Codex | OpenAI Developers"