Borrowing it
Nothing to install: this file belongs to pvliesdonk/paperless-mcp. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/pvliesdonk/paperless-mcp/main/.agents/skills/applying-template-updates/SKILL.mdgit clone --depth 1 https://github.com/pvliesdonk/paperless-mcpWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/pvliesdonk/paperless-mcp/applying-template-updates)<a href="https://agentmods.dev/skills/pvliesdonk/paperless-mcp/applying-template-updates"><img src="https://agentmods.dev/badge/skills/pvliesdonk/paperless-mcp/applying-template-updates/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/pvliesdonk/paperless-mcp/applying-template-updates"><img src="https://agentmods.dev/badge/skills/pvliesdonk/paperless-mcp/applying-template-updates.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00068 | $0.02313 |
| Opus 5.5 | $0.00027 | $0.00925 |
| Sonnet 5.5 | $0.00014 | $0.00463 |
| Haiku 4.5 | $0.00007 | $0.00231 |
Grade A, and why
applying-template-updates scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 25d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to applying-template-updates — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 191 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 25d ago Changed · +94 lines · -13 tokens per session ac5796e29750
- 1mo ago First seen · 97 lines · 81 tokens per session scan A dc36a70a6566
applying-template-updates is a skill published in the GitHub repository pvliesdonk/paperless-mcp (1 stars, last pushed yesterday), licensed MIT. It adds 68 tokens to every session and 2,313 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 100% identical to applying-template-updates, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
polish-docs-meta
Finalize documentation and project metadata for a ship-ready release. Use after implementation is complete, tests pass, and devcheck is clean. Safe to run at any stage — each step checks current state and only acts on what still needs work.
report-issue
File a bug or feature request against this repository (cyanheads/git-mcp-server) using the gh CLI. Use for tool logic bugs, git provider misbehavior, transport issues, auth/config problems, or new feature proposals.
triaging-incidents
Creating, triaging, updating, and analyzing ServiceNow incidents, including trend reports. Assess severity, check affected CIs, find related incidents, and recommend assignments. Use when the user mentions incidents, INC numbers, outages, service disruptions, ticket creation, triage, priority, severity, ITSM…
reviewing-update-sets
Reviewing, analyzing, and comparing ServiceNow update sets before promotion, singly or in batches. Shows changes, risks, dependencies, and conflicts. Use when the user mentions update sets, customizations, promotion, code review, change tracking, pre-deployment review, sysupdatexml, customer updates, 'what changed in…
assessing-change-impact
Assessing what a ServiceNow change request touched and what followed it: affected CIs, other changes on the same CIs in an overlapping window, and incidents on those CIs after the change, without trusting hidden incident-to-change links. Use this skill whenever the user asks whether a change (a CHG number) caused or…
reviewing-sla-definitions
Reviewing ServiceNow SLA, OLA and underpinning-contract definitions and how they perform: breach rates per definition, overlapping or duplicated definitions on the same table and target, and definitions that never attach. Use when the user asks about SLA breaches by definition, too many SLAs, duplicate or conflicting…