scholar-mcp: Skill for Claude Code

Applying template updates

This is not a merge. In most copier projects an update is mechanical: take what the template changed, settle the conflicts, done. Here the template is authoritative. In every file copier update re-renders, each line outside a sentinel block belongs to the template, and the update's job is to bring this project back to the template at the target ref. Conflict markers show only where git happened to notice a collision. Drift the template did not touch in this jump rides through without one, so an update with no conflicts can still leave the project forked.

That drift was written by this project, not by the template: an earlier commit put project content into lines the template owns. Your job is to recognise it as the project's decay, not to rationalise it. An update is done when every template-owned file conforms or has a Decay issue, not when the markers are gone.

docs/deployment/template-updates.md explains the update for a human; this skill is the procedure. Work on the copier/update branch the workflow opened (or the branch where copier update --trust was run). Stop and ask, rather than guess, at three points: a conflict hunk inside a sentinel block, an upgrade note you cannot perform (a secret, a repository setting), and a seeded-file change you are not certain applies to this project.

1. Read the pull request body

Extract from it: the previous and target template refs, the compare link, the UPGRADING.md sections for the jump, and the list of files with conflict markers. If the body has no upgrade notes, fetch UPGRADING.md at the target ref from the template repository — it is an index whose released ## vX.Y sections point at per-minor upgrading/vX.Y.md files — and fetch every per-minor file from the previous ref's minor through the target's, reading each one whole. Never grep or tail your way through them: each file is complete for its minor, and the index enumerates which files a jump needs.