Skills — the playbook library

Sonderr ships with a library of 65 skill playbooks — compact markdown procedures that encode how good work gets done, from designing an API to surviving a 72-hour task. This page explains what skills are, when they load, what’s in the library, and how to add your own. Nothing here is configuration you must babysit; it’s the part of Sonderr that makes the agent read the manual for exactly this situation.

1 · What a skill is

Each skill is a single .md file in the runtime’s skills/ directory — a focused playbook with the same structure every time: when the skill applies, the professional rules to follow while doing the work, and the definition of done that decides when it’s finished. Skills are not prompts-in-a-costume; they’re the distilled checklists of crafts. frontend-polish knows what a polished interface is supposed to satisfy. release-verification knows what must be true before a version ships. The agent that has them loaded behaves like someone who has done this before.

The library ships with a manifest (skills/_manifest.json) that counts and describes every playbook, so the runtime always knows what’s available without scanning the directory on every turn.

2 · When skills load

Skills are matched to the current task, not dumped into every conversation. Working through the runtime’s task guidance, the agent checks the shape of what you asked — wiring sessions, touching a database schema, producing release notes — and the matching playbooks are surfaced into context at the moment they matter. You don’t invoke them; there is nothing to remember. The practical effect is that the same request gets different, sharper handling depending on what it is: asking for an API gets api-design discipline; asking for a game gets game-development; asking for a poster gets the brand and craft rules.

This is also one of the quiet levers behind v1.7’s workflow release: the plan-act-verify loop assumes relevant skills load automatically at each phase, so the verification skill arrives exactly when verification starts.

3 · The library, grouped

• Build & code — api-design, api-contracts, api-integration, auth-system, node-backend, react-patterns, frontend-polish, error-handling, debugging, performance-profiling, refactor-clean, project-scaffolding, migration-upgrade, accessibility.
• Craft & content — brand-system, landing-copy, slide-decks, technical-writing, sonderr-docs, audio-experience, game-design, game-development, data-viz.
• Data — data-analysis, data-modeling, sql-queries, spreadsheets, regex-toolkit, web-scraping.
• Ops & release — ci-cd, docker-deploy, git-workflow, dependency-audit, incident-response, observability, release-notes, release-verification, documentation-maintenance, repo-audit, code-review, unit-tests, integration-testing, test-and-verify.
• Safety & trust — security-review, threat-modeling, privacy-redaction, email-safety, prompt-safety, wallet-safety, secure-integrations.
• Long work & method — long-running-work, task-resumption, prompt-design, developer-coaching, performance-review, contribution-workflow, shell-scripting, python-tooling.
• Web3 & integrations — web3-earning, wallet-intelligence, trading-research, faucet-claim, mcp-integration, mcp-workflows.

4 · Three worth reading yourself

long-running-work — how a U-tier marathon stays honest: milestone-sized slices, new evidence every pass, checkpointing an honest pause instead of inventing filler. It’s the playbook behind the 72-hour budgets. code-review — the review stance Sonderr takes on your diffs: what gets flagged, what merely gets noted, and why tone matters as much as findings. security-review — the pass that treats every new input path as hostile until shown otherwise; the same discipline that hardened the runtime itself.

5 · Adding your own

A skill is just markdown. Drop a .md file into the skills/ directory of your install with the same shape the built-ins use — when this applies, rules, definition of done — and keep the filename as the skill id (my-deploy-runbook.md → my-deploy-runbook). House conventions, org-specific checklists, a client’s style guide: anything you’d brief a new teammate on belongs here. Update the manifest count so the runtime sees it, and the playbook rides along like every other skill.

6 · Skills vs. modes vs. access

Three different dials, easy to blur. Task modes (Ask / Plan / Build / Vision) decide what the agent is allowed to do this turn. Tools & Access decides which tool schemas exist at all. Skills decide how well the allowed work gets done — they add discipline, never permission. A skill can’t write a file in Ask mode and can’t conjure a wallet tool into an access level that excludes it; it can only make the work it’s given noticeably better.