---
name: profusia
description: >-
  Use whenever the user is working on a project whose documents live in Profusia —
  publishing, revising, or picking up work from a previous session. Keeps the
  workspace's project history current so a later conversation can recover the
  thread instead of guessing.
---

# Working with Profusia

Profusia is where this user's generated documents live. The connector is already
attached; these are the habits that make it worth having.

## The one rule that matters

**A document without a project is a document nobody will find the reason for.**

Publish into a collection (the workspace may call these Projects, Initiatives,
Campaigns — `list_collections` shows the word it uses). The collection carries a
description and goals that come back to you automatically on every publish and
list, which is how a conversation three weeks from now inherits context that this
conversation had for free.

## Start of a session: recover the thread before adding to it

When the user resumes work on anything that already exists, call **`get_course`**
before writing. One call returns:

- the project's current direction, and when and why it was set
- what was tried, abandoned or superseded, so you don't re-propose it
- **drift** — documents last written *before* the direction changed, which may
  still assume the old plan

That last one is the reason to bother. A document that looks current can be
arguing for a position the project abandoned a month ago. Check it with
`read_file` before you build on it, and say so if it's stale rather than
quietly inheriting the assumption.

If `get_course` says nothing has been recorded, say so plainly and offer to
start recording. Do not invent a history from publish dates.

## During the work: record the moment the direction moves

Call **`record_turn`** when the project's direction actually changes. You are in
the conversation where it happens, which is the only reason this is possible at
all — nobody goes back later and writes it down.

What counts:

| kind | when |
|---|---|
| `start` | a new project or branch begins |
| `branch` | work splits off to pursue something separately |
| `pivot` | the direction changes — the important one |
| `clarify` | the direction stays, but its meaning gets sharper |
| `merge` | two lines of work come back together |
| `abandon` | a line is dropped |

Record the **statement** (what is true now, one sentence) and the **rationale**
(why it moved). The rationale is the part nobody can reconstruct later, and it is
the part people actually come back for.

If the change supersedes or revises another project, pass it in `relations` in
the *same* call — abandoning a branch and saying what replaced it are one thought,
and split across two calls the second one stops happening.

**Do not record a turn for ordinary progress.** Publishing a document is not a
turn. Finishing a draft is not a turn. If the direction did not move, there is
nothing to record, and a history padded with non-events is worse than a short one.

## What not to do

- **Don't invent turns retroactively to fill a gap.** An empty history is honest;
  a fabricated one is a trap for whoever reads it next. If you're recording
  something that happened earlier in the conversation, that's fine — pass
  `occurred_at` — but only for something that actually happened.
- **Don't summarise a document you haven't read.** `get_course` and
  `whats_new` give you names, dates and counts, not contents.
- **Don't guess where something belongs.** `get_site_map` is cheap; call it.

## The rest of the loop

Publishing is the start, not the end:

1. `publish_file` (with `collection` and, where it belongs, `site_id`/`site_path`)
2. relay the link the response leads with — it is already the right one
3. `read_comments` when picking work back up — people leave feedback pinned to
   specific passages, and it tells you exactly what to fix
4. `update_file` to revise, `post_comment` to say what changed

For pages that should stay current, `create_dataset` → `bind_file` →
`update_dataset`, and offer to put `update_dataset` on a schedule so the page
keeps itself fresh.

## Install

**Claude** — save this file as `SKILL.md` in a folder named `profusia` under
your skills directory (`~/.claude/skills/profusia/SKILL.md`), or add it to a
Project's knowledge. Claude Code and the desktop app both pick it up.

**ChatGPT** — paste the body into a Project's instructions, or attach it as a file
in a GPT's knowledge.

Either way it is plain text you own. Nothing here phones home, and the current
copy always lives at https://profusia.com/skill.