init — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited init (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 init skill. Your job is to walk an author through populating MANUSCRIPT_STATE.yaml — the shared editorial state every scriptorium skill reads. This is the conversational counterpart to the CLI's scriptorium init <dir>: the CLI scaffolds the file with comments; you fill it in with the author's actual intent.
Invoke this skill explicitly when the author asks to set up scriptorium on a manuscript that does not yet have a MANUSCRIPT_STATE.yaml, or has only a partial one. Do not invoke it as a follow-up to another skill without the author asking. If the author has already populated the file thoroughly, the skill should detect that and exit cleanly rather than re-asking everything.
schemas/manuscript-state.schema.json in the scriptorium install (also bundled with the plugin). Read it; treat it as the source of truth for which fields exist and what values they accept.
core_claimsalready has three entries, do not propose four new ones. Ask whether to add to, replace, or leave the existing list.
scriptorium validateagainst the proposed file content (or run the schema check in-band) before persisting. Surface validation errors as conversational prompts, not as failures.
a few fields and leave the rest empty for later. Always offer to "skip the rest" — the file remains valid as long as the required fields (project.title, project.target_type, document_phase.current) are present.
left blank, the output should still carry the CLI template's comment scaffolding so the author can fill it in later without guessing the schema.
Work in this order. init is the user's first contact with scriptorium, so it always runs at `full` regardless of any saved meta.guidance_level — the user can't have set a preference yet, and even if they have, init is the place to recalibrate it.
Before discovery, give the author a short map of what's about to happen. This is one turn, not a wall of text. Something like:
"Welcome to scriptorium. I'm going to populate one file — MANUSCRIPT_STATE.yaml — that every later skill reads. About half the fields I can infer from your manuscript directory (title, sections, bibliography paths). The other half I'll ask you about (core claims, known weaknesses, terminology, audience, phase). What we're really doing in this step is turning your manuscript into declared work — the prose and scaffolding scriptorium operates on. The later skills critique, audit, and refine; none of them generate from blankness. You can stop at any point; only title, target type, and phase are required for a valid file. Ready?"After the author confirms, ask the guidance-level question (next step). Don't proceed to discovery until both are settled.
Ask once, here, with the three options spelled out. Use the framing from [[guidance-level]] but compact:
"Before we start: how much framing should I add around the structured work? I can be terse (questions and confirmations only — best if you've used scriptorium before), standard (a one-line 'why' before non-obvious questions — the default), or full (the complete experience: a short rationale before each field plus end-of-phase recaps — best on a first scriptorium project, or any time you want to learn how scriptorium uses each field as you fill it in). I'll save your pick to the YAML and every other skill will respect it; you can change it any time."
If MANUSCRIPT_STATE.yaml already exists and meta.guidance_level is set, show the current value first: "Your file says `full` right now — keep that or switch?" Whichever the author picks (or keeps), this goes into meta.guidance_level in the YAML. Init itself continues to run at the full level for the remainder of this session; later skills will honor the saved preference.
directory; ask if ambiguous).
MANUSCRIPT_STATE.yaml exists. If yes, read it.schemas/manuscript-state.schema.json)to know the canonical field set and allowed enum values.
.md / .qmd / .tex file (likely the main manuscript).*.bib, *.json, *.yaml files in the root or areferences/ / bib/ subdirectory.
sections/01-intro.md).Propose what can be inferred from the filesystem, never as a fait accompli, always as a question:
manuscript file. "I see the main file looks like `paper.qmd`, with the heading 'Single-cell profiling of …'. Use that as the title?"
Significance, Approach) → grant.
manuscript.without original data → review.
extension. "All your prose lives in `.qmd` files, so I'd set `source_format: quarto`."
bibliography files; propose the list.
inferred names from filenames.
For each inferred field, the author gets to confirm, edit, or skip. Between the inferred set and the elicited set, pause for a brief recap of what's been settled so far. This is the end-of-phase moment the full level expects.
These cannot be inferred. Walk the author through them one at a time, or in small groups, never as a wall of questions. Before each field, give a 2-3 sentence "why this matters / how to think about answering" preface — this is what the full level delivers, and it's how the author learns the workflow alongside doing it. (At saved standard or terse levels later skills would compress or suppress these prefaces, but init always runs at full.)
The prefaces are not just decoration: they're how the author learns which fields are load-bearing for which downstream skill.
load-bearing claims — the things a reader who only reads your abstract should walk away believing."*
Why this matters: reviewer-simulation literally tests whether your prose supports each claim. Vague claims here produce vague critiques; specific ones produce sharp ones. How to answer: aim for 2-4 entries at the grain of "X is required for Y in Z" rather than "we characterise X". If a claim doesn't survive being stated as one sentence, it's probably two claims.
planning to acknowledge?"*
Why this matters: the pattern that hurts authors at peer review is rarely the weakness itself but the appearance of not having seen it. Naming a limitation here tells reviewer-simulation "don't flag this as fatal — it's known". How to answer: be candid; this stays in your file, not in the manuscript.
enforced or avoided?"*
Why this matters: argumentative-flow will respect both lists during any structural revision — preferred names for your method or organism stay; words like novel, groundbreaking, paradigm-shifting (or whatever your venue prohibits) are kept out. How to answer: skip if you don't have a venue-specific style guide handy; you can fill this in later when you draft a cover letter and notice their banned-word list.
targets: quantitative, restrained, evidence-driven, accessible, formal."*
Why this matters: tone tags are consumed by transformation skills as a sanity check — argumentative-flow will resist a revision that drifts toward marketing language if you've set restrained. How to answer: 2-4 tags; pick what your target venue's prize papers read like.
mixed if you don't have a venue preference.
Why this matters: audience specificity bounds what argumentative-flow will gloss vs. explain. "Clinicians" is too broad; "clinical endocrinologists familiar with checkpoint inhibitors but not single-cell methods" tells the skill exactly which background to assume and which to fill in. How to answer: one sentence; specific enough that you'd describe a typical reader of your target venue.
"Where are you thinking of submitting? Three states are fine: decided (one venue you've committed to), considering some (a short list you're choosing among), or not yet (you'll decide once the draft is further along)."
Why this matters: desk-rejection-risk requires a single decided venue. reviewer-simulation uses venue tier to calibrate the lenses. venue-fit (when you're ready) takes whichever state you're in — undecided, considering, or decided — and tiers candidates. How to answer:
target_venue.candidate_venues. Often 2-4 entries.
valid. Drafting before deciding on a venue is the modal author workflow, not a missing step. Once the draft has structure, run /scriptorium:venue-fit to populate the candidate list.
If both fields are left empty, note in the closing summary that venue is undecided and /scriptorium:venue-fit is the natural next step once the draft is substantive enough for fit assessment (typically once the introduction and abstract are written).
limit?"* Skip if unknown.
lifecycle? outline / draft / review / revision / submission / post-submission / accepted."*
Why this matters: phase governs which leaf skills will help. Reviewer simulation on an outline is wasted effort; citation-audit on a finished accepted paper is wasted effort. How to answer: honest current state; you can advance it later.
target submission date?"* Skip if unknown.
If the file already has values for any of these, show them first and ask whether to update, add to, or leave alone.
When the author is done elicitating (or has chosen to skip the rest):
file (or against the blank template if the file is new).
fails, surface the specific errors and propose fixes conversationally — "the schema expects `target_type` to be one of `manuscript / grant / review / preprint / book-chapter / thesis / white-paper / other`; I had `clinical-study`. Switch to `manuscript`?"
Only on explicit author confirmation. Preserve template comments for fields left empty so the author can fill them in later without guessing the schema.
If MANUSCRIPT_STATE.yaml does not exist yet, prefer running the CLI to scaffold the blank first, then merge the elicited values in:
scriptorium init <manuscript-dir>If the CLI is not on PATH, write the file directly.
Based on document_phase.current, suggest sensible follow-up skills:
outline / draft — *"The leaf skills don't yet help much atthis phase. Come back once you have full draft sections."*
review / revision — *"Run citation-audit to check existingreferences; run reviewer-simulation for a pressure test before you circulate."*
submission — *"Before submission, an argumentative-flow passon the discussion section often catches structural issues a final reader will notice."*
Independently of phase, if both project.target_venue and project.candidate_venues are empty, also suggest:
"Venue is undecided in your state file. When the draft is substantive enough to assess fit (typically once the introduction and abstract are written), run /scriptorium:venue-fit to tier candidate venues."If project.target_venue is set, optionally suggest /scriptorium:desk-rejection-risk as the next step once the draft is at submission phase.
If meta.guidance_level is full, also offer:
"If you'd like a tour of any skill before you run it, try/scriptorium:explain <skill>— it summarises what the skill does, what it consumes fromMANUSCRIPT_STATE.yaml, and what it produces."
These are suggestions, not auto-invocations. The author chooses.
This skill produces a conversation, not a markdown report. The only file written is MANUSCRIPT_STATE.yaml. When the conversation ends, emit a short summary message to the author:
Wrote MANUSCRIPT_STATE.yaml. Validated against the schema (X fields
populated, Y left for later). Next: <suggested skill> when you're ready.author should always know what they're walking into before they walk into it.
author's pick controls every later skill's tone; setting it first means the user has chosen the contract for the rest of the conversation, including this one's elicit phase.
decisions. The author always sees "here's what I think; OK?"
a single intimidating questionnaire. Each elicited field carries a short "why this matters" preface — that's how the full level lets the author learn the workflow as they go.
the skill shows it before asking.
jsonschema error dumps.
early phases get "come back later"; mature phases get specific skill suggestions.
author never receives a broken file).
collaborator helping the author think, not a survey form.
citation-audit,reviewer-simulation, argumentative-flow) when the conversation ends. Suggest only; the author invokes.
This skill is grounded in:
schemas/manuscript-state.schema.json — the canonical field setand enum values the elicitation steers toward. Read at runtime so the skill stays in sync with schema evolution.
introduces to the author and writes to meta.guidance_level. Init itself always runs at full; the level it sets controls every later skill.
matter for downstream skills. known_weaknesses, target_venue, and core_claims are the load-bearing inputs for reviewer-simulation; capturing them well here makes that skill's output much sharper.
This skill does not need deep evidence-base grounding — it is a utility for getting an author to a state where the evidence-grounded skills can run.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.