Owner desk

Questions in chat get buried, and the owner has to answer when the agent asks, not when they have time. The desk moves them out of the chat into a board: a Decisions tab and a Tasks tab with every open item, a yellow Urgent tab only when something can't wait, a Decided tab for answered ones, a Later tab for what can wait, and an Archive for what's done. On a phone or iPad, the owner swipes sideways to move between tabs. The owner answers there; you read the answers, act, and archive.

What this needs

• Claude artifacts with the db and comments capabilities, on claude.ai or in the Claude desktop app. Add assets if items will carry attached files, or if the owner should be able to attach screenshots to their questions.

• Tools:

  • Artifact, to publish the board and upload files;
  • ArtifactData, to write and read items;
  • ArtifactComments, to watch the board and answer the comments that wake you.

  Load them with ToolSearch when they're deferred.

• A main-loop session. Only a main-loop session can hold a watch; a subagent can't.

Without these, say so and keep the questions in chat as a numbered list. Don't pretend there's a board.

Who writes to it

One session only:

• the chief of staff, if there is one (see the chief-of-staff skill);
• otherwise, the session that works with the owner.

Two writers would number items twice and archive each other's work.

Create the board

1. Fill in the template, assets/desk.html. It has three placeholders:

   • {{TITLE}}: the board's name, two to four words, such as "Recipe App Desk";
   • {{EYEBROW}}: a small line above the title, such as "Recipe app · from the chief of staff";
   • {{AGENT}}: who reads the answers, as it reads mid-sentence: "the chief of staff", or "Claude". Plain words only, with no quotes.

   For example:

   sed -e 's/{{TITLE}}/Recipe App Desk/g' -e 's/{{EYEBROW}}/Recipe app · from the chief of staff/g' -e 's/{{AGENT}}/the chief of staff/g' <skill>/assets/desk.html > desk.html

2. Publish it with the Artifact tool:

   • capabilities: {"db": {}, "user": {}, "comments": {}}, plus "assets": {} if items will carry files;
   • icon: "inbox";
   • a one-line description.

   Publishing also starts this session watching the board.

3. Check it once: ArtifactData list on the collection items. It's empty, and the page says "Nothing needs you."
4. Give the owner the link, and say the board is private to them.
5. Write the link into a file in the project (the status page, or the project's notes), so a fresh session can find it.

Opened outside Claude, in a plain browser, the page shows made-up example items with a note saying so. That's for previews and screenshots; it never writes anything.

Be woken by answers

A database write doesn't wake you; a comment sent to Claude does.

• Answers wait for "Send all". An answer, or a task marked done, on an ordinary item is saved with wakePending: true and a short wakeLine ("Yes (+ note)", "CHANGED to No"), and wakes nothing yet. A bar at the bottom of the page lists them; when the owner presses it, one comment comes, anchored on the desk's title, with a line per answer ("№ 12 · Open the beta this Friday? → Yes (+ note)"). The page then clears wakePending. Ten answers wake you once, not ten times.
• Urgent items and questions still go at once, as a short comment in the item's own thread, for example "№ 16 · Stop build 1.1? Answer: Stop it now".
• On a "Send all" comment: read every comment thread on the cards it names first (an earlier thread can change what an answer means), re-read each card, act on all of them in that one turn, and reply once.
• That comment wakes the session watching the board.
• Publishing starts the watch, but it's only a watch once ArtifactComments watch (with no url) lists the board as connected, with auto-replies armed.
• A fresh session must watch again, with ArtifactComments watch and the board's url. Auto-replies arm only when the owner gave that link in their own message, so the link goes in the restart prompt the owner pastes.
• The page tells the owner which case they're in: "…is told the moment you answer", or "Saved here; … reads it at its next check".
• If comments can't reach you (they're off, or no session is watching), fall back on these:
  • read the desk at the start of every turn;
  • ask the owner to say "desk" in chat after answering;
  • offer a scheduled check, only if the owner wants one.

An item

Each item is one document in the collection items. Its document id is its handle: use q<number> for decisions and t-<word> for tasks. Use plain words throughout, since the owner may read it on a phone.

Tester feedback (kind: "beta") gets its own tab and never counts as something that needs the owner, whatever its flags; it stays there when answered, until you archive it. It's a decision with these extra fields: tester (a name or a label; real names only on a private desk, never in a repo or an example), build, date, said (their words, as they wrote them) and testerQuestions (questions the owner can send back; the owner replies to testers themselves). body holds how the session that read it understands it, and from names that session. Attach the tester's screenshots as files in links.

assets/example-items.json holds eight made-up items, as ArtifactData batch writes. Use them to try a board, never on the owner's real one.

Post items

• Add new items with ArtifactData. Use set for a new document, and batch for more than two. Never republish the page to change items.
• Then say in chat what you added, with a link to each item: <board url>#<doc id> opens its tab and scrolls to it.
• If you also work from a chat list of open questions (as the chief of staff does), keep both the same: the same number, the same words.
• Write each item so it stands on its own: what is being decided, what changes either way, and what you recommend.
• A task lists the exact steps, the text to paste in copies, and the guide in links.
• To attach a file: read the whole file first, then upload it with Artifact (url of the board, asset: true) and link it as /_blob/<asset id>.
• To show a screenshot on the card: upload it the same way and put it in images with a one-line caption, rather than in links.
• A test item on a live board can get answered. Title it "TEST ITEM", and delete it pinned to the version you read; if the version moved, read it again first.
• Never put passwords, keys or private records in an item. A task that needs a secret says where to type it, never what it is.

Read, act, archive

When a comment wakes you, or at the start of a turn:

1. ArtifactData query on items with where: [["status", "==", "answered"]]. Read each item's answer and any new asks. An item with wakePending: true is answered but not sent yet: act on it like the others.
2. Act on the answer. With a chief of staff, relay the owner's choice and note verbatim to the session that asked.
   • The comment and the item normally agree.
   • If the item isn't saved as answered, but the comment carries an answer, the comment is the owner's newer word. Write it into the item yourself.
3. Archive the item: update it with status: "archived", a one-line outcome ("The builder moved the beta to Friday"), and archived (the time). Pin every write with if_version, so an answer the owner changes meanwhile isn't overwritten.
4. Answer each open entry in asks on the same item. Send the whole asks array back, with a and aAt filled in, pinned with if_version.
5. Reply in the comment thread with one line ("Got it: moving the beta to Friday"), then resolve the thread (ArtifactComments reply, then resolve).

• A batch write fails whole if one card moved (the owner answered again, or an automatic reply bumped its version). Query again and resend, rather than writing the rest one by one.
• Read every automatic reply in the desk's threads against the files, and correct it in its thread. On a real desk they have said work was "going ahead" when nothing was being built, misread a card, and invented a mock-up nobody made.

Park an item with later: true, and bring it back with later: false. A decided item can stay on Later until it's time to act on it. Archive instead of deleting: the Archive is the record of what was decided. Delete only on the owner's word.

Status and Roadmap (optional)

Two more tabs show the owner where the project stands, between the Overview and the items. Each appears once you write its document to the collection board, and updates live. Write each with ArtifactData (set the first time, then update pinned with if_version). assets/example-board.json holds a made-up pair.

board/status: where every session stands. Update it each time you check on the team; a chief of staff writes it whenever it updates its status page.

The Status tab counts the owner's urgent and open items by itself; don't repeat them in oneLine.

board/roadmap: the plan, stage by stage. Update it when a stage or one of its items moves.

Updates (optional)

An Updates tab lists what changed, one entry per pull request, in the collection updates. Add an entry only after the reviewer passed it and it merged, never when the builder finishes. The tab shows how many are new. The owner marks each one read (saved in the database, so it holds on every device), and read entries move to an "Updates archive" tab at the far right. assets/example-updates.json holds three made-up entries.

Change the page

• Republish the page only to change the page itself. Pass the same capabilities, or omit capabilities to keep them.
• If another session published the board, read it first (Artifact read) and build on what comes back.
• The items live in the database, so they survive a republish.
• Keep anything the owner marks (read, seen, ticked) in the database, never in browser storage: it has to hold on every device.
• A collection other than items redraws the page only on its own tab; elsewhere, redraw just the tab rail, or a live write wipes a half-typed answer.
• To test without signing in, serve a local copy from 127.0.0.1 with a stand-in window.claude.use("db") that supports collection().onSnapshot and doc().update. Load a copy of the real items, and compare every tab before and after the change.