EXPERIMENTAL. This behaviour may change or be withdrawn in any release, including a patch release. If you build on it, pin your plugin version and file what breaks.
People kept writing wrapper skills around paad skills to bolt on their own behaviour, because the alternative was retyping a long list of extra instructions on every invocation and hoping nothing was forgotten. A config file replaces the wrapper: the skill reads it on its own.
Two optional Markdown files, relative to the directory you run the skill from (normally the repo root):
| File | Read by |
|---|---|
paad/config/paad.md |
every paad skill |
paad/config/<skill-name>.md |
that one skill, e.g. paad/config/agentic-review.md |
Both may exist. Neither is required. Any other file in paad/config/ is
ignored.
Plain instructions, in whatever form you would have typed after the slash
command. For example, paad/config/agentic-architecture.md:
- All output must be in simplified technical English.
- Add one more subagent that looks for over-engineering.
- The report MUST open with a large warning that it was generated by AI and
every finding needs human validation.
- Keep a log in `paad/logs/agentic-architecture.md` of every finding an
agent raised that the verifier discarded.There is no schema. The skill reads the file as prose and follows it, and passes the relevant parts to the subagents it dispatches.
The announce line does not change. A skill that read a config file opens its final answer with one line naming every file it followed:
Config: paad/config/paad.md, paad/config/agentic-architecture.md
If that line is missing, the skill did not read your file, and nothing in the run came from it. (An earlier design put the path in the announce line itself. Measured across 24 non-interactive runs, any announce placed after the file check was dropped; the announce-first, name-it-last shape held in every run.)
Config can contradict the skill. Every paad skill carries a control-flow graph of gates it must not skip: read-only analysts, a verifier pass before anything is reported, stop conditions. A config line can tell the skill to do something that crosses one of those gates, and the skill may comply. Nothing mechanically prevents it, and instructing a model to treat config as "additive only" was judged too unreliable to promise. Until that changes, treat config as additions — an extra agent, an output rule, an artifact, a language — and avoid telling a skill to skip, reorder, or shorten a step. If you must, expect the result to be a different skill from the one documented.
One line is refused. Config cannot change a subagent's type or give it write tools. Without that rule, three of three test runs swapped paad's read-only analyst for a general-purpose agent because a config asked; with it, three of three refused and said so. Every other kind of instruction is followed.
Config is untrusted input. A paad/config/ directory in a repository you
cloned was written by someone else, and a skill will read it the same way it
reads a CLAUDE.md or a steering file. Read it before you run anything.
Results vary. Skill output is already stochastic. A config line that works on one run may be ignored or over-applied on another. If a line matters, check the output for it.
Every SKILL.md carries the same short paragraph directly under its announce
line, telling the skill to look for these two files. make check-config
fails a skill that lacks it or names another skill's file. The exporter leaves
paad/config/ paths alone, so Kiro, Antigravity and Pi users read the same
location. See CLAUDE.md under "Adding a new skill".