DannyMac180/skills: Two MIT-Licensed Agent Skills You Install by Copying a Folder
AI agent skills created by me: Dan McAteer
At a glance
- What is it?
- The repository ships two skills, codex-dynamic-workflows and explain-this, and no runtime, no package manifest and no releases. Installation is a git clone plus a recursive copy into your agent's skills directory, and the interesting part is what each skill leaves behind on disk.
- Who is it for?
- Adopt this if you already have an agent that reads skills from a local directory and you want either approval-gated multi-agent planning or a persistent learner profile, and you are willing to read the skill folders yourself because the README describes them in a single sentence each. Skip it if you need a packaged, versioned dependency with a changelog, or if your agent has no skills directory to copy into.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the repository actually contains
This is a distribution repository, not a library. The README lists exactly two skills, codex-dynamic-workflows and explain-this, each in its own top-level folder. The primary language is listed as JavaScript, which tells you the skills are not pure prose prompts, but the README never states which files inside those folders are executable and which are instructions. There is no package.json mentioned, no install script, no build step, and no releases have been retrieved. The last push is dated 2026-07-17, so the repository is active rather than archived. The licence is MIT, stated in the README and in the repository metadata. If you are looking for a framework, a CLI or a server, this is not it. It is a folder of agent instructions with a copy-paste install path.
The problem each skill claims to solve
The two skills target different problems and do not depend on each other. codex-dynamic-workflows is aimed at people running multi-step agent work who want supervision built into the process rather than bolted on afterwards. The README describes it as planning and running supervised dynamic workflows with goal mode, subagents or simulated work packets, approval gates, integration, verification, and reusable workflow artifacts. That list is the whole specification available here. The vocabulary matters: approval gates means the workflow is expected to stop and ask, and simulated work packets means the skill can proceed without live subagents, which is a useful fallback when your agent runtime does not support spawning them. explain-this targets a different problem, comprehension rather than execution. It explains a digital artifact, with papers, articles and code named as examples, and shapes the explanation around a persistent learner profile. It adds comprehension quizzes and spaced-repetition review. The audience is one person studying a subject over weeks, not a team shipping a feature.
How the two skills differ in mechanism
codex-dynamic-workflows is a process skeleton. Based on the README wording, the flow is plan, then execute through subagents or simulated packets, then pass approval gates, then integrate, then verify, then emit reusable artifacts. Each stage is a checkpoint the agent is supposed to honour, and the artifacts are meant to be reused on the next run rather than regenerated. explain-this is a stateful profile system. The README states that on first use it interviews you for roughly ten minutes and creates ~/.explain-this/. That directory is the mechanism: the learner profile lives there, and subsequent explanations, quizzes and review scheduling read from it. The two designs fail in opposite directions. The workflow skill degrades if your agent ignores the gates and runs straight through. The explain skill degrades if the profile directory is lost, because the personalisation is the product. Neither is a plugin with a stable API, so both depend on the host agent interpreting the skill files as intended.
Installation, as documented
There are two documented paths. The first is to point your agent at the GitHub URL and ask it to install the skill, with the README giving this example: Install the AI agent skill at https://github.com/DannyMac180/skills/tree/main/codex-dynamic-workflows. The second is manual. Clone the repository, create a skills directory, and copy the folder in. The README's example uses Codex's default location and expands CODEX_HOME with a fallback to $HOME/.codex:
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/"
The README is explicit that the destination path must be adjusted for your agent, so the Codex path is an example rather than a requirement. After copying, you start a new agent session and invoke the skill by name, as in: Use $codex-dynamic-workflows to plan and run a supervised multi-agent workflow for this task. Note that the invocation syntax with the dollar sign is shown for codex-dynamic-workflows only. The README does not show an equivalent invocation line for explain-this, so how you trigger that one depends on your agent's own skill-naming convention.
Where the documentation stops
The README is a catalogue, not a manual. Each skill gets one sentence. There is no description of what a workflow artifact looks like, where artifacts are stored, or whether they persist across sessions. There is no list of the questions asked during the explain-this interview, no schema for the learner profile, and no statement about what happens if ~/.explain-this/ already exists or is malformed. The word simulated in simulated work packets is never expanded, so you cannot tell from this material whether a simulated packet is a stub the agent fills in or a distinct execution mode. No releases have been retrieved, which means there is no changelog to consult when a skill's behaviour shifts. Anyone adopting this is adopting an unversioned copy: the clone you make today is the version you keep until you pull again. That is a real constraint, not a criticism of the design, and it is the reason the manual copy path is arguably the better of the two install options, since it at least leaves you with a folder you can diff.
The case for a different tool
If what you want is repeatable multi-agent orchestration with typed inputs, retries and a trace you can inspect, a code-first orchestration library is the wrong comparison and the right answer. The difference in approach is where the control lives. A library puts the loop, the state machine and the error handling in code you import and version; the agent calls into it. codex-dynamic-workflows puts the loop in instructions the agent reads, so the control lives in the model's compliance with those instructions. That buys portability, because a folder of instructions can be dropped into any agent that supports skills, and it costs determinism, because nothing enforces the approval gate except the agent's own adherence. The same split applies to explain-this. A notes application or a spaced-repetition tool gives you a database and a review schedule you can query and back up. explain-this gives you a directory that the agent reads and writes. If you need to audit or export your learning history, the notes tool wins. If you want the explanation and the review to happen inside the same conversation where you are reading the paper, the skill wins.
Licence, maintenance and what to verify first
MIT covers both skills and the repository as a whole. That permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. It also means no warranty, and this repository is a good illustration of why that clause exists: there is no test suite mentioned, no CI configuration in the README, and no release history to pin to. Maintenance cost is therefore on you. Every pull from main is an unreviewed change to instructions your agent will follow, and because the skills are plain folders, a merge conflict is possible if you edited a skill locally. Read the two skill folders before you copy them, confirm which files your agent will execute versus merely read, and check whether explain-this writes anywhere other than ~/.explain-this/. If your agent has no skills directory or does not resolve the dollar-sign invocation syntax, the documented install will not get you to a working skill, and the README offers no troubleshooting path beyond adjusting the destination path.
Editorial conclusion
Adopt this if you already have an agent that reads skills from a local directory and you want either approval-gated multi-agent planning or a persistent learner profile, and you are willing to read the skill folders yourself because the README describes them in a single sentence each. Skip it if you need a packaged, versioned dependency with a changelog, or if your agent has no skills directory to copy into. Before copying anything, open the two skill folders and check what files each one expects to create or read, since explain-this writes to ~/.explain-this/ on first use and the README does not document that directory's contents or how to delete it.
Community notes