Tour

tour: conversational onboarding for new users

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.

Invocation discipline

Invoke this skill when:

• The user types /scriptorium:tour.
• The user asks "what is scriptorium?" or "how do I get started?" and no skill is currently running.
• A maintainer or another user has pointed them at this skill as 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.

What "tour" is and is not

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.

Conversational style

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.

Operational protocol

1. Detect the situation

Before greeting, do a single read:

• Is there a MANUSCRIPT_STATE.yaml in the current working directory? 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).
• Is the cwd otherwise empty / a fresh manuscript directory / a 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.

2. Greet and orient (turn 1)

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 (your MANUSCRIPT_STATE.yaml is 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?

3. Walk through the relevant subset (turn 2)

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: init populates 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 (its SKILL.md declares 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.

4. Show concrete state (turn 2 or 3)

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: revision

One short sentence after the snippet: "Each skill reads this file before doing its work, so they all share the same view of the manuscript."

5. Mention guidance levels briefly (turn 3)

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.

6. End with one concrete next move (turn 3 or 4)

Pick the single best next command for their situation and present it clearly. Do not list five options — pick one.

• They have a manuscript directory and want to use scriptorium on it: /scriptorium:init <path-to-manuscript-dir>.
• They have a MANUSCRIPT_STATE.yaml already: suggest the leaf skill that fits their document_phase.current.
• Just exploring: /scriptorium:explain <skill> to drill into whichever 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."

What "good output" looks like

• Three or four turns total. Tour is short. If you're at turn five, something has gone wrong.
• The user's stated context drives the second turn. A grant writer does not get the manuscript walkthrough.
• One concrete next command at the end, not a menu.
• Plain, factual tone — no "powerful", "revolutionary", "supercharge". The README's tone is the model.
• The MANUSCRIPT_STATE.yaml snippet is concrete, not abstract description.
• Returning users are detected and shortcut, not subjected to the new-user walk-through.
• No file is written. No other skill is invoked.

What you must not do

• Write any file. Tour is read-only.
• Auto-invoke init, citation-audit, reviewer-simulation, argumentative-flow, or explain at the end. Suggest, don't invoke.
• Read manuscript prose, bibliography, or any file other than MANUSCRIPT_STATE.yaml (for situation detection only).
• Produce a wall of text up front. The first turn is one paragraph plus a question.
• Use marketing language. "Agentic operating system for scholarly writing" is the project's own framing and is fine; "revolutionary AI-powered editorial workflow" is not.
• Cover every skill at equal weight. Pick the loop the user needs.

Grounding

• [[guidance-level]] — tour introduces the three levels so the user 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 the tour 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.