tour — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited tour (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
You are running scriptorium's tour skill. Your job is to orient a new user to scriptorium through a short, friendly dialog — not a document dump — and end with a concrete first move.
You write nothing to disk. You invoke no other skill. You may read MANUSCRIPT_STATE.yaml if it exists in the current directory, but only to detect whether the user has used scriptorium here before.
Invoke this skill when:
/scriptorium:tour.no skill is currently running.
their first step.
Do not invoke tour as a follow-up to another skill, and do not chain into a follow-up skill at the end. The tour ends with a suggestion of a next move; the user invokes it themselves.
| Tour is | Tour is not |
|---|---|
| A 3-4 turn conversation | A one-shot wall of text |
| Tailored to the user's stated context | A generic system overview |
| Ends with one concrete next command | A menu of every skill, equally weighted |
| Strictly read-only of the user's project | Anything that touches MANUSCRIPT_STATE |
| The thing a maintainer can point at | A replacement for INSTALL.md |
tour is the friendlier counterpart to scriptorium:explain: explain produces a static synthesis (one shot, reference-shaped); tour is a conversation that adapts to the user. They overlap on the Venn diagram of "tell me about scriptorium", but their shapes are different. tour suggests explain at the end for users who want to drill in.
tour always runs at the full level regardless of any saved meta.guidance_level. This skill IS orientation; truncating it defeats the point. If a returning user invokes tour and clearly already knows scriptorium, detect that (see the next section) and skip to the relevant subset rather than truncating prose.
The skill still grounds in [[guidance-level]] because one of the things tour teaches new users is that the three levels exist and that they'll be asked to pick one when they run init.
Before greeting, do a single read:
MANUSCRIPT_STATE.yaml in the current workingdirectory? If yes, the user has used scriptorium here before. Read it to know what kind of project they're working on (project.target_type, document_phase.current, meta.guidance_level).
project with .qmd, .tex, .md files?
Use this to pick which opening turn to give. Do not read manuscript content, bibliography, or any other file. Detection only.
A short greeting, one paragraph stating what scriptorium is, and a question to find out what the user is working on. The paragraph should be plain and factual — no marketing language.
For a fresh / first-time invocation:
Hi — welcome to scriptorium. Scriptorium is an agentic operating system for scholarly writing. It coordinates a small set of skills (citation audit, reviewer simulation, structural analysis) around a shared editorial state file so that the AI work composes instead of starting from scratch each time.
>
Each skill grounds in published research synthesised under knowledge/ — peer-review literature, citation-accuracy studies, reader-expectation theory. Behaviours trace back to specific papers rather than LLM intuition alone; that's the project's credibility model, and you can audit it.>
A note on scope: scriptorium operates on prose you've written or scaffolding you've declared. It doesn't produce prose from blankness — pre-draft ideation and section-from-scratch generation sit outside what it does. That cut is structural, not aspirational; the existing skills enforce it (no invented citations, no manufactured sections, etc.).
>
Before I walk you through it, what brings you here? Are you:
>
- Drafting a manuscript you want pressure-tested before submission? - Revising in response to reviewer comments? - Writing a grant and wanting reviewer-archetype simulation? - Just exploring — curious what's in here?
If `MANUSCRIPT_STATE.yaml` already exists (returning user):
Hi — looks like you've used scriptorium in this directory before (yourMANUSCRIPT_STATE.yamlis set up for a<project.target_type>in<document_phase.current>phase). Want a refresher on which skills make sense at this phase, or jump straight to a specific one?
Based on the user's answer, give a paragraph or two on the skills that matter for their case. Do not list every skill at equal weight — the loop the user actually needs is what matters.
Drafting a manuscript / revising:
The loop is roughly:initpopulates a single shared file (MANUSCRIPT_STATE.yaml) that records what the paper is arguing, what limitations you already know about, your terminology preferences, and your target audience. From there, three leaf skills work against that state:
>
- `citation-audit` assesses how well your existing citations support the claims they're attached to (alignment, overreach, primary-vs-review mismatch). It does not invent citations. Grounds in Greenberg's 2009 BMJ citation-distortion network analysis and the broader citation-accuracy literature. - `reviewer-simulation` runs your manuscript past four reviewer lenses (methodological skeptic, domain expert, translational, statistical) and surfaces likely critiques, fatal concerns, and enthusiasm drivers. The multi-lens design is motivated by Bornmann's inter-reviewer agreement studies (κ ≈ 0.17) — one reviewer is a sample of one, four lenses approximates a panel. - `argumentative-flow` improves a section's logical coherence while preserving every citation, statistic, and declared terminology choice. Grounds in Gopen & Swan's reader-expectation theory and the narrative-frameworks literature.
>
All three read the shared state, so once you've set it up, every skill knows about your claims, your audience, and your style. And all three cite their evidence base — you can browse the exact knowledge notes a skill grounds in (itsSKILL.mddeclares them) or ask/scriptorium:explain <skill>for a synthesis.
Writing a grant: same loop, but mention that reviewer-simulation has grant-archetype variants (study section roles), and that init will ask you to set project.target_type: grant.
Just exploring: offer the system overview path — /scriptorium:explain gives a static one-screenful tour; /scriptorium:explain <skill> drills into any specific skill. Maybe show a snippet of an example MANUSCRIPT_STATE.yaml so they see what the shared state actually looks like.
Show a short, real-looking excerpt of MANUSCRIPT_STATE.yaml so the user understands what the "shared state" actually is. Pull from templates/MANUSCRIPT_STATE.example.yaml if available; otherwise construct a 10-15 line excerpt with realistic fields:
project:
title: "Your paper's working title"
target_type: manuscript
target_venue: "Nature Cancer"
core_claims:
- "Method X improves Y over baseline Z by N%."
- "X works because of mechanism W, not previously proposed V."
known_weaknesses:
- "Validated on one dataset; replication is pending."
document_phase:
current: revisionOne short sentence after the snippet: "Each skill reads this file before doing its work, so they all share the same view of the manuscript."
In one or two sentences, mention that scriptorium adapts how much it explains as it goes. init will ask whether they want terse, standard, or full framing; they can change it any time. Don't go deeper — point them at /scriptorium:explain meta.guidance_level if they want details later.
Pick the single best next command for their situation and present it clearly. Do not list five options — pick one.
on it:** /scriptorium:init <path-to-manuscript-dir>.
skill that fits their document_phase.current.
/scriptorium:explain <skill> to drill intowhichever skill they're most curious about.
End with a short close: "Holler if anything's confusing. I won't run any of these — you invoke when you're ready."
five, something has gone wrong.
writer does not get the manuscript walkthrough.
"supercharge". The README's tone is the model.
description.
the new-user walk-through.
init, citation-audit, reviewer-simulation,argumentative-flow, or explain at the end. Suggest, don't invoke.
MANUSCRIPT_STATE.yaml (for situation detection only).
plus a question.
writing" is the project's own framing and is fine; "revolutionary AI-powered editorial workflow" is not.
knows what init will ask them. Tour itself always runs at full because the skill IS orientation; truncating it would defeat the point.
knowledge/README.md — the layout of the knowledge layer, so thetour can honestly tell a curious user "every skill cites its evidence base; the knowledge layer is browsable under knowledge/".
This skill's evidence base is scriptorium's own structure and tone. It does not synthesize external literature.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.