[dmccoystephenson]

Summary

When a <slug>-dev-loop skill already exists for the current repo, /create-dev-loop now offers three modes instead of the previous binary overwrite/cancel:

• update (default) — re-derive the skill from the current template + current repo state, then show a diff before overwriting. Aborts on uncommitted changes in the local skill directory. Skips Step 6 (create repo) and Step 7 (record in example-skills-catalog) since those artifacts already exist.
• overwrite — full regeneration, idempotently re-asserting the GitHub repo and example-skills-catalog entry.
• cancel — exit without changes.

Recommends option A from #16's design notes (re-derive from evidence). Option B (section tagging for surgical updates) is deferred.

This closes the loop with PR #33 (template-version header): #33 detects drift via the embedded SHA; this PR is the remediation channel — re-run /create-dev-loop in update mode to pull in template improvements.

Closes #16

Test plan

• Step 1's "skill already exists" branch now offers update / overwrite / cancel with the recommended default flagged
• Update-mode uncommitted-changes guard: git status --porcelain check with explicit abort message
• Pre-overwrite diff (diff -u against /tmp/<slug>-dev-loop.new.md) and explicit-confirmation requirement
• Step 6 (create GitHub repo) skips in update mode, runs in fresh/overwrite
• Step 7 (record in example-skills-catalog) skips in update mode, runs in fresh/overwrite
• Step 5 (register slash command) is idempotent (ln -sf + mkdir -p) so no conditional needed — confirmed by re-reading the existing block
• README "Usage" section documents the three-way prompt
• No new {{placeholders}} introduced (MODE is a runtime control variable in the instructions, not a generation-time substitution)
• Diff: 29 LOC across 3 files — well under scope ceiling
• Localization verified: "### 1 — Identify the repository" at line 11, "### 6 — Create a private GitHub repo" at line 553, "### 7 — Record the skill in example-skills-catalog" at line 577 (line numbers shifted by edits, but headings are present)
• Per the rule shipped in PR Promote 'verify each Closes #N' to template Phase 4 #26, ran gh issue view 16 and confirmed title/body match
• Per the rule shipped in PR Track implementation outcomes back into RESEARCH.md #27, added an Implementations entry under RESEARCH.md §8
• Do-not-auto-merge check (PR Add hard PR scope gates: LOC ceiling, do-not-auto-merge paths #30): modified README.md, RESEARCH.md, create-dev-loop.md; no matches

Note on option B (section tagging)

#16 recommends starting with option A and evaluating after a few cycles whether human customizations get lost during update. The <!-- template-version --> header from PR #33 makes this observable: if a future cycle shows that customized skills lost manual tweaks during update, that's the trigger for revisiting option B.

---

drafted by Claude on behalf of Daniel Stephenson

[dmccoystephenson]

Self-review rubric:

• Scope: PASS — 3 files; each change maps to one of #16's 7 AC items or a CLAUDE.md/Phase 7 rule. Net 29 LOC under the 400 ceiling.
• Tests-new: PASS-with-caveat — the update-mode flow is exercised by reading-through, not by running /create-dev-loop end-to-end against a fixture repo (no fixture tooling exists). The guards (uncommitted-changes check, pre-overwrite diff, explicit confirmation) are described concretely enough that an agent following them produces verifiable shell output.
• Tests-fix: N/A — not a bug fix.
• Sibling structure: PASS — Step 6 and Step 7 both prepend a **Skip this step if MODE=update** line (siblings updated together); Step 1's three-way prompt uses the same bullet-with-bold-name shape as the existing CONVENTIONS-style identity prompt.
• Sibling renames: PASS — Step 6 and Step 7 'Skip in update mode' annotations use identical phrasing.
• Docs: PASS — README "Usage" section updated to describe the three-way prompt; both Phase 7 sources (create-dev-loop.md, README.md) modified together. RESEARCH.md §8 gets an Implementations entry.
• Issue resolution: PASS — all 7 AC items met: (1) three-way choice with update default; (2) Steps 2–4 reused as-is; (3) pre-overwrite diff with confirmation; (4) uncommitted-changes abort; (5) Step 6 skipped in update; (6) Step 7 skipped in update; (7) flow documented in README + create-dev-loop.md.
• Validation: PASS — placeholder count unchanged at 22; no new fenced blocks inside the outer template (the new fenced blocks in Step 1's update-mode section are outside the embedded markdown template, so no escape needed); phase numbering unchanged.
• {{EXTERNAL_SIGNAL_LABEL}}: N/A — no CI; manual validation against the diff served as the anchor.
• Placeholder-consistency: N/A — no new placeholders; MODE is a control-flow variable not a template substitution.
• Escaping: PASS — the new bash blocks (git status, diff, git rev-parse) live in Step 1, which is outside the embedded skill-template markdown block — they use plain triple-backticks without escape, which is correct for that location.

Adversarial probe — 'In update mode, the agent re-runs Step 2 (explore the repository) — what if the repo's CLAUDE.md / build files have changed since the original generation? Will the substituted values be correctly refreshed?' Yes — Step 2 reads current state; Step 4 substitutes current values. The whole point of update mode is to pick up repo-state drift as well as template drift. Concretely: if a repo added a CI workflow since first generation, update mode will set CLAUDE_MD and EXTERNAL_SIGNAL_LABEL/CMD based on the new state. Confirmed by reading Step 2 prose (unchanged) and Step 4 substitution descriptions (all read 'output of git rev-parse...' or similar — runtime queries, not stored values).