|
| 1 | +# Pepsy skill policy |
| 2 | + |
| 3 | +This file is the source of truth for designing and maintaining the local |
| 4 | +Pepsy skills under `.github/skills/`. It governs the skill catalog itself; it |
| 5 | +does not replace domain-specific invariants in an individual `SKILL.md`. |
| 6 | + |
| 7 | +## Design principles |
| 8 | + |
| 9 | +- Keep one skill focused on one reusable subsystem or workflow. Do not create |
| 10 | + a skill for a single class, one-off investigation, or information already |
| 11 | + covered by an existing skill. |
| 12 | +- Keep repository-wide rules in `AGENTS.md` and cross-cutting routing in |
| 13 | + `pepsy-maintainer/SKILL.md`. Keep numerical and API invariants in the owning |
| 14 | + domain skill. |
| 15 | +- Prefer composition over duplication. A cross-domain skill may point to the |
| 16 | + owning skills; it must not copy their invariants and let the copies drift. |
| 17 | +- Optimize for progressive disclosure: concise `SKILL.md` first, one-level |
| 18 | + `references/` only for details needed by a subset of tasks. |
| 19 | + |
| 20 | +## Package contract |
| 21 | + |
| 22 | +Every skill is a flat directory with this shape: |
| 23 | + |
| 24 | +```text |
| 25 | +.github/skills/<name>/ |
| 26 | +├── SKILL.md # required instructions and trigger metadata |
| 27 | +├── agents/openai.yaml # required local UI metadata |
| 28 | +├── references/ # optional, direct supporting material |
| 29 | +└── scripts/ # optional, deterministic local helpers |
| 30 | +``` |
| 31 | + |
| 32 | +Required rules: |
| 33 | + |
| 34 | +- Use lowercase hyphen-case for `<name>`, matching the `name` frontmatter. |
| 35 | +- `SKILL.md` frontmatter contains only `name` and `description`. Put all |
| 36 | + trigger conditions in `description`; do not hide them in a body section. |
| 37 | +- Keep `SKILL.md` under 500 lines. Move detailed method notes, API maps, and |
| 38 | + variant-specific guidance to direct `references/` files. |
| 39 | +- Keep references one level deep and link them from `SKILL.md`. Do not add |
| 40 | + README, CHANGELOG, installation, or quick-reference files inside a skill. |
| 41 | +- Keep `agents/openai.yaml` synchronized with the skill name and purpose. |
| 42 | +- Add every skill to `.github/skills/README.md` and |
| 43 | + `.github/skills/agent-bundle.yaml` with the correct role and upload files. |
| 44 | + |
| 45 | +## How to use skills |
| 46 | + |
| 47 | +1. Read the repository `AGENTS.md` and inspect Git status before editing. |
| 48 | +2. Classify the request as cross-cutting or domain-specific. |
| 49 | +3. For cross-cutting work, read `pepsy-maintainer/SKILL.md`, then load the |
| 50 | + smallest set of domain skills that own the affected code or invariants. |
| 51 | +4. For a focused task, read only the matching domain skill and its direct |
| 52 | + references. Do not load the full catalog by default. |
| 53 | +5. If two skills overlap, identify the primary owner and use the other only |
| 54 | + for its explicit interface or invariant. Report the selected skills. |
| 55 | +6. Read the closest source, tests, and API docs after the skill guidance. |
| 56 | +7. Validate the skill/catalog changes separately from package behavior; run |
| 57 | + focused package tests when implementation behavior also changes. |
| 58 | + |
| 59 | +## Adding a skill |
| 60 | + |
| 61 | +Add a skill only when all of these are true: |
| 62 | + |
| 63 | +- The subsystem has a stable public or implementation boundary. |
| 64 | +- Users will ask for it repeatedly and its correct workflow is not obvious |
| 65 | + from the source alone. |
| 66 | +- The skill has clear trigger language and a clear owner namespace. |
| 67 | +- Its rules cannot be expressed more cleanly by extending an existing skill. |
| 68 | + |
| 69 | +Use this sequence: |
| 70 | + |
| 71 | +1. Search existing skills, `AGENTS.md`, docs, and source for overlap. |
| 72 | +2. Choose a short hyphen-case name and define concrete trigger phrases. |
| 73 | +3. Create the package with `SKILL.md` and `agents/openai.yaml`; add |
| 74 | + `references/` or `scripts/` only when needed. |
| 75 | +4. Write the smallest reliable workflow, including boundaries, invariants, |
| 76 | + source/test paths, and validation commands. |
| 77 | +5. Add the skill to the catalog and upload manifest. Update the maintainer |
| 78 | + router only if the new routing is not already covered. |
| 79 | +6. Run `quick_validate.py` for the new skill and |
| 80 | + `python .github/skills/pepsy-maintainer/scripts/validate_catalog.py`. |
| 81 | +7. Forward-test a representative request. If implementation behavior changed, |
| 82 | + run the owning focused tests and Ruff as required by `AGENTS.md`. |
| 83 | + |
| 84 | +## Updating, deprecating, and removing |
| 85 | + |
| 86 | +- Update the skill in the same change as the code/API workflow it documents. |
| 87 | + Remove stale claims; do not preserve historical behavior as active guidance. |
| 88 | +- When a subsystem moves, update source links, tests, namespace examples, |
| 89 | + catalog entries, and the upload manifest together. |
| 90 | +- Before deprecating a skill, search the repository and agent bundle for its |
| 91 | + name, links, and trigger phrases. Add a replacement route to the maintainer |
| 92 | + skill and catalog before removing it. |
| 93 | +- Remove a skill only after its replacement is documented, references are |
| 94 | + migrated, and validation passes. Never delete a skill merely because it is |
| 95 | + currently unused in one task. |
| 96 | +- Do not silently merge two skills. Keep the clearer owner, move unique |
| 97 | + guidance deliberately, then remove duplicate references and update routing. |
| 98 | + |
| 99 | +## Quality gate |
| 100 | + |
| 101 | +For every skill/catalog change, require: |
| 102 | + |
| 103 | +```bash |
| 104 | +source ~/envs/py312/bin/activate |
| 105 | +python /home/reza.haghshenas@quantinuum.com/.codex/skills/.system/skill-creator/scripts/quick_validate.py .github/skills/<name> |
| 106 | +python .github/skills/pepsy-maintainer/scripts/validate_catalog.py |
| 107 | +git diff --check |
| 108 | +``` |
| 109 | + |
| 110 | +For a skill that governs implementation behavior, also run the closest |
| 111 | +focused test and `python -m ruff check src tests`. For cross-cutting changes, |
| 112 | +run the full suite according to `AGENTS.md`, or explicitly report why it was |
| 113 | +not run. |
0 commit comments