refactor(templates): share one apply instruction body across skill and command - #1515
Conversation
…d command The apply skill and command templates each carried a full ~150-line copy of the same instruction body, differing in exactly one line (the `contextFiles` note). Two near-identical copies invite silent drift. Author the body once in `getApplyInstructions(contextFilesNote)` and render it per surface, passing each surface's own note. The single intentional wording difference stays explicit as a named constant, and further per-surface parameters can be added here as the surfaces evolve — the skill and command remain distinct templates. Pure refactor: the generated skill and command output is byte-identical to before (SKILL.md and all parity hashes unchanged). Added a contract test that fails both if the shared body drifts between surfaces and if the intentional contextFiles difference is flattened away. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe apply workflow now generates its instructions through one exported helper. Skill and command templates use the helper, and parity tests verify that both surfaces render the shared instruction core. ChangesApply template parity
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
alfred-openspec
left a comment
There was a problem hiding this comment.
Approved at efc5f3e. The shared instruction body preserves the one intentional contextFiles wording difference, the contract test pins both parity and that exception, and the full hosted matrix is green.
Builds on the shared-core extraction: the apply skill and command still each carried a slightly different `contextFiles` note (skill spelled out example artifact sets, command said only "varies by schema"). That difference was long-standing accidental drift between the two copies, not an intentional surface distinction — the surfaces are meant to differ only in how they are invoked, which the generation transformers already handle downstream by rewriting `/opsx:<id>` tokens per surface. Resolve the drift by unifying on the more informative note, so both surfaces render one shared `getApplyInstructions()` body with no per-surface text. Skill output is unchanged; the command's contextFiles note gains the example artifact sets. Updated the contract test to assert both surfaces render the shared core (no silent template-level drift), and regenerated the command function hash accordingly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
alfred-openspec
left a comment
There was a problem hiding this comment.
Re-reviewed at bcb1131 after the follow-up. The generated skill remains unchanged, the command gains only the clearer contextFiles examples, and both now render one shared instruction body. A fresh frozen install, build, lint, 365 focused template/reference/init/update/migration tests, static-skill regeneration, and the full hosted matrix pass.
Deploying openspec-docs with
|
| Latest commit: |
7a81745
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://d1c26a02.openspec-docs.pages.dev |
| Branch Preview URL: | https://claude-apply-template-shared.openspec-docs.pages.dev |
Status: Ready. Internal refactor plus one small drift fix — no change to the generated skill; the generated command gains a more informative note.
What was wrong
The apply skill and command templates each held a full ~150-line copy of the same instruction body. They differed in exactly one line — the
contextFilesnote (skill spelled out example artifact sets; command said only "varies by schema"). Two near-identical copies drift over time, and that one line was itself long-standing accidental drift between the copies.What it does
getApplyInstructions()and rendered by both surfaces./opsx:<id>tokens per surface (/openspec-*for skills,/opsx:*for commands, etc.). ThecontextFileswording was never an intentional surface difference, so both now use the more informative note.test/utils/command-references.test.ts.Proof it's safe
skills/openspec-apply-change/SKILL.md) is byte-identical to before.contextFilesline now reads(varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)instead of(varies by schema). One parity hash regenerated to match.Scope
apply-change.ts(the shared core), a one-line re-export inskill-templates.ts, and the contract test. No other workflow file touched.Summary by CodeRabbit
Documentation
Tests