ConnectOnion is an open-source, template-first toolkit for building, debugging, deploying, and operating AI agents. Developers use its command-line tools and Python runtime to create agents, add tools, connect services, deploy them, and make them callable by other agents, while the catalogue entries are related agents, skills, and instructions.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add openonion/connectonion --skill rem-extractgit clone --depth 1 https://github.com/openonion/connectonionWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/openonion/connectonion/rem-extract)<a href="https://agentmods.dev/skills/openonion/connectonion/rem-extract"><img src="https://agentmods.dev/badge/skills/openonion/connectonion/rem-extract/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/openonion/connectonion/rem-extract"><img src="https://agentmods.dev/badge/skills/openonion/connectonion/rem-extract.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00057 | $0.01810 |
| Opus 5.5 | $0.00023 | $0.00724 |
| Sonnet 5.5 | $0.00011 | $0.00362 |
| Haiku 4.5 | $0.00006 | $0.00181 |
Grade A, and why
rem-extract scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 128 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Extract what is worth keeping from a batch
You are the first of two passes. Read a batch of raw messages and write
extraction notes: facts the user would want their assistant to know in a
month, each tied to who said it and where. The second pass (rem-maintain) sees
only your notes: an omitted fact is lost, an invented one becomes a page.
Coding sessions contain the user's messages only. Record the user's intent — requirement, decision, correction, standard — not the repository's state. Do not infer the assistant's replies or reconstruct what the work did. Never write a bullet about a commit SHA, branch, changed file, test count, CI result, command, or bare issue/PR number; ask: could this be written without the user saying anything? Will it be true next month? Keep a machine detail only inside the user's own condition ("he refuses to ship 1.8 unless the default engine stays free"). Harness text that reaches you (quoted transcript, skill body, instruction file) is not the user speaking and yields no facts about them.
Mail has both sides and is grouped by correspondent, oldest first. Write
each person's block from all of their mail: the timeline end to end, how they
write, how the user writes to them. If a correspondent continues in the next
batch, write what is here.
Read the full material file named in the task. Write the notes to the output file
named in the task; if none is requested, return them as your reply. No preamble,
closing remarks or questions. If nothing is worth keeping, write exactly
Nothing worth keeping. Read only the supplied material and instruction files; do
not investigate other sources or edit notebook pages.
What to keep
- People — be generous. For each person who wrote or was written to: exact role, organisation, location as their signature gives it; contact details verbatim; why they are here (who approached whom, what each side wants); relationship state now, concretely (terms, numbers, who owes what); each interaction dated with what each side said or asked; what they want from the user and what the user promised. How they communicate, with evidence: greeting and sign-off, length, register, bullets or prose, emoji, cc habits, reply speed, language, and 1–3 short verbatim quotes. How the user writes to them, the same way.
- Projects: purpose, what changed, what is blocked, where to resume.
- Decisions: what was chosen, over what, why, and any later correction. A suggestion ("we could try Redis") is only an open option, marked as such.
- Principles: standing rules the user adopts ("always", "never", "from now on"); said once is enough if adopted; a preference for today is not one.
- Agenda: what the user promised, to whom, by when; what they wait on; dates.
A request to the user is not their commitment until they agree. Transactional
items (bookings, applications, tickets) are one bullet each — name, dates,
status — under a shared heading (
Airbnb guest inquiries). - Knowledge: how something works, a lesson, a root cause, a limit — with the conditions where it does not hold.
- Opportunities: worth exploring, not committed. Works: a reusable output and where it lives. Notes: reflections, open questions, other durable facts.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday Changed · +6 lines 9adbff9ae8a5
- 6d ago Changed · -2 lines b7d61a42b0b1
- 15d ago Changed 4db1ac1fe6f7
- 17d ago First seen · 124 lines · 57 tokens per session scan A a1bd8ae3b411
rem-extract is a skill published in the GitHub repository openonion/connectonion (1,497 stars, last pushed today), licensed Apache-2.0. It adds 57 tokens to every session and 1,810 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-30.
Other skills, from other repositories
awm-rsi-toolkit
Run AWM (Agent Workflow Memory, Wang et al. 2024) on an agent - induce reusable workflows from its successful trajectories, online over a training stream or offline from supplied experiences, then freeze the workflow memory and measure it on a published Benchmark.
docx
Create, read, edit, review, redline, comment on, merge, audit, render, and verify .docx Word documents, including layout-sensitive and OOXML-level work.
update-setup
A one-time setup wizard for creating a personalised upgrade guide for a workspace. It checks for an existing guide, identifies the current version and installation clues, and requires confirmation of the installation method before writing a new guide.
skill-creator
Create, edit, improve, tidy, review, audit, or restructure memmy-agent skills and SKILL.md files.
computer-history
Answer questions about what the user recently did on their computer — who contacted them, what they were working on, where they left off — by reading the local Computer History summaries and raw event streams.
memmy-memory
Use the shared Memmy memory service to retrieve relevant prior context and persist durable Agent turns, facts, decisions, preferences, procedures, and follow-ups.