DannyMac180/skills: two public AI agent skills for Codex and other agents

What DannyMac180/skills actually ships

This is a personal collection, not a framework. The README opens by calling the contents "Public AI agent skills by DannyMac180", and the repository holds exactly two of them. The first, codex-dynamic-workflows, is described as planning and running "supervised AI-agent dynamic workflows with goal mode, subagents or simulated work packets, approval gates, integration, verification, and reusable workflow artifacts". The second, explain-this, explains "any digital artifact (papers, articles, code) shaped by a persistent learner profile, with comprehension quizzes and spaced-repetition review".

The audience is narrow and specific: people who already have an AI agent that supports the skills convention and who want to hand it a prepared procedure rather than write one themselves. The repository is written in JavaScript and licensed MIT. It is not a library you import, and there is no package to add to a dependency file. What you get is a folder of instructions and supporting files that your agent reads.

One thing worth noticing before anything else: the top-level listing shows a third directory, codex-relay, that the README's "Available Skills" list does not mention. The README is the only documentation here, and it does not cover that folder. Treat the two listed skills as the supported surface.

How a skill is loaded, and what the two skills do differently

The mechanism is directory-based. An agent that supports skills looks in a skills directory, finds a named folder, and reads what is inside. The README's install example targets Codex's default folder, which it writes as "${CODEX_HOME:-$HOME/.codex}/skills", so the environment variable CODEX_HOME overrides the default of $HOME/.codex. Nothing in the repository describes a registry, a manifest resolution step or a runtime that fetches skills for you.

The two skills sit at opposite ends of the same idea. codex-dynamic-workflows is a coordination procedure: it structures a task into a goal, splits work across subagents or "simulated work packets", inserts approval gates where a human signs off, then integrates and verifies the result and leaves behind reusable workflow artifacts. The phrase "simulated work packets" in the README suggests the workflow can be rehearsed without dispatching real subagents, though the README does not explain when that mode is chosen.

explain-this is stateful in a different way. It keeps a persistent learner profile, and on first use it "interviews you (~10 min) and creates ~/.explain-this/". So the first invocation is not an explanation at all, it is a setup conversation, and everything afterwards is shaped by what you said during it. Comprehension quizzes and spaced-repetition review imply the skill expects repeat sessions rather than one-off answers. That is a real design commitment: a ten-minute interview is a poor trade for a single question and a reasonable one if you intend to keep using it on the same subject.

Installing a skill from GitHub into Codex

There are two documented routes. The first is to let the agent do it: point your agent at the GitHub URL for the skill folder and ask it to install that skill. The README gives this exact prompt form.

Install the AI agent skill at https://github.com/DannyMac180/skills/tree/main/codex-dynamic-workflows

This only works if your agent supports skills and has some way to fetch a URL. If it does not, use the manual route. The README's commands clone the repository, create the Codex skills directory if it is missing, and copy one skill folder into it.

git clone https://github.com/DannyMac180/skills.git
cd skills
mkdir -p "${CODEX_HOME:-$HOME/.codex}/skills"
cp -R codex-dynamic-workflows "${CODEX_HOME:-$HOME/.codex}/skills/"

After the copy, the skills directory contains a codex-dynamic-workflows folder. The README then says to start a new agent session, which matters because a running session has already scanned its skills directory. Invocation uses a dollar-prefixed name, and the README's example is:

Use $codex-dynamic-workflows to plan and run a supervised multi-agent workflow for this task: ...

Swap codex-dynamic-workflows for explain-this in both the clone-and-copy step and the invocation to install the other skill. The README explicitly says the destination path should be adjusted for your agent; the Codex path is an example, not a requirement.

Where this repo is thin, and where it will not help you

The README is roughly a page. It lists two skills, gives one install route with one agent's path, shows one invocation, and states the licence. It does not document how a skill folder is structured, what files an agent is expected to read, or how to write your own. If you want to modify codex-dynamic-workflows, you are reading the folder itself, not a spec.

There is no release history in the repository metadata, so there is nothing to pin to and no changelog to read before upgrading. Updating means re-cloning or re-copying the folder over the one in your skills directory, and the README does not describe how to do that safely or what happens to any local edits you made. If you have customised a skill in place, a plain copy over it is a destructive operation and the documentation is silent on the subject.

The last push to the default branch was on 2026-07-17, which is roughly two months before this writing. That is recent enough that the code is unlikely to have drifted far, but there is no stated support commitment, no issue triage process described, and no compatibility matrix naming which agent versions were tried. The install example assumes Codex; the README's own hedge, "Adjust the destination path for your agent", is the entire portability story.

Finally, explain-this writes a learner profile to ~/.explain-this/ in your home directory. That is a persistent, personal data store created by a skill you copied from a public repository. The README does not describe its format, whether it is plain text, or how to remove it.

Compared with writing the skill yourself or using a packaged agent framework

The realistic alternative is not another skills repository, it is writing the procedure yourself as a prompt file in your agent's skills directory. The difference is effort against fit. A hand-written skill encodes exactly the steps you want and nothing else, and you know why every line is there. codex-dynamic-workflows gives you a pre-built shape: goal mode, subagents or simulated packets, approval gates, integration, verification, artifacts. If that shape matches how you already work, you skip the design step. If it does not, you are adapting someone else's procedure, and the README gives you no guidance on which parts are load-bearing.

The second alternative is a general agent framework that manages multi-step runs in code, with explicit state and logging. Those give you inspectable execution and versioned dependencies. This repository gives you a folder that an agent reads and interprets, which is more portable across agents but far less deterministic. Nothing in the README claims reproducible runs, and the "approval gates" and "verification" steps are instructions to the agent, not enforced checkpoints in a runtime.

For explain-this the comparison is a spaced-repetition tool plus your own notes. Those keep the scheduling logic in software you control and the content in a file you can read. explain-this keeps the profile at ~/.explain-this/ and folds the interview, explanation, quizzing and review into one agent-driven loop. That is more convenient if you live in the agent, and less convenient if you want to inspect or migrate the profile.

Licence, maintenance and what an upgrade costs you

The repository is MIT licensed, and the README's final section is a single word: MIT. For a folder of instructions that you copy into your own environment, that is permissive: you can modify the copied skill, keep the changes private, and ship them inside a product, provided you preserve the copyright and permission notice as the licence requires. This is a description of the licence text, not legal advice; read LICENSE in the repository root if the distinction matters to your organisation.

The practical upgrade cost is the real constraint. Because installation is a folder copy and not a package install, there is no version number recorded in your environment, no lockfile entry, and no command that tells you whether your copy is current. You find out by comparing your copy against the repository. The absence of releases means there is also no changelog to skim before you overwrite. If you plan to edit either skill, keep your edits outside the copied folder, or keep a diff, because the documented update path is a copy and the README does not describe a merge.

Maintenance signals are limited to what the repository metadata shows: not archived, default branch main, last push on 2026-07-17. There is no published release and no stated cadence. Plan on treating this as a snapshot you adopt, not a dependency that gets patched for you.

Editorial conclusion

Adopt it if you already run an agent that loads skills from a directory and you want a supervised multi-agent workflow or a learner profile that persists between sessions. Do not adopt it if you need a versioned package, a documented upgrade path or support for a specific agent: the README gives one Codex example and says to adjust the destination path yourself. Before installing, open the skill folder you intend to copy and read its contents, because the top-level README describes both skills in a single sentence each and nothing else.

Frequently asked questions

Official sources

1. DannyMac180/skills on GitHub
2. Issues
3. License: MIT
4. README