| 1 | --- |
| 2 | title: Customize |
| 3 | description: One place for what shapes how a workspace's agents work - Skills, Connectors and Plugins, each with what you have and what you can add. Everything installs in the formats Claude Code reads, so public marketplaces, plugins, skills, subagents and MCP servers work on g1t as they are, and what you customize reaches Claude Code when it runs on a g1t runner. |
| 4 | --- |
| 5 | |
| 6 | **Customize** is where a workspace shapes what its agents know, what they |
| 7 | can reach, and what they bring with them. It has three parts, each in two |
| 8 | halves: **Yours**, what the workspace has, and **Discover**, what it can |
| 9 | add. |
| 10 | |
| 11 | | Part | What it holds | |
| 12 | | --- | --- | |
| 13 | | **Skills** | What agents know how to do: g1t's [foundational skills](/guides/agent-skills/#the-foundational-skills), your workspace's [skill library](/guides/agent-skills/#the-skill-library), and every skill published in a marketplace. | |
| 14 | | **Connectors** | What agents can reach: MCP servers connected once and given to agents, and g1t's own [integrations](/guides/integrations/) (GitHub, trackers, alerts, model providers). | |
| 15 | | **Plugins** | Skills, agents and connectors published together, from any marketplace in the open plugin format. | |
| 16 | |
| 17 | Everything installable keeps the formats and the names the open ecosystem |
| 18 | uses. A marketplace is a repository with `.claude-plugin/marketplace.json`; |
| 19 | a plugin is a folder with `skills/`, `agents/`, `commands/` and `.mcp.json`; |
| 20 | a skill is a `SKILL.md` folder. g1t reads them exactly as Claude Code does |
| 21 | and invents no format of its own, so a plugin written for Claude Code |
| 22 | installs here unchanged, and what a workspace customizes reaches Claude |
| 23 | Code when it [runs on a g1t runner](#what-a-run-gets). |
| 24 | |
| 25 | Open Customize from **Apps** at the foot of the rail (the Apps page and |
| 26 | the launcher lead here), from **More** on a phone, or with |
| 27 | <kbd>Ctrl</kbd> <kbd>K</kbd> and *Customize*. Its address is |
| 28 | `g1t.sh/<workspace>/-/customize`; each part has its own, such as |
| 29 | `…/-/customize/skills`. The old `…/-/marketplace` addresses arrive here. |
| 30 | |
| 31 | ## Who adds things |
| 32 | |
| 33 | Every member of a workspace browses Customize. Only its **owners** add |
| 34 | marketplaces, install plugins, connect connectors and decide which agents |
| 35 | get what, because each of those reaches the workspace's data or spends |
| 36 | its money. Everyone else sees **Request** where an owner sees **Install** |
| 37 | or **Connect**, and asks (see [requests](#requests)). Writing and |
| 38 | importing skills stays with owners and team maintainers, as in the |
| 39 | [skill library](/guides/agent-skills/#who-can-do-what). |
| 40 | |
| 41 | Every page has a search, filters by category, by source (which |
| 42 | marketplace) and by availability, and an **Add** menu: **Write a skill**, |
| 43 | **Import**, **Add a marketplace** and **Add a connector by URL**. |
| 44 | |
| 45 | ## Skills |
| 46 | |
| 47 | **Skills → Yours** is the skill library, the same one as **Agents → |
| 48 | Skills**: g1t's foundational skills, the skills your workspace wrote, |
| 49 | imported or saved from a session, and the skills installed plugins brought. |
| 50 | Writing, importing, versions and the linked repository are in |
| 51 | [agent skills](/guides/agent-skills/). |
| 52 | |
| 53 | **Skills → Discover** lists every skill the marketplaces your workspace |
| 54 | reads publish, one card per skill, with the plugin and the marketplace it |
| 55 | comes from. Each card says whether your library has it already, and |
| 56 | whether the plugin it is in can be installed here (see |
| 57 | [what g1t can read](#where-plugins-come-from)). |
| 58 | |
| 59 | ### Add a skill from Discover |
| 60 | |
| 61 | 1. Open **Customize → Skills → Discover** and find the skill, by name or |
| 62 | by what it does. |
| 63 | 2. Choose **Add**. g1t installs the plugin that carries it, at its current |
| 64 | commit, and the plugin's skills join the library. |
| 65 | 3. Choose who gets it under **Available to**: every agent in the |
| 66 | workspace, a team (every agent on it), or one agent. This is a skill |
| 67 | [attachment](/guides/agent-skills/#the-skill-library), so the same |
| 68 | rules apply: owners attach anywhere, team maintainers on the teams they |
| 69 | maintain. |
| 70 | |
| 71 | A skill does nothing until it is available to someone. Owners can turn any |
| 72 | skill off for one agent from its **Skills** tab, as with every skill. |
| 73 | |
| 74 | ### Skills from plugins |
| 75 | |
| 76 | A skill a plugin brings is named `plugin:skill`, after the plugin's name |
| 77 | (`pdf@anthropic-agent-skills` brings `pdf:pdf`), on the library's page, on |
| 78 | each agent's Skills tab and in the agent's own instructions. Agents call it |
| 79 | with `use_skill` by that name, or by its bare name when only one plugin |
| 80 | brings a skill called that. A plain name always means the workspace's own |
| 81 | skill first. |
| 82 | |
| 83 | | | A skill written here | A skill from a plugin | |
| 84 | | --- | --- | --- | |
| 85 | | Name | Lowercase letters, digits and single hyphens, at most 64 characters; the foundational skills' names are taken | As Claude Code takes it: letters, digits, dots, underscores and hyphens, at most 64, case kept; may reuse a foundational name, since it is always called as `plugin:name` | |
| 86 | | Edited | In the editor, or from the linked repository | Read-only. It changes when the plugin is reinstalled at a newer commit, and leaves with the plugin | |
| 87 | | Size | 1 MB and 200 files | 1.5 MB and 1,000 files kept here. A larger folder keeps its text and leaves its biggest files out, binaries first, each named on the plugin's page; Claude Code on a runner gets the whole plugin | |
| 88 | | `description` | At most 1,024 characters | Kept as written; a longer one is shortened for the listing | |
| 89 | | `tools:` | Only tools agents have are accepted | Tools agents don't have are kept aside rather than refused | |
| 90 | | `commands/*.md` | — | Each command file becomes a one-file skill named after the file, its `description` (or first line) saying when to use it | |
| 91 | |
| 92 | When a plugin is **switched off**, its skills leave every agent that had |
| 93 | them at once, and come back when it is switched on. When it is |
| 94 | **uninstalled**, its skills and their attachments go. |
| 95 | |
| 96 | ## Connectors |
| 97 | |
| 98 | A **connector** is an MCP server the workspace connects once, then gives |
| 99 | to agents. **Connectors → Yours** lists the ones your workspace has, each |
| 100 | with its state and how many tools it offers, beside g1t's own integrations |
| 101 | connected here (GitHub, Linear, Jira, Sentry, Datadog, model providers and |
| 102 | the rest), which keep their own [setup pages](/guides/integrations/). |
| 103 | |
| 104 | **Connectors → Discover** is the [directory](/guides/integrations/#the-directory): |
| 105 | every tool g1t connects to, by category. A tool that publishes a remote |
| 106 | MCP server (Linear, Notion, Sentry, Stripe, Figma, Supabase, Cloudflare |
| 107 | and more) is connected from here; an integration g1t built itself |
| 108 | (trackers, alerts, model providers) opens its own page; one marked |
| 109 | **Soon** can be asked for. |
| 110 | |
| 111 | ### Where a connector comes from |
| 112 | |
| 113 | | From | How | |
| 114 | | --- | --- | |
| 115 | | **The directory** | Choose the tool and **Connect**. g1t knows its address and how it signs in. | |
| 116 | | **A plugin** | A plugin's `.mcp.json` names servers. Installing it adds each remote (`http` or `sse`) server as a connector, named *Plugin: server*, waiting for an owner to sign in or paste a key, unless it is open. A `stdio` server runs only where Claude Code runs, and is marked so. | |
| 117 | | **An address** | **Add a connector by URL**: a name (2 to 32 lowercase letters, digits and hyphens) and an HTTPS address on a public host, with how it signs in. | |
| 118 | |
| 119 | Two connectors with the same name get numbered. A workspace keeps at most |
| 120 | 50. |
| 121 | |
| 122 | ### Signing in |
| 123 | |
| 124 | Each connector signs in the way its server asks. A directory card says |
| 125 | which, and anything to know first, such as where a key comes from: |
| 126 | |
| 127 | | Sign-in | What happens | |
| 128 | | --- | --- | |
| 129 | | **Browser** | OAuth. g1t finds the server's authorization server from the server's own metadata, registers itself as a client there when the server allows it, and sends you to sign in; the sign-in uses PKCE and comes back to g1t with a code, which g1t exchanges for tokens. Tokens are kept sealed and renewed before they expire. A sign-in that takes more than 15 minutes is started again. | |
| 130 | | **Key** | A key an owner pastes, sent as a header (`Authorization` unless the server names another). The key is kept sealed and never shown again. | |
| 131 | | **Open** | The server needs nothing. | |
| 132 | |
| 133 | A server that doesn't register clients on its own can't be signed in with |
| 134 | the browser from g1t; when it takes a key instead, add it by address with |
| 135 | a key. A server that answers a sign-in with `401` or `403` is marked, and |
| 136 | the connector asks to be signed in again or for its key to be checked. |
| 137 | |
| 138 | #### What each directory server needs |
| 139 | |
| 140 | | Sign-in | Servers | |
| 141 | | --- | --- | |
| 142 | | **Browser**, with g1t registering itself as a client | Atlassian, Canva, Cloudflare, Figma, Hugging Face, Intercom, Linear, Neon, Notion, PayPal, PostHog, Sentry, Stripe, Supabase and Vercel | |
| 143 | | **Browser**, but only for apps registered with them | Asana and HubSpot. g1t isn't registered with them yet, so signing in from here fails until it is; their cards say so | |
| 144 | | **Key** | GitHub's MCP server (a personal access token) and Zapier (the token from its MCP settings), each pasted as `Bearer <token>` | |
| 145 | | **Open** | Cloudflare docs, Context7, DeepWiki and Microsoft Learn | |
| 146 | |
| 147 | A server that speaks only the older event-stream transport isn't listed |
| 148 | until it serves the current one. |
| 149 | |
| 150 | On g1t.sh the sealing key is set. On a g1t you run yourself, the agents |
| 151 | service's `CONNECTORS_KEY` seals connectors' keys and tokens; without it, |
| 152 | open servers work and nothing that signs in can be kept. See |
| 153 | [run g1t yourself](/guides/self-hosting/). |
| 154 | |
| 155 | ### States |
| 156 | |
| 157 | | State | What it means | |
| 158 | | --- | --- | |
| 159 | | **Connected** | Its tools were listed and agents that have it can use them. | |
| 160 | | **Needs sign-in** | A browser sign-in hasn't been done, or was signed out. | |
| 161 | | **Needs a key** | A key hasn't been pasted yet. | |
| 162 | | **Problem** | Its last check or renewal failed; the connector says why. **List its tools again** checks again. | |
| 163 | |
| 164 | Only a connected connector reaches agents. One in any other state is |
| 165 | listed, with what it needs, and gives agents nothing until it is fixed. |
| 166 | |
| 167 | ### Tools and what agents may do with them |
| 168 | |
| 169 | When a connector connects, g1t lists the server's tools and keeps the |
| 170 | first 40. Each becomes an ability on every agent that has the connector, |
| 171 | offered as `<connector>__<tool>`, with the arguments the server |
| 172 | describes, under the same [levels](/guides/agent-abilities/#the-levels) |
| 173 | as every ability: |
| 174 | |
| 175 | - a tool the server marks read-only is a **read**, Alone by default; |
| 176 | - any other tool, including one the server says nothing about, is a |
| 177 | **write outside g1t**, Ask first by default: the agent posts a card |
| 178 | saying what it would do, and waits for Allow or Deny. |
| 179 | |
| 180 | A call carries the connector's sign-in. If the sign-in can't be renewed, |
| 181 | the agent is told that an owner needs to sign the connector in again, and |
| 182 | the connector shows **Problem**. Levels, Ask-first cards and the |
| 183 | [audit log](/guides/audit-log/) work exactly as for an agent's own MCP |
| 184 | servers. |
| 185 | |
| 186 | ### Who gets a connector |
| 187 | |
| 188 | A connector reaches agents through **grants**, which work like a skill's |
| 189 | attachments. Open the connector and choose **Give to**: |
| 190 | |
| 191 | | Give to | Who gets it | Who can | |
| 192 | | --- | --- | --- | |
| 193 | | Every agent in the workspace | Every agent, `@g1t` included | Owners | |
| 194 | | A team | Every agent on the team | Owners | |
| 195 | | One agent | That agent | Owners | |
| 196 | |
| 197 | The same grant twice is one. An agent's **Abilities** tab lists each |
| 198 | connector that reaches it under **Connectors**, with how it has it (every |
| 199 | agent, a team, this agent) and a level for each tool, beside the MCP |
| 200 | servers added to that agent alone, marked **Only this agent**. See |
| 201 | [agent abilities](/guides/agent-abilities/#connectors). |
| 202 | |
| 203 | ### Manage a connector |
| 204 | |
| 205 | On a connector's page, owners can: |
| 206 | |
| 207 | - **List its tools again**, to pick up a server that changed, or to check |
| 208 | one that showed a problem. |
| 209 | - **Sign out** (browser sign-ins): the tokens go, and the connector needs a |
| 210 | sign-in again. **Replace the key** (keys): the new key is sealed and the |
| 211 | tools listed again. |
| 212 | - **Take back** a grant, or **Remove** the connector, which removes every |
| 213 | grant with it. Uninstalling a plugin removes the connectors it brought. |
| 214 | |
| 215 | Adding, keying, signing in and out, granting, taking back and removing a |
| 216 | connector are in the audit log under `customize/connectors/<name>`. |
| 217 | |
| 218 | ## Plugins |
| 219 | |
| 220 | A **plugin** is a folder in the open plugin format, listed in a |
| 221 | **marketplace**. Installing one spreads its parts to where g1t's agents use |
| 222 | them, and keeps the rest for Claude Code on a runner. |
| 223 | |
| 224 | ### Marketplaces |
| 225 | |
| 226 | Every workspace starts with three marketplaces, built in, kept current by |
| 227 | g1t and not removable: |
| 228 | |
| 229 | | Marketplace | What it lists | |
| 230 | | --- | --- | |
| 231 | | `claude-plugins-official` | Anthropic's reviewed plugins: tools, connectors and skills from Anthropic and the companies behind them. | |
| 232 | | `anthropic-agent-skills` | Anthropic's skills: documents, spreadsheets, presentations, PDFs, design, testing and more. | |
| 233 | | `g1t` | g1t's own plugins: what g1t is building for what a team does besides code (see [what g1t is building](#what-g1t-is-building)). | |
| 234 | |
| 235 | Owners add more with **Add a marketplace**, from **Plugins** or |
| 236 | `…/-/customize/marketplaces`, in the forms Claude Code's |
| 237 | `plugin marketplace add` takes: |
| 238 | |
| 239 | | Type | Read as | |
| 240 | | --- | --- | |
| 241 | | `owner/repo`, `owner/repo#ref` or `owner/repo@ref` | A public repository on GitHub, or a repository on this g1t when `owner/repo` names one you can read | |
| 242 | | A `github.com` address, with or without `.git` or `/tree/<ref>` | The same repository on GitHub | |
| 243 | | A git address on this g1t | The repository here | |
| 244 | | A link ending in `marketplace.json` | That file alone. Plugins it lists by a relative path can't be reached this way, so add such a marketplace by its repository instead | |
| 245 | |
| 246 | The marketplace is named as its `marketplace.json` names itself, unless |
| 247 | you give another name. Names Claude Code keeps for its own marketplaces |
| 248 | (and `g1t`) are refused, so `name@claude-plugins-official` always means |
| 249 | the real thing. A workspace reads at most 20 marketplaces of its own; a |
| 250 | `marketplace.json` is at most 4 MB. |
| 251 | |
| 252 | A marketplace's manifest is read when it is added, again when it is older |
| 253 | than six hours and someone opens Discover, and on **Read it again**. |
| 254 | When it can't be read, the marketplace stays listed with the problem, so |
| 255 | it can be read again later. **Remove** takes a marketplace off the |
| 256 | workspace; plugins installed from it stay installed. |
| 257 | |
| 258 | ### Where plugins come from |
| 259 | |
| 260 | Each plugin entry in a marketplace says where its files are (Claude Code's |
| 261 | `source`). g1t reads some of those places and not others: |
| 262 | |
| 263 | | Source | On g1t | |
| 264 | | --- | --- | |
| 265 | | A relative path inside the marketplace's repository | Read, when the marketplace is on GitHub or on this g1t | |
| 266 | | `github` (`owner/repo`, with a `ref` or a `sha`) | Read: public repositories, at the commit the ref names | |
| 267 | | `url` or `git-subdir` on github.com or on this g1t | Read | |
| 268 | | `archive` (a zip over HTTPS, with an optional `sha256`) | Read; the checksum is checked when given | |
| 269 | | `npm` | Listed as **Not available here**: g1t doesn't install from npm yet. It still works in Claude Code | |
| 270 | | `command` | Listed as **Not available here**: it is produced by a command on the installing machine, which g1t can't run. It still works in Claude Code | |
| 271 | | A git host other than GitHub or this g1t | Listed as **Not available here** | |
| 272 | |
| 273 | Private GitHub repositories aren't read yet. A plugin read here holds at |
| 274 | most 2,000 files and 24 MB together; a file over 2 MB is left out and |
| 275 | named on the plugin's page. Claude Code on a runner fetches the plugin |
| 276 | whole for itself, so nothing is lost there. |
| 277 | |
| 278 | ### Discover and a plugin's page |
| 279 | |
| 280 | **Plugins → Discover** lists every plugin every marketplace lists, by |
| 281 | category, each with its availability: |
| 282 | |
| 283 | | Availability | What it means | |
| 284 | | --- | --- | |
| 285 | | **Available** | Installable now. Owners see **Install**; everyone else **Request**. | |
| 286 | | **Installed**, or **Switched off** | The workspace has it. | |
| 287 | | **Not available here** | g1t can't fetch it, with why (above). | |
| 288 | | **Soon** | g1t's own, announced but not released. Nothing can be pressed. | |
| 289 | |
| 290 | A plugin's page, `…/-/customize/plugins/<name@marketplace>`, shows its |
| 291 | README, its marketplace and who owns it, its manifest (name, version, |
| 292 | license, repository), and what it brings: skills, agents, commands, MCP |
| 293 | servers, and whether it carries hooks, LSP servers, output styles or |
| 294 | `bin/`. Anything that couldn't be read is listed too. |
| 295 | |
| 296 | ### Install a plugin |
| 297 | |
| 298 | 1. Open the plugin's page and choose **Install**. Owners only. |
| 299 | 2. g1t fetches the plugin at a **pinned commit**: the commit the |
| 300 | marketplace's `sha` or `ref` names, or the head it is at now. The |
| 301 | install remembers that commit; the plugin never changes under you. |
| 302 | 3. Each part goes where g1t's agents use it: |
| 303 | |
| 304 | | In the plugin | Becomes | |
| 305 | | --- | --- | |
| 306 | | `skills/<name>/SKILL.md` | A library skill, `plugin:name`, read-only, ready to be made available to agents | |
| 307 | | `commands/<name>.md` | A one-file skill, `plugin:name` | |
| 308 | | `agents/<name>.md` | A template under **Agents → Templates → From plugins**, to [hire an agent from](/guides/agents/#role-templates) | |
| 309 | | `.mcp.json` servers of type `http` or `sse` | A connector each, waiting for an owner to sign in or paste a key | |
| 310 | | `.mcp.json` servers of type `stdio` | Marked **Claude Code only**; nothing on g1t's agents | |
| 311 | | `hooks/hooks.json`, `.lsp.json`, `output-styles/`, `bin/` | Kept for Claude Code on a runner, which fetches the plugin whole at the same commit | |
| 312 | |
| 313 | The plugin's files aren't copied into g1t beyond its skills and |
| 314 | subagents. A runner fetches them when a job runs (see |
| 315 | [what a run gets](#what-a-run-gets)). |
| 316 | |
| 317 | ### Switch off, uninstall and update |
| 318 | |
| 319 | | | | |
| 320 | | --- | --- | |
| 321 | | **Switch off** | The kill switch. The plugin's skills leave every agent at once, its agents leave Templates, and runners stop getting it. **Switch on** brings them back. | |
| 322 | | **Uninstall** | Its skills and their attachments go, and the connectors it brought are removed. The record of who installed and removed it stays. | |
| 323 | | **Update available** | Its marketplace lists a newer version or commit than the one installed. An install never moves on its own: to take the update, uninstall the plugin and install it again, then make its skills available again. | |
| 324 | |
| 325 | A workspace installs at most 100 plugins. Installing, switching on and |
| 326 | off and uninstalling are in the audit log under |
| 327 | `customize/plugins/<name@marketplace>`, and adding or removing a |
| 328 | marketplace under `customize/marketplaces/<name>`. |
| 329 | |
| 330 | ### What g1t is building |
| 331 | |
| 332 | g1t's own marketplace, `g1t`, is where g1t's own plugins are listed as |
| 333 | they are released. The ones announced are marked **Soon** and can't be |
| 334 | installed until their first release: |
| 335 | |
| 336 | | Plugin | What it adds | |
| 337 | | --- | --- | |
| 338 | | **Mail** | Email on your own domain, with shared inboxes agents work in. | |
| 339 | | **Support** | Conversations, escalations, macros and a knowledge base; bug reports become issues in Code. | |
| 340 | | **CRM** | Accounts, deals by stage and a forecast, kept current by agents. | |
| 341 | | **Recruiting** | Openings, candidates, scorecards and interview loops. Agents screen; people decide. | |
| 342 | | **On-call** | Rotations, pages and incidents. | |
| 343 | | **Helpdesk bridge**, **CRM bridge**, **ERP bridge** | Each bridges a system your team already runs, so agents work across it and g1t together. Anything that changes money or stock waits for a person. | |
| 344 | |
| 345 | ## The formats |
| 346 | |
| 347 | g1t reads the files below exactly as Claude Code does, and ignores keys it |
| 348 | doesn't know, so a plugin never needs a g1t version. Paths are inside the |
| 349 | repository or the plugin's folder. |
| 350 | |
| 351 | ### `.claude-plugin/marketplace.json` |
| 352 | |
| 353 | | Key | Required | What it is | |
| 354 | | --- | --- | --- | |
| 355 | | `name` | Yes | The marketplace's name: letters, digits, `.`, `_` and `-`, starting with a letter or digit, at most 64. Plugins are `name@marketplace` by it. | |
| 356 | | `owner` | Yes | `{ "name", "email", "url" }`, or a name alone. | |
| 357 | | `plugins` | Yes | The plugins it lists (below). An entry that can't be read is noted, not refused, and the others are listed. | |
| 358 | | `description`, `version` | No | Shown on the marketplace. `metadata.description` and `metadata.version` are read too. | |
| 359 | | `metadata.pluginRoot` | No | The folder bare plugin paths resolve under. | |
| 360 | |
| 361 | Each entry in `plugins`: |
| 362 | |
| 363 | | Key | Required | What it is | |
| 364 | | --- | --- | --- | |
| 365 | | `name` | Yes | The plugin's name, like `pr-review-toolkit`: letters, digits, `.`, `_` and `-`, at most 64. Listed once per marketplace. | |
| 366 | | `source` | Yes | A relative path (`./plugins/pdf`), or an object: `{ "source": "github", "repo", "ref", "sha" }`, `url`, `git-subdir` (`url`, `path`), `archive` (`url`, `sha256`), `npm` (`package`, `version`), `command` (`command`). See [where plugins come from](#where-plugins-come-from). | |
| 367 | | `description`, `version`, `author`, `homepage`, `repository`, `license`, `keywords`, `category`, `tags`, `displayName` | No | Shown on the card and the page. | |
| 368 | | `skills`, `commands`, `agents` | No | Component paths, added to the plugin's standard folders. A skills-only plugin that names its skills here is listed in Discover's Skills without being fetched. | |
| 369 | | `mcpServers` | No | Servers, in `.mcp.json`'s shape, for a plugin without a `plugin.json`. | |
| 370 | | `strict` | No | `false` means the entry names its components outright and the standard folders aren't read, as a marketplace that keeps many plugins in one repository does. | |
| 371 | |
| 372 | ### `.claude-plugin/plugin.json` and the plugin's layout |
| 373 | |
| 374 | `plugin.json` is optional: a folder with the layout alone is a plugin, and |
| 375 | only `name` is required when the file is there. |
| 376 | |
| 377 | | Key | What it is | |
| 378 | | --- | --- | |
| 379 | | `name` | The plugin's name, as above. | |
| 380 | | `displayName`, `version`, `description`, `author`, `homepage`, `repository`, `license`, `keywords` | Shown on the page. | |
| 381 | | `skills`, `commands`, `agents`, `hooks` | Component paths besides the standard folders (`./` is kept off; `.` is the root). | |
| 382 | | `mcpServers` | Servers inline, in `.mcp.json`'s shape, or a path to a file holding them. | |
| 383 | | `lspServers` | Whether it brings LSP servers (Claude Code only). | |
| 384 | |
| 385 | | In the folder | What g1t does with it | |
| 386 | | --- | --- | |
| 387 | | `skills/<name>/SKILL.md` | A skill each | |
| 388 | | `commands/*.md` | A one-file skill each | |
| 389 | | `agents/*.md` | A hireable template each | |
| 390 | | `.mcp.json` | Connectors (remote servers) | |
| 391 | | `hooks/hooks.json`, `.lsp.json`, `output-styles/`, `bin/` | Kept for Claude Code on a runner | |
| 392 | | `README.md` | Shown on the plugin's page | |
| 393 | |
| 394 | ### `SKILL.md` |
| 395 | |
| 396 | The [skill format](/guides/agent-skills/#the-skill-format), unchanged: |
| 397 | YAML front-matter, then the instructions. |
| 398 | |
| 399 | | Key | Required | What it is | |
| 400 | | --- | --- | --- | |
| 401 | | `name` | Yes (for a plugin's skill, the folder's name when absent) | The skill's name. | |
| 402 | | `description` | Yes | When to use it, at most 1,024 characters. | |
| 403 | | `license`, `compatibility`, `metadata`, `allowed-tools` | No | Kept as written; change nothing. | |
| 404 | | `tools` | No | g1t's own key: the agent tools the skill uses. | |
| 405 | | `requires_computer` | No | g1t's own key: `true` when the skill needs the agent's own computer. | |
| 406 | |
| 407 | ### `agents/<name>.md` |
| 408 | |
| 409 | A subagent file: front-matter, then the system prompt as the body. Both |
| 410 | `name` and `description` are required, and the body can't be empty. |
| 411 | |
| 412 | | Key | What it is | On g1t | |
| 413 | | --- | --- | --- | |
| 414 | | `name` | At most 256 characters, no colon, not starting with a hyphen | The template's name, `plugin:name` | |
| 415 | | `description` | When to use it | The template's description | |
| 416 | | `model` | The model it prefers | Kept with the template, for the agent's model limits | |
| 417 | | `tools`, `disallowedTools` | Claude Code's or MCP tool names, as a list or separated by commas | Kept with the template; g1t's agents use g1t's own tools and abilities | |
| 418 | | `skills`, `mcpServers`, `color` | Skills to preload, servers it uses, its colour | Kept as written | |
| 419 | | The body | The system prompt | The agent's instructions when you hire from it | |
| 420 | |
| 421 | ### `.mcp.json` |
| 422 | |
| 423 | ```json |
| 424 | { |
| 425 | "mcpServers": { |
| 426 | "linear": { "type": "http", "url": "https://mcp.linear.app/mcp" }, |
| 427 | "search": { "type": "sse", "url": "https://example.com/sse", "headers": { "Authorization": "Bearer ${SEARCH_KEY}" } }, |
| 428 | "local": { "command": "npx", "args": ["-y", "some-server"] } |
| 429 | } |
| 430 | } |
| 431 | ``` |
| 432 | |
| 433 | | Server | On g1t | |
| 434 | | --- | --- | |
| 435 | | `type: http` (or `streamable-http`) or `sse`, with a `url` | A connector. One whose `url` or `headers` reference a `${VARIABLE}` asks for a key; one without asks for a browser sign-in. | |
| 436 | | `type: stdio`, or a `command` with no type | Claude Code only. | |
| 437 | | A `url` with no `type` | Noted as a problem: a remote server says its type. | |
| 438 | | `ws`, `sdk` | Not a connector. | |
| 439 | |
| 440 | A server's name is letters, digits, dots, underscores and hyphens, at |
| 441 | most 64. |
| 442 | |
| 443 | ## Requests |
| 444 | |
| 445 | Anyone who isn't an owner asks for what they need from the same place an |
| 446 | owner would add it: |
| 447 | |
| 448 | 1. Choose **Request** on a plugin, a skill from Discover, or a connector. |
| 449 | 2. Check what you are asking for: the dialog shows where it comes from and |
| 450 | that it is available. |
| 451 | 3. Say why you want it, if you like (280 characters), and choose |
| 452 | **Send request**. |
| 453 | |
| 454 | Every owner is notified. The button then reads **Requested**, and **Your |
| 455 | requests** lists it until an owner answers; you are notified when one does. |
| 456 | You can't ask twice for the same thing while a request is waiting, and you |
| 457 | can have 20 waiting at once. |
| 458 | |
| 459 | Owners answer requests from **Requests** in Customize's header, at |
| 460 | `…/-/customize/requests`, which shows how many are waiting: |
| 461 | |
| 462 | | | | |
| 463 | | --- | --- | |
| 464 | | **Install** or **Connect** | Opens where it is added. Installing a plugin, or signing a connector in, answers every request for it by itself. | |
| 465 | | **Mark added** | After you added it another way. | |
| 466 | | **Turn down** | The person who asked is told. They can ask again. | |
| 467 | |
| 468 | Answered requests stay listed for 30 days. A request names its listing as |
| 469 | `plugin:<name@marketplace>`, `skill:<name@marketplace>/<skill>`, |
| 470 | `connector:<id>` (from the directory) or `integration:<id>` (one of g1t's |
| 471 | own integrations). When an agent needs a connector or an integration that |
| 472 | isn't connected, it posts a **Request** card in the conversation that |
| 473 | opens the same request (see |
| 474 | [when something is missing](/guides/agent-abilities/#when-something-is-missing)). |
| 475 | Open requests also appear on owners' |
| 476 | [Home](/guides/home/#where-youre-needed). |
| 477 | |
| 478 | ## What a run gets |
| 479 | |
| 480 | When Claude Code runs a job on a [g1t runner](/guides/self-hosted-runners/), |
| 481 | it is given what the workspace customized, as the job's agent would have |
| 482 | it: every installed plugin that is switched on, to fetch at its pinned |
| 483 | commit; the library's own skills that reach the agent, as files; and the |
| 484 | connected connectors that reach it, with what signs them in. The runner |
| 485 | writes the plugins to disk and starts Claude Code with each as a plugin |
| 486 | directory, puts the skills where it reads them, and merges the connectors |
| 487 | into its MCP configuration. See |
| 488 | [plugins and skills on runners](/guides/self-hosted-runners/#plugins-and-skills-on-runners). |
| 489 | |
| 490 | Chat replies and [sessions](/guides/agent-sessions/) on g1t get the same |
| 491 | things in their own way: skills through `use_skill`, connectors as |
| 492 | abilities with levels. |
| 493 | |
| 494 | ## API |
| 495 | |
| 496 | Customize is in the REST API under `/workspaces/{workspace}/customize/…` |
| 497 | and in the MCP server as the `customize` tool, one action per thing an |
| 498 | owner does here: marketplaces, Discover, plugins and installs, connectors |
| 499 | with their sign-ins and grants. Reading needs `workspace:read`; adding, |
| 500 | installing, connecting and granting need `workspace:admin`, as a person |
| 501 | who owns the workspace. The bundle a runner reads, |
| 502 | `GET /workspaces/{workspace}/customize/bundle`, needs `agents:run` and is |
| 503 | read with a job's agent token, since it carries the connectors' sign-ins. |
| 504 | See the [MCP tools](/reference/mcp/) and the [API reference](/reference/api/). |
| 505 | |
| 506 | ## Next |
| 507 | |
| 508 | - [Agent skills](/guides/agent-skills/): the library, the skill format, versions and the linked repository. |
| 509 | - [Agent abilities](/guides/agent-abilities/): the levels every connector's tools run under. |
| 510 | - [Agents](/guides/agents/): hiring an agent from a plugin's template. |
| 511 | - [Self-hosted runners](/guides/self-hosted-runners/): where what you customize reaches Claude Code. |