hello-xotong1

xotong1 Skills Hub — Claude Code Marketplace

Central plugin marketplace for xotong1. One URL to configure; all team and platform skills flow through here.

• Platform-verified skills: curated by the Platform Team, safe to install on any machine.
• Team skills: each team maintains a private repo inside the skillshub GitLab group; the catalog here lists them so tenants can discover and install them.
• Vendored upstream: well-known community skills (superpowers, frontend-design) pinned and audited by the Platform Team.

---

For tenants: one-time Claude Code setup

Add one entry to your ~/.claude/settings.json. If the file does not exist, create it.

{
  "extraKnownMarketplaces": {
    "xotong1-marketplace": {
      "source": {
        "source": "git",
        "url": "https://gitlab.company.com/skillshub/claude-marketplace.git"
      }
    }
  }
}

Replace gitlab.company.com with your internal GitLab hostname.

Git authentication prerequisite: Claude Code clones marketplace repos using your system git. You must have git configured to authenticate to the internal GitLab — either an SSH key registered in your GitLab profile, or a Personal Access Token stored in your macOS Keychain. If you can run git clone https://gitlab.company.com/any-repo.git in your terminal today, you are already set.

Install platform-verified skills (recommended for everyone)

/plugin install platform-verified@xotong1-marketplace
/reload-plugins

Install your team's skills

/plugin install <your-team-name>@xotong1-marketplace
/reload-plugins

Your team repo must already exist in the skillshub GitLab group and be listed in .claude-plugin/marketplace.json. See the section below if it is not yet listed.

Install community skills (vendored)

/plugin install superpowers@xotong1-marketplace
/plugin install frontend-design@xotong1-marketplace
/reload-plugins

---

For teams: create and publish your skills repo

Step 1 — Request a repo in the skillshub group

Open an issue in this repo using the title: [New team repo] <team-name>-skills. Include:

• Team name and GitLab group/subgroup path for access control
• Slack channel or contact for the Platform Team to reach you
• Brief description of what kinds of skills you plan to build

The Platform Team will create skillshub/<team-name>-skills and grant your team Developer+ access. No one outside your team will have read access to that repo.

Step 2 — Structure your repo

Your repo must follow this layout for Claude Code to recognise it as a plugin:

<team-name>-skills/
  .claude-plugin/
    plugin.json             ← required: plugin manifest
  skills/
    <skill-name>/
      SKILL.md              ← required: the skill itself
      supporting-doc.md     ← optional: referenced by SKILL.md

Minimal plugin.json:

{
  "name": "<team-name>",
  "version": "0.1.0",
  "description": "Skills for the <team-name> team.",
  "author": {
    "name": "<Team Name>"
  }
}

Bump version each time you publish a change that tenants should pull. Use semver: 0.1.0 → 0.1.1 for fixes, 0.2.0 for new skills, 1.0.0 for breaking changes.

Step 3 — Write your skills

A skill is a markdown file with a YAML frontmatter block followed by the instruction body.

skills/<skill-name>/SKILL.md template:

---
name: <skill-name>
description: >
  One to three sentences. Start with what this skill does. Then list the
  trigger phrases or situations where Claude should activate it. Be specific —
  Claude matches this description against user messages to decide whether to
  load the skill. Vague descriptions cause false positives and missed triggers.
---

# <Skill Name>

(Write the instructions Claude should follow when this skill is active.
Be explicit. Claude reads this as a system-level instruction set.)

## What to do

1. Step one.
2. Step two.

## What NOT to do

- Do not call external APIs unless the user has explicitly authorised it.
- Do not write or delete files outside the project directory.

Description field tips:

• Include example trigger phrases: "Use this skill when the user says 'deploy to staging', 'run the release pipeline', or asks to promote a build."
• Include anti-triggers if there is ambiguity: "Do NOT activate for local test runs or unit tests."
• Keep it under 200 words; Claude truncates long descriptions.

Skill dos and don'ts: