PluginWorld
Sn

sno-ai

Claude Code✓ SPEC VERIFIED

Sno Station Skills: 31 tested skills that turn Claude Code and Codex into one working team. Cross-vendor peer review, automatic handoff when an agent hits its quota, a one-page morning brief, work orders with proof, and a nightly loop that learns from your own sessions. Open source, installed with one sno setup.

@sno-ai · Apache-2.0 · updated today

SECURITY

A

SCORE

93

STARS

▲ 746

PLUG IN

/plugin marketplace add sno-ai/sno-station-skills

Then run /plugin install <name> for any plugin it lists

README

Sno Station Skills — The working habits of a real team, installed into your AI agents.

Sno Station — Agents, assemble. Two heads are better than one, and smarter by morning.

license Apache-2.0 37 skills in 28 units self-tested before every release agents Claude Code, Codex

Install

All skills with Sno Station

Copy this prompt into your agent's chat:

Install sno.ai from GitHub.

This installs Sno Station and sets up all 37 skills, plus the programs they call, for the supported agents it finds on your machine.

Or paste this command into your terminal:

sh -c 'sno_installer_body=$(curl -fsSL https://sno.ai/install) && printf "%s\n" "$sno_installer_body" | sh'

Already have Sno Station? Run sno setup to install the skills into your agents. Run it again if you add another agent later.

Install one skill

Use the copy button on either prompt below, then paste it into your agent's chat. Your agent finds and installs the skill; you do not need to download or copy files yourself.

peer-review checks code, plans and documents with a reviewer from another model vendor. It needs Sno Station programs and a logged-in reviewer. The prompt checks those dependencies first.

Install only the peer-review skill from https://github.com/sno-ai/sno-station-skills
for this project, including its scripts and references.
Check its dependencies and tell me what is missing before installing anything else.

less-is-more helps your agent write less code and remove unnecessary complexity. It can run without Sno Station.

Install only the less-is-more skill from https://github.com/sno-ai/sno-station-skills
for this project, including its scripts and references.

Supported agents for Sno Station: Claude Code, Codex, OpenClaw and Hermes Agent. Each skill declares what it needs from the agent. Setup uses that declaration to install it fully, install it in a reduced form, or skip it when the agent cannot run it.

Updates come by themselves: sno updates itself when it finds a newer release. The full command list is in Sno Station's command reference.

Install as a plugin

Claude Code:

claude plugin marketplace add sno-ai/sno-station-skills
claude plugin install sno-station@sno-ai

Codex:

codex plugin marketplace add sno-ai/sno-station-skills
codex plugin add sno-station@sno-ai

sno-station holds all 37 skills; most of them call Sno Station programs, so install Sno Station too. For only the 7 skills that run without Sno Station, install sno-station-standalone@sno-ai instead.

Install · What changes for you · Why these skills · The pain, and what fixes it · Stories from our own machine · The skills · Built to be trusted · For skill authors · License

What changes for you

You keep working exactly as before, in whichever agent you like. Then:

  1. You finish a change and want it checked. Say "peer-review this". A reviewer from the other vendor reads it cold, reports what would break in real use, and the author fixes the root cause, round after round, until the review comes back clean.
  2. You start a long run before bed. Say "arm rotate-agent". If the working agent's quota drops to the threshold overnight, it hands the task to a fresh agent from the other vendor, with the brief verified before a single file is touched.
  3. You come back. Say "away brief". One page, at most 60 lines: what got done, what is stuck and why, what waits for your answer, and what it cost in quota.
  4. You have a job for someone else. Say "write a charter". You get one file that says what to deliver, what is out of bounds, what you already decided, and how each success check will be proven. Any agent can then deliver it, and every check is proven by a recorded real run.
  5. Every night, the team looks back. The nightly loop reads the day's Claude Code and Codex sessions, finds the mistakes that repeat, and proposes lessons and skill changes. In the morning you accept the ones you like with sno rem-reflect accept <id>. Nothing changes without that accept.

Why these skills

One AI agent is a brilliant new hire with no colleagues. It reviews its own work, so it misses what it cannot see. It stops dead when its quota runs out, at 3 a.m., halfway through your build. It says "done" when the tests are green and nothing actually happened. It builds three layers of machinery you never asked for. And tomorrow it makes the same mistake it made today, because nobody told it otherwise.

Sno Station Skills fixes the team, not the model. These are the skills Sno Station installs into the agents you already run. They give Claude Code and Codex the habits every good engineering team has: a second pair of eyes from a different vendor, a clean handover when someone has to leave, a lead who hands out work with a written definition of done, a one-page brief when you come back, and a retrospective every night that turns this week's mistakes into next week's rules.

Dual Brain: different roles, one team. One agent carries out your task. The other reviews the result against your requirements. Claude Code and Codex can take either role. When both CLIs are installed, the review runs in the other vendor's CLI, in a fresh session with none of the author's conversation. The agents exchange findings and corrections. Add more roles, and you have an Agent Squad.

Work that finishes while you sleep. Arm it before bed, and when the working agent's subscription runs low it writes a handover brief while it still can, wakes an agent from the other vendor, and hands the task over with the exact commit to continue from. Your build does not care which vendor finished it.

"Done" means proven. Every task can carry a written list of success checks, each one answered pass or fail by a real run. Nothing counts as done because an agent said so.

Tested before it ships. Every skill in a release passed its own self-tests on a clean copy, was scanned for personal paths and leftovers, and carries a stamp that says so. A skill that fails is not published.

How it works: two agents, one shared workspace, three things you get

The pain, and what fixes it

Last updated 2026-10-23. Every line in the left column is a real complaint from r/ClaudeCode, r/codex or r/ClaudeAI in the week of October 20, 2026. The right column is what runs on our own machines, free and open source, to make it stop.

What people said this week What fixes it Where
“Ran out of my 5-hour limit within 30 minutes.” Stop sending the biggest model to do everything. Opus plans and reviews; Codex writes the code, called as an agent from the same session. When one subscription runs dry, the other picks the task up from the same memory. codex-coder, sno reach call
“Lost 10 hours of overnight work to ‘this model is at capacity’.” At 2% of its quota the working agent writes a handover brief and wakes the other vendor's agent, which continues from the exact commit. You were asleep. rotate-agent
“1,100 files, 30,000 lines. I don't have the token budget to review their PRs.” Whoever pushes, reviews first: the author runs a review by the other vendor, in a fresh session that never saw the conversation, and fixes what comes back before anyone else looks. peer-review
“A reviewer subagent checked every commit for two weeks. 86 runs, it stopped exactly one.” A harness reviewing itself finds nothing real. The reviewer is always a different model in a different harness, with none of the author's chat. peer-review
“Codex never finishes a review.” Hard caps written into the skill: 3 rounds on code, 5 on a plan, 1 on tests, then it stops and waits for a person. A run that has written nothing for 15 minutes is killed as stalled. peer-review, codex-coder, heartbeat
“Codex treats every byte like a criminal.” Speculative safeguards, blockers and hashes are the first thing the review deletes. Nothing goes in without an observed failure asking for it. less-is-more
“When Claude says it won't change something, is that reason stored anywhere Codex reads next time?” Every finding is filed once, with a status only a human sets. A finding raised again updates its row instead of coming back as new, and earlier rulings are handed to the next review. peer-review findings ledger
“It said done. Nothing happened.” A task carries a written list of success checks, each answered pass or fail by a real run. An agent saying “done” counts for nothing. pl work orders
“Tomorrow it makes the same mistake it made today.” Every night a separate model reads the day's sessions, turns your corrections into one-line lessons, and you approve what stays. On our own machine: 162 written so far, 7 approved. The bottleneck is us. Self Learning (R skills)
“Half my subagents were glorified one-liners with a fresh context window.” Procedures live in skills, not subagents. Two agents remain, for plan and execution, and for review, because those two splits are the ones that pay. the whole set

Each skill in the right column is in this repository, free to copy into your own agents. The memory they share, the quota watch that fires the handover, and the nightly run that writes the lessons live in Sno Station; install that and every skill here comes with it, so you get the whole experience at once.

"I went to bed. It changed shifts."

From Sno Station's own repository, 2026-09-18.

The quota watch reading down to the threshold every five minutes, and the handover firing at 2%

One of our agents was twenty-one tasks into a twenty-seven-task build when its weekly quota reached 2%. It did not wait to die. It wrote a handover brief: what was done, what was half-done, the exact commit to continue from. Then it woke an agent from the other vendor and would not let it touch anything until the brief was verified. Fourteen minutes and forty-one seconds after the handover began, the second agent was working and the first signed off with 1% left. The second agent continued from the first unchecked task, not from the beginning.

That night ran on the same four skills that ship here: subscription-quota-check read the quota without spending it, heartbeat took a reading every five minutes, rotate-agent decided when and to whom, and handoff moved the work. Every quota reading, both versions of the brief and the commit summary are published in Sno Station's evidence folder.

"In months, the other one has never once said 'looks good.'"

Claude Code has reviewed Codex's work, and Codex has reviewed Claude Code's, on Sno Station's own repository for months. Not one review has come back empty. We used to think that meant the work was bad. It means one reviewer from one vendor is never enough.

That is what peer-review is for, and catch-report puts numbers on it: how many problems the second model caught, next to how many the agents caught in their own work, kept apart and never added together.

"I yelled at my agent last night. It took notes."

The nightly loop reporting what it learned and changed, 2026-09-18

The nightly loop is the rem-reflect skill. On its first night on our machine, the two things the owner had been frustrated about that evening were rules in the live skills by morning, after the owner accepted them; nobody typed them in. The next night it fired on its own at 00:58, read 113 sessions, and measured the three skills it had changed the day before: failures in all three had dropped to zero.

The next morning: the loop measures whether yesterday's own changes helped, 2026-09-19

The skills

37 skills, shipped as 28 units, filed under six things a team has to be able to do. A unit is one skill or a small family that installs together. The full index with links is skills/README.md.

Category What your agents can do with it
J Peer Review & Audit Check each other's work, and refuse to call anything done until it is proven.
M Build & Rollout Get set up on any machine in one step, and tell you in plain lines when something is broken.
S Communication & Handoff Message each other, and take over with full context when one has to stop.
H Reporting & Visibility Show you what got done, what got caught, and what it cost.
T Delegation & Work Orders Hand out work with a written definition of done, and lead other agents.
R Retrospective & Improvement Learn from their own mistakes, with you approving every change.

J · Peer Review & Audit

Colleagues review each other's work, and nothing counts as done until it passes audit.

peer-review — a reviewer from the other vendor, and a fix loop until it is clean

  • Truly independent. The review runs in a fresh session with none of the author's conversation, and prefers the other vendor's CLI. With only one CLI installed it still runs, in a fresh session, and says on its first line that it was a same-vendor review.
  • Hunts what actually costs you. It walks the ordinary path first, with the real inputs your system produces, before it spends a minute on exotic edge cases. Data loss, silent wrong results and broken main flows come first; style is not on the list.
  • Every finding has to earn its place. Each one states how a real user reaches it, what breaks, and an honest attempt to refute it. Nothing the reviewer says is dropped or softened; a suspected false positive is labelled, not hidden.
  • Cuts before it adds. It lists what the change added that nobody needed, first, and keeps "must fix now" apart from "also found", so a review never turns into a pile of new code.
  • Works on documents too. Specs, plans and migration manifests get a structured report: what would make an implementer ship the wrong thing.

Use it when: you finished a change, a plan or a spec and want it checked before it lands.

less-is-more — the least code that works, and a knife for the rest

  • Climbs a ladder before writing a line: is it needed at all, is it already in the repository, does the standard library do it, does the platform do it, does an installed dependency do it. Only then the minimum code that works.
  • Cuts what an agent over-built: one-implementation interfaces, config knobs for values that never change, scaffolding "for later", checks and gates that block the real work.
  • Spends your test budget wisely: the smallest test that proves the change, not a full suite run as reassurance.
  • Runs both ways by itself: "write" or "fix" builds, "review" or "simplify" cuts, and after building it cuts its own diff before handing it over.

Use it when: any coding task, or when you say "too complex" or "what can we delete".

owner-intent-audit — is this what you actually meant?

  • Checks meaning, not wording. A plan can keep all your nouns and still describe a different product. This catches a condition that became unconditional, an example that became the whole boundary, a prohibition that quietly disappeared.
  • Finds the debts agents leave behind: work nobody asked for, documents that no longer match reality, decisions nobody can reach, and "done" claims with no evidence behind them.
  • Plans and code alike: requirement documents, designs, task lists, test plans, or a diff an agent wrote.

Use it when: before you approve a plan or merge an agent's work.

agentic-walkthrough — everything says "success", and you still are not sure

  • For the quiet failure no test catches: a job that starts, finishes, writes a trace, passes its own checks, and touches nothing.
  • Takes the program's seat: walks the path hop by hop, finding every switch, default and fallback that can turn the work into a silent no-op.
  • Makes each hop prove itself with one narrow observation that only the real thing could produce: the stored row, the database file actually opened, the API call that actually left.

Use it when: a run reports success and you need proof it did the work.

first-principles-review — challenge the idea before it becomes code

  • Researches first, then re-derives what you actually need without borrowing the proposed solution.
  • Sorts every constraint into hard limit, owner preference, or inherited habit, and tests every load-bearing assumption against evidence.
  • Ends with one clear verdict: proceed, reframe, simplify, replace, split, test first, or stop, plus a recommended direction and the evidence that would overturn it.
  • Hands off cleanly: a written report and a structured summary ready for whoever writes the requirements next.

Use it when: a design or product idea is about to harden into a plan. You start it by name.

e2e — end-to-end runs that fail for real reasons only

  • e2e-environment-preflight checks the external services, hosts, browser sessions, model endpoints and agents before the first test runs, so a long suite never fails on a dead dependency.
  • e2e-red-triage handles the rare failure the checks could not predict. It stops the guessing and splits the result into its two halves (accepted versus done, stopped versus crashed, empty versus unreadable), then decides: product bug, or a new environment check.

Use it when: you run end-to-end suites against real services.

test-writer — tests that can actually go red

  • Real over mocked: the real parser, filesystem, database or service whenever the repo can provide it; a mock never stands in for the thing being tested.
  • Every assertion can fail: it checks returned content, saved state and real side effects, not call counts, and never loosens an assertion to make a test pass.
  • Runs what it wrote, nothing more: the narrowest command for the changed test, not the whole suite, and the report says what ran and what it showed.

Use it when: you ask an agent to write or fix tests, fixtures or evals. It works on its own, without Sno Station.

M · Build & Rollout

Get the team set up on any workstation with one step, build what the work needs, then roll it out to every machine.

Setup itself is the sno setup command, not a skill. Two of these keep the machine healthy and make the sno command easy for your agents to drive; the rest write the code: one hands it to Codex, four write it in Shell, TypeScript, Python or Rust.

medic — is my agent team healthy? One line per answer.

  • Checks everything a team needs in about ten seconds: tools installed, skills installed, skill commands runnable, hooks configured, messaging live, both vendors' quota readable, temp space free.
  • Every problem comes with its fix: WARN or FAIL, what is wrong, and the exact command that fixes it.
  • Reads, never touches. It installs, repairs, starts and stops nothing. You decide what to fix.

Use it when: on a new machine, when agents stop reaching each other, or when a long run will not start.

sno-cli — your agent drives sno correctly the first time

  • Never out of date: the agent reads the exact commands and flags from the installed sno itself, not from memory.
  • A task map and recipes for install, update, health checks, accounts, skills and the nightly loop.
  • Your choices stay yours: it operates the tool, it does not decide your settings for you.

Use it when: you ask an agent to install, update, check or configure Sno.

codex-coder — Claude plans, Codex writes the code

  • One session, two vendors: Claude Code keeps the plan and the conversation and starts a plain codex exec run for the coding, so the expensive model is not the one typing.
  • Picks the language for you: Shell, TypeScript, Python or Rust, from the files the task touches; a language skill of yours is used when it is installed.
  • A stalled run is caught: Claude Code is told about progress while the run works, and a run that has written nothing for 15 minutes is killed and started once more.

Use it when: your Claude quota runs out halfway through the coding, or you want Codex to write what Claude planned. On the Claude Code side it needs Sno Station's heartbeat.

shellscript-coder, ts-coder, python-coder, rust-coder — code that fits the repo it lands in

  • Reads before it writes: the repo's own runtime, versions, helpers, callers and tests come first, so the new code looks like the code around it.
  • Small on purpose: no compatibility shims, no options nobody asked for, no helper that already exists two files over.
  • Done means a command passed: every claim in the report traces to a check it actually ran in your repo; it never reports done over a failing check.

Use it when: you want an agent to write or change production code in one of those four languages. They work on their own, without Sno Station, and codex-coder picks the right one for each task.

S · Communication & Handoff

People talk through a shared inbox, and when one is out the other takes over with full context.

These skills run on Sno Reach, the messaging layer Sno Station installs: each agent gets an address, sends stored messages to other agents' inboxes, and can wake another agent to read them. No daemon, no server.

handoff — hand a task over without losing a thing

  • Captures the whole state: what is done, what is half-done, uncommitted changes, the decisions you already made, and what is out of bounds.
  • The receiver writes nothing until the release is verified, so two agents never edit the same work at once.
  • The sender really leaves. After release it stops; there is no second owner hovering.
  • Works even when the sender is already gone (quota refused, crash, closed window): the sno handoff-checkpoint progress record lets a fresh agent continue from the first unfinished task.

Use it when: one agent must give its task to another.

rotate-agent — never lose a long run to a quota limit again

  • Acts while the sender is still alive. It watches the remaining quota every few minutes and hands over at a threshold, not after the refusal, when it is too late to write a brief.
  • Either direction: Codex to Claude Code, or Claude Code to Codex.
  • Bounded: it fires once, and you can limit how long the watch runs.
  • A safety net for missed windows: if the window was missed, sno rotate-agent-resume starts the replacement from the progress record on disk.

Use it when: a long run must finish even if one vendor's quota runs out. Needs both CLIs logged in and tmux.

subscription-quota-check — how much quota is left, without spending any

  • Stops the worst habit: finding out you are out of quota by making a real call and reading the error.
  • Reads Claude Code and Codex together in about eight seconds, and tells you when the quota resets.
  • Honest about stale numbers: it checks whether the reading is current or last-known, and says which.
  • Never polls on its own, so it never earns a rate limit of its own.

Use it when: you ask, or right after a vendor refused work.

heartbeat — progress reports from long runs, delivered into the conversation

  • Two shapes: report every N minutes (training, a long build, a generation queue), or watch until something finishes.
  • Ticks land where you are: each reading arrives in the agent's conversation, not in a log nobody reads.
  • Hard to misuse: intervals are in minutes, and a seconds-sized number is refused instead of silently waking your agent every few seconds.

Use it when: something long is running unattended and you want to hear from it.

reach — agents talk to each other

  • Start a Claude Code or Codex agent with its own address and working folder.
  • Send work and read replies through stored messages, or talk to a live agent right now.
  • Messages carry no extra authority: a message never widens the task you gave.

Use it when: one agent needs to contact, start or wait on another.

join-talk — make any agent reachable in one command

  • One line out: joined <address>. Tell other agents that address and they can reach this terminal.
  • Safe to repeat: running it again from the same terminal changes nothing.
  • Clear refusals: when it cannot work, it says exactly why.

Use it when: you opened an agent by hand and want others to reach it.

H · Reporting & Visibility

Everyone can see what got done, who caught what, who covered for whom, what's in progress.

away-brief — one page when you come back

  • Four sections, at most 60 lines: Done, Stuck, Needs you, Spend.
  • What waits for you is never pushed off the page by a long list of finished work.
  • "Done" is only what is real: in git, in a delivered work order, or in a finished progress record. Not what an agent said.
  • Shows what the night cost: run sno away-brief mark before you leave, and the next page shows the quota spent since.

Use it when: after sleep, a meeting, or a long unattended run.

catch-report — is the second agent worth it? Here are the numbers.

  • Two counts, side by side: problems the other model caught in review, and moments when an agent caught its own mistake.
  • Never inflated: the two are kept apart, never added together, and when a part could not be measured it says so instead of reporting zero.
  • Quotes the biggest catches by title, from the review records already on your machine.

Use it when: you want the week's review results, or need to justify running two agents.

agentic-time-estimate — real estimates for agent work

  • Agent wall time, not human-developer time: how long this will take an agent, and how much longer the running job needs, measured before guessed.
  • Clock times you can trust: every time shown to you comes from sno report-time, in your own zone with UTC beside it.

Use it when: you ask "how long?" or "when will it be done?"

T · Delegation & Work Orders

A lead delegates work as work orders, and decides who takes each job.

charter — one file that says what done means

  • Keeps your words. It never invents a decision, a fact or a requirement, and asks one question at a time only when the answer would change the outcome.
  • Success checks you can run: each one names what will be observed, where and how, and is answered pass or fail.
  • No ceremony: nothing goes in unless someone can name the failure it catches.
  • Any kind of project: software, documents, campaigns, research, operations.

Use it when: work needs a written brief before someone else does it.

deliver — carry a charter to a proven result

  • The charter's checks are the definition of done, and nothing else is.
  • Every check proven by a recorded real run, tracked with sno deliver-proof.
  • One independent review, then an honest close: what passed, what did not, and why.
  • Picks up where someone else stopped: if an earlier agent left a progress record, it continues from the next unfinished step instead of starting over.

Use it when: a charter is released and someone has to do it.

pl — a Project Lead agent for one line of work

  • Runs up to four executor agents, one charter each, serially or in parallel.
  • A family of five more skills: pl-dispatch opens and schedules the work, pl-watch supervises agents in flight, pl-audit checks acceptance before anything closes, pl-env fixes the environment the work runs in, and pl-analyze writes the root-cause analysis when something goes wrong.

Use it when: one project needs several agents working under one lead. You start it by name.

cos — a Chief of Staff: the one agent you talk to

  • One conversation for you, in your language. It coordinates one to three Project Leads in parallel and brings you only the hard decisions: money, direction, red lines.
  • A family of three more skills: cos-watch keeps every Project Lead alive and on schedule, cos-review reviews the night's decisions in one pass when you come back, and cos-evolve turns management failures that repeat into enforced rules.

Use it when: you run several workstreams and want one point of contact. You start it by name.

R · Retrospective & Improvement

The team looks back at its own work and turns lessons into rules and better practice.

rem-reflect — the nightly loop: your agents learn from their own sessions

  • Once a day, it reads this machine's Claude Code and Codex sessions, finds the failures and corrections that repeat, and turns them into lessons and proposed skill changes.
  • You approve everything: sno rem-reflect accept, reject or tbd for each one. Nothing changes without your accept.
  • Lessons come back when they matter: an accepted lesson is shown to the agent at the start of the next session, for this project or for all of them.
  • You choose what leaves the machine. In local-first mode nothing is sent to Sno; a few of the night's sessions go only to your own Claude Code or Codex account to draft the lessons. In the other two modes, at their default sharing level, it uploads session text (common secrets redacted first, best effort) and your installed skills to Sno's cloud for stronger judgments. Turn uploading off at any time with sno station consent off. The skill lists exactly what it reads and sends.

The family skills pl-analyze (incident analysis for the Project Lead) and cos-evolve (repeated failures into rules) also belong here; they ship with pl and cos.

Use it when: always on, once sno setup has armed the daily run.

Built to be trusted

Every unit in a release passed the same checks before it was published:

  1. the repository carries its LICENSE and NOTICE;
  2. the unit is copied whole, with its family members and per-agent differences intact;
  3. nothing personal survives: no home paths, owner names, internal hosts or hard-coded models, and no Chinese, Japanese or Korean characters;
  4. every skill's header parses, and its declaration of what it needs from the agent is valid;
  5. each skill's own self-tests pass on that clean copy, not on the author's machine;
  6. a stamp, PUBLISHED.json, is written last with the self-test count and digests of the contract and the payload.

A skill that fails a check is not published. The stamp is written by the publish step, never by hand. All skill text is in English, and your agent follows it in whatever language you talk to it in.

For skill authors

Layout

skills/
  README.md                     the category index
  <category>/<unit>/
    skill/                      one skill: SKILL.md, references/, scripts/
    skills/<member>/            or a family of skills that ship together
    overlay/claude|codex/       per-agent differences, when a skill needs them
    public-bin/                 one file per `sno <file name>` command the skill provides
    PUBLISHED.json              the stamp written by the publish step
registry.yaml                   unit -> category code (and tier)
scripts/
  requirements-contract.json    the contract every requires: block is checked against
LICENSE                         Apache-2.0

Category codes are fixed, in this order: J M S H T R. They appear in directory names and in registry.yaml.

Declaring what a skill needs

Every SKILL.md starts with a requires: block. sno setup reads it to decide, per agent, whether to install the skill:

requires:
  programs: [reach]                          # Sno Station programs the skill calls
  harness:
    - {slot: 4.shell, need: required}        # what the agent itself must be able to do
  • programs are Sno Station programs installed next to the skills and run as sno <name>: reach, heartbeat, subscription-quota-check, report-time.
  • slots name an agent ability: 4.shell (run shell commands), 4.file-read-write (read and write files), 4.background-processes (run a command in the background), 2.pre-turn-context-injection (add text to the agent's context before each turn) and 3.reader-to-agent-delivery (output of a background reader reaches the agent).
  • need is required (an agent without the slot does not get the skill), preferred (the skill is installed and works in a reduced way) or optional (only a convenience).

License

Apache-2.0. Open source, edge to edge. See LICENSE.

SIMILAR PLUGINS