Scope create-dev-loop to also update existing dev loops #16

Problem

Every time a rule is promoted into create-dev-loop.md, every existing child skill silently lags until a human (or Claude in an ad-hoc session) retrofits it. CLAUDE.md acknowledges this with the "Promoting a rule into the template" checklist, but the checklist is manual work whose cost scales linearly with the number of child skills.

Recent example: PR #15 (rubric-based self-review) required three follow-up retrofit PRs (example-a-dev-loop#33, example-q-dev-loop#3, example-l-dev-loop#19). Two of those skills (herald, dpm) had additionally drifted on an older template change (PR #8 — unconditional self-review) that had never been retrofitted, so they accumulated multiple drifts before being caught.

Proposal

Extend /create-dev-loop so it can update an existing dev-loop skill in place, not just generate a new one. Two viable shapes:

A. Re-derive from evidence (simpler — recommended first step)

When /create-dev-loop detects an existing skill, offer "update" mode. Update mode regenerates the skill from scratch using the current template and current repo state.

• Pros: small change to existing flow; reuses all existing exploration logic; produces a clean diff against the previous skill.
• Cons: clobbers any customizations that aren't re-derivable from the evidence in the repo (e.g., a hand-tuned IDENTITY line, repo-specific rubric items the human added but didn't put in CLAUDE.md).

B. Surgical update with section tagging (better but heavier — defer)

Tag each generated section as "template-driven" vs "customized" (e.g., via HTML comments or a frontmatter manifest in the generated skill). Update mode regenerates only template-driven sections.

• Pros: preserves human customizations.
• Cons: requires changing the template structure to carry markers; adds complexity to the substitution step; needs a clear definition of what counts as "customized."

Recommendation

Start with A. After a few more template-promotion cycles, evaluate how often human customizations are lost during update. If frequently, invest in B.

Acceptance criteria for A

• /create-dev-loop detects an existing skill for the current repo and offers a three-way choice: update (default), overwrite, cancel.
• Update mode runs Steps 2–4 (explore, substitute) against the current template and produces a fresh skill file.
• Update mode produces a git diff for the user to review before overwriting, since the change happens in ~/local-skills/<slug>-dev-loop/.
• If the local skill directory has uncommitted changes, update mode aborts with a clear message so user-in-progress edits aren't lost.
• Update mode does not re-run Step 6 (create GitHub repo) since the repo already exists.
• Update mode does not re-run Step 7 (record in example-skills-catalog) since the entry already exists.
• The update flow is documented in README.md and create-dev-loop.md.

Related

• The empirical motivation for treating template drift seriously is recorded in RESEARCH.md §8 — Prompt and model drift.
• This is a structural fix for the problem CLAUDE.md's promotion-with-retrofit rule papers over.

drafted by Claude on behalf of Daniel Stephenson