Skip to main content
You can build three things for other people to install: agents, skills, and extensions. A GitHub repository containing any of them is a package, and a person installs it by pasting its link into Rundock.

​
Which one am I building?

One question decides it.
  • Does it add teammates or abilities? That is an agent or a skill. You are sharing knowledge, judgement, or a way of working.
  • Does it change how a file looks or behaves? That is an extension. You are adding a way of seeing something.
  • Both? One repository carries both. Somebody pastes one link and gets your extension and your agents together.
Build your view from Rundock UI, the components Rundock puts into every extension: buttons, tabs, tables, boards and more, already in Rundock’s look. If you find yourself rebuilding something Rundock has that is not there, such as a sidebar or a chat panel, stop and tell us. That is usually a sign Rundock has not exposed something it should have.

​
Agents and skills are content

Agents and skills are ordinary markdown files. When someone installs them they land in that person’s workspace, in the same .claude/agents/ and .claude/skills/ folders as the agents and skills they wrote themselves, and they become theirs. They can open your agent, disagree with a line and change it. That is what they are for. That has two consequences worth knowing before you start:
  • Uninstalling removes only what is still as you shipped it. A person can uninstall your package from the Packages page. Each agent and skill that is exactly as installed goes; anything they edited, and every starter file, stays theirs.
  • Updates are offered, and their edits are kept. When you tag a new release, it is offered as an update from the package’s card. Whatever the person changed is kept, and your new version of it is saved beside it for them to review. Nothing is pushed into their workspace without their say-so.
Write for that. You are giving someone a starting point they will edit. Agents and skills are not sandboxed. Once added, they act with the same access the person’s own agents have, and the install screen says so. See Share agents and skills.

​
An extension is code

An extension changes how a file opens. Rundock already works this way internally: a markdown file with kanban-plugin in its frontmatter opens as a board instead of text. That is a renderer, and an extension is the same idea written by someone else. Your extension declares which files it can display, such as every .csv file, or only the markdown files carrying a frontmatter key you name. Somebody opens one of those files and gets your view instead of the plain one, drawn with Rundock’s own components. A note can also name other files for your view to be handed, which is how a dashboard over several files is built, and your view can draft a message to one of the person’s agents for them to send. Extensions stay yours. They install from a tag or an exact commit of your repository, never a branch, and are updated and uninstalled with their package. Your code runs in a sandbox, so it can do less than you might expect. Read What an extension cannot do before you write any of it. It is the page most likely to save you a weekend.

​
When you need a manifest

A manifest is a file called rundock.json at the root of your repository. Agents and skills need no manifest. A repository with .claude/agents/*.md and .claude/skills/*/SKILL.md already says everything Rundock needs. So a repository that was never built for Rundock still installs: somebody pastes the link and Rundock tells them how many agents and skills it found, then asks before adding anything. You may still add a rundock.json with just name, version and displayName, to give the package the name people see. An extension always needs one, because an entry point and a match rule are things you claim rather than things Rundock can read off the disk. A repository without a valid manifest has no extension to install, whatever else it carries. See the rundock.json reference.

​
What a package looks like

A package carrying both halves:
Leave out rundock.json and view/ and you have a package of agents and skills. Leave out .claude/ and starter/ and you have an extension. Starter files are files your agents or your view work on, such as a portfolio, added only where the person has nothing at that path and theirs from then on: see Ship starter files.

​
What happens when someone installs it

They paste your repository link into Settings, under Packages, and see what is in the box before anything is written. The screen splits by what can be undone:
  • What will run. Your extension, sandboxed, removable later.
  • What you will keep. Your agents, skills and starter files, theirs to edit.
Rundock reads that list from your package, not from anything you say about it. You cannot describe your extension as doing less than it does. See Install a package for the whole flow as the person installing it sees it.

​
Examples to learn from

Each of these installs from its link in Settings, Packages, and each is small enough to read before you do.
  • Rundock package starter: a template repository with a team package and a team that brings its own view, a checker that reads a package the way Rundock will, and tests.
  • Lean Agent Team: agents and skills only, no code, with a routine.
  • CSV Viewer: an extension in one file, that draws every .csv file as a table.
  • Investment Partner: a full package: a dashboard built from Rundock UI, three agents, skills and starter notes.

​
Where to next

Share agents and skills

Repository structure, writing agents that travel well, and what happens on import.

Build an extension

A working extension in one file, and how to test it locally.

Rundock UI

The components Rundock gives every extension view.

What an extension cannot do

The sandbox’s limits, stated up front so you build something that works.

Publish and get listed

Tag a release and list your package in the Directory.