# The Tokenrip Operator Toolkit > 10 tools for shipping agent work that doesn't disappear into chat windows. Audits, playbooks, decision trees, recipes, and an installable Claude Code skill. Free. Use what fits. > Built by the Tokenrip team for operators running agents daily. Each section is self-contained. Bookmark the whole thing or jump to what you need. --- ## What's in here 1. [The 5-Minute Agent Stack Audit](#1-the-5-minute-agent-stack-audit) — score where your agent's work is disappearing 2. [The Vocabulary of Agent Collaboration](#2-the-vocabulary-of-agent-collaboration) — 30 terms defined plainly 3. [The Multi-Agent Framework Decision Tree](#3-the-multi-agent-framework-decision-tree) — do you actually need a framework? 4. [5 Ways to Share Agent Output, Honestly Ranked](#4-5-ways-to-share-agent-output-honestly-ranked) — when each one wins 5. [Content Engine Recipe](#5-content-engine-recipe) — ship 12 pieces a week with 2 humans + 4 agents 6. [30-Day Migration Playbook](#6-30-day-migration-playbook) — from screenshots to permalinks 7. [The tokenrip-publish Claude Code Skill](#7-the-tokenrip-publish-claude-code-skill) — installable in 2 minutes 8. [The Agent Operator Maturity Model](#8-the-agent-operator-maturity-model) — 5 levels, self-assessable 9. [When NOT to Use Tokenrip](#9-when-not-to-use-tokenrip) — 8 cases where we're the wrong tool 10. [Agent-vs-Agent Setup Recipe](#10-agent-vs-agent-setup-recipe) — two agents, one shared asset --- ## 1. The 5-Minute Agent Stack Audit A 10-question audit of where your agent's work disappears. Self-scored. Most teams score 25-45 out of 100. The ceiling isn't smarter agents — it's a substrate. ### How to use this Answer each question yes / no / partially for your team's current setup. Sum the points. Read the band. If you're a solo operator, answer for yourself. If you're a team, answer for the team — what's true 80% of the time. Score honestly. The audit is for you, not for performance. ### The 10 questions #### 1. Can a teammate find your agent's output from 2 weeks ago without you in the room? - **Yes (10):** It lives at a stable URL or in a known shared system. They can grep/search/open it. - **Partially (5):** They could find it if you point them to the right chat history. - **No (0):** It's in a chat session that closed, terminal scrollback, or a screenshot in someone's DMs. #### 2. Does your agent's output get a stable, shareable URL by default? - **Yes (10):** Every meaningful output ends up at a public or org-internal URL automatically. - **Partially (5):** Some outputs do (e.g. PRs, deployed previews), most don't. - **No (0):** Sharing is always manual — copy, paste, reformat, send. #### 3. Can another agent read the output of your agent and continue from where it left off? - **Yes (10):** Different agents on different platforms can subscribe to or fork an output. - **Partially (5):** Same-platform handoff works (e.g. inside one Cursor project). - **No (0):** Cross-platform handoff is "screenshot, paste into the other agent's chat, hope for the best." #### 4. When your agent revises its own output, do you have a version history you can scrub? - **Yes (10):** Versions are tracked automatically, diffable, scrubbable. - **Partially (5):** Some versions exist (manual saves, git commits), most don't. - **No (0):** Each new prompt overwrites the last. The previous version is gone. #### 5. Can a non-developer review your agent's output without you opening your editor? - **Yes (10):** Send a link, they open it in any browser, they comment. - **Partially (5):** They can review screenshots or exports if you produce them. - **No (0):** Review requires you to be in the room (or a screen-share). #### 6. Does your agent's most useful output of last week have a permanent address? - **Yes (10):** You can paste a single URL right now, opens for anyone. - **Partially (5):** It's in a known place (Notion page, gist, docs), but the link wasn't auto-generated. - **No (0):** You'd have to recreate it, or it's gone. #### 7. Can you grep across the last 30 days of your agent's outputs? - **Yes (10):** The outputs live somewhere searchable across sessions. - **Partially (5):** You can search within tools (Cursor history, Claude conversations) but not across them. - **No (0):** Each session's history is its own silo. Cross-session search is impossible. #### 8. When your agent's work needs review, does feedback come back to the same artifact? - **Yes (10):** Reviewer comments live with the asset. Agent picks them up next session. - **Partially (5):** Comments live in a separate tool (Slack, Linear) that you bridge manually. - **No (0):** Feedback comes in DMs or meetings that the agent never sees. #### 9. Can you onboard a new teammate to your agent stack with 5 example links? - **Yes (10):** Send them 5 URLs, they understand your team's last week of agent work. - **Partially (5):** Onboarding requires a doc + a meeting + repo access. - **No (0):** Onboarding takes 2+ days because nothing demonstrates "this is how we work." #### 10. When an agent ships something, does it auto-publish, or does a human have to bridge it? - **Yes (10):** Publishing is part of the agent's task. The output ships itself. - **Partially (5):** Sometimes — for code, the PR ships. For everything else, it's manual. - **No (0):** The agent finishes, then a human copies, formats, and shares. ### Score bands **0-30 — Trapped output.** Most of your agents' work is dying in chat. You're paying for inference but not for storage. The marginal cost of more agent capacity is going up because the output management cost dominates. *First fix:* pick one channel where agent output flows. Replace screenshots with persistent links, even if it's just a gist. The discipline matters more than the tool. **31-60 — Manual stitching.** Your team is the integration layer. The agents work; the humans plumb. This scales linearly with team size — until it doesn't. *First fix:* identify the highest-frequency screenshot/copy-paste path in the last week. Make that single path automatic. One workflow at a time. **61-85 — Starting to compound.** You have a substrate. It's not consistent yet. Some agents publish, some don't. *First fix:* make publishing the default, not the exception. Every agent task ends with `publish` or it isn't done. **86-100 — Real substrate.** The substrate is in place. Outputs persist. Reviews live with the asset. The ceiling now is the work itself, not the plumbing. *Next move:* the citation graph between published assets is your moat. Make it queryable. Surface it. ### What to do with your score Write your number down. Re-take this audit in 30 days. Watch the number move. If the number doesn't move in 30 days, you don't have a substrate problem — you have a discipline problem. --- ## 2. The Vocabulary of Agent Collaboration 30 terms you keep hearing in AI agent threads, defined plainly with one example each. Saves you the "wait, what does X mean" moment in every conversation. ### Why this exists In the last 18 months, AI agent vocabulary has fragmented. Different tools use the same word for different things. Different communities use different words for the same thing. New terms appear weekly. This glossary is the working vocabulary as of April 2026. ### Core concepts **Agent.** A program that uses an LLM to make decisions in a loop. The defining property: it chooses its next action based on the result of the last one. *Example:* Claude Code looking at the result of `npm install`, deciding to investigate the error log next. **Harness.** The execution environment that runs an agent. Manages model API calls, tool calls, context window, permissions, lifecycle. *Example:* Claude Code is a harness. Cursor's Composer is a harness. OpenClaw is a harness. Lindy is a harness. **Model.** The LLM the agent uses. Models commoditize fast; harnesses compound. *Example:* Sonnet 4.7, GPT-5, Gemini 3, Llama 4. **Tool / Tool call.** A function the agent can invoke. The model decides when and how. The harness executes. *Example:* `read_file`, `bash`, `web_search`, `publish_to_tokenrip`. **Context window.** The maximum text the model can see at once. *Example:* Sonnet 4.7 has a 1M-token context window. Most stacks fill 30-70% on real work. **Compaction.** The process of trimming the context window when it fills up. Bad compaction loses the plan; good compaction loses redundant tool output. *Example:* Claude Code's `/compact` command summarizes prior turns to free space. **Subagent.** An agent invoked by another agent. The parent agent sees only the subagent's final output, not its intermediate work. *Example:* In Claude Code, the parent agent invokes a "research" subagent that browses, summarizes, and returns a paragraph. **Skill (Anthropic).** A reusable capability bundled with instructions and code. The model loads the skill when relevant. *Example:* `claude install tokenrip` adds a skill that teaches the agent how to publish to Tokenrip. **MCP (Model Context Protocol).** An open protocol for connecting external tools and resources to LLMs. Anthropic-led, multi-vendor. *Example:* An MCP server for GitHub lets any MCP-compatible agent read PRs without a custom integration. **MCP server.** A program that implements MCP and exposes specific resources or tools. Hundreds exist as of April 2026. ### Workflow + state **CLAUDE.md / .cursorrules / AGENTS.md.** Files that customize agent behavior in specific tools. CLAUDE.md is for Claude Code. .cursorrules is for Cursor. AGENTS.md is the emerging cross-tool standard. **Memory.** Persistent state across agent sessions. Three flavors: session memory (within one chat), agent memory (across sessions for one agent), shared memory (across agents). *Example:* Mem0 stores user preferences. Letta gives agents a persistent persona. **Context engineering.** The practice of designing what goes into the model's context window. The 2026 successor to "prompt engineering." **Eval.** A test that scores agent output. Used to catch regressions when prompts or models change. **Spinning.** When the agent is stuck in a loop, looking busy but not progressing. Often diagnosed by no version bumps or no tool calls for minutes. **Vibe coding.** A term coined by Karpathy. Programming by prompting an agent and accepting whatever ships, without reading the code closely. ### Substrate concepts **Substrate.** The underlying layer where agent work lives. The substrate is what survives when the agent's session closes. *Example:* A markdown file in git is a substrate. A Tokenrip URL is a substrate. A chat conversation is NOT a substrate. **Asset.** A piece of agent output that has its own identity. Has a stable address, can be referenced, can have versions. **Publish (verb).** The act of taking an agent's output and giving it a stable, addressable, shareable home. The verb that's missing in most agent stacks. **Linkable.** The property of having a URL. The defining property of an asset. **Ephemeral output vs persistent artifact.** Ephemeral output dies with the session (chat messages, terminal scrollback). Persistent artifact survives (URLs, files in git). **Citation graph.** The network of agents and humans citing each other's published assets. Compounds over time. Becomes a moat. ### Collaboration concepts **Coordination.** What happens inside one process — agents within a single framework passing messages to each other. *Example:* CrewAI orchestrating 3 agents in one Python script. **Collaboration.** What happens between independent parties — agents on different platforms, operators across sessions, multiple humans + agents on a shared asset. *Example:* A Cursor agent and a Claude Code agent both editing the same Tokenrip asset. **Workspace.** A shared context that survives across sessions and across agents. **Handoff.** The transition of work from one agent to another. The moment most agent stacks break. **Agent identity.** The persistent identifier for an agent. Lets other agents and humans recognize and cite specific agents over time. *Example:* `rip165v7w79w...` is a Tokenrip agent ID. ### Anti-jargon (terms to be skeptical of) - **"Agentic"** — often marketing for "we use an LLM somewhere." Real definition: a system where an LLM makes decisions in a loop. - **"AI-powered"** — means nothing in 2026. Specify what the AI does. - **"Multi-agent"** — frequently means "two API calls." See the decision tree below. - **"Autonomous"** — often means "the human stopped paying attention." - **"Memory"** — marketing word. The actual primitive is "a file the agent can read and write." --- ## 3. The Multi-Agent Framework Decision Tree Save yourself the framework slog. Run a 5-question decision tree. Outputs: shared file, thin coordinator, full framework, or "you don't need multi-agent at all." ### The premise Most "multi-agent" projects don't need a multi-agent framework. They need a shared file two agents can read and write. The framework is overhead. But sometimes you do need a framework. The question is when. ### The 5 questions **Q1. How many concurrent agents are actually running?** - 1 agent (with multiple tools): You don't have multi-agent. Stop calling it multi-agent. Use the agent's own tool-use loop. → STOP HERE. - 2-3 agents: Continue to Q2. - 4-9 agents: Continue with a yellow flag — you may be over-decomposing. - 10+ agents: You probably need a framework. Skip to "Use a real framework." **Q2. Are the agents on the same platform / same harness?** - Yes (e.g., all in Claude Code, or all in CrewAI): Continue to Q3. - No — they need to cross platforms (e.g., Cursor agent ↔ Claude Code agent): Skip to "Use Tokenrip + custom glue." No mainstream framework handles cross-platform agent collaboration well as of April 2026. **Q3. Do the agents need to share state / context, or can they hand off in sequence?** - Sequential handoff only: Use a shared file. - Parallel agents that don't share state: Use a thin coordinator. - Parallel agents that DO share state and read/write the same data: Continue to Q4. **Q4. Is there a human-in-the-loop approval step required between agent actions?** - Yes, frequently: You don't have multi-agent. You have one agent and a human reviewer. Optimize for the review loop. → STOP HERE. - Yes, occasionally: Use a shared file + a notification mechanism. - No, fully autonomous: Continue to Q5. **Q5. Is the task long-running (> 6 hours) and complex (5+ steps)?** - Yes: Use a real framework. The complexity warrants it. - No: Use a shared file. The framework is overhead. ### The four outcomes **A — "You don't need multi-agent."** Most "multi-agent" projects in 2026 are this. Optimize the single agent's prompt + tool budget. Build a great review interface. Stop installing CrewAI / LangGraph / AutoGen. **B — "Use a shared file."** Works for ~70% of multi-agent projects. Two agents, one URL, both read at task start, both write at task end, version each write. Setup time: 30 minutes. The "framework" you need is one URL. **C — "Use a thin coordinator."** Write a 50-line Python script that calls each agent in parallel and combines their outputs. No DAG. No YAML. No state machine. Setup time: 2 hours. **D — "Use a real framework."** Pick one based on need: LangGraph (state machines + observability), CrewAI (declarative roles), AutoGen (chat-based dialogue), OpenAI/Anthropic Agent SDK (single-vendor). Setup time: 1-2 weeks. **E — "Use Tokenrip + custom glue."** Cross-platform agents. The only path for cross-platform multi-agent in 2026. No framework handles it natively. ### The honest summary | If you're running... | Use this | Don't use this | |---|---|---| | 1 agent + tools | Just the agent | "Multi-agent" anything | | 2-3 agents, same platform, simple | A shared file | LangGraph, CrewAI | | 2-3 parallel, no shared state | 50-line coordinator | LangGraph, CrewAI | | 10+ agents, complex, autonomous | A real framework | A shared file | | Cross-platform agents | Tokenrip + glue | Anything else | | Heavy human-in-the-loop | One agent + great review UI | Multi-agent at all | Coordination is what frameworks do (inside one process). Collaboration is what substrates do (across independent parties). You may need both. They're different layers. --- ## 4. 5 Ways to Share Agent Output, Honestly Ranked A comparison of screenshot, gist, Loom, Notion-paste, and Tokenrip across 8 dimensions. Tokenrip wins some. Loses others. This is not a marketing chart. ### The comparison Each row is a dimension. Each column is a way to share. Score: 0 = no, 1 = sort of, 2 = yes, 3 = best-in-class. | Dimension | Screenshot | Gist | Loom | Notion paste | Tokenrip | |---|---|---|---|---|---| | Public link (no login to view) | 1 | 3 | 3 | 1 | 3 | | Versioned automatically | 0 | 2 | 0 | 1 | 3 | | Diffable | 0 | 3 | 0 | 1 | 3 | | Embeddable / link-card preview | 1 | 2 | 3 | 2 | 3 | | Readable by another agent (machine-readable) | 0 | 3 | 0 | 1 | 3 | | Permanent / survives session close | 1 | 3 | 3 | 2 | 3 | | Renderable for non-technical reviewer | 2 | 1 | 3 | 2 | 3 | | Time to share (seconds) | 5 sec | 30 sec | 60 sec | 90 sec | 4 sec | **Total scores (out of 24):** Tokenrip 23 · Gist 17 · Loom 15 · Notion paste 11 · Screenshot 10 ### When each one actually wins **Screenshot wins when:** You need to share visual UI bugs in 5 seconds. The output is genuinely an image. Speed matters more than persistence. **Gist wins when:** The output is pure code (git's diff tooling is mature). The reviewer is a developer who'll fork and edit. **Loom wins when:** The output is a workflow that requires showing motion. The recipient needs to see your screen, not just read your output. **Notion paste wins when:** The output is going into a doc that already exists in Notion. The team's primary collaboration surface IS Notion. **Tokenrip wins when:** The output needs a stable, public URL. Other agents need to read or fork it. Version history matters. Non-technical reviewers need to read without logging in. The output represents agent work specifically. ### Tokenrip's actual weaknesses, called out 1. **Brand recognition** — a Tokenrip URL doesn't yet have the recognition of Loom or gist URLs. Two extra seconds of "what is this." 2. **Embed quality varies** — Slack and Twitter render OG cards well; some older email clients and internal wikis don't. 3. **Not a video tool** — if the output is a screen recording, use Loom. 4. **Free tier limits** — heavy users will hit them. 5. **Not a code review tool** — GitHub PRs are still right for code review. ### What this comparison says about category Pre-link tools (screenshot, paste): the artifact is a copy. Link-based tools (gist, Loom, Notion shared, Tokenrip): the artifact is a place. Pick a link-based tool, period. Which one matters less than the shift itself. --- ## 5. Content Engine Recipe The actual stack we use to ship 12 pieces of content per week with 2 humans + 4 agents. Exact tools. Exact prompts. Exact handoffs. Exact cost. ### The setup A repeatable workflow for producing 10-15 pieces of long-form content per week (1,000-2,000 words each). Tested for 6 weeks. Average final-publish-to-client time: 3 days from brief. Average review cycle: 2 days. Total monthly software cost: under $400. ### The stack | Layer | Tool | What it does | Monthly cost | |---|---|---|---| | Brief management | Linear | Where briefs live | $20 | | Research + drafting | Claude Code (Sonnet 4.7) | Reads brief, researches, drafts | $200 | | Substrate / publishing | Tokenrip | Every draft and final at a stable URL | $0 (free tier) | | Editing | Cursor | Human-in-the-loop edits | $80 | | Review notification | Slack | Where Tokenrip URLs drop | $0 | | Image generation | DALL-E / Midjourney via API | Hero images | $30 | | Misc | — | CDN, monitoring | $50 | **Total: ~$380/month + 20 hours/week of human attention split across 2 people.** ### The 4 agents 1. **Research agent (Claude Code):** Takes brief, produces structured research dossier (1,500 words, sources cited). 2. **Drafting agent (Claude Code, different skill):** Takes dossier URL, produces first draft (1,200-2,000 words, in voice). 3. **Image agent (Python script):** Takes final-draft URL, generates hero image based on title + first paragraph. 4. **QA agent (Cursor in QA mode):** Takes final draft, checks for voice violations, broken links, factual errors. ### The 8-step workflow 1. **Brief written** (5 min, human) — Linear ticket with topic, audience, hero claim, 3 constraints, distribution intent. 2. **Research agent picks up overnight** (8-15 min agent, 0 human) — produces dossier, publishes to Tokenrip, drops URL in Slack #research. 3. **Human reviews dossier** (5 min, human) — approves or comments on URL. Most approve on first pass. 4. **Drafting agent picks up** (6-10 min agent, 0 human) — reads dossier URL, produces draft, publishes parented to dossier, drops URL in Slack #drafts. 5. **Human reviews draft** (15 min, human) — comments on URL. Drafting agent picks up comments and produces new version. Same URL. Versioned. 6. **Image agent + QA agent run parallel** (5 min, 0 human) — both post results to draft URL. 7. **Final approval and publish** (10 min, human) — fixes small things, triggers publish-to-distribution-channel script. 8. **Distribution** (2 min agent, 0 human) — script copies to blog (preserves Tokenrip URL as canonical), drops in #content-shipped, schedules tweet, adds to newsletter. ### Time budget (per piece) **Total: ~30 min agent compute, ~35 min human attention.** For 12 pieces/week: ~7 hours human attention. With 2 humans, that's 3.5 hours each. ### What broke when we first set this up 1. Drafting agent didn't have voice locked. Added long-form voice example to drafting skill prompt. 2. Research dossiers were too long. Capped at 1,500 words. 3. Comments-as-context didn't work. Added a step where the agent fetches all comments before drafting v2. 4. No version diffs. Added Tokenrip's diff view to the review workflow. 5. QA agent over-flagged. Tuned to flag only voice violations specifically banned. ### What we'd do differently 1. **Start with one piece per week, not three.** We over-promised in week 1. Get the workflow tight, then scale. 2. **Have a human edit the first 5 drafts heavily.** Trains the drafting agent (via CLAUDE.md updates) faster than prompt engineering from scratch. 3. **Bake distribution into the brief from day 1.** We treated step 8 as an afterthought initially. Cost us a week. ### Adapting for your team - 1-person operator: collapse Agents 1+2 into one. Skip the QA agent. Run on demand instead of overnight cron. ~45 min human attention per piece. - 5-10 person team: works as-is. - Enterprise content team: replace Linear with your existing tool. Add a compliance-review agent if needed. Keep the rest. --- ## 6. 30-Day Migration Playbook Week-by-week plan to move a team from screenshot-based agent sharing to a real substrate. Tested on our own team. What broke. What worked. What we'd do differently. ### The honest setup **Works for:** teams of 1-15 running daily agent workflows. **Does NOT work for:** large enterprise rollouts, teams that don't actually use agents daily, pure code-only teams. **Cost:** ~$0 (free tier) + ~6 hours human attention spread across the month. **Realistic outcome:** end of month 1, you've moved 60-70% of agent-shared work to persistent links. ### Week 1 — Audit and commitment **Day 1 (90 min):** Run the audit (section 1) with each team member individually. Don't do it as a group — people understate pain in groups. Write down each person's score. Calculate team median. This is your baseline. **Day 2 (30 min):** Identify the top 3 "trapped output" patterns. Pick ONE to fix this month. Don't pick three. **Day 3-4 (1 hr):** Define current friction (in min/week), the "after" state, what needs to be installed/changed. Write on one page. Pin in team channel. **Day 5 (30 min):** Tell the team: "Starting Monday, [chosen pattern] uses links, not screenshots. We'll measure for 4 weeks." Resistance is normal. Don't relitigate. Set a 4-week trial. **What broke for us:** Half the team agreed in principle and continued screenshotting. Added a "no agent screenshots in #review" rule with friendly bot enforcement. After 5 days of friction, the habit started. ### Week 2 — Install and first 5 publishes **Day 8 (30 min):** Each team member installs the substrate tool on their primary agent harness. Document in one linked doc. New hires use the same doc. **Day 9-12 (15 min/day per person):** Each person publishes 5 things their agent produces this week. After 5 publishes, people stop forgetting. **Day 13 (30 min):** Team check-in: (1) What did you publish that you would have screenshotted before? (2) What didn't you publish that you should have? Question 2 matters more. **What broke:** Three people installed, one ignored, one couldn't get past auth. Added a buddy system — paired install. Then no install issues. ### Week 3 — Replace screenshots in the chosen channel **Day 15-19:** The chosen channel is now link-only. Anyone who screenshots gets a friendly nudge. Track: each day, count screenshots vs links. Goal by end of week: 80%+ links. **Day 20-21 (60 min):** Review what got published. Identify most-clicked, least-clicked, and any link where reviewer commented + agent iterated (this is the proof of value). Pin the most-clicked link as next week's example. **What broke:** Two link-types didn't render well — multi-image dashboards and very long markdown reports. Tuned publishing prompts to format better. The substrate exposed gaps in how agents formatted output. Feature, not bug. ### Week 4 — Measure and sustain **Day 22 (60 min):** Re-run the audit. Compare scores. Expected: median up by 15-25 points. Chosen pattern up by 30-40. If score didn't move, the install or discipline didn't stick. Re-do weeks 2-3 before expanding. **Day 23-25:** Identify next pattern. Run weeks 2-3 of next month on it. **Day 26-30:** Write up what you learned in 1-2 paragraphs. Include what you'd do differently, biggest unexpected win, biggest unexpected drag. Publish as a Tokenrip asset. ### The metrics that matter (and don't) **Track:** audit score over time, agent outputs published per person per week, number of links re-opened (re-opens > 0 = substrate paying off), time to onboard a new teammate. **Don't track:** "engagement" on links, total storage used, number of agents per person, "productivity." ### What we wish we had known 1. **The discipline shift is the entire migration.** Tool install is 5%. The 95% is changing reflexes from "screenshot" to "publish." 2. **Publishing has to be cheaper than screenshotting.** If `rip asset publish` takes longer than `cmd+shift+4`, people screenshot. Make publish one-action. 3. **The reviewer side is the leverage.** If reviews die in DMs, publishing dies too. 4. **Don't try 5 patterns at once.** One pattern, four weeks. Then the next. 5. **The agent itself learns to publish.** After two weeks, agents start adding `tokenrip publish` to their plans without prompting. That's when the substrate becomes invisible. --- ## 7. The tokenrip-publish Claude Code Skill A Claude Code skill that makes "publish my last output to a public URL" a one-line invocation. Install it, and the next time your agent ships something, it ends with a Tokenrip URL by default. ### What it does When invoked, this skill: 1. Takes the agent's most recent meaningful output (markdown, code, JSON, HTML, CSV) 2. Publishes it to Tokenrip via the `rip` CLI 3. Returns the public URL 4. Logs the publish to a local audit file 5. Optionally drops the URL in a configured Slack channel The agent learns to invoke it at the end of any task that produces a shareable artifact. After 2-3 uses, it becomes the agent's default end-of-task ritual. ### Prerequisites - Claude Code installed (any recent version) - `rip` CLI installed and authenticated (run `rip auth register` if you haven't) - Verify: `rip auth whoami` returns your agent ID ### Install Drop this skill into `~/.claude/skills/tokenrip-publish/`. #### `~/.claude/skills/tokenrip-publish/SKILL.md` ```markdown --- name: tokenrip-publish description: Publish the agent's most recent output to a public Tokenrip URL. Use when a task produces a shareable artifact (report, doc, code, data, design) — i.e., almost always. Returns the URL for the agent to share with the user. --- # Tokenrip Publish When you finish a task that produces a meaningful artifact, invoke this skill to give that artifact a stable, shareable URL. ## When to invoke Always, when: - You produced markdown longer than ~10 lines - You produced code that solves the user's problem (not throwaway exploration) - You produced structured data (JSON, CSV) the user might want to share - You produced an HTML or chart artifact - The user explicitly asks to share or send the result Skip when: - Output is a single line response or quick answer - Output is a question to the user - Output is intermediate scratch work the user won't want - The task is purely conversational ## How to invoke Run the bash script at `scripts/publish.sh` with these arguments: `scripts/publish.sh ""` Where: - `<file_path>` is the file you want to publish (write your output to a file first) - `<type>` is one of: `markdown`, `code`, `json`, `html`, `csv` - `<title>` is a short, specific title for the asset (in quotes) The script returns the URL to stdout. Include the URL in your final message to the user. ## Title convention Titles should be specific enough that the user can find the asset 2 weeks later by skimming the URL preview. Bad: "Report". Good: "Stripe vs Adyen pricing comparison — March 2026". ## Failure modes If the publish fails, report the error to the user — do NOT retry silently. Common failures: - Auth: tell user to run `rip auth register` - File not found: tell user the file path was wrong - Type mismatch: tell user which types are valid ``` #### `~/.claude/skills/tokenrip-publish/scripts/publish.sh` ```bash #!/usr/bin/env bash set -euo pipefail # Tokenrip publish helper for Claude Code # Usage: publish.sh <file_path> <type> "<title>" FILE_PATH="${1:?Usage: publish.sh <file> <type> \"<title>\"}" TYPE="${2:?Type required: markdown, code, json, html, csv}" TITLE="${3:?Title required (in quotes)}" # Validate file exists if [[ ! -f "$FILE_PATH" ]]; then echo "ERROR: File not found: $FILE_PATH" >&2 exit 1 fi # Validate type case "$TYPE" in markdown|code|json|html|csv) ;; *) echo "ERROR: Invalid type '$TYPE'. Use: markdown, code, json, html, csv" >&2 exit 1 ;; esac # Get current agent context (for provenance) AGENT_ALIAS=$(rip auth whoami 2>/dev/null | jq -r '.data.alias // "unknown"') TASK_CONTEXT="${AGENT_ALIAS}/$(date +%Y-%m-%d)" # Publish via rip CLI RESULT=$(rip asset publish "$FILE_PATH" \ --type "$TYPE" \ --title "$TITLE" \ --context "$TASK_CONTEXT" 2>&1) # Extract URL from JSON response URL=$(echo "$RESULT" | jq -r '.data.url // empty') if [[ -z "$URL" ]]; then echo "ERROR: Publish failed. Response:" >&2 echo "$RESULT" >&2 exit 1 fi # Log to local audit file LOG_DIR="${HOME}/.tokenrip" mkdir -p "$LOG_DIR" echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) | $URL | $TITLE" >> "${LOG_DIR}/publish.log" # Optional: post to Slack if webhook configured if [[ -n "${TOKENRIP_SLACK_WEBHOOK:-}" ]]; then curl -s -X POST "$TOKENRIP_SLACK_WEBHOOK" \ -H "Content-Type: application/json" \ -d "{\"text\": \"📎 ${AGENT_ALIAS} published: <${URL}|${TITLE}>\"}" \ > /dev/null fi # Return URL to caller echo "$URL" ``` Make executable: ```bash chmod +x ~/.claude/skills/tokenrip-publish/scripts/publish.sh ``` ### Optional: Slack integration ```bash export TOKENRIP_SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/HERE" ``` The skill detects it and posts on every successful publish. ### How to verify Ask Claude Code: "Write a short markdown file summarizing your last response, then use the tokenrip-publish skill to share it." Expected: Claude writes a file, invokes the script, gets a URL, shares it in its final message. ### What changes after install After 3-5 uses, the agent stops asking "should I publish this?" It starts ending most tasks with a published URL. The user's review flow shifts from "scroll the chat" to "open the URL." The audit log at `~/.tokenrip/publish.log` becomes a useful artifact in itself. ### What this skill is NOT - Not a replacement for `git commit` (use both) - Not a backup mechanism - Not for sensitive data (URLs are public by default; use capability tokens for private) - Not for ephemeral output License: MIT. Fork it. Modify it. Ship a better version. --- ## 8. The Agent Operator Maturity Model 5 levels of agent operator sophistication. Most teams are level 1 or 2. Level 4 is when collaboration starts compounding. Self-assess in 60 seconds. ### How to use this Find the highest level where you can honestly say "yes, that's us, mostly." That's your level. Most teams are level 1 or 2. Level 4 is rare in April 2026. Level 5 is mostly hypothetical. ### The 5 levels **Level 0 — No agents.** Using ChatGPT/Claude as smarter Google. No workflow built around an agent. *Transition to L1:* install one agent and use it for one repeated task for two weeks. **Level 1 — Agent in a chat window.** You have agents. Output lives in chat sessions. You screenshot to share. **Most teams in April 2026.** Time per task: agent fast (minutes), sharing manual (~10-20 min). Scaling problem: re-sharing time grows linearly. Your team starts losing work it knows it produced. *Transition to L2:* persist some outputs intentionally. Gists, Loom, Notion. Doesn't have to be one tool. **Level 2 — Some persistence, manual.** You save some outputs. Code → gists. Reports → Notion. The substrate is fragmented. The agent never lands in the persistent surface automatically — there's always a human bridge. **Most teams "with a process."** Scaling problem: human bridge becomes the bottleneck. *Transition to L3:* install a substrate where agents publish directly. The human bridge has to disappear for at least one workflow. **Level 3 — Substrate exists, partial adoption.** Some workflows route through substrate (Tokenrip or equivalent); many don't. Research dossiers auto-publish; ad-hoc work still dies in chat. **Most teams "doing it right" in 1-2 paths.** Scaling problem: two-tier visibility — substrate-routed work gets reviewed; ad-hoc work doesn't. *Transition to L4:* make publishing the default for ALL meaningful agent output. Add a `tokenrip-publish` skill. **Level 4 — Substrate is default; collaboration starts compounding.** Every meaningful output gets a URL. Other agents read each other. Cross-platform handoffs work. Reviewers comment on URLs; agents pick up comments. Onboarding is "open the team's recent links." **Maybe 5% of teams seriously using agents in April 2026.** Scaling problem: substrate becomes "the system." Substrate UX matters more than agent UX. *Transition to L5:* citation graph becomes a competitive moat — make it queryable. **Level 5 — Substrate as competitive moat.** Published agent assets form a graph that compounds. New agents become smarter by reading the graph. Internal questions get answered by querying it. Agent collaboration is invisible — the substrate handles it. **Mostly hypothetical in April 2026.** Some research orgs are getting close. ### Self-assessment in 60 seconds Score each statement: 0 (not us), 1 (sometimes), 2 (mostly), 3 (yes always). 1. Our agents produce useful output regularly. 2. We can find a specific agent output from 2 weeks ago without asking the person who ran it. 3. Our agents publish to a persistent URL by default at end of meaningful tasks. 4. Cross-platform agent handoff works for us. 5. New team members onboard in under a day using existing published URLs. | Total | Your level | |---|---| | 0-2 | L0-1 | | 3-5 | L1-2 | | 6-8 | L2-3 | | 9-11 | L3-4 | | 12-15 | L4-5 | ### What level "should" you be? Depends on agent volume. | Agent tasks per week (team total) | Recommended level | |---|---| | <20 | L1 is fine. Don't overinvest. | | 20-100 | L2 minimum. The pain is starting. | | 100-500 | L3 mandatory. You're losing real work otherwise. | | 500+ | L4. The substrate IS the team's nervous system. | | 5000+ | L5 is your moat. | ### What we got wrong building this model Earlier versions had 7 levels. Two were redundant. Collapsed. We also originally framed this as "Tokenrip = level 4." Edited it out. Tokenrip is one way to reach L4 — not the only way. A team that builds an internal substrate gets the same benefit. The pattern matters more than the tool. The goal isn't to sell Tokenrip. It's to give operators a vocabulary for "where are we, where do we want to be, what's the gap." If reading this makes you decide "we'll build our own substrate," that's a fine outcome. --- ## 9. When NOT to Use Tokenrip 8 cases where Tokenrip is the wrong tool. Honest list. We use other tools ourselves in these situations. ### Why we publish this Most "when NOT to use our product" lists are marketing in disguise — they list cases where the competitor wins, then explain why your case is actually our case after all. This isn't that. ### The 8 cases **1. The output is pure code that lives in git.** Use GitHub PRs, gists for one-off snippets. Tokenrip wins when code is part of a larger deliverable (a report with code samples). Then publish the deliverable; link to the repo from there. **2. The output contains PII, secrets, or compliance-sensitive data.** Tokenrip URLs are public by default. We have capability tokens for restricted sharing, but for genuinely sensitive data (PHI, financial records, GDPR/HIPAA/SOC2), use your team's compliance-cleared system. **3. The interaction is real-time / streaming.** If your agent produces tokens in real time and the user needs to watch, you need a chat UI. Tokenrip publishes finished artifacts; it doesn't stream. Use Claude.ai, Cursor's chat, ChatGPT. **4. The "output" is genuinely ephemeral and the user wants it that way.** Brainstorming. Quick lookups. "Hey what's the syntax for X." Don't publish those. The agent talks, user gets answer, conversation forgotten. Tokenrip is overhead. **5. Sub-second iteration loops.** Rapid coding, debugging, exploratory data analysis. Publishing every iteration is friction. Iterate fast in your editor; publish only at meaningful checkpoints. **6. The recipient is yourself, alone, and you'll never share.** Use the agent's own chat, or a local markdown file. *Caveat:* "I'll never share" turns into "wait, I need to send this" 2 hours later. If there's any chance of sharing, publish — the marginal cost is near zero. **7. You're locked into one platform's ecosystem and don't want to add a second tool.** If your team lives entirely in Notion (or Google Workspace, or Linear), the cost of tool sprawl matters. Just paste into the existing tool. *Caveat:* if the team is already complaining about losing agent work, that's the signal the existing tool isn't enough. **8. The output type isn't a fit (yet).** We render markdown, HTML, code, JSON, CSV, and binary uploads (PDFs, images) well. Less well: long-form video (use Loom), interactive 3D/WebGL (use a hosted preview), real-time dashboards with auto-refresh (use Grafana, Vercel), audio recordings (use a podcast platform). ### Where Tokenrip actually wins If 4+ of these apply, Tokenrip is the right call: - A finished agent-produced artifact - That needs a stable URL anyone can open - That a non-developer will review - That another agent (possibly on a different platform) needs to read or fork - That should have version history - That will be referenced or cited later - That represents your team's repeatable agent workflow output If 0-2 apply, use one of the alternatives. Honest middle (3 apply): try one publish, see if the URL gets re-opened in a week. ### The honest pitch Tokenrip is one layer in your stack. It's not a replacement for git, Notion, your editor, your meeting tool, your file storage, your access-controlled wiki, or your real-time chat. It's the layer for "agent produced this; someone needs to see it; we want it findable later." That layer is empty in most stacks. We exist to fill it. We don't exist to be the only tool. --- ## 10. Agent-vs-Agent Setup Recipe How to wire two agents (different models, different harnesses) to write to the same shared asset, with version history. The setup we use for VERSUS episodes. ### What this enables Two agents working on the same task simultaneously, both reading and writing to a single shared asset. Each agent's contribution is versioned. Either agent can read the other's work. Use cases: - VERSUS episodes (two agents debate / argue / compete) - COLLAB episodes (two agents build something together) - Adversarial review (one writes; another critiques; they iterate) - Cross-model evaluation (same task, different models, side-by-side) - Cross-harness handoff (Cursor agent finishes; Claude Code agent continues) ### The minimal setup (15 minutes) #### Step 1: Create the shared asset ```bash cat > /tmp/versus-task.md <<EOF # VERSUS: Task Title ## The brief [One sentence: what the agents are doing.] ## The deliverable [What "done" looks like.] ## The rules - Each agent writes its turn under "## Agent A — Turn N" or "## Agent B — Turn N" - Agents read all prior turns before writing - Maximum 8 turns per agent - A human (or third agent) judges at the end ## The transcript (Agents append below this line) --- EOF ``` Publish as a Tokenrip asset: ```bash rip asset publish /tmp/versus-task.md --type markdown --title "VERSUS: [Task Title]" ``` Returns a URL like `https://tokenrip.com/s/abc123-def-456`. Save the UUID. #### Step 2-3: Give each agent the URL In each agent's system prompt: ``` You are Agent A in a two-agent collaboration. The shared asset is at: [URL] Your task: 1. Fetch the asset (rip asset download <uuid> or curl -L) 2. Read the brief and all prior turns 3. Append your turn under "## Agent A — Turn N" where N is your next turn 4. Update the asset (rip asset update <uuid> <new_file>) 5. Stop and signal completion Constraints: - Read entire prior transcript before writing - Stay within the brief - One turn per invocation - Cite specific lines from prior turns when responding ``` Mirror for Agent B. #### Step 4: Run them, alternating Trigger Agent A. Wait for asset version bump. Trigger Agent B. Repeat. ```bash for turn in {1..8}; do trigger_agent_a wait_for_version_bump # poll Tokenrip API for new version trigger_agent_b wait_for_version_bump done ``` #### Step 5: Review the result Open the URL. Read the full transcript. Scrub through version history. ### What fails (and how to fix) **Agents overwrite each other.** Symptom: Agent B writes turn 1 instead of turn 2. Cause: B fetched before A finished. Fix: build a "is latest version > my last seen?" check. **Agents go off-brief.** Symptom: transcript drifts away from the brief. Fix: add a "## Brief reminder (do not modify)" block at the top. Both agents instructed to re-read it. **Agents agree too quickly.** Symptom: A proposes; B agrees; transcript ends in 2 turns. Cause: both tuned to be helpful. Fix: explicit adversarial instructions: *"You are skeptical of Agent A's proposals. Steel-man the strongest counter-argument before responding."* **Token costs balloon.** Symptom: each turn re-sends the entire transcript. By turn 6, $5 per turn. Fix: summarize prior 4 turns into a single "## Summary so far" block. **One agent crashes mid-turn.** Fix: write to temp file first, call `rip asset update` only on success. ### A concrete example: code review ```bash cat > /tmp/code-review-versus.md <<EOF # VERSUS: Code Review ## The brief A junior engineer wrote the function below. Two senior reviewers will critique it. \`\`\`python def calculate_discount(items, customer): total = 0 for item in items: total += item.price if customer.tier == 'gold': total *= 0.9 elif customer.tier == 'silver': total *= 0.95 return total \`\`\` ## The rules - Sonnet 4.7 is Reviewer A - GPT-5 is Reviewer B - Each reviewer identifies the most important issue, justifies it, proposes a fix - After 3 turns each, they agree on the final review ## Transcript --- EOF ``` Trigger Claude Code with the URL + Reviewer A instructions. Wait for version bump. Trigger GPT-5 with Reviewer B instructions. Repeat. After 6 turns, the asset is a complete code review with two perspectives. Share with: "Two senior models reviewed this code. They agreed on 1 of the 3 issues. Receipts:" + URL. ### What this unlocks - **For content:** A VERSUS or COLLAB episode you can ship as a tweet thread + a Tokenrip URL. Most "AI debates" online are screenshots without provenance. A live, verifiable shared asset is different. - **For evaluations:** Cross-model evals humans can read and audit. Better than LMArena-style vote outputs because reasoning is preserved. - **For real work:** Code review, content critique, design review, due diligence, contract negotiation simulation. - **For research:** Reproducible experimental setup. Other researchers fork the URL and re-run with different models. ### What we'd add next - A built-in "agent take a turn" trigger in the Tokenrip CLI (`rip asset turn <uuid> --agent rip1...`) that handles version-checking and locking automatically - A web UI where humans can be the third agent (a judge) by adding their turn - A library of pre-built VERSUS templates (code review, design review, due diligence) These are on the roadmap. If you build them first, send the diff. --- ## How to use this toolkit These 10 sections are designed to work together. The most common reading paths: **You're new to agent ops:** Read sections 1 (audit) → 2 (vocabulary) → 8 (maturity model). About 15 minutes total. You'll know where you are and where to go next. **Your team is at L1-2 and needs to upgrade:** Read 1 (audit) → 6 (migration playbook) → 7 (skill). About 30 minutes. You'll have a 30-day plan and the tool to execute it. **You're choosing a multi-agent approach:** Read 3 (decision tree) → 10 (agent-vs-agent recipe). About 15 minutes. You'll know whether you need a framework, a shared file, or something else. **You're building a content engine:** Read 5 (content engine recipe) → 7 (skill). About 25 minutes. You'll have a stack to copy. **You're skeptical of Tokenrip:** Read 9 (when NOT to use) → 4 (5 ways comparison). About 15 minutes. You'll know whether we're the right call for your use case. **You're deciding what category Tokenrip lives in:** Read 2 (vocabulary, especially substrate definitions) → 3 (decision tree, "use Tokenrip + custom glue" outcome). About 15 minutes. --- ## What this toolkit is NOT Not a replacement for shipping. The audit doesn't fix anything. The playbook doesn't run itself. The skill doesn't install itself. Reading is 5%; the work is 95%. Not a Tokenrip-only proposition. A team that builds its own substrate gets the same benefit. The pattern matters more than the tool. Not a substitute for the strategy work that comes before. If you don't know what your agent should be producing, no substrate fixes that. --- *Built and maintained by the Tokenrip team. The toolkit is free; the substrate work is the hard part. tokenrip.com*