agentleFS
Sign inStart free
kiku-jwkiku-jw/codex-skills/codex-execution-pack/SKILL.md

codex-execution-pack

Skill0 starsChanged 4 months agoMITView on GitHub

Build a Codex execution pack from a raw task or PRD: `AGENTS.md` plus `docs/PLAN.md`, `docs/STATUS.md`, `docs/TEST_PLAN.md`, and `docs/BACKLOG.md`, with optional prompt surfaces and a spec companion when the work is large enough to justify them.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not use when: the work is tiny, highly reversible, or better served by a short execution brief.

    line 10
  2. Distinctive:

    Create a durable execution harness that survives long runs and resumptions by separating execution policy, plan, live status, validation, …

    line 14
  3. Distinctive:

    Do not generate a full pack for tiny work.

    line 22
  4. Distinctive:

    Every meaningful milestone has explicit validation, repair-before-continue expectations, and a durable status surface.

    line 23
  5. Distinctive:

    If issue or board sync fails, that fact is written into the pack instead of disappearing into chat.

    line 25

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Codex Execution Pack

Metadata

  • Trigger when: the user wants a durable operating pack for Codex instead of a loose spec or one-off prompt.
  • Do not use when: the work is tiny, highly reversible, or better served by a short execution brief.

Skill Purpose

Create a durable execution harness that survives long runs and resumptions by separating execution policy, plan, live status, validation, and backlog into explicit files.

Instructions

  1. Decide whether a full pack is honest. If the source is still fuzzy, route through $idea-validation or $spec-bundle first. If the pack is justified, scaffold it with ~/.codex/skills/codex-execution-pack/scripts/init_execution_pack.py. Use ~/.codex/skills/codex-execution-pack/references/pack-shape.md only when you need the exact file roles.
  2. Fill only the artifacts that materially improve execution quality: AGENTS.md, docs/PLAN.md, docs/STATUS.md, docs/TEST_PLAN.md, and docs/BACKLOG.md, plus optional prompt surfaces or spec/ files when they reduce ambiguity. Keep one source of truth per concern.
  3. Validate the pack. Every milestone must have concrete validation commands, docs/STATUS.md must own live done/now/next state, and the pack must stay synchronized with any separate spec bundle instead of forking reality.

Non-Negotiable Acceptance Criteria

  • Do not generate a full pack for tiny work.
  • Every meaningful milestone has explicit validation, repair-before-continue expectations, and a durable status surface.
  • Prompt surfaces and spec companion files exist only when they reduce ambiguity or recovery cost.
  • If issue or board sync fails, that fact is written into the pack instead of disappearing into chat.

Output

  • The created or updated pack files on disk.
  • A short summary of what starts first, which validation gates matter most, and what would stop execution.
  • Any missing input or blocker that prevents the pack from being truly executable.
  • Next skill options (only if needed): $spec-bundle — add deeper contracts or architecture artifacts; $justdoit — drive execution from the generated pack; $continuity-ledger — preserve durable state across long execution runs.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free