Add SHD MCP plugin package

2026-08-24 16:51:12 +05:00
parent ce6e619731
commit 39fb5c02b7
15 changed files with 426 additions and 0 deletions
@@ -0,0 +1,20 @@
 {
  "name": "shd-public",
  "interface": {
    "displayName": "SHD Public Plugins"
  },
  "plugins": [
    {
      "name": "shd-mcp-plugin",
      "source": {
        "source": "local",
        "path": "./plugins/shd-mcp-plugin"
      },
      "policy": {
        "installation": "AVAILABLE",
        "authentication": "ON_INSTALL"
      },
      "category": "Productivity"
    }
  ]
 }
@@ -0,0 +1,7 @@
 .env
 .env.*
 !.env.example
 .DS_Store
 .idea/
 .vscode/
 *.log
@@ -0,0 +1,37 @@
 SHD MCP PLUGIN LICENSE
 Copyright (c) 2026 SHD
 This license applies to the SHD MCP Plugin package, its Skills, manifests,
 documentation and SHD branding in this repository. The SHD MCP service and
 its backend are separate systems and remain subject to their own terms.
 1. Permission
 SHD grants a limited, non-exclusive, non-transferable permission to install and
 use an unmodified copy of this plugin with an authorized SHD account and a
 compatible MCP client.
 2. Restrictions
 Unless SHD gives prior written permission, you may not sell, sublicense,
 redistribute, publish modified versions of, remove notices from, or use this
 package and its branding to provide a competing service. Public access to this
 repository does not transfer copyright, trademark or other intellectual
 property rights.
 3. No credentials or access grant
 This package contains no access token and grants no access to SHD data. Access
 is controlled by SHD authentication, organization membership and server-side
 permissions.
 4. Warranty and liability
 The package is provided "as is" to the maximum extent permitted by law,
 without warranties of any kind. SHD is not liable for indirect, incidental or
 consequential damages arising from its use.
 5. Third-party materials
 Third-party software and assets, if any, remain subject to their own licenses.
@@ -0,0 +1,43 @@
 {
  "name": "shd-mcp-plugin",
  "version": "0.1.0",
  "description": "Ready-to-install SHD workflows backed by the authenticated SHD MCP server.",
  "author": {
    "name": "SHD",
    "url": "https://shd.xyz.su"
  },
  "homepage": "https://shd.xyz.su",
  "repository": "https://github.com/bulava92/shd-mcp-plugin",
  "license": "Proprietary",
  "keywords": [
    "SHD",
    "projects",
    "ProjectBase",
    "tasks",
    "finance",
    "CRM",
    "MCP"
  ],
  "skills": "./skills/",
  "interface": {
    "displayName": "SHD MCP",
    "shortDescription": "SHD projects and operations",
    "longDescription": "Installable SHD MCP workflows for project status, ProjectBase audits, tasks, files, finance, CRM and safe operational workflows.",
    "developerName": "SHD",
    "category": "Productivity",
    "capabilities": [
      "Read",
      "Write"
    ],
    "websiteURL": "https://shd.xyz.su",
    "brandColor": "#1E88E5",
    "composerIcon": "./assets/logo.png",
    "logo": "./assets/logo.png",
    "defaultPrompt": [
      "Покажи активные проекты с датой завершения и статусом.",
      "Сделай сводку по проекту и его рискам.",
      "Проверь ProjectBase без изменения данных."
    ]
  },
  "mcpServers": "./.mcp.json"
 }
@@ -0,0 +1,9 @@
 {
  "mcpServers": {
    "shd": {
      "type": "http",
      "url": "https://shd.xyz.su/mcp",
      "oauth_resource": "https://shd.xyz.su/mcp"
    }
  }
 }
@@ -0,0 +1,28 @@
 # SHD MCP plugin package
 This directory is the installable Codex plugin. It packages reusable SHD
 workflow Skills and the official SHD MCP connection; it does not contain the
 SHD backend or a second MCP server.
 The plugin requires an SHD account authorized for the requested projects and
 modules. Skills do not grant permissions or bypass server-side ACLs.
 ## Included workflows
 - active projects with completion dates and statuses;
 - project status and risk summaries;
 - ProjectBase schema and data-quality audits;
 - guarded task workflows;
 - project file inspection and actions;
 - finance and CRM read/audit workflows;
 - safe bulk-change planning and validation rules.
 ## MCP connection
 The package points to `https://shd.xyz.su/mcp` and requests OAuth for that MCP
 resource. The client stores the resulting authorization; this repository never
 contains an access token.
 If a client or SHD installation uses another official endpoint, change the
 connection in `.mcp.json` in that client's secure configuration. Do not commit
 tokens, cookies, client secrets or private host credentials.
@@ -0,0 +1,33 @@
 ---
 name: shd-active-projects
 description: Use when the user asks for all active SHD projects, project deadlines, project statuses, or a project register sorted by the nearest completion date.
 ---
 # Active SHD projects
 ## Workflow
 1. Call `shd_list_projects` once with `archived: false` and `limit: 100`.
 2. If the user supplied a search term, pass it as `q`; otherwise do not add a
   search filter.
 3. Use the project fields returned by that tool. Do not call
   `shd_get_project` once per row just to repeat list data.
 4. Sort projects with a non-null `deadline` in ascending order. Put projects
   without a deadline after dated projects; do not invent a date.
 5. Return the compact table:
   `Проект | Дата завершения | Статус`
 6. Preserve the server's project name/code and status. If a deadline is a
   datetime, format it with its returned timezone when available; otherwise
   keep the value unmodified and state that timezone data was unavailable.
 ## Boundaries
 - “Активные” defaults to non-archived projects (`archived: false`). If the user
  means a particular business status rather than archive state, ask which
  status or report the returned statuses without filtering them locally.
 - Do not use task due dates as project completion dates.
 - If the server indicates more records than the tool can return, report that
  the current tool limit was reached; do not claim a complete list.
 - This workflow is read-only and must not update, archive or delete projects.
@@ -0,0 +1,35 @@
 ---
 name: shd-finance-crm
 description: Use when the user asks for finance or CRM information, document/payment checks, customer records, deals, relationships, or a project business overview in SHD.
 ---
 # SHD Finance and CRM
 For a high-level project overview, prefer `shd_get_project_context` and request
 only the `finance` or `summary` sections needed. For a detailed request use
 the module tools below.
 ## Finance
 - Find documents with `shd_list_finance_documents`.
 - Read one with `shd_get_finance_document`.
 - Read payments with `shd_list_finance_payments` or
  `shd_get_finance_payment`.
 - Resolve allowed references with `shd_list_finance_refs`.
 When auditing, compare document type, project/counterparty links, line items,
 currency, totals, due dates, payment state and returned validation. Never infer
 approval, payment or publication from a document's title or amount.
 ## CRM
 - Find entities with `shd_list_crm` and read one with `shd_get_crm_entity`.
 - Resolve relationships with `shd_list_crm_entity_links` and inspect available
  pipelines/stages before a deal change.
 - Use `shd_save_crm_entity` only for an explicitly requested create/update after
  duplicate and relationship checks.
 Do not approve, publish, delete, merge, move a deal stage, create a payment or
 change ownership unless the user explicitly requests that exact operation.
 Report IDs, resolved links, changed fields and server validation separately from
 recommendations.
@@ -0,0 +1,37 @@
 ---
 name: shd-project-db-audit
 description: Use when the user asks to inspect ProjectBase tables, validate project data, find duplicate or broken links, or audit ProjectBase quality without changing records.
 ---
 # ProjectBase audit
 ## Workflow
 1. Resolve the canonical Base identity. A supplied `project_code` is accepted
   as the legacy alias only when the server accepts it; prefer the returned
   Base identity for subsequent calls.
 2. If no table is named, call `shd_project_db_tables` first and select only the
   relevant tables. Do not load every table by default.
 3. Call `shd_project_db_schema` for each selected table before reading its
   records. Pass the table explicitly when a single-table audit is requested.
 4. Call `shd_project_db_records` with bounded reads and the selected table.
 5. Compare records with the returned schema and report only evidence visible in
   the response.
 ## Findings
 Check for duplicate business numbers, missing required values, invalid select
 values, unresolved linked records, orphaned references, conflicting DALI or
 electrical identifiers, formula/derived-field risks and incomplete source data
 when the selected tables expose those fields.
 Report `table → record → field → observed value → reason → priority`. Distinguish
 confirmed defects from data that could not be checked because the schema or
 records were unavailable.
 ## Safety
 This workflow is read-only. Do not call create, update, delete, import, bulk
 upsert or generic action tools while auditing. If the user asks to repair
 findings, first present the proposed records and then use the dedicated
 validation/dry-run contract before any explicit write.
@@ -0,0 +1,28 @@
 ---
 name: shd-project-files
 description: Use when the user asks to inspect project files, obtain a file link, share or zip a file, rename or move a path, or delete project files.
 ---
 # SHD project files
 ## Resolve paths
 1. Call `shd_list_files` with the exact `project_code` and, when supplied, the
   path.
 2. Resolve the exact file or directory path and distinguish files from
   directories before any action.
 3. Use `shd_get_file_link` only when the user asks for a temporary file link or
   download.
 ## Actions
 `shd_create_file_action` supports the explicit actions `share-link`, `zip-link`,
 `rename`, `move` and `delete`. Use the exact action matching the request. For
 rename, move and delete, confirm the source/destination and replacement scope
 from the current listing first. Mutating actions require a stable
 `idempotency_key`; delete additionally requires `confirm: true` and the server
 version/confirmation fields accepted by its schema.
 Do not expose bearer tokens or raw secret material in prose or logs. Return a
 temporary URL only when the user explicitly asks for it. Do not overwrite,
 publish, share or delete a path merely because the user asked to inspect it.
@@ -0,0 +1,39 @@
 ---
 name: shd-project-status
 description: Use when the user asks for a status report, operational summary, risks, blockers, next actions, or a cross-module overview of one SHD project.
 ---
 # SHD project status
 ## Resolve the project
 - If the user supplied an exact project code, use it directly.
 - If the user supplied only a name, call `shd_list_projects` with `q` once,
  choose only an unambiguous exact match, and ask for the project code when
  multiple projects match.
 ## Read the context
 For a full summary call `shd_get_project_context` with the resolved
 `project_code`, `include` set to the requested sections, and
 `limit_per_section: 100`. The available sections are:
 `summary`, `tasks`, `discussions`, `documents`, `finance`, `terms`, `agents`.
 Request only the sections needed for a narrow question. Do not pretend that a
 section is empty when the server reported it unavailable or the user lacks
 access.
 ## Report
 Separate the result into:
 - confirmed project state;
 - current deadlines or status values returned by SHD;
 - blockers and risks supported by retrieved records;
 - next actions, clearly marked as recommendations;
 - unavailable or unresolved sections.
 Do not convert a task deadline into a project deadline, infer a completion date
 from activity, or claim deployment success from a status field. This workflow is
 read-only unless the user separately requests a specific change.
@@ -0,0 +1,45 @@
 ---
 name: shd-routing
 description: Use for any request that asks SHD for data, a project operation, a module workflow, or a change to SHD records. Route the request to the narrowest existing SHD MCP tool and preserve server-side permissions.
 ---
 # SHD routing and safety
 SHD MCP is the source of truth for live data, tool schemas, permissions,
 organization/project scope, conflicts, idempotency, audit and persisted
 readback. Do not invent fields, statuses, identifiers, routes or capabilities.
 ## Route the request
 - Project list, project status, deadlines or project context: use the Projects
  Core tools and the `shd-active-projects` or `shd-project-status` workflow.
 - ProjectBase schema, records, links or data quality: use Project DB tools and
  the `shd-project-db-audit` workflow.
 - Tasks, task projects, task status or task dates: use Tasks tools and the
  `shd-task-workflow` workflow.
 - Project files and paths: use Files tools and the `shd-project-files` workflow.
 - Finance or CRM records: use the specific module tools and the
  `shd-finance-crm` workflow; use project context for a high-level overview.
 - A multi-record change: use `shd-safe-bulk-change` before any mutation.
 Use `shd_capabilities` only when the available module or permission boundary is
 unclear. If a tool or module is unavailable, report that fact instead of
 falling back to an undocumented endpoint.
 ## Read-first rule
 For every write, first read the target and its relevant schema or metadata.
 Only perform a mutation when the user explicitly requested that mutation. A
 request to inspect, summarize, compare, audit or suggest is not permission to
 write.
 Preserve the exact server result. Separate confirmed values from inference,
 and include affected identifiers, conflicts, validation errors and final
 readback when the server returns them.
 ## Scope and secrets
 Never ask for or expose access tokens, passwords, cookies, private keys, raw
 public-link bearer tokens or integration secrets. Never use a user-provided
 project name as an identifier when SHD has not resolved it to a returned
 project code or ID.
@@ -0,0 +1,28 @@
 ---
 name: shd-safe-bulk-change
 description: Use before any SHD bulk create, update, import, archive, delete, or other multi-record mutation, and whenever the user asks to plan a mass change.
 ---
 # Safe SHD bulk changes
 ## Plan first
 1. Confirm the target module, organization/project scope, exact match rule and
   intended side effect.
 2. Read current schemas and records. Estimate affected, skipped, invalid and
   ambiguous rows.
 3. Prefer a server validation or dry-run operation. For ProjectBase use
   `shd_project_db_validate_records`, then
   `shd_project_db_bulk_create_records` or
   `shd_project_db_bulk_upsert_records` with `dry_run: true` when applicable.
 4. Present the plan and stop unless the user explicitly authorized execution.
 ## Execute safely
 Use stable idempotency keys, expected versions and exact match fields accepted
 by the selected tool. Do not silently widen a project, organization, table or
 record filter. Do not convert a failed or conflicting row into a new record.
 After execution, report created, updated, skipped, rejected and conflicted
 rows, then use the server's persisted readback when available. Destructive
 operations require explicit confirmation and remain subject to server ACL.
@@ -0,0 +1,37 @@
 ---
 name: shd-task-workflow
 description: Use when the user asks to find, inspect, create, update, reschedule, archive, or delete SHD tasks or task-project data.
 ---
 # SHD task workflow
 ## Read and resolve
 - Use `shd_list_task_projects` when the request concerns a task project or its
  status.
 - Use `shd_list_tasks` with `project_code`, `project_id`, `q`, `archived`,
  `limit` or `offset` to find tasks.
 - Use `shd_get_task` for one resolved task and
  `shd_get_task_project_meta` for statuses, tags, sprints, views and custom
  fields.
 - Read comments or attachments only when they are relevant to the request.
 Do not create a task from an ambiguous project name or duplicate a task that
 already matches the request.
 ## Mutations
 Only mutate when the user explicitly asks for the exact operation:
 - create with `shd_create_task`;
 - update fields with `shd_update_task`;
 - change status with `shd_update_task_status`;
 - archive with `shd_archive_task`;
 - delete with `shd_delete_task` and the server's explicit confirmation contract.
 Before updating, pass the latest `updated_at` when the tool accepts it. Use an
 idempotency key when the tool schema accepts one. If the server reports a
 conflict, stop and show the current state; do not overwrite it by guessing.
 Report the task ID, changed fields, server validation, conflict state and final
 status. Never treat a suggested change as authorization to execute it.