| name | regenerating-training |
| description | Use when a maintainer asks to regenerate, refresh, or update an existing training package after source changes ("regenerate the training", "the docs changed, update the course", "/training-generator:regenerate"). |
Regenerating a Training Package
Regeneration updates the clean training repository for future learners. It
never touches existing learner clones — they keep the version they started.
- Confirm the existing package:
<sourceRoot>/<submodulePath> must contain
training-manifest.json and a .git history. Read its
training-version.json and compare sourceCommit with the current
source HEAD; if identical and no config changed, report that regeneration
is unnecessary and stop.
- Run the full generating-training workflow (Phases 1–5). Version the new
package deliberately in the content manifest:
- additive content changes → minor bump;
- removed or reordered modules/lessons, changed identifiers, or a
progress-schema change → major bump;
- prose-only corrections → patch bump.
- The scaffolder writes into the existing repository as a new commit —
history is preserved, stale generated files are removed, and identical
inputs produce no commit at all. It will refuse if the target contains
live learner state (that's a learner clone, not the clean repo).
- Re-register the gitlink:
node ${CLAUDE_PLUGIN_ROOT}/scripts/register-submodule.mjs --source <sourceRoot> --path <submodulePath>
- Report old → new version, what changed at curriculum level, and the
validation results. Remind the maintainer that publication (push) is
theirs to run; active learners are unaffected by design.