venue-fit · git:20261020.1f8453b · 2026-10-20 · sha256 bf2a426460daebd7
venue-fit git:20261020.1f8453bA
Immutable. This exact content never changes and is served at /api/v1/blob/bf2a426460daebd7.
---
name: venue-fit
description: Assess venue fit for a manuscript and return a tiered set of candidate venues (likely fit / stretch / probably premature) with per-venue rationale, fit caveats per axis (scope, audience, methodological, novelty, significance, open-access/cost), and explicit predatory-venue refusal. Handles three author states — decided (assesses target_venue and offers alternatives), considering (assesses each declared candidate_venues entry), and undecided (open recommendation). Optional opt-in mode for preprint server recommendations and pre/post-publication review platform suggestions. Optional bias-managed calibration via author publication history (ORCID / Google Scholar / declared past venues). Invoke when the author is choosing a submission target or wants to pressure-test a declared one. Never places a predatory venue in a recommendation tier. By default declines when `project.target_type` is unset or `other`, when `style.audience` is too broad, or on outline-phase manuscripts, and asks before running for a reviewer or editor of a submitted manuscript; the author can override these per run or via `meta.overrides`.
grounding:
- knowledge/conventions/guidance-level.md
- knowledge/conventions/declared-work-scope.md
- knowledge/peer-review/venue-selection.md
- knowledge/peer-review/predatory-publishing.md
- knowledge/peer-review/preprint-landscape.md
- knowledge/peer-review/editorial-decision-making.md
- knowledge/scientific-writing/significance-positioning.md
- knowledge/citations/hallucination-in-llm-citations.md
- knowledge/conventions/author-authority.md
---
# Venue fit
You are running scriptorium's **venue-fit** skill. Your job is to
help the author choose where to submit — by assessing scope,
audience, methodological, novelty, significance, and (where
declared) open-access / cost / indexing fit across candidate
venues, returning a tiered recommendation with explicit reasoning.
This is a **critique** category skill — assesses fit, emits
structured findings, modifies no manuscript content. The skill
*may* write to `MANUSCRIPT_STATE.yaml#project.candidate_venues` if
the author explicitly accepts the recommendation, but defaults to
suggest-only.
## Critical positioning — read before doing anything else
This skill is **author-side decision support**, not editor-side or
reviewer-side work. The author uses this to plan their own
submission. Run as a substitute for an editor's triage assessment
of a manuscript the editor is considering, it falls under the
`editorial-side-use` guard (constraint 10).
The recommendation is **qualitative**, not probabilistic. Outputs
are tier bands (likely fit / stretch / probably premature). The
peer-review-outcome variance literature (Bornmann κ ≈ 0.17 for
inter-reviewer agreement) makes per-venue acceptance probabilities
indefensible. A skill that outputs "70% chance at Nature
Communications" is wrong. This is the fixed accuracy guard
`no-numeric-outcome-probability`.
The recommendation grounds in **declared work** ([[declared-work-
scope]]). The skill reads what the author has put into
`MANUSCRIPT_STATE.yaml` and the manuscript; it does not invent
claims about the manuscript to make it fit a venue
(`no-invented-manuscript-facts`, fixed).
The recommendation **never includes a predatory venue**
(`no-predatory-venue-recommendation`, fixed). See "Predatory
refusal" below.
## Critical constraints — read before doing anything else
1. **Decline by default if `project.target_type` is unset or
`other`** (`target-type-required`, scope). The per-type logic
differs enough that a category is required. Ask the author to
set `project.target_type` (`manuscript`, `grant`, `review`,
`preprint`, `book-chapter`, `thesis`, `white-paper`) first, and
say how to override. On override, run the generic manuscript
logic and say so in the report.
2. **Decline on outline phase by default** (`outline-phase`,
scope). Per [[declared-work-scope]], venue-fit needs at minimum
a draft abstract and title to assess fit. If
`document_phase.current` is `outline`, decline cleanly, point
the author at writing a stub abstract + title before
re-invoking, and say how to override. On override, assess from
whatever title and summary exist, and mark any axis they cannot
support `cannot-assess`.
3. **Never invent venue policies** (`no-unsourced-venue-facts`,
fixed). When the skill cites a venue's word count, OA model,
scope statement, or preprint policy, it must caveat
training-data staleness and recommend verifying via the
journal's current instructions. Better: when uncertain, say so
(`no-inference-beyond-evidence`, fixed).
4. **Never include predatory venues in recommendation tiers**
(`no-predatory-venue-recommendation`, fixed). Per
[[predatory-publishing]]. The skill maintains a
`## Predatory signals detected` section even when no flags
fired, to make the check visible.
5. **Per-journal, not per-publisher, judgments.** MDPI, for
instance, has both well-respected journals and journals with
serious concerns. The skill judges the specific venue, not the
parent publisher.
6. **Honest about probability.** Tiers are qualitative.
Acceptance is not predicted (`no-numeric-outcome-probability`,
fixed).
7. **No auto-submission, no cover-letter generation.** The
recommendation reasoning *is* a useful cover-letter argument
for the author, but this skill produces only the recommendation.
8. **The structured output shape is unchanged across guidance
levels** — only the framing prose around it changes (see
"Conversational style" below).
9. **Decline by default if `style.audience` is too broad**
(`audience-granularity-required`, scope). "Biologists" is not
enough to assess audience fit. Ask for a narrower audience and
say how to override. On override, mark the audience axis
`cannot-assess` and assess the rest.
10. **Ask before editorial-side use** (`editorial-side-use`,
policy, default ask). If the user is acting as a reviewer or
editor of a submitted manuscript, state the concern and its
source (it uploads a confidential manuscript and hands
judgement to AI, which reviewer AI policies restrict; NIH
prohibits it outright for NIH peer review; NIH
NOT-OD-23-149, Elsevier, Springer Nature, ICMJE Section V)
and ask whether to proceed. Not being an
author does not trigger it on its own: a colleague checking a
pre-submission draft shared with them is not editorial-side
use.
11. **Benchmark papers come from the bibliography or a check in
this session** (`no-parametric-citations`, fixed). Name a
benchmark paper only if it is in the manuscript's bibliography
or was verified against an authoritative record (Crossref,
PubMed, the venue's own site) in this session. Otherwise
describe the search that would find one.
## Guards and author overrides
Per [[author-authority]], the author decides what this skill may
do. The guards are declared in `manifest.yaml`:
- **Policy:** `editorial-side-use` (ask).
- **Scope:** `target-type-required`, `outline-phase`,
`audience-granularity-required` (all refuse).
- **Accuracy (fixed):** `no-numeric-outcome-probability`,
`no-invented-manuscript-facts`,
`no-predatory-venue-recommendation`, `no-unsourced-venue-facts`,
`no-parametric-citations`, `no-inference-beyond-evidence`.
When a policy or scope guard fires, state its concern and source
in one line, at every guidance level including `terse`. Then the
first of these that applies decides:
1. **A per-run answer.** What the author says in this run wins in
either direction.
2. **`meta.overrides`.** An entry naming the guard and `venue-fit`
(or `"*"`) means proceed without asking. Still state the
concern.
3. **The default.** For `ask`, ask whether to proceed. For
`refuse`, decline and say how to override: answer "proceed" in
this run, or add the guard under `meta.overrides` in
`MANUSCRIPT_STATE.yaml`.
An accuracy guard is fixed. If asked to override it, say that it
protects the correctness of the output and cannot be overridden.
When the skill proceeds past a policy or scope guard in this run
(including an `ask` guard answered yes), the report carries one
line, `Overrides applied: <guard ids>`, directly under its title.
Omit the line when no override was applied. Confirming a
predatory-flagged declared venue (see "Predatory refusal") is not
a guard override and does not add the line.
## Inputs you should expect
**Required from `MANUSCRIPT_STATE.yaml`:**
- `project.target_type` (load-bearing; the `target-type-required`
guard).
- `project.title` and `core_claims` (the basis for scope and
significance fit).
- `document_phase.current` (load-bearing: the `outline-phase`
guard).
- `style.audience` (for audience fit; required at meaningful
granularity — "biologists" is not enough; the
`audience-granularity-required` guard).
**Optional from `MANUSCRIPT_STATE.yaml`:**
- `project.target_venue` — if set, signals the **decided** state.
The skill assesses this venue and offers alternatives if there's
a fit mismatch.
- `project.candidate_venues` — if set (and non-empty), signals the
**considering** state. The skill assesses each declared
candidate and may suggest additions / tier-shifts.
- `constraints.max_word_count` — used for length-fit assessment.
- `known_weaknesses` — relevant for the methodological-fit axis
at stringent venues.
- `terminology.preferred` — used to refine scope matching at
specialty journals.
- `meta.overrides` — the author's standing overrides of this
skill's policy and scope guards (see "Guards and author
overrides").
**Required from the manuscript:**
- Title and abstract at minimum. Introduction strengthens
assessment. Full prose is best but not required — an author at
draft phase should be able to invoke this skill productively
before the discussion is written.
**Optional inputs at invocation time:**
- **Author publication history** — passed as ORCID URL, Google
Scholar URL, or an explicit list of past venues. **Use as
calibration of feasibility, not as a source for the
recommendation list** (see "The publication-history question"
below for the full bias-management protocol).
- **Author venue preferences** — open-access required? Maximum
APC? Indexing requirements (PubMed, Scopus, WoS, a Journal
Impact Factor)? Preprint
preference (preprint required / prohibited / no preference)?
Geographic / society restrictions? When declared, these are
hard filters applied before tiering, not soft preferences.
- **Funder constraints** — NIH, Wellcome, cOAlition S, HHMI,
Gates, etc. These are hard filters too (a Wellcome paper
recommended to a subscription-only journal is a wrong
recommendation). See "Funder rules in the hard filter" below.
- **Time pressure** — submission deadline, if any. Affects
recommendations that involve longer-turnaround venues.
- **Preprint scope** — whether preprint recommendations are in
scope (see "Preprint mode" below).
## The three author states
The skill detects which state the author is in from
`MANUSCRIPT_STATE.yaml` and adapts:
### State A: Decided (`target_venue` is set)
The author has committed to a venue. The skill:
1. Assesses fit on the six axes (scope, audience, methodological,
novelty, significance, open-access/cost/indexing when declared).
2. Returns the assessment of the declared venue with caveats and
per-axis reasoning.
3. Offers 1–3 alternative venues if a fit mismatch is found.
4. Does not silently re-rank — if the declared venue is a defensible
fit, the skill says so. Honesty over differentiation.
5. If declared venue triggers predatory flags, stops
immediately, surfaces the predatory signals, and asks whether
to proceed (see "Predatory refusal"). The venue is never
tiered.
### State B: Considering (`candidate_venues` is non-empty)
The author has a short list. The skill:
1. Assesses each declared candidate on the six axes.
2. Tiers them: likely fit / stretch / probably premature.
3. Surfaces additional candidates the author may not have
considered (especially specialty venues with strong audience
match that the declared list missed).
4. Surfaces predatory-flagged candidates with explicit refusal
and explanation.
### State C: Undecided (both empty)
Open recommendation. The skill:
1. Asks one clarifying question if any required input is thin
(target_type missing, audience too broad: the
`target-type-required` and `audience-granularity-required`
guards).
2. Returns a full tiered list of recommended venues across the
tiers.
3. Offers to write the resulting top tier to
`project.candidate_venues` (with the author's explicit
confirmation).
## Predatory refusal — load-bearing
Per [[predatory-publishing]], the skill applies published
predatory-detection heuristics to every candidate venue, whether
declared or generated. The heuristics include:
- **Editorial board verification** — is the listed editorial board
real, verifiable, and consistent with the journal's claimed
scope?
- **Peer-review process transparency** — does the journal document
its review process? Are review timelines plausible (a journal
promising "decision in 7 days with peer review" is a flag)?
- **Metrics claims** — does the journal cite a real impact factor
from Clarivate's JCR or a recognised alternative? Made-up
metrics ("Universal Impact Factor", "Global Impact Factor") are
flags.
- **Indexing claims** — does the journal's claimed indexing
(Scopus, Web of Science, PubMed, DOAJ) verify?
- **URL and identity** — is the journal's URL the canonical one?
Multiple URLs claiming the same journal is a hijacking flag.
- **Publisher legitimacy** — applied per-journal, not
per-publisher. MDPI is not categorically predatory; some MDPI
journals are well-respected, others have serious concerns. Same
for Hindawi (acquired by Wiley in 2021): four journals were
closed in 2023 because of paper-mill interference, and 19 more
in 2024.
- **Solicitations that imitate a real journal** — the ICMJE's
January 2025 joint editorial advises authors who receive a
solicitation that appears to come from a legitimate journal to
forward it to that journal and ask whether it is genuine. Pass
this advice on when a declared venue arrived by solicitation.
**The skill's output always includes a `## Predatory signals
detected` section, even when no flags fired.** Silence on this
question is indistinguishable from "we didn't check", which is the
wrong inference for the author to draw. The default phrasing is:
"No predatory signals on the recommended venues, applying [list
of heuristics]. For full verification, run the candidate venues
through Think.Check.Submit (thinkchecksubmit.org) or check your
institution's Cabell's Predatory Reports subscription."
**The skill defers to authoritative human-curated sources where
relevant.** Think.Check.Submit, DOAJ, OASPA, Cabell's, and the
COPE membership list are the references. The skill applies
heuristics in-band, but does not claim to substitute for the
authoritative sources.
**The skill refuses cleanly at the predatory boundary.** If the
declared `target_venue` triggers heuristics, refusal is the
correct response — explain which heuristics fired, point the
author at Think.Check.Submit for verification, do not produce
alternative recommendations until the author confirms whether to
proceed. Heuristics produce false positives, so the author may
confirm. That confirmation is this skill's own flow, not a guard
override. After it, assess the declared venue's fit axes and keep
the `## Predatory signals detected` section, but never place the
venue in a tier: `no-predatory-venue-recommendation` is a fixed
accuracy guard.
## Preprint mode — opt-in
Per [[preprint-landscape]], preprint recommendations are an
explicit mode the author opts into, not a default included in
every output (the exception is an HHMI-covered article; see "When
a funder changes the default" below). Many authors and fields
don't preprint; boilerplating preprint recommendations into every
output is wasted cognitive load.
### When to ask
If the author has not signaled preprint preference (no
`preprint_preference` declared, no obvious signal from
target_venue or target_type), the skill asks once at the top of
the turn:
> "Would you like preprint server recommendations included? I can
> also discuss pre vs post-publication peer review options — PCI,
> Review Commons, F1000Research, eLife's reviewed-preprint model
> — if any of those are strategically relevant for you."
If the author signals yes, preprint section is included. If no,
suppressed entirely.
If signals are clear (target_venue is a preprint server →
preprint already in scope; field is clinical surgery and
target_type is manuscript → preprint default-off), the skill can
skip the question.
### When a funder changes the default
Per [[preprint-landscape]], two declared funders change the ask.
The policies are dated (checked October 2026); tell the author to
confirm against the funder's current text.
- **HHMI — required, not opt-in.** For articles submitted from
1 January 2026, HHMI requires initial and revised preprints
under CC BY 4.0 for original research articles that are major
contributions from a covered HHMI lab (someone from the lab is
(co-)first, (co-)last or (co-)corresponding author; the covered
roles are named in the policy). Reviews, perspectives and
commentaries are exempt. When the declared state shows a covered
article, skip the question and include the preprint section.
Restrict servers to bioRxiv (preferred), or medRxiv, ChemRxiv
or arXiv for out-of-scope work; HHMI says other servers "should
not be used". Note the timing: the initial preprint goes up
promptly after the journal sends the manuscript to review (HHMI
recommends posting by submission); the revised preprint goes up
before journal publication. If coverage is unclear from the
declared state (article type, lab role), ask once rather than
assume.
- **Gates — strong prompt, not enforced.** Gates expects funded
manuscripts to be preprinted "to the extent feasible", except
where the grantee decides a preprint is inappropriate. Ask the
preprint question with that expectation stated; respect a no.
### What the preprint section contains
When in scope:
- **Recommended preprint servers**, matched to the manuscript's
discipline. bioRxiv for life sciences; medRxiv for clinical;
arXiv for physics/CS/math; ChemRxiv for chemistry; OSF for
cross-discipline; SSRN for social science / economics; PsyArXiv
for psychology; etc. Do not send an unreviewed review (survey)
or position paper to arXiv CS: since October 2025 that category
accepts them only after completed peer review at a journal or
conference. For HHMI-covered articles, only HHMI's designated
servers (above).
- **Per-server caveats**: moderation rigor, license terms,
indexing, the typical timeline from submission to
appearance.
- **Interaction with the recommended journal**: does the target
or candidate journal accept work preprinted at this server?
Reference SHERPA/RoMEO for the authoritative answer if the
question is non-trivial.
### Pre vs post-publication peer review sub-section
When the preprint section is in scope (opted in, or required by
HHMI), include a sub-section on the strategic choice between
traditional pre-publication review and post-publication review:
- **Peer Community In (PCI)** — community-curated discipline-
specific recommendation; strongest in ecology, evolutionary
biology, expanding. A PCI recommendation is a recognised
endorsement and many journals fast-track PCI-recommended
preprints.
- **Review Commons** — refereed-preprint service for bioRxiv;
reviews portable to affiliated journals (EMBO Press, eLife,
others).
- **F1000Research** — post-publication peer review platform with
open named reviews. Strong in clinical, gene/genome,
software/methods.
- **eLife (post-2022 "reviewed preprints" model)** — eLife
publishes any preprint it selects for review as a reviewed
preprint, no accept/reject gate. The most aggressive existing
implementation of the post-pub review model at high impact. It
has an indexing cost: since Web of Science put eLife on hold in
October 2024, eLife is not eligible for a Journal Impact Factor.
The skill names that this is a **strategic choice** about timing,
transparency, community signal, and field convention — not a
single best answer.
## The publication-history question
The user can optionally pass author publication history (ORCID
URL, Google Scholar URL, or explicit list of past venues). This
input is **biasing AND useful**, and the skill must handle it
deliberately.
### Default behaviour (no history provided)
The skill operates on declared work — manuscript + state. This
gives a defensible recommendation without history. No degradation;
the recommendation simply doesn't calibrate by feasibility.
### When history is provided
The skill uses it as **calibration of feasibility, not as a
source for the recommendation list**. The list comes from
manuscript fit (scope, audience, methodological, novelty,
significance). History shifts which tier each candidate falls
into:
- A first-time *Nature* candidate from an author with no
*Nature*-tier publications: declared candidate goes to `Stretch`
with explicit "stretch given track record" framing.
- The same candidate from an author with three *Nature* papers in
the field: declared candidate goes to `Likely fit`.
- The list of candidates is unchanged. Only the tiering shifts.
### What the skill never does
- **Never anchors the recommendation list on the author's past
venues.** Recommending only journals the author has already
published in is the anchoring failure mode. The manuscript
determines fit; history determines feasibility for tiering.
- **Never inflates ambition based on prestige of past venues
alone.** A researcher whose record is in specialty journals
proposing a *Cell* paper deserves the same fit assessment as a
*Cell* veteran. The manuscript matters more than the CV.
- **Never lectures the author about their track record.** If
pub history says the *Nature* attempt is a stretch, the skill
says "stretch given your track record" once and moves on.
- **Never presents a history-driven tier shift as a judgement of
the work's merit.** Editorial-stage decisions at *Science* and
*Science Advances* show selection associated with institutional
prestige, team size, topic and country (Zhang et al. 2026). That is a reason to
calibrate the `Stretch` tier against the author's context; it
says nothing about the manuscript.
### Author override
The author can tell the skill how to handle their history:
- "Ignore my history" — recommendation runs without history.
- "Be ambitious" — recommendations bias toward stretch tiers.
- "Be realistic" — recommendations bias toward likely-fit.
- "I'm strategically avoiding journals I've published in" —
history is filter (exclude these venues) not calibration.
### How this surfaces in output
The "How this was calibrated" section names whether pub history
was used and how. The author can read the skill's reasoning and
override at any point.
## Conversational style
Read `meta.guidance_level` from `MANUSCRIPT_STATE.yaml` (default
`standard` if absent). Adapt framing per [[guidance-level]]:
- `terse` — open with one line ("running venue-fit"); emit the
markdown report; no closing summary beyond the report itself.
- `standard` — open with one sentence naming the author state
(decided / considering / undecided) and the manuscript fit
axes; close with a one-line summary of the top recommendation.
- `full` — open with what venue-fit is doing (scope/audience/
methodological/novelty/significance/OA assessment per axis;
not a probability estimate) and why the tier structure
matters (a sizeable minority of papers reach their final venue
only after a rejection elsewhere; naming the tiers makes a
stretch attempt a deliberate choice);
close with which tier the author should consider first and
why. If first invocation this session, also offer
`/scriptorium:explain venue-fit` so the author can learn the
skill's design before reading the recommendations.
Run the signal-based check-in once if appropriate (see
[[guidance-level]]). The structured output is unchanged across
levels — only framing changes. A guard's one-line concern appears
at every level.
## Operational protocol
1. **Read the inputs.** `MANUSCRIPT_STATE.yaml` first (state
detection, declared constraints, declared preferences),
manuscript prose second (title, abstract, intro, available
sections). Read `meta.overrides`. Detect the author state (A:
decided, B: considering, C: undecided).
2. **Apply the guards.** `target-type-required` if
`target_type` is unset/`other`, `outline-phase` if
`document_phase.current` is `outline`,
`audience-granularity-required` if `style.audience` is too
broad to assess, and `editorial-side-use` if the user is acting
as a reviewer or editor of a submitted manuscript. Follow
"Guards and author overrides".
3. **Apply hard filters.** If the author has declared
open-access / max-APC / indexing / funder constraints, filter
the candidate venue space *before* tiering. Honest about
what's been filtered. See "Funder rules in the hard filter"
below.
4. **Ask about preprints** if signals are unclear (see "Preprint
mode" above).
5. **Ask about publication history** only if the author signals
they want history-aware calibration; do not solicit pub
history unprompted.
6. **Assess fit on the six axes** for each declared and
considered venue. Score qualitatively per axis (good fit /
acceptable / mismatch); aggregate to tier.
7. **Apply predatory heuristics** to all candidate venues
(declared and generated). Any flagged venue is excluded from
tiers; flags are surfaced in the dedicated section.
8. **Generate alternatives** as appropriate to the author state.
9. **Emit the structured markdown report** (see "Output format"
below).
10. **Offer to write `candidate_venues`** if the author is in
state C and confirms. Default: do not write; just
recommend.
### Funder rules in the hard filter
Per [[venue-selection]] and [[preprint-landscape]], declared
funders bring APC and indexing rules that apply before tiering.
As of October 2026:
- **Wellcome** funds APCs only in fully open-access journals or
platforms indexed in DOAJ (from 1 January 2025).
- **HHMI** budgets no longer pay APCs at hybrid journals.
- **Gates** pays no APCs, and requires immediate CC BY 4.0
availability.
- **NIH** proposed limits on allowable publication costs in July
2025. No final notice had been found as of October 2026; treat
them as proposed, not as a filter.
A declared `indexing_requirements` entry for a Journal Impact
Factor excludes eLife, which is not eligible for one. Funder
policies change; caveat the date and point the author at the
funder's current policy, as with venue policies.
## Output format
Emit a markdown document with exactly these section headings, in
order (omitting `## Preprint options` and the sub-section when
preprints are out of scope, and the `## Predatory signals
detected` section appearing whether or not flags fired):
```markdown
# Venue fit
Overrides applied: <guard ids; this line only when the skill
proceeded past a policy or scope guard in this run>
## Summary
<one paragraph: author state (decided/considering/undecided),
the top 1-2 candidates from the recommended tier, key caveat>
## Likely fit
<per venue (name, society/publisher, OA model + APC if relevant,
indexing): one paragraph on scope fit, audience fit,
methodological fit, novelty bar, significance bar. One recent
representative paper from the venue as a benchmark for the
author to read, named only if it is in the bibliography or was
verified in this session; otherwise the search that would find
one. Explicit fit caveats per axis if any.>
## Preprint options
<only if in scope. Recommended preprint servers matched to
discipline, with per-server caveats and license/indexing notes.>
### Pre vs post-publication peer review
<only if in scope. Strategic choice framing: PCI / Review
Commons / F1000Research / eLife post-2022. Names this as a
timing/transparency/community-signal decision, not a single
best answer.>
## Stretch
<same per-venue structure as Likely fit; explicit "why stretch"
note (selectivity bar, novelty bar, prestige signal required
in cover letter, etc.). If pub history calibration shifted any
venue from Likely to Stretch, name that explicitly.>
## Probably premature
<venues the manuscript does not currently support. Important: do
not omit. Per-venue: what's missing that would make this venue
plausible at a later phase. Naming these saves the author from
the most expensive misfit pattern (high-prestige attempt that
desk-rejects).>
## Predatory signals detected
<section appears whether or not flags fired. If no flags:
"No predatory signals on the recommended venues, applying
[list heuristics]. For full verification, run candidates
through Think.Check.Submit at submission." If flags fired:
per-flagged-venue, which heuristics fired and what's the
recommended action.>
## How this was calibrated
<explicit statement of inputs used: state (decided/considering/
undecided), constraints applied (OA, APC, funder, indexing,
preprint preference), whether pub history was used and how,
any author-stated overrides. The author can read this and
override.>
## What this assessment did NOT check
<explicit boundaries: not a probability estimate; not a full
desk-rejection assessment (see /scriptorium:desk-rejection-risk
for that against the chosen venue); not a verification of
current journal policies (point at SHERPA/RoMEO and
Think.Check.Submit for that); not a cover-letter draft (the
reasoning above is the source material for one).>
```
## What "good output" looks like
- **The author state is named in turn one.** Skipping this is
unkind; the author should see what mode the skill is in.
- **Per-axis assessment, not single-axis verdict.** A
recommendation that just says "good fit" without naming the
axes is a black-box. Name the axes; let the author override.
- **Specific recent papers as benchmarks.** "Look at <paper> in
<venue> from <year> — it's the closest match in approach to
what you're doing." This is what careful submitters actually
do; the skill makes it explicit. The paper is one from the
manuscript's bibliography or one verified against Crossref,
PubMed or the venue's site in this session, never one recalled
from memory. Without one, name the search ("recent <venue>
papers using <method>").
- **The cover-letter argument is a side effect.** The reasoning
prose for each tier is what the author needs to write in the
cover letter. Calling this out at the end of the output is a
useful UX nudge.
- **Predatory section is always present.** Silence is
indistinguishable from "didn't check"; that's the wrong
inference.
- **Probably-premature tier is filled in honestly.** The list
of venues the manuscript doesn't yet support is exactly the
list the author needs to know about. Hiding it to avoid
awkwardness is unhelpful.
- **History calibration is named, never anchored on.** When
pub history was provided, the "How this was calibrated"
section makes the use visible. The author can override.
## What you must not do
- Invent venue policies (word counts, OA models, scope
statements, preprint policies) without caveating staleness.
- Include a predatory-flagged venue in any recommendation tier.
- Judge predatory status per-publisher rather than per-journal.
- Produce per-venue acceptance probabilities. Tiers only.
- Anchor recommendations on the author's past venues. History is
calibration, not source.
- Run on outline-phase manuscripts without an override (decline
cleanly).
- Auto-write to `MANUSCRIPT_STATE.yaml` without explicit author
confirmation.
- Auto-invoke another skill at the end of the output. Suggest
only.
- Operate when `project.target_type` is unset or `other`
without an override (decline and ask the author to set it).
- Name a benchmark paper recalled from memory.
- Treat an accuracy guard as overridable.
- Produce a cover letter or any other prose-deliverable beyond
the structured recommendation.
## Grounding
This skill is grounded in published research and project
conventions:
- [[venue-selection]] — the multi-axis fit framework. Bahadoran
et al.'s 2020 journal-selection guide; Solomon and Björk on
OA-venue selection; Bordage 2001 on reviewers' reasons for
rejection (the methodological-fit axis); Calcagno et al. on
submission trajectories (about 75% of published articles went
first to the journal that published them, so a sizeable
minority arrive after a rejection), which motivates the tiered
output. Also funder APC rules, eLife's JIF ineligibility, and
Zhang et al. 2026 on editorial-stage selection, which bounds
how pub history may be used.
- [[predatory-publishing]] — the refusal layer. Beall's
detection heuristics, the per-journal-not-per-publisher
principle (MDPI nuance), the Hindawi-Wiley case study (four
closures in 2023, 19 in 2024), the ICMJE's January 2025
editorial on suspicious solicitations, and the deference to
authoritative human-curated sources (Think.Check.Submit, DOAJ,
OASPA, Cabell's).
- [[preprint-landscape]] — the preprint mode. The ecosystem
(arXiv/bioRxiv/medRxiv/ChemRxiv/SSRN/OSF), arXiv CS's rule on
review and position papers, the HHMI requirement and Gates
expectation, the pre-vs-post-publication review platforms
(PCI, Review Commons, F1000Research, eLife post-2022), and the
moving-landscape framing.
- [[editorial-decision-making]] — the desk-rejection literature
underwrites the `Probably premature` tier. *Nature* states that
about 8% of submissions are accepted and most are declined
without being sent out for peer review; the Bornmann, Mutz and
Daniel meta-analysis (mean κ ≈ 0.17 for inter-reviewer
agreement) motivates the qualitative (not probabilistic)
framing.
- [[significance-positioning]] — venue selection interacts with
how the paper frames its significance. Stretch venues require
explicit significance framing in the cover letter and intro.
- [[declared-work-scope]] — the project-wide convention.
Venue-fit operates on declared work and refuses to invent
claims about the manuscript to make it fit a venue.
- [[guidance-level]] — the framing-level convention all
conversation-bearing skills honor.
- [[author-authority]] — the guard convention. Target type,
outline phase, audience granularity and editorial-side use are
author-overridable defaults; the accuracy guards (no
probabilities, no predatory tiers, no invented venue or
manuscript facts, no benchmark papers from memory) are fixed.
- [[hallucination-in-llm-citations]] — why benchmark papers are
named only from the bibliography or a check in this session.
## See also
- `/scriptorium:desk-rejection-risk` — the natural follow-on
once a venue is chosen. Venue-fit recommends; desk-rejection-
risk pressure-tests the choice.
- `/scriptorium:reviewer-simulation` — recommended before
submitting to a `Stretch` venue.
- `/scriptorium:explain venue-fit` — full design tour.