Merge pull request 'feat: add mmd-it marketplace + mmd-workspace plugin (4 MMD skills)' (#1) from feat/mmd-workspace-marketplace-20260806 into main

2026-08-06 14:26:16 +00:00
parent 933bd8bc14 526b14ae00
commit 899417f357
8 changed files with 293 additions and 1 deletions
@@ -0,0 +1,13 @@
 {
  "name": "mmd-it",
  "owner": {
    "name": "MMD Group IT"
  },
  "plugins": [
    {
      "name": "mmd-workspace",
      "source": "./plugins/mmd-workspace",
      "description": "MMD Group IT workspace skills for Claude Desktop: house-style documents and emails, the MMD Support ticket workflow, and safe data handling on the MMD AI gateway."
    }
  ]
 }
@@ -1,3 +1,42 @@
 # claude-plugins
-MMD Group IT Claude Desktop plugin marketplace — org-wide skills and plugin distribution. Public by design: end-user devices clone with no credential. No secrets live here.
+MMD Group IT's Claude Desktop plugin marketplace. Every MMD device with Claude Desktop
 configured for MMD's third-party inference bootstrap clones this repository and installs the
 `mmd-workspace` plugin automatically (`installationPreference: required`), giving every MMD
 user the same skills without per-device setup.
 This repository is **public and contains no secrets by design** — end-user devices clone it
 without any git credential, since MMD's internal Gitea repositories are private and devices in
 the field have none configured. Anything that needs a credential (MCP server URLs, API keys,
 tenant IDs) is delivered separately, per signed-in user, through the `managedMcpServers` field
 of the bootstrap response served at `claude-config.baobab-ts.com/user/bootstrap` — never
 through this repo. Do not add credentials, tokens, or API keys here, ever.
 ## Structure
 ```
 .claude-plugin/marketplace.json      marketplace manifest (name: mmd-it)
 plugins/mmd-workspace/
  .claude-plugin/plugin.json         plugin manifest (installationPreference: required)
  version.json                       bump this to push an update to every device
  skills/
    mmd-document-style/SKILL.md      MMD-branded Word/PDF/PowerPoint house style
    mmd-email-style/SKILL.md         MMD email conventions incl. [MMD #ticket] + helpdesk copy
    mmd-it-support/SKILL.md          how to raise/track an IT request via MMD Support (GLPI)
    mmd-data-handling/SKILL.md       what may/may not go into the assistant given MMD's gateway
 ```
 ## Rolling out an update
 1. Edit the plugin content on a feature branch, open a PR, merge to `main`.
 2. Bump `plugins/mmd-workspace/version.json`.
 3. Update the `ref` in `allowedPluginMarketplaces` (in `mmd-ops`'
   `manifests/claude-config-server/configmap.yaml`) to the new commit's full 40-character SHA —
   Claude Desktop refuses to auto-install from a branch or tag name.
 4. Push that change through `mmd-ops` (feature branch + PR + merge); ArgoCD rolls the config
   server.
 Devices pick up the new revision on next launch or plugin-settings refresh.
 See `https://claude.com/docs/third-party/claude-desktop/extensions` for the marketplace/plugin
 schema this repository follows.
@@ -0,0 +1,6 @@
 {
  "name": "mmd-workspace",
  "version": "1.0.0",
  "description": "MMD Group IT workspace skills: house-style documents and emails, the MMD Support ticket workflow, and safe data handling on the MMD AI gateway.",
  "installationPreference": "required"
 }
@@ -0,0 +1,60 @@
 ---
 name: mmd-data-handling
 description: Use before pasting, uploading, or discussing sensitive company or personal data in Claude Desktop as an MMD user, or when asked what is and isn't safe to share with the AI assistant. Triggers on "can I paste this", "is this safe to share with AI", "data handling", "confidential data in Claude", "what data can I give the assistant", or "AI policy".
 ---
 # What can go into Claude Desktop at MMD
 MMD Claude Desktop does not talk to Anthropic directly. Every request is routed through MMD's
 own AI gateway, running on MMD's own infrastructure, which sits in front of the actual model
 providers and presents them to Claude Desktop under MMD's own model labels. In practice that
 means the model actually doing the work behind a given "Claude" label in the app is not
 necessarily an Anthropic model — MMD's gateway maps some of the model tiers you see onto a
 different underlying provider's models, labelled so the experience is consistent, while still
 being routed and metered entirely through MMD's own gateway rather than a raw pass-through to
 one vendor.
 The practical consequence: treat the assistant as an MMD-operated tool sitting in front of a
 third-party model backend, not as a private, Anthropic-only channel. Apply the same judgment
 you would to any other external processor of company data — the data leaves MMD's direct
 control and is processed by a model vendor outside MMD, even though the request and the keys
 are MMD's own.
 ## Safe to use normally
 - Ordinary work drafting: documents, emails, meeting notes, summarizing something you already
  have access to, general research and writing help.
 - Company information you would already put in an ordinary internal email or document, at the
  sensitivity level appropriate to that channel.
 ## Think before pasting
 - **Credentials, API keys, tokens, passwords.** Never paste a live credential into a chat to
  "have the assistant use it" — every MMD automation pattern that needs a credential fetches it
  itself from a secured store; a credential typed into a prompt has left that store's
  protection and is now sitting in a model request.
 - **Bulk personal data about other people** (employee records, customer PII, ID numbers,
  health or financial detail) beyond what the specific task actually needs. Give the assistant
  the minimum slice required, not a whole export "just in case it's useful."
 - **Anything under legal hold, an NDA that names AI processing restrictions, or a specific
  confidentiality marking** that would already stop you from emailing it externally — if it
  wouldn't go in an external email, it should not go into a prompt either, since a prompt is
  also leaving MMD's boundary to a third-party model backend.
 - **Unreleased financial results, M&A, or similarly market-moving information** — treat the
  assistant as an external party for the purposes of information-barrier rules that already
  apply to that category of data.
 ## If you're not sure
 Ask before pasting rather than after. Sensitivity judgment calls for a specific document or
 dataset are exactly the kind of thing worth a quick check with MMD IT (see the
 `mmd-it-support` skill) rather than guessing.
 ## What NOT to do
 - Don't assume "it's just Claude, it's fine" — the routing above means that assumption doesn't
  hold at MMD; the request goes through MMD's gateway to whichever backend model is actually
  serving that tier.
 - Don't paste a secret/token to get something done faster — use the credential's own store.
 - Don't upload a full customer or employee database when a filtered extract would answer the
  question.
@@ -0,0 +1,58 @@
 ---
 name: mmd-document-style
 description: Use when writing, formatting, or reviewing any MMD / MMD Steel Group IT document meant to look official — memos, policies, status reports, audits, process docs, or anything going out under the MMD or Baobab name as a Word or PDF file. Triggers on "MMD format", "MMD branded", "MMD Word doc", "MMD report", "baobab-red", "house style", or "make this look like an MMD document".
 ---
 # MMD document house style
 MMD Steel Group IT documents follow one house style. The goal is a document that reads as
 official, dense, and quick to scan on a page — not a slide deck blown up to paper size.
 ## Type and layout
 - **Body text: 8-8.5pt.** MMD documents run small and dense. Do not default to 11-12pt body
  copy — that is web-writing habit, not this house style.
 - **Title: 12pt maximum, bold, ink-black.** Titles are not hero headlines. No title larger than
  12pt, ever, on an MMD document.
 - Prefer a serif or a clean UI serif (Aptos is the standard MMD body font) over a display
  sans for body copy — it reads better dense and small.
 - Subtitle (if any): italic, in the accent red, smaller than the title.
 - A short grey metadata block under the title works well: Prepared by / for, date, status —
  then a red rule dividing it from the body.
 ## Color
 - Accent: baobab red, `#8B1A1A`. Use it sparingly — section numbers, the title-divider rule,
  small accents. It is not a background color and not a body-text color.
 - Ink: `#1A1A1A` for headings and emphasis. Body: `#333333`. Supporting greys: `#666666` /
  `#999999`.
 - Never invent a new palette or reach for a different red. If baobab red looks wrong for a
  specific document, that is a house-style question to raise, not something to improvise
  around locally.
 ## Density and content rules
 - No dashboards, no oversized stat cards, no decorative whitespace. A working MMD document is
  a working surface, not a poster.
 - Every table should be tight: minimal row padding, real data, no placeholder or "illustrative"
  rows presented as if real.
 - Cut narration about the document itself ("this report was prepared using...", "how this
  document is organized"). State the content; do not explain the act of writing it.
 - Footer convention: `MMD Steel Group IT | CONFIDENTIAL | Your partner in steel`.
 ## Producing the file
 If a local MMD document-rendering pipeline is available in the working environment (Markdown
 in, branded `.docx`/`.pdf` out, built on the real MMD policy-document template with the logo
 header and footer baked in), prefer it over hand-building a Word document from scratch — it
 already encodes the header, footer, and color/type rules above. If no such pipeline is
 available, apply every rule in this skill by hand: 8-8.5pt body, <=12pt title, baobab red as a
 sparing accent only, dense layout, real content only.
 ## What NOT to do
 - Do not use a different brand red, a different footer line, or a heavier/larger title "for
  emphasis" — house style is fixed centrally, not per document.
 - Do not pad a short document with restated headings, a table of contents for a two-page memo,
  or decorative section dividers.
 - Do not present sample/placeholder figures as if they were real reported numbers.
@@ -0,0 +1,52 @@
 ---
 name: mmd-email-style
 description: Use when drafting or sending any email on behalf of MMD or an MMD Group IT/Support matter — acknowledgements, clarification questions, progress updates, completion messages, or anything referencing an MMD Support (GLPI) ticket. Triggers on "draft an email", "reply to this ticket", "MMD #", "helpdesk", "email the requester", or "write to the user about their request".
 ---
 # MMD email conventions
 MMD email is clean plain text, not marketing HTML, and it carries a specific ticket-reference
 and copy convention tied to MMD Support (the GLPI system at `support.baobab-ts.com`).
 ## Format
 - Clean, well-spaced **plain text**. No HTML templates, no colored boxes, no signature images.
 - Short paragraphs, real line breaks between them — not one dense block of prose.
 - No filler ("I hope this finds you well", "just circling back") and no over-explaining. State
  what happened and what, if anything, the reader needs to do.
 ## The `[MMD #ticket]` line
 When an email is about an MMD Support ticket, put the ticket reference on its own first line,
 in the exact form `[MMD #<ticket number>]` — e.g. `[MMD #368]`. This is the same marker MMD
 Support's own inbound mail bridge looks for when it turns email into a ticket (it polls the
 support inbox and creates/updates a ticket from a message carrying this marker), so using the
 real format on outbound mail keeps the thread matched to the right ticket instead of spawning
 a duplicate one.
 ## Copy MMD Support on the loop
 Acknowledgements, clarification questions, progress updates, and completion messages that
 relate to an MMD Support matter should copy `helpdesk@Fabrimetal.net` — that address is the
 outbound side of the same ticket system (GLPI relays through it), so copying it keeps the
 ticket's own record in sync with what the requester was actually told. Skip this only when the
 sender has an explicit reason not to for that specific thread.
 After sending a batch of these, it is worth a second check that MMD Support did not spawn a
 duplicate ticket from your own outbound copy landing back in the inbox — the mail bridge polls
 every few minutes, so give it one cycle before assuming the thread is clean.
 ## Signing
 Sign as whoever is actually writing. Do not adopt another identity's signature. If you are an
 AI assistant sending mail on behalf of a specific person, make that relationship explicit in
 the signature (name the assistant and who it is acting for) rather than signing as if you were
 that person, and rather than leaving the email unsigned.
 ## What NOT to do
 - Do not paste a ticket number into the subject line only and skip the `[MMD #...]` body line —
  the mail bridge keys off the body marker.
 - Do not send an MMD Support–related email without helpdesk on copy unless there is a stated
  reason for that thread.
 - Do not write long, hedged emails. State the fact, state the ask (if any), stop.
@@ -0,0 +1,63 @@
 ---
 name: mmd-it-support
 description: Use when an MMD staff member needs to raise, track, or ask about an IT request — a new PC, a broken tool, a licence, remote help, or "who do I ask about X". Triggers on "IT ticket", "raise a request", "MMD Support", "helpdesk", "is this broken for everyone", "how do I get help with", or "what will IT do remotely".
 ---
 # Getting help from MMD IT
 MMD's IT ticket system of record is **MMD Support** (GLPI, `support.baobab-ts.com`). It is not
 a chat channel or an ad-hoc email address — every real IT request should end up there as a
 ticket, because that is the only place status, history, and follow-up are tracked.
 ## How to raise a request
 Two ways in, both land in the same system:
 1. **Email `helpdesk@Fabrimetal.net`.** An inbound mail bridge polls that inbox and turns the
   message into a ticket automatically, tagging it with a `[MMD #<number>]` reference. Anyone
   replying on the thread afterwards should keep that marker in the body (see the
   `mmd-email-style` skill) so replies land on the same ticket instead of opening a new one.
 2. **Go to `support.baobab-ts.com` directly** and sign in with your normal MMD account (Entra
   single sign-on) to open a ticket, or to check status on one already open.
 Either way produces the same ticket, visible to IT, with the same tracking.
 ## What to expect back
 - A ticket gets picked up, worked, and updated on the same thread/record — not answered once
  and dropped.
 - For something IT needs to fix on your machine or account remotely, the tool is
  **MeshCentral** (`mesh.baobab-ts.com`) — remote control of an enrolled device, always
  launched *from* a ticket rather than as a cold connection. If someone claiming to be IT asks
  to remote into your machine outside of an open ticket, that is worth double-checking.
 - Device-level changes (enrolling a new PC, wiping/resetting one, pushing configuration) go
  through **Intune**, MMD's device-management platform — not through hand-editing a machine
  locally. That is a deliberate control, not a workaround to route around.
 - Identity and licence changes (new accounts, licence assignment, access to a system) go
  through MMD's account-provisioning process, tied to Entra ID — not a manual one-off grant.
 ## What IT will and won't typically do remotely
 - Will: diagnose and fix software/account issues through a ticket, using MeshCentral for
  hands-on remote control of an enrolled, managed device.
 - Will: push configuration and app changes through Intune to enrolled devices.
 - Won't: make changes to an unmanaged/unenrolled personal device the same way a managed
  corporate device gets handled — enrollment is what makes MeshCentral/Intune apply at all.
 - Won't: action account, licence, or device changes from an unverified request outside the
  ticket system — that is what the ticket record and sign-in are for.
 ## If something in the IT tool catalog looks broken
 MMD IT tracks the real, currently-verified status of every tool it runs (not just whether a
 URL returns 200) — sign-in pages, dashboards, and known-broken tools are all recorded plainly
 rather than hidden. If a link in the portal's IT section is dead or a tool errors out, that is
 worth a ticket in its own right (with the exact URL and what happened) rather than assuming
 it's a one-off.
 ## What NOT to do
 - Don't email a random personal inbox or chat message about an IT problem and expect it to be
  tracked — if it didn't become a ticket, it isn't tracked.
 - Don't ask for remote access to be granted outside of a ticket.
 - Don't try to self-serve a device wipe/re-enrollment by hand; that is Intune's job and doing
  it manually breaks the record IT relies on.
@@ -0,0 +1 @@
 {"version": "1.0.0"}