Head to the app and sign in with Google, or with an email and password if you have one. If a collaborator or beta reader invited you, the magic link in that email will sign you in and drop you at their project — no password needed.

Your dashboard is the first thing you see after sign-in. It shows your recent manuscripts and a quick way to start a new draft or open one someone shared with you. Every project holds one manuscript plus any characters, settings, worldbuilding, and style docs you build up alongside the writing.

If this is your first time and you want to poke around, start a blank draft — nothing you do is permanent until you say so, and you can delete a draft any time from the sidebar.

The editor gives you one page per chapter. Four parts to know:

• The sidebar on the far left lists your chapters and design docs. Toggle it with the icon at the top-left of the app, or hide it entirely in focus mode.
• The rail just inside the sidebar carries formatting — bold, italic, headings, lists, blockquotes, images, tables. It's context-aware; buttons cascade into an overflow as the window narrows.
• The page in the middle is where you write. It's paper — no chrome inside the column, no dashboard clutter. A chapter header sits at the top; the layer picker sits under it.
• The Foli chatbox at the bottom of the page is where you talk to Foli about your draft. She reads what's selected (or the whole chapter if nothing is) and responds in the same register the work is in.

Along the bottom you get autosave state, history, Foli's current mode, plugins, comments, and your word count — everything's one click away without competing with the prose.

You can write end-to-end without touching Foli. Nothing she does lands in your draft without you keeping it — every change is a proposal you accept or drop.

Click New chapter in the sidebar (or press the + at the top of the chapter list), give it a title, and start writing. There is no Save button — autosave runs on every change and the status bar tells you when it landed.

When you want a second opinion, drag-select a passage and use the Foli chatbox: ask her to tighten a line, check a beat, rewrite a paragraph in a different register, or explain what isn't landing. She responds with a proposal you keep or drop.

Undoing is safe. You can undo up to 100 steps of your own work, and every version writefolio saves is in the history — reachable from the status bar. If something feels wrong, roll back to a version that worked and start again.

The rest of what writefolio does — layers, the knowledge base, plugins, workflows, publishing — is here when you want it. Start with the writing.

A project in writefolio is one manuscript — one novel, one novella, one screenplay. Everything you write lives on the page, and the page is a single readable column. There's no three-pane dashboard, no folder tree of scenes, no separate "scenes" and "chapters" concept to keep in your head. Just the page.

Alongside the page, a project holds knowledge docs (characters, settings, worldbuilding, style). They're where you record what you've decided about the story so that Foli — and future you — can lean on it later. More on those in The knowledge base below.

A chapter is a heading and the prose that follows it. Add a chapter and you get a new page with a title at the top. Chapters show up in the sidebar as an outline; drag to reorder, click to open. Sub-headings inside a chapter nest under it in the same outline so you can move at scene resolution when you need to.

Chapters carry more than prose — every chapter has its own layer chip strip (see below), notes table for Foli to read on later runs, and a publish pointer that decides who gets to read this chapter and when. But if you never touch any of that, it's still just a chapter with prose in it.

Layers are the central move of writefolio. A chapter can hold more than one version of itself, stacked. You might have an outline layer on top of a beat sheet, a draft layer on top of that, and a line-edit layer on top of that. Each is its own pass; you can flip between them with a tap on the chapter's chip strip. One layer is visible at a time.

Layers matter for two reasons:

• Revision without loss. Try a rewrite as a new layer. The old one stays underneath. Nothing is destroyed.
• Working with Foli. When you ask Foli to build something structured — an outline, a beat sheet, a critique pass — she puts it on its own layer. You keep it or drop it as a unit without losing the layer under it.

The layer picker sits at the top of each chapter, next to the title. Add a layer with + add; each new layer gets a name (you can rename it later) and starts empty or picks up context from the layer under it.

Alongside the prose, writefolio maintains a knowledge base about your story — characters, settings, worldbuilding, style. Each is a dedicated doc opened as a subtab of the project. Inside each doc lives a facts table: rows of question → answer about that entity ("What does Mara fear?" · "Deep water, ever since the accident").

You can write facts yourself. You can also let Foli mine them from your prose — every save triggers a light background pass that reads changed paragraphs and files anything durable ("she's twenty-nine", "the manor floods every spring", "he's allergic to iron") into the right doc's right field. You review what she adds; nothing lands silently in your reference.

The knowledge base earns its keep the moment you ask Foli about your own story. She looks there before answering. Continuity questions ("did I say Mara was left- or right-handed?") get answered from what you've already saved, not from a fresh guess.

Foli is a co-writer. She lives in the chatbox at the bottom of the page. You ask her things; she reads what's relevant (the current selection, the chapter, saved knowledge) and responds. When you ask for a change, she proposes it as a track-change suggestion — never a silent edit. You keep it or drop it.

What she is:

• A second voice in the margin for the work in front of you.
• A reader who remembers what you've established.
• A tool that can run structured passes (outlines, critiques, reviews) at your direction.

What she isn't:

• The one deciding what happens in your story.
• A ghostwriter running unattended in the background.
• A grade or a metric on your work.

Everything Foli does surfaces as a proposal, a suggestion, or a note. The writer keeps the pen.

Chapters live in the sidebar as an outline. Add one from the + at the top of the chapter list; give it a title; you're in. Sub-headings (H2, H3) inside a chapter nest under it in the outline so you can jump at scene resolution.

Drag to reorder. A chapter dragged to a new position keeps its layers, notes, and publish settings — the move is non-destructive.

Inline rename. Double-click a chapter title in the sidebar to rename in place. The heading on the page updates in the same motion.

Deleting a chapter asks you to type the title to confirm. It's the one action that gets a friction step because it's the one that's expensive to undo.

Every chapter has a chip strip just under its title showing its layers. One is visible at a time. Tap another to switch.

Two easy starting patterns:

• A notes layer — a scratchpad above the prose for reminders, cut lines, questions to yourself. Add one from the + on the chip strip; pick "Notes" from the layer type.
• A fresh empty layer — a blank slate to write a new version without losing the current one.

When Foli builds a layer for you (an outline, a beat sheet, a review pass), it lands as its own chip. Keep it as-is, edit it, or drop it — the layer underneath is untouched.

The toolbar to the left of the page carries formatting: bold, italic, underline, strikethrough, H2 and H3 headings, block quotes, bullet and numbered lists, horizontal rules, alignment, images, and tables.

Headings previews render in their actual on-page register — the H2 button shows you the H2 face. Tables come with a full menu: add or delete rows and columns, merge and split cells, toggle header rows.

Images are drag-and-drop. Drop an image into a chapter and it lands where the cursor is.

Clean paste. Pasting from Word or Google Docs is sanitized to writefolio's typography — no rogue fonts, no leftover styles. Copying inside writefolio round-trips at full fidelity, including track-change history.

There is no Save button. Autosave runs on every change and the status bar reports its state: "Autosaving · just now", "Version saved", or "Offline · reconnect".

Two things worth knowing:

• Every save is a version. Reachable from history in the status bar. Nothing is overwritten silently.
• Offline is safe. If your connection drops, keep writing. Local edits queue and sync when you're back online. The CRDT layer under the editor merges them cleanly — no lost keystrokes, no manual conflict resolution.

The sidebar carries a search box that scans the whole manuscript. Matches highlight in the prose; per-chapter counts appear in the outline with clickable sentence previews so you can jump to any match in two clicks.

Find and replace is available for larger sweeps — a name change, a term rename — with scope options (this chapter, the manuscript).

Type # inside your prose to reference a heading elsewhere in the manuscript. A popover appears with a live list of headings; pick one to insert a link. The link reads as the heading's text and clicks through when you tap it.

Useful when you're mid-scene and want to point to where a beat lands earlier or later. The reference updates if you rename the heading — it points to the heading, not the text.

Two ways to strip chrome when the writing is what matters:

• Focus mode collapses the sidebar, the toolbar, and every status readout, leaving only the page. Toggle it from the user menu or with the keyboard shortcut.
• Fullscreen takes it further — the browser chrome goes too.

Beyond that, the user menu carries theme (light or dark), font-size (compact, default, comfortable), and the archive notebook (a place to stash things without deleting them).

Up to 100 steps of your own work are undoable — Ctrl+Z / Cmd+Z. Redo is Ctrl+Shift+Z / Cmd+Shift+Z. Undo covers your own typing and edits; changes from Foli or a collaborator have their own history through the version band (see Revisions and history).

Foli lives in the chatbox at the bottom of each chapter page. Type a question, drag-select a passage first if you want her to read it with you, and press Send (or ⌘+↵).

Every message opens a thread. The reply appears in the margin next to your chapter, anchored to what you were looking at. Threads are addressable — you can reply to Foli later, come back to the conversation, or delete it. Foli's message history inside a thread is context she'll read on the next reply, so you can build a discussion instead of asking one question at a time.

If you didn't select anything, Foli talks about the chapter you're in. If you selected a passage, the discussion opens "about" that passage — the anchor is visible in her reply so it's obvious what she's speaking to.

Three chip types you can drop in a message:

• @person — mention a collaborator or Foli herself. Notifies them (or routes the turn to her). Auto-completes as you type.
• #thing — reference something structural: a character (#Mara), a setting (#The Harbour), a chapter (#Chapter Three), or a whole category (#All characters). Foli gets the referenced content pre-loaded — no need to quote or paste it. Live search and keyboard nav in the picker.
• /verb — a slash command. /create character mints a fully-populated character doc; /create setting a setting; and so on. The slash surface is the fastest way to spin up a new design doc from a conversation.

Chips render as compact tags inside your message — they read tightly, but each is a pointer to real state. When Foli replies, she'll cite what she pulled from each.

Drag-select a passage and the right-side action rail lights up with one-click verbs — Rewrite, Compact, Expand, Add sensory detail, Simplify, Polish, Explain. Each returns three alternative rewrites as track-change suggestion cards you can flip through and accept or reject. No silent edits, ever.

Explain is the odd one out — it's a discussion, not an edit. Foli reads the selection and tells you what's landing (or what isn't) as a margin note.

You can also compose a custom action: type an ad-hoc directive over a selection ("cut the last sentence, tighten the dialogue") and run it once, or save it as a reusable plugin for later.

When you ask Foli for something structured — an outline, a beat sheet, a critique pass — she runs a layer build. It lands on its own layer chip on the chapter (see Working in layers in the Writing section).

A layer build is guided:

1. Foli silently reads project context (the chapter, saved knowledge, prior layers).
2. She walks you through a tap-through question carousel — POV, scope, tone, whatever the build needs. Answer or skip.
3. She offers you direction choices. Pick one, or hit "+" to see more.
4. She generates.

Prose lands in the doc live as it streams — Foli appears as a presence cursor while she writes. Cancel anytime. If she needs more from you mid-build, an awaiting input chip appears on the layer and the run pauses until you answer.

Beyond the built-in selection actions, writefolio ships a library of plugins — saved prompts for actions, layer builds, reviews. You'll see them in the plugin picker under each chapter, or reference one from chat with /plugin-name.

Any custom prompt you write can be saved as a plugin (with a name and a description) so you can run it again — or share it publicly if it's useful to other writers. See the Plugins section for the full CRUD.

A workflow is a chain of plugins Foli runs on a chapter in sequence — for example: outline → beats → draft → line-edit → review. Each step runs, hands off to the next, and the status bar shows you where the chain is.

Workflows are pausable. If a step needs your input, the run holds until you answer. You can resume from where it stopped, or step in and edit an intermediate layer before letting the next step run over it.

See the Workflows section for building your own.

A reviewer is a plugin that reads a layer and returns findings — not edits. POV check, adverb check, dialogue attribution, pacing. Findings land as anchored margin comments with suggested rewrites. "No issues" is a valid result and Foli says so.

You can write custom reviewers the same way you write custom actions. A reviewer's job is to notice, not to change.

While Foli works, the chatbox shows what she's doing — a rotating live thought ("Checking the manor setting…", "Reading chapter two…"). Inline cancel button while she's running; retry on failure. If a run needs your input to continue, an awaiting input chip shows on the layer or thread it belongs to.

Errors are typed and named — the UI never wedges. If Foli is offline, she says so.

Every LLM call Foli makes debits a small number of credits from your balance. Costs are visible per-run when it matters (bigger builds show their credit estimate before starting).

More on how credits work in the Plans and credits section.

Foli doesn't:

• Edit your prose silently. Every change is a proposal in track-change; you keep it or drop it.
• Publish, invite, or delete on your behalf. Actions that affect other people or move money go through your own hands.
• Remember conversations across projects. Each project's chat history is scoped to that project.
• See other users' work. She's reading yours.

Every project has a knowledge base alongside the manuscript. Four kinds of docs live in it:

• Character docs — one per character. Traits, arc, relationships, voice.
• Setting docs — one per place. Geography, feel, rules, who owns it.
• World docs — worldbuilding at the scale of the whole story. Systems, history, technology, cultures.
• Style docs — decisions about voice, POV, tense, cadence — the register the writing is committed to.

Each doc opens as a subtab of the project. Rename inline — the new name propagates everywhere it's referenced.

Inside each doc is a facts table: rows of question → answer about that entity. "What does Mara fear?" · "Deep water, ever since the accident." Rich-text answers, keyword tags, and a location chip telling you where the fact came from and where it applies:

• Author-authored — you wrote it directly.
• AI-routed — Foli mined it from your prose.
• Pinned to a chapter — the fact is only true as of chapter N and later.
• General — evergreen; true across the whole story.

Fact rows are the source of truth. When Foli answers a continuity question ("did I say Mara was left- or right-handed?"), she reads the facts, not the prose.

Each knowledge doc has insight fields — structured slots grouped by category, filled by AI summaries over your facts. For a character, the fields include values, beliefs, desires, conflicts, arc, voice, and dozens more (over fifty across all doc types), covering everything from physical description to psychological profile.

You never write insight fields directly. As facts accumulate, Foli refreshes each field's summary from the facts underneath — the field is always a projection of what you've established. If you edit or delete facts, the field re-summarizes on the next pass.

Every time you save, writefolio runs a background pass on changed paragraphs: it mines them for entity mentions ("she's twenty-nine", "the manor floods every spring", "he's allergic to iron") and files each into the right doc's right field.

Two rules keep it honest:

• Review before it counts. New facts land as pending — you glance and approve, or drop. Nothing appears in your reference without your read.
• Deleted prose orphans its facts. If you cut the paragraph that established a fact, the fact is marked orphaned so you know its source is gone.

Extraction is a light background job; it doesn't block your writing.

Every chapter has its own notes table — a Q&A scratchpad about that chapter specifically. Foli reads it before every run on that chapter, so anything you record there shapes what she does next.

Fresh chapters ship with one seed question: "What's the chapter's driving question or scene goal?" Answering it once sets the compass for everything Foli does on the chapter.

You can add notes yourself, and Foli can append to the notes when you tell her to remember something ("Mara sees the harbour from the window here — hold that image"). She summarizes the notes into a chapter approach she reads back on later runs.

Insight fields resolve as-of the chapter you're in.

Chapter 3 sees a character as they were in chapter 3 — before the reveal in chapter 7, before the death in chapter 9. When Foli answers a question in chapter 3, she uses the chapter-3-version of the character. When you re-open chapter 9, the same character shows their chapter-9 fields.

Concretely: any fact pinned to chapter N or later is invisible to Foli when she reads from chapter M < N. Continuity holds because Foli respects when things became true, not just what became true.

For a fresh character or setting doc, writefolio offers a facts interview — a guided slide-based carousel that walks you through fleshing out the essentials. Answers batch into facts at the end; skip anything that doesn't apply.

Useful when you're starting from a name and a vibe. Not required when you already have a character sketched out elsewhere and just want to paste it in.

Turn suggest mode on to type in track-changes only — nothing lands as final prose. Every insertion and every strike appears as a suggestion the writer decides on later. The mode is toggled from the editor's mode row; it applies to your session.

Runs of typing coalesce into one suggestion, not one per keystroke. Editing a passage while suggest mode is on produces one clean proposal per contiguous edit, with the surrounding prose intact.

Who lands in suggest mode by default: editors and beta readers. Co-authors write directly. Owners choose per session.

Suggestions appear in the left margin as cards, one per suggestion, tinted by the author who made it. Each card shows:

• The proposed change (insertion in green, strike in red).
• A rationale field (optional — the suggester can note why).
• Accept and Reject buttons.
• Position counter (3 of 12) with prev / next cycling.

Filter by author to focus on one reviewer's pass. Bulk-accept or bulk-reject when you're sure. On overlapping edits from different authors, a conflict cycler lets you pick one — accepting one automatically rejects the others.

A resolved suggestion shows a small resolved badge in the gutter so you can see at a glance what's been touched.

Every save is a version. Autosaves, manual saves, and AI-pass completions each write an immutable diff — author, word delta, and whether the version came from a human keystroke, an autosave, or an AI pass.

The status bar carries a history popover with a sparkline of activity and a date-grouped list of versions. Click any version to open the History band — a read-only overlay above the live doc, scroll-synced, showing that version's state. Reconstruct any past version; revert to it if you want to go back.

Because history is immutable, nothing is lost. Every state your manuscript has been in is reachable.

Versions written by Foli are marked as AI-authored in the history. You can filter for AI passes, human passes, or both. Every LLM call is audited (tokens, latency, cost) so the provenance of any change in the manuscript is traceable — you know what came from where.

Fork a document to spin an alternate version with its own version chain. Useful when you want to try a rewrite that goes in a different direction — a shorter chapter, a different ending, a POV swap — without losing your current version's history.

Forks are separate documents. Delete them independently. If you decide the fork is better, you can promote its content back into the original (via export/import if needed).

Ordinary undo/redo covers your own recent keystrokes and edits — Ctrl+Z / Cmd+Z back, Ctrl+Shift+Z / Cmd+Shift+Z forward, up to 100 steps.

For anything beyond that (a Foli pass, a collaborator's edit, a suggestion you accepted an hour ago), the version history is the way back. Undo is for the last few minutes; history is for everything else.

Open the project properties panel and pick Collaborators. Type an email and choose a role. If the person already has a writefolio account, they get an in-app notification with Accept and Decline buttons. If they don't, they get an email with a magic link — clicking it signs them in and lands them at your project. Magic links expire after seven days; you can resend if they miss it.

Pending invites appear in the roster with a Revoke button. Revoking a pending invite invalidates the link.

Every collaborator has one role. Six exist:

• Owner — the project belongs to them. Full write, invite, publish, delete. One owner per project.
• Co-author — writes directly in the manuscript. Adds chapters, layers, subdocs. Can run Foli and plugins.
• Editor — writes in suggest mode by default. Every edit lands as a track-change proposal for the writer to accept or reject.
• Reader — read-only across the manuscript. Can leave margin comments; can't touch the prose.
• Beta — reads the layers marked for beta release; leaves suggestions and comments in a private feedback channel only the writer sees.
• Subscriber — reads whatever their subscription tier unlocks; comments are optional (writer-toggleable).

Change a role at any time from the collaborators panel. The change takes effect on their next page load.

When two people are in the same chapter, each sees the other's cursor and selection in a named, colored highlight. Type into the same paragraph and the writing merges cleanly — no conflicts, no manual resolution. The editor uses a CRDT (the same layer that keeps offline edits safe) so concurrent work is safe by construction.

If your connection drops mid-session, keep writing. Local edits queue and sync when you're back. Nothing is lost.

Any collaborator can leave a comment. Select a passage, tap Add comment, write your note. The comment appears as a card in the right margin, anchored to the passage.

Comment cards support:

• Reply threads — anyone in the project can reply.
• Emoji reactions — full picker.
• @-mentions of other collaborators — mentioning someone notifies them by bell.
• Destination chip — mark a comment as private (only you see it), public (readers see it too), or scoped to a specific beta reader.
• Archive / restore — clear resolved threads without losing them.

Comments show up color-coded by source (team / Foli / beta / public) so you can tell at a glance who's talking.

Comment filter lives in the status bar: toggle sources on and off, drill down per beta reader, text-search across all comments with a "3 of 12" readout.

For the deeper mechanics of proposing prose changes rather than commenting on them, see Revisions and history.

The bell in the top-right shows unseen activity — invites, comment mentions, new-chapter alerts from writers you follow. The tray drops down for a glance; a full Notifications page groups by category (security, billing, team, system, export) with inline action buttons (accept an invite, download an export). Seen-state syncs across devices.

Remove a collaborator from the roster with the Remove button. They lose access immediately — their open session on your project is severed. Their past comments and suggestions remain in the history; only their live access ends.

Open the project properties panel, pick Beta readers, and add an email. You can attach a label — the name they'll appear under in your roster and their comment attributions ("Sara", "Reading group 2", "Alex from writing group"). Labels are helpful when you have several betas and want to keep them straight in your head.

A brand-new email gets a passwordless magic link account automatically. Existing accounts get an in-app invite. Either way, they land at your project with a beta-reader view of the manuscript.

The roster shows active and pending betas with a Revoke button.

A beta reader sees the layers you've marked for beta release — nothing more. Chapters you haven't released to them yet don't appear. Chapters partially released show the layers they have access to and nothing beyond.

The chrome they see is a slim reading surface — no toolbar, no layer picker, no rail. Just the prose, comments, and a way to navigate between released chapters.

Every beta reader has their own isolated comments channel. They see only their own comments; they never see anything another beta wrote. This is enforced at the data layer, not just the UI — the comments doc is scoped per beta.

For you as the writer, all beta channels are readable and filterable. Filter the margin by a specific beta reader and see just their pass; drop the filter to see everyone at once.

Betas can propose changes through suggest mode — every edit they make lands as a track-change suggestion in your column, tinted with their color. They cannot land prose directly in the manuscript.

You see their suggestions in the track-change column alongside any co-author or editor suggestions; accept, reject, and cycle the same way (see Track changes in the margin).

When you publish a new chapter to beta, betas can be notified in-app and by email — "Chapter 4 of The Harbour is now live." Alerts are opt-in per beta reader; they choose their preference from their notification settings.

Alerts fire in the background from the release schedule (see Publishing) — one per beta, coalesced if multiple chapters go live at once.

Read a beta comment in the margin. Reply if you want a conversation with that beta; leave a reaction if you just want to acknowledge. Archive a thread when it's resolved (it disappears from view; you can restore it any time from the comment filter).

Betas don't see your replies to other betas — only their own thread stays in their private channel with you.

Publish any chapter to the public tier and your project becomes publicly readable. Anyone with the link can read the released chapters — no account required. Comments on the public side are optional; you toggle them on or off per project.

The link is a short URL you can share anywhere. It carries Open Graph metadata so the preview looks right in links shared on social platforms, in email, or as a chat unfurl.

Turn public off any time — the reader page returns a uniform "not found" (no leaks about whether the project existed). If you re-enable it later, the same URL works again.

Create tiers to structure who reads what. Each tier has a name, a description, and a price (or free). Tiers are ordered top-down; higher tiers automatically include everything the lower tiers get.

Examples:

• Free → new-chapter alerts, first three chapters
• Reader tier — $5/mo → all released chapters, all layers
• Patron tier — $15/mo → all of the above, plus commentary chapters, cut scenes, an early-access lane

Drag to reorder; enable and disable per tier without deleting. When you publish a chapter, you pick which tier gets it — the release cascades up to every higher tier automatically.

Note: payouts (writers being paid by paid subscribers) are not yet live in writefolio; the mechanics for setting prices and gating chapters are in place, but the money flow will be enabled in a future release.

A chapter above a reader's tier renders as a paywall: the tier's name, description, and price, plus an Unlock button. Free tiers unlock instantly. Paid tiers will route through checkout when payouts ship.

Scheduled chapters that haven't fired yet render as "Coming <date>" — the reader sees when it'll be live without seeing the prose.

Every locked chapter has the same treatment so a reader can scan a project's table of contents and understand what's available to them at a glance.

Your project's landing page is what a reader lands on before they open the first chapter. It carries:

• Title, byline, tagline — the top of the page.
• Cover image — optional; upload from the project properties panel.
• Synopsis — a short pitch of the story.
• Status — drafting, ongoing, complete, on hiatus.
• Language — the language the manuscript is in.
• Up to three genres — from a picker (fantasy, thriller, literary, etc.).
• Tropes and keywords — free-form tags for discovery.
• Content warnings — a curated set; readers can filter their subscriptions by them.
• Accept / Decline buttons for invitees.

Fill these in from the project properties panel. Everything is optional; the more you fill in, the better a reader can decide whether to open the first chapter.

The subscriber roster (in the project properties panel) shows every subscriber, their tier, and their payment state — active, pending, past-due, revoked. Filter and paginate; revoke access per-row if you need to.

Preview mode lets you see exactly what a given audience sees — the public tier, a specific paid tier, a beta reader. Enter preview from the project menu; an "Exit preview" banner sits at the top of the page until you switch back to writer view.

Useful before publishing to confirm the release actually looks the way you want in the reader's chrome.

Publishing is per-chapter and per-tier. On each chapter's layer chip strip, a publish popover lets you point a layer at a tier (public, beta, or any subscriber tier). The chapter's state moves through three visible phases:

• Marked — you've said this layer will be published, but haven't given it a fire time yet.
• Scheduled — you've set a fire-at datetime. It'll go live automatically.
• Live — the chapter is readable by that tier.

You can publish now (the layer becomes live immediately), or schedule for later. You can cancel a pending publish any time before it fires.

You pick which layer of the chapter is the released one — often the polished draft or line-edit layer, not the outline or the beat sheet. The other layers stay in your writing column; readers only see the layer you pointed at their tier.

If you re-publish the same chapter (say, after revisions), just point at a newer layer and hit publish. The reader sees the new version.

Point a layer at a tier, pick a fire-at datetime, done. Scheduled releases fire in the background — writefolio checks every minute or so, and once the time hits, the chapter goes live for that tier (and every higher tier that inherits it).

Two views of your schedule:

• Week strip — the next seven days, one row per chapter.
• Month calendar — the whole month, chapters as tiles on their fire day.

Both views let you drag a scheduled release to a new day, cancel a pending one, or click through to the chapter to edit the target layer.

Every scheduled release has an optional notify flag. When it fires, subscribers to that tier (and every beta reader, if the release includes them) get an in-app notification and, if they've opted in, an email — "Chapter 4 of The Harbour is now live."

Alerts are opt-in per subscriber; they choose their preference from their notification settings. You choose whether the release fires them at all.

Publish now skips the schedule and makes the chapter live immediately. Useful for a bonus chapter, a re-release after edits, or when you're moving faster than a schedule can keep up with.

Cancel a pending release any time before its fire. The pointer to the target layer goes away; the chapter stays in your editor exactly as it was. Cancelling never touches the prose.

Unpublishing a chapter that's already live is the same motion — pull the tier pointer off the layer and the chapter is no longer visible to that tier. Readers who already read it don't forget; the chapter just stops appearing in the manuscript's current release.

Before you fire a release, jump into preview mode (from the project menu) and pick the tier you're publishing to. You'll see exactly what a reader on that tier sees — the released layer, the paywalls above it, the navigation between chapters they can read.

An "Exit preview" banner at the top of the page reminds you you're in preview until you switch back.

Details in Writer preview mode.

Once readers start showing up, the Readership panel (chart icon in the sidebar of any manuscript you can edit) tells you how they read what you published. Everything here is per-manuscript. Anyone with edit access sees it; readers and subscribers do not.

Five tabs, one filter row.

Date range. Every tab respects the range picker at the top: 7 / 30 / 90 / 180 days rolling, or click Custom range to draw two dates on the calendar. 180 days is the ceiling — that's how long visit history is kept.

Overview

Four numbers side by side: Views (every open — one reader opening twice counts twice), Sessions (unique visits — the same reader on the same tab counts once), Active readers (people with an account who came back), and New subscribers in the window.

Underneath is a chart of visits over time split by Anonymous readers (no account) vs Signed-in readers, plus a callout for new chapters your subscribers haven't seen yet.

Traffic

Where readers came from and how they got in.

The Landed → Tapped → Reached funnel counts everyone who hit your public page, then how many tapped through to read, then how many actually reached your book. How they found you buckets the referrer host into categories (search, social, direct, other). Below that: the top referring sites, UTM campaigns you tagged on your own share links, and reader countries (populated in production only).

Chapters

Drop-off curve — one bar per chapter showing how many readers reached that chapter, with a survival-curve overlay so you can see where they leave. Furthest chapter reached is the same story from the other side: for each chapter, how many signed-in readers hit that as their deepest point and stopped.

Time spent per chapter is median active reading time, not wall-clock. If a reader leaves a tab open for six hours, that doesn't count as six hours of reading (see below).

Subscribers

Growth stacked by tier over the selected range. The tier hues match the layer palette used elsewhere in the app. Current roster is the size of each tier right now; free grants (comps you handed out) count separately.

The wall funnel is Saw the wall → Tapped upgrade → Started checkout. That last step means the reader clicked through to Stripe — it does NOT mean they finished paying. The Growth chart above is the truthful count of subscribers who actually completed checkout.

Where subscribers came from buckets the referrer for the click that unlocked their tier. Session-scoped — a reader who signed up months ago and later opened your link fresh won't have a referrer stamped against their subscription.

Engagement

Time actively reading per visit is the histogram of active-reading durations. Reading time only accrues while the reader is scrolling, clicking, or otherwise interacting with the page. After five minutes of no activity the timer pauses; it resumes on the next interaction. So a tab left open for hours doesn't inflate this number — it measures reading, not tab-lifetime.

How often readers come back is the return-visit histogram: how many readers came once, twice, three times. New readers by day shows fresh arrivals over the window. Cleared from reading list is anyone who explicitly removed your manuscript from their sidebar — a stronger signal than just not coming back.

The two kinds of reader, in one place

You'll see these terms across every tab:

• Anonymous readers — visits without a signed-in account. Counted per browser session, not per person.
• Signed-in readers — people with an account who came through the reader surface. Counted per user, because we know who they are.

A reader who signs up mid-visit changes lanes: their pre- signup activity stays anonymous; their post-signup activity attributes to their user.

writefolio's goals use a sentence builder: you compose your goal in a sentence, one dropdown per part.

"Write 500 words in this manuscript daily."

"Edit 1,500 words in any manuscript on Mon+Wed+Fri."

Parts you can pick from:

• Verb — write or edit.
• Amount — a word count.
• Scope — this specific manuscript, or any manuscript you work on.
• Cadence — daily, weekly, or on specific days of the week.

Add as many goals as you want. Each runs on its own cadence and its own scope.

Progress is derived from version diffs — every save contributes its word delta toward whatever goals it satisfies.

Two things worth knowing:

• Revert-tolerant. If you write 400 words and then undo 200, your daily count reflects 200. Reverting cancels the contribution; you don't get to game the count by writing and deleting.
• Latch on met. Once a goal is met for its period, it stays met — writing more doesn't un-meet it, and undoing after the meet doesn't un-meet it either. The meet is the event.

Periods roll over automatically. A daily goal resets at midnight in your local timezone; a weekly goal resets on Monday.

Goals appear in three places:

• Home screen — a weekly list with a progress readout on each. Good for a glance at the beginning of a session.
• Status bar — an always-on goal pill with the count toward the most-relevant active goal ("+320 today", "✓ met"). Click to open the popover with all your goals and an inline new-goal form.
• Notifications — a bell notification when a goal ticks over from unmet to met.

The pill is the one persistent surface. It's small enough to ignore when you don't care, close enough to hand when you do.

The activity calendar on your home screen tints each day by how much you wrote (or edited) on it. Empty days are pale; heavy days are dark. Under the calendar, two numbers:

• Current streak — consecutive days with activity.
• Longest streak — your record.

Streaks are calibrated to the goals you've set. If you have a daily goal of 200 words, the streak counts days you hit 200 or more. If you have no goal, the streak counts any activity.

Missing a day breaks the streak. There's no shield, no makeup day, no "you almost had it" nudge — writefolio doesn't nag.

The status bar always shows word counts for what you're looking at:

• Selection count — words in the current selection.
• Chapter count — words in the current chapter.
• Manuscript count — words in the whole manuscript.

Click the count for a per-chapter breakdown with totals at the bottom. Useful for pacing, for planning a release, or for finding the chapter that ballooned.

The home screen carries a recent manuscripts strip along the top — the projects you've opened most recently, one card each. Click through to jump back in.

If you work on one manuscript, the strip is quiet. If you juggle several, it's the fastest way to swap.

Drag a document into the sidebar (or into an existing project's chapter list) and writefolio imports it as a new manuscript or into an existing one. Supported formats:

• .docx — Microsoft Word.
• .txt — plain text.
• .md — Markdown.
• .html — HTML.

Detection is automatic; a chip appears in the drop overlay telling you what format writefolio picked so you can confirm or override.

Chapter detection. The first H1 in the imported file becomes the chapter title. Subsequent H1s become new chapters. H2s and H3s nest under the chapter they're in.

Images. Images embedded in the source are stripped during import, with a warning telling you how many were removed. You can re-add images from the editor afterward.

Formatting. Bold, italic, underline, strike, headings, lists, block quotes, tables, and horizontal rules survive the import cleanly. Fonts and colors don't — they're replaced by writefolio's own typography.

Two import destinations:

• New manuscript. Drop onto the sidebar or use New from import on the home screen. Creates a fresh project with the imported content as its chapters.
• Into an existing project. Drop into a project's chapter list. The imported chapters append at the end (drag to reorder afterward).

You choose in the drop overlay when both are ambiguous.

writefolio exports to six formats:

• PDF — the polished, print-ready format.
• DOCX — for anyone who needs to keep working in Word.
• EPUB — for e-readers.
• RTF — universal rich text.
• ODT — LibreOffice / OpenOffice.
• Markdown — plain-text portable.

Pick a format from the export menu on the project. Larger exports queue in the background — you get a notification with a download link when the file is ready. If the link expires before you download, the export offers to re-render.

The export includes exactly the cut a given audience would see. Pick a tier scope when you export:

• Public — only the chapters released to the public tier.
• Beta — the layers marked for beta release.
• A specific subscriber tier — everything that tier unlocks (and every lower tier below it).
• Full writer view — everything, including unreleased drafts and cut layers.

Useful when you're sending a preview to a publisher (their tier), or when you want a snapshot of what your public readers currently see.

You can also export a single chapter — right-click the chapter in the sidebar and pick Export chapter. Same format options; the resulting file contains just that chapter.

Useful for sharing an excerpt without exporting the whole manuscript.

A plugin is a saved prompt Foli runs on demand. You get the built-in library seeded to your account when you sign up — selection actions, layer builds, reviewers, and workflows — and you can author your own.

Four plugin types:

• Action plugins — run over a text selection. Return three alternative rewrites as track-change suggestions (rewrite, compact, expand, sensory detail, etc.).
• Layer plugins — build a whole layer on a chapter (outline, beats, draft, line edit).
• Reviewer plugins — read a layer and return findings as margin comments (POV check, adverb check, pacing).
• Workflows — a chain of plugins that run in sequence. See Workflows.

Two ways to invoke a plugin:

• From chat. Type /plugin-name in the Foli chatbox (auto-completes as you type) and send. Foli runs the plugin and shows the result.
• From the plugin panel. Open the plugin panel from the status bar. Pick a plugin, pick a target (chapter, layer, selection), run.

Plugins that take a target respect what you have open: if a chapter is active and you invoke a layer plugin, it runs on that chapter. Selection plugins need a selection first.

Two ways to write a plugin:

• Directive mode — write what you want Foli to do in plain language. "Rewrite this passage as if the narrator were doubting themselves." Fastest to author. Best for action plugins.
• Templated mode — write a full prompt with <<<variable>>> slots that pull in project state at run time. Variables include the current chapter, prior layer text, character/setting facts, chapter notes, and more. Better for layer builds and reviewers where you need precise context.

Give the plugin a name and a description; save. Now it's in your plugin picker, invokable from chat with its slash, or from the plugin panel.

Every edit is versioned. You can roll back a plugin to a previous version any time.

The public catalog is where every writefolio user can publish their plugins for others to use. Browse by popularity or newest; filter by category; search by name.

• Subscribe — one click to add a public plugin to your own picker. It behaves like your own from then on.
• Favorite — pin a subscribed plugin to the top of your picker.
• Unsubscribe — remove it from your picker (the plugin stays in the catalog).

Publishing your own plugin to the catalog runs it through a moderation gate first — writefolio checks for prompt-injection patterns, offensive content, and other issues that would make it unsafe to share. Once approved, your plugin is listed.

Workflow subscribe cascades — subscribing to a workflow subscribes you to every plugin in its chain.

Reviewer plugins don't edit — they read a layer and return findings as margin comments. Each finding can carry a suggested rewrite (which appears as a track-change proposal you can accept). A reviewer's job is to notice.

"No issues" is a valid result. A well-written reviewer tells you when there's nothing to say instead of inventing findings.

A workflow is a chain of plugins that run on a chapter in sequence. Typical shape: outline → beats → draft → line-edit → review. Each step runs a plugin on the chapter, lands its output as a layer, and hands off to the next step.

Workflows encode a repeatable writing pattern. Once you have one you like, running it on a fresh chapter takes one click.

Open the workflow builder from the plugin panel. Drag plugins from your library onto the chain in the order you want them to run. Reorder by drag; remove a step with the ×.

Steps run in strict sequence — no parallelism, no branching. Each step reads the layer the previous step produced (or the chapter's current prose if it's the first step).

Save the workflow with a name and a description. It joins your plugin picker as a runnable workflow plugin.

Invoke a workflow the same way you invoke any plugin — from chat (/workflow-name) or from the plugin panel. Pick a chapter, hit run.

Each step shows its progress in the status bar and on the chapter's chip strip:

• Queued — the step is waiting for the previous one.
• Drafting / reviewing — the step is running.
• Settled — the step's output has landed as a layer.

You can watch a workflow run in real time; prose streams into the doc as each step generates it.

Any step in a workflow that needs your input will pause. An awaiting input chip appears on the layer that step is building; the chain waits for you.

Answer the question or pick a direction (the same tap-through carousel any layer build uses — see Layers as guided flow). When you answer, the step continues; when it finishes, the next step runs.

You can also pause manually — hit the pause button in the status bar mid-run. The current step finishes what it's doing; the chain holds. Hit resume when you're ready to continue.

You can edit the output of any settled step before letting the next one run over it. Pause the workflow after the step you want to touch; open the layer; edit as you would any layer. When you resume, the next step reads your edits.

Useful when a step produced something almost-right and a small human tweak makes the next step's output better.

Publish a workflow to the public catalog the same way you publish any plugin. Subscribing to a workflow cascades — you get every plugin in its chain subscribed to your account automatically. If any step's plugin changes upstream, your workflow picks up the change on the next run.

Details in Sharing plugins.

writefolio has three plan tiers:

• Trial — a limited free plan you get when you sign up. Enough credits to see how Foli works on your writing before committing.
• Pro — the standard writer plan. Recurring monthly credit grant, full Foli access, publishing, subscribers, betas.
• Team — for co-writing groups. Credits scale per seat; includes SSO and shared billing.

Change plans from your account settings. Downgrades take effect at the end of the current billing cycle; upgrades take effect immediately with a prorated charge.

Every LLM call Foli makes debits credits from your balance. Bigger calls (a whole layer build over a long chapter, a workflow chain) cost more; smaller calls (a selection rewrite, a chat message) cost less.

Credits are USD-pegged — one credit represents a small, consistent dollar amount of underlying compute. When you buy more, you're buying more compute directly; there's no mystery-metric conversion.

Monthly grant. Your plan grants a fixed number of credits at the start of every billing cycle. Unused credits from the grant do not roll over — the next cycle starts with a fresh grant.

Purchased credits. Credits you buy on top of your grant (one-off top-ups) do roll over and never expire until used.

Two kinds of Foli calls, roughly:

• Chat messages and selection actions — small. Sub-cent order.
• Layer builds, workflows, reviewers — larger. Cent to tens-of-cents order, depending on the chapter's size and the model chosen.

Costs are visible per-run when it matters — bigger builds show their credit estimate before starting so you can decide whether to run.

Everything is metered in real time. If you're near the end of your grant, the meter tells you before a big call, not after.

Run out of credits mid-session and the next Foli call is refused — she tells you why in the chatbox. Buy a top-up from account settings; the credits land instantly and the call you tried to make is safe to retry.

Purchased credits go to your purchased balance, which never expires. Your monthly grant is spent first when there's overlap.

Your account settings carry a usage history — every LLM call itemized (chapter, plugin or action, credits spent, model). Filter by date range, by project, by action type.

Useful for:

• Figuring out which plugin or workflow is the expensive one.
• Reconciling a monthly grant against a project you were heavy on.
• Understanding your baseline before deciding whether to upgrade your plan.

Your profile carries the name and avatar collaborators see next to your cursor and in comment threads. Change them from account settings; the update propagates immediately.

Email. Change your sign-in email from the profile section. The change requires confirmation from both the old and the new address; either can cancel the swap.

Password. Set or change your password from the security section. If you sign in with Google, you don't have one by default — you can add one to enable email-and-password sign-in as an alternative.

Set your preferred language from the profile section. The app chrome (buttons, labels, error messages) uses your choice; your writing is unaffected.

Currently English is the shipped language. Adding more is on the roadmap.

Three appearance preferences live in the user menu at the top-right of the app:

• Theme — light or dark. Follows your system preference by default; override in the menu. Switch is instant.
• Font size — compact, default, or comfortable. Changes the body type across the app so the reading register matches your eyes.
• Focus mode — a per-session toggle that collapses the sidebar, toolbar, and status bar. See Focus mode.

The notifications tray (bell in the top-right) shows every event that touches you — invites, comment mentions, new-chapter alerts from writers you subscribe to, export completions, billing events.

The full Notifications page groups by category:

• Security — sign-in from a new device, password changes.
• Billing — grants, top-ups, plan changes.
• Team — invites, role changes, removals.
• System — release announcements from writefolio.
• Export — export completions with download links.

Per-category delivery preferences (in-app only, email, both, none) live in the notifications settings. Seen-state syncs across your devices.

Your billing section shows:

• Current plan and its price.
• Payment method — card on file. Add, update, or remove.
• Invoices — every charge itemized, downloadable as PDF.
• Subscription controls — upgrade, downgrade, or cancel.

Cancelling keeps you on your plan through the end of the current billing cycle; after that you drop to the trial tier. Nothing you've written is deleted — your projects stay readable at trial-tier limits until you upgrade again.

Close your account from the security section. Before you delete:

• Export your manuscripts — closing the account removes them. Every manuscript, every version, every knowledge doc, every fact. This is not recoverable.
• Transfer projects you want to keep alive to a collaborator (change ownership from the project properties panel).

Deletion requires typing your email to confirm. Once confirmed, your account is queued for removal — you get a short grace window to cancel, after which the deletion is permanent.