seandavi/scriptorium/compression
Claude Code and agent skill by seandavi/scriptorium
- community
Checking that the SKILL.md file is still in the repository.
Propose page-limit-driven length reductions on a manuscript section while preserving every citation, every declared statistic, every core claim, and every declared terminology choice. Emits a structured markdown report with per-edit diffs, a preservation report, and a list of edits NOT proposed because compression would risk losing a load-bearing nuance. Suggests edits; never auto-applies. Invoke ONLY when the user explicitly asks for compression against a declared length target.
Install
npx vskill@latest install seandavi/scriptorium/compressionSKILL.md
Compression pass
You are running scriptorium's compression skill. The job is to reduce the length of a manuscript section so it fits a declared length target (word count, page count, or character count), while preserving every citation, every declared statistic, every core claim, and every declared terminology choice. This is a transformation skill that operates one level closer to copyediting than argumentative-flow does — it does sentence-level and paragraph-level reductions, not structural reorganisation — but it inherits the same preservation contract.
This skill suggests edits. It does not apply them. The output is a structured markdown report the author reads, accepts, or rejects edit-by-edit. The manuscript on disk is unchanged.
Invocation discipline — read before doing anything else
This skill must be invoked explicitly by the user. Never run it proactively, never run it as a follow-up to another skill's output without the user re-asking. The author owns their voice and their section length; an unrequested compression — even a "helpful" one — is unwelcome.
If the user has not specified a section, ask. The unit of work is one section at a time (introduction, abstract, results, discussion, or a named subsection). Single-section scope is what makes the diff reviewable; a whole-manuscript pass is outside the default scope (the single-section-unit guard below).
If no length target is declared in MANUSCRIPT_STATE.yaml#constraints.max_word_count and the user has not supplied one at invocation, ask for one. If the author does not give one, the length-target-required guard below applies: by default the skill does not "just shorten" without a target — compression without a target is an opinion about the author's prose, not a structural service.
Guards and overrides
This skill's guards are declared in manifest.yaml and follow [[author-authority]]: the author decides what the skill may do, except where proceeding would make the output wrong.
- `single-section-unit` (scope; default refuse). If the author
asks for a whole-manuscript pass, state the concern and its source in one line: "This skill transforms one section per run so every change stays reviewable; a whole-manuscript pass is outside its default scope (single-section-unit; source: this skill's reviewability design)." Then decline, and say how to override: answer "proceed" in this run, or add an entry for this guard and this skill under meta.overrides in MANUSCRIPT_STATE.yaml. On override, work through the sections one at a time, in manuscript order, with a complete report for each section.
- `length-target-required` (scope; default refuse). If no target
is declared and the author gives none when asked, state the concern and its source in one line: "No length target is declared or supplied; compression without a target is a judgement about the prose, not a service the author asked for (length-target-required; source: this skill's design)." Then decline, and name the same two override routes. On override, propose only cheap reductions (redundant phrasing, hedging stacks, filler discourse markers), no structural edits, and label the run untargeted in the Summary.
- Accuracy guards (fixed).
preserve-cited-support,
preserve-quantities-verbatim and preserve-claim-set are the hard preservation constraints below. no-false-verification-claims means the preservation report is never clean when a proposed edit is not. Neither a per-run answer nor meta.overrides lifts them; if asked to, say the guard protects correctness and cannot be overridden.
Read meta.overrides with the rest of MANUSCRIPT_STATE.yaml. For each scope guard, the first of these decides: the author's answer in this run, in either direction; an entry under meta.overrides naming the guard and this skill (or "*"); the default, refuse. State the one-line concern at every guidance level, including terse, and even when an override applies. When the run proceeds past a scope guard, the output carries an Overrides applied: line listing the guard ids (see Output format); otherwise the line is omitted.
Hard preservation constraints
These are non-negotiable. Constraints 1–4 and 7 are the skill's fixed accuracy guards (preserve-cited-support, preserve-quantities-verbatim, preserve-claim-set), and no override lifts them; terminology and voice/tone follow the state file, which the author controls. Every proposed edit must satisfy all of them. If you cannot satisfy them while reducing length, do not propose the edit — surface it in the "Edits NOT proposed" section with the reason.
- **Every cite key in the source is present in the output, with the
same cite key.** No removals, no renamings. If a sentence is cut, any citations it carried must be re-attached to the surviving sentence that makes the same claim, or the edit is not proposed. Reference [[hallucination-in-llm-citations]] for the failure mode inverse to this constraint (invention); the failure mode here is omission of cited support.
- Every quantitative statement is preserved verbatim — numbers,
units, p-values, confidence intervals, effect sizes, percentages, sample sizes. Do not round, re-express, or substitute "majority" for "53%." A compression that swaps a number for a word has crossed into translation, not reduction.
- Every declared `core_claim` is preserved. Read
MANUSCRIPT_STATE.yaml#core_claims. Any candidate edit that would re-scope, weaken, or remove a declared claim is not a compression edit — it is a scope change, and scope changes belong to the author.
- **Every distinct claim in the source is preserved as a distinct
claim.** Two claims that the prose presents as distinct may not be merged into one. Granularity loss looks like compression but reads as a stealth scope change.
- **Terminology declared in
MANUSCRIPT_STATE.yaml#terminologyis
honored.** Use terminology.preferred. Avoid terminology.forbidden. Apply terminology.synonyms where the author has licensed them. Do not introduce new terms not licensed by the state file.
- Voice and tone are preserved. Active or passive as the source
has it; the style.voice and style.tone from the state file are the targets. No "helpful" stylistic embellishment. Per [[ai-writing-failure-modes]], LLM editing measurably shifts vocabulary toward a recognisable register and flattens individual voice. Compression is a common surface for AI-writing tells to creep in: em-dash overuse, rule-of-three constructions, inflated symbolism, replacement of plain words with elevated synonyms. These are forbidden transformations.
- Hedging and stance markers are preserved. Epistemic modals
("may", "might", "could"), epistemic adverbs ("possibly", "apparently"), approximators ("approximately", "about"), attributive verbs ("we suggest", "we propose"), and indirect attributions ("it has been suggested", "it is possible that") are how the source calibrates the strength of its claims. Per [[esl-writers-swales-hyland]], these patterns vary legitimately across linguistic backgrounds. A compression that removes a hedge has weakened (or strengthened) the underlying claim and crossed a claim boundary. Hedging stacks ("may potentially possibly") are the only legitimate target: a stack adds no calibration, only tokens. Reducing a stack to a single hedge is compression; removing the hedge entirely is not.
If preservation conflicts with a length reduction, preservation wins every time. The conflict goes into "Edits NOT proposed"; it does not silently violate.
BERTScore and similar embedding metrics are documented to be insensitive to negation and to numerical changes ([[semantic-preservation]]), so embedding similarity is not a safe guard against meaning flips. Read each proposed edit against the source for semantic preservation; do not rely on automated similarity as evidence.
Allowable transforms
These are the legitimate length-reducing moves:
- Tighten redundant phrasing. "due to the fact that" → "because".
"In order to" → "to". "At this point in time" → "now". Word-level redundancy is the cheapest compression and the safest.
- Merge adjacent paragraphs that say the same thing twice. If
two paragraphs state the same claim with the same supporting evidence, the second is a candidate for absorption into the first. Citations from both must survive the merge.
- Reduce hedging stacks ("may potentially possibly") to a single
hedge ("may"). The single hedge is the author's calibration; the stack is filler.
- Eliminate filler discourse markers that add no information
("It is important to note that", "It should be mentioned that", "As previously discussed"). These are conversational scaffolding the academic register tolerates but does not require. Justify each cut by what the marker fails to add, not by a supposed scientific norm of sparser stance marking: Hyland & Jiang (2018) found interactional metadiscourse rose in the sciences ([[esl-writers-swales-hyland]]).
- **Move discursive parentheticals to footnotes or supplementary
material** — only if the manuscript permits footnotes and the parenthetical is not load-bearing. Most journals limit footnote use; check before proposing.
- Tighten subordinate clauses that restate the main clause.
Per [[reader-expectation-approach]], a 30-word subject phrase is often compressible by moving stress-bearing material into the stress position; the resulting sentence is shorter and more readable. Name the subject–verb-distance repair in the rationale as a diagnosis the author can overrule: Gopen & Swan say their principles are not rules and that "any reader expectation can be violated to good effect".
Per [[hayes-flower-writing-model]], compression is justified when it removes extraneous load (filler, unmotivated repetition, mechanical scaffolding). It is not justified when it removes germane content (scaffolding the reader needs to construct the claim's schema). Each proposed edit should be classifiable as one or the other; edits removing germane content are not proposed. Do not describe germane load as a quantity an edit adds or removes: Sweller's 2019 update treats it as a redistribution of working memory, not an additive load.
Forbidden transforms
These look like compression but are not. Never propose them.
This is the start of the file. Read the full SKILL.md on GitHub.
Security
- Security scanPassed, 100 of 100Pattern checks on the skill's files.
- Model reviewNot runA model review is scheduled for the next rescan.
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingskills/compression/SKILL.md
Popularity
- Repository stars
- 3
- 7-day trend score
- 7
Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/seandavi/scriptorium/compression)