174 lines
6.9 KiB
Markdown
174 lines
6.9 KiB
Markdown
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"
|
||
|