Your voice: the style guide and venue notes

Two things shape how a drafted report or letter sounds. One is your style guide. The other is your venue notes, which you write yourself.

The style guide

Your style guide is STYLE.md in your reviews folder. Setup copies it from the guide that ships with refereekit. Edit it in any text editor. Every draft, the OpenReview form included, gives the whole file to the model backend as the voice to write in.

Put in it how you like a report built, the words you reach for at each verdict, and habits of phrasing you want a draft to copy. Never put in it a passage of a report you sent, a paper’s title or authors, or another paper’s content. If you keep the reviews folder in git, the style guide is committable, and nothing keeps it private.

The packaged guide shows what belongs in one: rules of voice and structure, with no report text. Rewrite it until it is yours.

The files you edit

Editing a file is not running a command. Three files in the reviews folder are yours:

• STYLE.md, your voice. Edit it yourself, or ask the agent to.
• venue-policy.toml, the venues that forbid a language model. Edit it yourself. Lifting a venue’s refusal is your decision, so the guides tell the agent to leave it to you.
• .env, where Model access keeps your keys. Use Model access rather than the file. In the agents with hooks, the agent is refused this file.

Venue notes

A venue note is a sentence in your own words about how you review for a venue. Write one once you have settled on a verdict:

PRX: lean accept-after-major on approximate-but-validated theory

Write and read notes in the private view: /refx-note in pi, or the Venue notes part of the review window. A note belongs to the venue the session recorded. The agent’s model learns only whether a note was stored, and how many there are.

The notes live in one file in your reviews folder, beside the sessions. So a note carries from one paper to the next. Every later draft for the same venue recalls up to 20 of your notes for it, newest first, as one more input. With no venue known, nothing is recalled. Deleting a session leaves your notes alone.

What the leak guard rejects

A note may hold only your own judgment, never the paper’s words. Before a note is stored, refereekit compares it with the paper’s text. Try a quotation from the tutorial’s paper as a note:

a finite set of nodes

The private view shows:

input is a verbatim manuscript fragment (short verbatim manuscript fragment)

Nothing is stored. The check ignores case, spacing and typography, as verification does. It has two rules:

• A note under eight words is refused if it appears anywhere in the paper’s text, even inside a longer word. So a one-word note such as he is refused, because it occurs inside “the”.
• A longer note is refused if any eight words in a row appear in the paper, or if it shares several scattered runs of eight with it.

A paper with no readable text refuses every note. With nothing to compare against, refereekit refuses rather than skip the check.

The check compares wording, not meaning. It cannot tell a paraphrase from a judgment, and it cannot stop you summarizing the paper in your own sentences. Write what you concluded, and why. A note that would let someone rebuild a sentence of the paper is the wrong kind of note, whatever the guard says.

See also

• Reviewing for a journal: how the venue is recorded.
• Confidentiality: what else protects the paper.