From a synthetic manuscript to a reviewer evidence file

Start with a synthetic manuscript, not a confidential submission

Use this fictional brief: “How do changes to a digital platform’s developer interfaces affect complementor autonomy? We propose a comparative qualitative study of governance changes, developer adaptation and exit across platform ecosystems.” The brief has no real authors, institution, confidential findings or participant data. It is an input exercise, not a completed study.

The goal is a reviewer evidence file for human assessment, not a list ready for automatic invitations. This walkthrough is illustrative and checked against the downloadable skill’s workflow and scripts. No real reviewer shortlist has been executed for this fictional manuscript, and no named candidate’s availability or conflict status is asserted.

Choose the focused skill, not the platform recommendation tool

Download Scholion’s Reviewer Suggestions skill and read its security guidance. The host agent conducts retrieval and judgment; bundled scripts normalize input, calculate scores and produce Markdown/HTML reports. MCP is preferred when connected, with a Python REST client as fallback.

The focused skill explicitly does not call the platform’s recommend_reviewers tool or the REST /recommend/reviewers endpoint. That separate platform recommendation feature is not interchangeable with this agent-guided evidence chain. Other supported retrieval endpoints remain available.

Set a budget and decide what may leave the host. Manuscript text and search queries can be sent to the host model and Scholion services. Reports are written locally. PDF extraction can require an additional package, and endpoint overrides can redirect credentials. For a real confidential manuscript, obtain authorization and assess the services’ terms before using it. The synthetic brief avoids those disclosure concerns for this exercise.

Normalize the input and constraints

Save the fictional brief as synthetic-manuscript.txt, then use the downloaded skill’s script:

python3 <skill-dir>/scripts/extract_input.py synthetic-manuscript.txt \
  --out manuscript.json

<skill-dir> is a placeholder for the extracted folder. Review the normalized title, text, references and warnings. Do not pretend the fictional brief has a validated reference list or real manuscript authors. For a real workflow, supply authors, institutions, target journal and explicit exclusions and check how the input parser represents them.

Retrieve through multiple evidence paths

Ask the agent to use keyword and semantic searches for platform governance, complementor autonomy, boundary resources and ecosystem dependency. The skill also supports manuscript-reference, citing-paper and bibliographically coupled-paper paths. Because this synthetic brief has no references, the agent should record that limitation rather than invent a reference list to fill the paths.

As a deliberate public seed, inspect the catalog-verified ISR paper Exploiting and Defending Open Digital Platforms with Boundary Resources. Its DOI can support reference and related-paper exploration. This is a seed-selection example, not evidence that every author on the paper is an appropriate reviewer.

For each potential candidate, preserve a real retrieved paper and DOI, the topical reason for inclusion, and the available identity evidence. Distinguish ORCID/OpenAlex-linked evidence from name-only matches. Two records with the same name are not automatically the same scholar.

Screen conflicts before ranking

The skill checks supplied author exclusions, available coauthor links, institutions and target-journal editors. These are limited screens. Incomplete affiliations, missing collaborations, name ambiguity, recent employment changes and relationships outside the catalog can all leave conflicts undetected.

An illustrative evidence row—not an actual candidate—would contain: “Candidate A; identity unresolved; supporting DOI to be supplied from retrieval; institutional relationship unknown; do not invite until verified.” It belongs in an unresolved-evidence queue, not the recommended tier. A report that cannot trace a name to a returned paper must not invent that link.

Before an invitation, a human editor should check the journal’s conflict window, employment, recent collaborations, supervisory relationships, personal or financial conflicts and current editorial roles. The synthetic exercise cannot establish any of those facts.

Score only a validated candidate file

The scoring script expects the skill’s JSON contract. Do not pass raw search results or the manuscript extraction file directly to it. Ask the agent to build a candidate file from the evidence, then inspect the template and validate the fields:

python3 <skill-dir>/scripts/score_reviewers.py --print-template
python3 <skill-dir>/scripts/score_reviewers.py \
  --input candidates.json --out scored.json --career-stage junior
python3 <skill-dir>/scripts/render_report.py \
  --input scored.json --md reviewers.md --html reviewers.html

These commands demonstrate the workflow, not a completed run. The junior option is a scoring preference in the supplied script; it does not verify age, years since PhD, job level, workload, willingness or availability. Recent publications and author order cannot establish those attributes. Inspect sensitivity to that preference and do not describe a publication-history band as a verified career stage.

What a defensible handoff contains

The final human-reviewed report should connect each retained candidate to relevant papers, identify missing evidence, explain score components and exclusions, and separate uncertain identities from confirmed ones. Its recommendation is provisional. A score measures the configured evidence and assumptions, not a person’s likely review quality.

MCP and REST calls made by the skill share the same API credit pool and daily limits as other API use. Consult current prices and stop at the agreed budget. Keep the synthetic exercise outputs separate from any actual editorial submission. For a real invitation decision, use the report as a starting point for manual checks—not as authorization to contact someone.