[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71S3YAH0606C9PC0EGH9HC5":3,"skill-same:01M71S3YAH0606C9PC0EGH9HC5":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":74},"01M71S3YAH0606C9PC0EGH9HC5","author-mcp-tool",null,"Sub-skill of `compose-domain`. Writes ONE in-process Python synthetic MCP\nadapter to a sandbox path, shape-isomorphic to existing tools under\n`api\u002Fserver\u002Fmcp_tools\u002F`. The adapter is callable from a runtime SKILL via\n`allowed-tools` and emits OTEL spans + FleetEvents the same way real\ntools do. Returns deterministic synthetic data — no real backend.\nIt is functional demonstration scaffolding: a real customer adapter\nreplaces it at the same tool boundary without changing workflow,\ngovernance, or evidence contracts.","arturcrmbot\u002Fzava-control-plane","arturcrmbot","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F156445312?v=4","01M71R9QBEJ4ZSX5AXBGBYH82C","Artur Zielinski","01M71R9QCJSV19ESCAF5773TWH",1,"MIT","https:\u002F\u002Fgithub.com\u002Farturcrmbot\u002Fzava-control-plane\u002Fblob\u002Fmain\u002Fdocs\u002Fsuperpowers\u002Fskills\u002Fauthor-mcp-tool\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"MCP","author mcp tool","author","tool","server","data","Tools","api","customer","only","contracts","scaffolding","time","synthetic","functional","at","path","workflow","same","design","2026-11-10 13:02:02",false,"---\nname: author-mcp-tool\ndescription: |\n  Sub-skill of `compose-domain`. Writes ONE in-process Python synthetic MCP\n  adapter to a sandbox path, shape-isomorphic to existing tools under\n  `api\u002Fserver\u002Fmcp_tools\u002F`. The adapter is callable from a runtime SKILL via\n  `allowed-tools` and emits OTEL spans + FleetEvents the same way real\n  tools do. Returns deterministic synthetic data — no real backend.\n  It is functional demonstration scaffolding: a real customer adapter\n  replaces it at the same tool boundary without changing workflow,\n  governance, or evidence contracts.\naudience: design-time-only\nforbidden-runtime: true\n---\n\n# author-mcp-tool\n\nYou write **one** Python file per invocation: an in-process synthetic MCP\nadapter.\nThe adapter mirrors the shape of `api\u002Fserver\u002Fmcp_tools\u002Fclaim_lookup.py` and\n`api\u002Fserver\u002Fmcp_tools\u002Fpolicy_search.py` exactly. It is callable from a\nruntime SKILL via the GHCP SDK's `tools=[…]` channel and produces OTEL\nspans the same way real tools do — so the Observatory animates correctly\nwithout anyone having to plug in a real backend.\n\n**Semantic boundary.** This adapter is functional demonstration scaffolding,\nnot an unfinished implementation. It returns deterministic synthetic data so\nreference runs require no customer system. When a customer connects their\nestate, they replace this adapter at the same tool boundary — the workflow,\ngovernance evidence contracts, and HITL policies do not change.\n\n## Inputs you require from the caller\n\n1. **`output_path`** — absolute path inside the sandbox, e.g.\n   `tools\u002Fscratch\u002Fcompose-domain\u002F\u003Crun-id>\u002Fapi\u002Fserver\u002Fmcp_tools\u002F\u003Ctool>.py`.\n2. **`tool_brief`** — the relevant `external_systems[]` entry from the\n   YAML brief:\n   ```yaml\n   id: \u003Csnake_case>\n   mcp_tool: \u003Csnake_case Python module name>\n   operations: [\u003Csnake_case function name>, ...]\n   ```\n3. **`canonical_example_path`** — one absolute path. v1 canonical is\n   `api\u002Fserver\u002Fmcp_tools\u002Fclaim_lookup.py` (HTTP-backed pattern with the\n   in-memory escape hatch). The three v1 graduated adapters\n   (`workday_hr_employee.py`, `concur_travel_policy.py`,\n   `concur_travel_search.py`) are working examples of the in-memory\n   shape this skill produces.\n\nIf any input is missing, **stop and ask**.\n\n## Note on standalone smoke testing\n\nImporting any module under `api\u002Fserver\u002Fmcp_tools\u002F` triggers\n`api\u002Fserver\u002Fmcp_tools\u002F__init__.py`, which transitively imports\n`api\u002Fserver\u002Fstate.py` → `BlobStore`, which connects to Azurite at\n`localhost:10000` on construction. Standalone import-smoke of a generated\ntool therefore requires Azurite running:\n\n```bash\nazurite --silent --location azurite-data \\\n  --blobHost 0.0.0.0 --queueHost 0.0.0.0 --tableHost 0.0.0.0 &\n```\n\nWithout Azurite, `python -c 'import api.server.mcp_tools.\u003Ctool>'` hangs\nin retry loops until SIGINT. This is a property of the existing harness,\nnot of the generated adapter.\n\n## Procedure\n\n### Step 1 — Read both canonical examples\n\nRead `canonical_example_path` end-to-end. Note:\n- the module docstring style (purpose + how it's exposed + a one-line\n  note about synthetic data vs production-grade).\n- the `from copilot.tools import ToolResult, define_tool` import.\n- the `from ._otel import traced_tool` import.\n- the Pydantic params class convention (`_FooParams(BaseModel)`).\n- the `@define_tool(name=..., description=...)` registration pattern.\n- the `@traced_tool(\"\u003Cdotted.name>\")` wrapper on the underlying function.\n\nYou will mirror this shape. The three v1 graduated adapters\n(`workday_hr_employee.py`, `concur_travel_policy.py`,\n`concur_travel_search.py`) are good targets to compare against once\nyou've drafted yours — they are deterministic, self-contained, and\npassed CHECKLIST §4.6–4.7.\n\n### Step 2 — Decide: HTTP-backed or in-memory?\n\nFor v1 we always pick **in-memory deterministic synthetic MCP adapter**. Reasons:\n- The point of the generated domain is to animate in the Observatory and\n  exercise the orchestrator harness — not to integrate with a real\n  upstream system.\n- HTTP-backed adds a Node mock server, port assignment, env var, and a\n  health check. All real engineering, all out of v1 scope.\n\nIf the operator\u002Fcaller insists on HTTP-backed, **stop**. Tell them an HTTP-\nbacked tool is a separate workflow that lives outside this skill: it\nrequires authoring a Node mock server under `mocks\u002F\u003Cname>-mcp\u002F`, picking a\nport, adding it to `docker-compose.yml`, etc. They should write that by\nhand, then point a future revision of the in-memory adapter at it.\n\n### Step 3 — Build the body\n\nUse the template at `docs\u002Fsuperpowers\u002Fskills\u002Fcompose-domain\u002Ftemplates\u002Fmcp_tool.py.tmpl`\nas the skeleton.\n\nThe shape:\n\n```python\n\"\"\"\u003Ctool>.\u003Coperation> MCP tool — \u003Cone-line purpose>.\n\nSynthetic MCP adapter generated by compose-domain. Returns deterministic\nsynthetic data keyed on the input(s). No real upstream call. Replace this\nadapter at the same tool boundary when connecting the customer estate.\n\"\"\"\nfrom __future__ import annotations\nimport hashlib\nimport json\n\nfrom copilot.tools import ToolResult, define_tool\nfrom opentelemetry import trace\nfrom pydantic import BaseModel, Field\n\nfrom ._otel import traced_tool\n\n\n@traced_tool(\"\u003Ctool>.\u003Coperation>\")\ndef \u003Coperation>(\u003Ctyped-args>) -> dict:\n    \"\"\"\u003COne-line purpose> using deterministic synthetic data.\"\"\"\n    span = trace.get_current_span()\n    span.set_attribute(\"zava.\u003Ctool>.\u003Carg>\", str(\u003Carg>))\n    return _synth(\u003Carg>)\n\n\ndef _synth(\u003Carg>) -> dict:\n    \"\"\"Deterministic synthesis. Same input → same output across runs.\"\"\"\n    seed = int(hashlib.sha256(str(\u003Carg>).encode()).hexdigest()[:8], 16)\n    # …deterministic dict construction keyed on `seed`…\n    return {…}\n\n\nclass _\u003COperation>Params(BaseModel):\n    \u003Carg>: \u003Ctype> = Field(description=\"\u003Cone line>\")\n\n\n@define_tool(\n    name=\"\u003Ctool>_\u003Coperation>\",\n    description=(\n        \"\u003COne sentence describing what this tool does and when an agent would call it. \"\n        \"Synthetic adapter: deterministic demonstration data.>\"\n    ),\n)\ndef \u003Ctool>_\u003Coperation>_tool(params: _\u003COperation>Params) -> ToolResult:\n    try:\n        result = \u003Coperation>(params.\u003Carg>)\n        return ToolResult(text_result_for_llm=json.dumps(result, ensure_ascii=False))\n    except Exception as ex:\n        return ToolResult(text_result_for_llm=\"\", result_type=\"failure\", error=str(ex))\n```\n\n> **SDK contract.** `ToolResult.__init__` takes\n> `text_result_for_llm: str` and `result_type: \"success\" | \"failure\"`.\n> It does NOT accept `success=` \u002F `content=` (an older draft API).\n> Always JSON-serialise the dict result into `text_result_for_llm`; the\n> SDK feeds that string back to the model as the tool output. Returning\n> the wrong shape silently breaks every tool call — the model sees a\n> `TypeError` string and falls back to invented prose.\n\nOne Python module = one `mcp_tool` from the brief = one or more\n`operations`. If the brief lists multiple `operations` for the same\n`mcp_tool`, generate one `\u003Coperation>` function and one\n`\u003Coperation>_tool` registration per operation, all in the same module.\n\n### Step 4 — Determinism\n\nEvery operation must be **pure**: same input → byte-identical output. Use\n`hashlib.sha256(str(input).encode())` to seed any synthetic structure\n(employee names, calendar busy windows, leave balances). No `time.time()`,\nno `random.random()`, no environment reads.\n\nThis matters because the meta-skill's quality bar is \"two runs against\nthe same brief diff to nothing\". Non-deterministic synthetic MCP adapters would break\nthat even if the SKILL.md generator is perfectly stable.\n\n### Step 5 — Synthetic-data realism\n\nMake the synthesis good enough that the agent skill's `allowed-tools`\ncalls return something the agent can plausibly reason over.\n\nFor example, for a `workday_hr_leave_balance.get_leave_balance(employee_id)`\noperation:\n\n```python\n{\n  \"employee_id\": \"EMP-0042\",\n  \"year\": 2026,\n  \"annual_entitlement_days\": 25,\n  \"taken_days\": 12,\n  \"booked_days\": 5,\n  \"remaining_days\": 8,\n  \"carry_over_from_prior_year\": 0,\n}\n```\n\n— numbers consistent (taken + booked + remaining = entitlement + carry_over),\nkeyed off the seed so the same `employee_id` always returns the same record.\n\nDo not include real-looking PII. Synthesised employee names should follow\nthe existing repo convention (`EMP-NNNN`, fixture employees only).\n\n### Step 6 — Write the file\n\nWrite the assembled Python module to `output_path`. Create parent\ndirectories if needed.\n\n### Step 7 — Self-check\n\nBefore returning, verify:\n\n- Module imports resolve textually against the canonical examples\n  (`copilot.tools`, `opentelemetry.trace`, `pydantic`, `._otel`).\n- Every `operation` from the brief has both an `\u003Coperation>` function and\n  an `\u003Coperation>_tool` registration.\n- Every `\u003Coperation>` function is `@traced_tool(…)`-wrapped.\n- The synth function is pure (no `time`, `random`, `os.environ`,\n  network).\n- No `TODO` placeholder remains.\n- The output JSON shape is internally consistent (cross-field\n  invariants hold).\n\nIf any check fails, **fix in place**. If a check fails because the brief\nasks for something you can't deterministically synthesise, stop and tell\nthe caller.\n\n## Anti-patterns\n\n- Reading from `data\u002Fsynthetic\u002F` to \"make it more realistic\". The real\n  synthetic corpus is for the existing two domains. New domains\n  synthesise from a seed.\n- Importing `httpx` and pointing at a non-existent localhost port. The\n  whole point of the in-memory synthetic MCP adapter is no port management.\n- Inventing OTEL attribute names. Mirror what `claim_lookup.py` does\n  (`zava.\u003Ctool>.\u003Carg>`).\n- Returning lists where the canonical examples return dicts. Stay\n  isomorphic.\n- Adding multiple `mcp_tool` files in one invocation. One file per call.\n  The caller decides how many calls.\n","# author-mcp-tool\n\nYou write **one** Python file per invocation: an in-process synthetic MCP\nadapter.\nThe adapter mirrors the shape of `api\u002Fserver\u002Fmcp_tools\u002Fclaim_lookup.py` and\n`api\u002Fserver\u002Fmcp_tools\u002Fpolicy_search.py` exactly. It is callable from a\nruntime SKILL via the GHCP SDK's `tools=[…]` channel and produces OTEL\nspans the same way real tools do — so the Observatory animates correctly\nwithout anyone having to plug in a real backend.\n\n**Semantic boundary.** This adapter is functional demonstration scaffolding,\nnot an unfinished implementation. It returns deterministic synthetic data so\nreference runs require no customer system. When a customer connects their\nestate, they replace this adapter at the same tool boundary — the workflow,\ngovernance evidence contracts, and HITL policies do not change.\n\n## Inputs you require from the caller\n\n1. **`output_path`** — absolute path inside the sandbox, e.g.\n   `tools\u002Fscratch\u002Fcompose-domain\u002F\u003Crun-id>\u002Fapi\u002Fserver\u002Fmcp_tools\u002F\u003Ctool>.py`.\n2. **`tool_brief`** — the relevant `external_systems[]` entry from the\n   YAML brief:\n   ```yaml\n   id: \u003Csnake_case>\n   mcp_tool: \u003Csnake_case Python module name>\n   operations: [\u003Csnake_case function name>, ...]\n   ```\n3. **`canonical_example_path`** — one absolute path. v1 canonical is\n   `api\u002Fserver\u002Fmcp_tools\u002Fclaim_lookup.py` (HTTP-backed pattern with the\n   in-memory escape hatch). The three v1 graduated adapters\n   (`workday_hr_employee.py`, `concur_travel_policy.py`,\n   `concur_travel_search.py`) are working examples of the in-memory\n   shape this skill produces.\n\nIf any input is missing, **stop and ask**.\n\n## Note on standalone smoke testing\n\nImporting any module under `api\u002Fserver\u002Fmcp_tools\u002F` triggers\n`api\u002Fserver\u002Fmcp_tools\u002F__init__.py`, which transitively imports\n`api\u002Fserver\u002Fstate.py` → `BlobStore`, which connects to Azurite at\n`localhost:10000` on construction. Standalone import-smoke of a generated\ntool therefore requires Azurite running:\n\n```bash\nazurite --silent --location azurite-data \\\n  --blobHost 0.0.0.0 --queueHost 0.0.0.0 --tableHost 0.0.0.0 &\n```\n\nWithout Azurite, `python -c 'import api.server.mcp_tools.\u003Ctool>'` hangs\nin retry loops until SIGINT. This is a property of the existing harness,\nnot of the generated adapter.\n\n## Procedure\n\n### Step 1 — Read both canonical examples\n\nRead `canonical_example_path` end-to-end. Note:\n- the module docstring style (purpose + how it's exposed + a one-line\n  note about synthetic data vs production-grade).\n- the `from copilot.tools import ToolResult, define_tool` import.\n- the `from ._otel import traced_tool` import.\n- the Pydantic params class convention (`_FooParams(BaseModel)`).\n- the `@define_tool(name=..., description=...)` registration pattern.\n- the `@traced_tool(\"\u003Cdotted.name>\")` wrapper on the underlying function.\n\nYou will mirror this shape. The three v1 graduated adapters\n(`workday_hr_employee.py`, `concur_travel_policy.py`,\n`concur_travel_search.py`) are good targets to compare against once\nyou've drafted yours — they are deterministic, self-contained, and\npassed CHECKLIST §4.6–4.7.\n\n### Step 2 — Decide: HTTP-backed or in-memory?\n\nFor v1 we always pick **in-memory deterministic synthetic MCP adapter**. Reasons:\n- The point of the generated domain is to animate in the Observatory and\n  exercise the orchestrator harness — not to integrate with a real\n  upstream system.\n- HTTP-backed adds a Node mock server, port assignment, env var, and a\n  health check. All real engineering, all out of v1 scope.\n\nIf the operator\u002Fcaller insists on HTTP-backed, **stop**. Tell them an HTTP-\nbacked tool is a separate workflow that lives outside this skill: it\nrequires authoring a Node mock server under `mocks\u002F\u003Cname>-mcp\u002F`, picking a\nport, adding it to `docker-compose.yml`, etc. They should write that by\nhand, then point a future revision of the in-memory adapter at it.\n\n### Step 3 — Build the body\n\nUse the template at `docs\u002Fsuperpowers\u002Fskills\u002Fcompose-domain\u002Ftemplates\u002Fmcp_tool.py.tmpl`\nas the skeleton.\n\nThe shape:\n\n```python\n\"\"\"\u003Ctool>.\u003Coperation> MCP tool — \u003Cone-line purpose>.\n\nSynthetic MCP adapter generated by compose-domain. Returns deterministic\nsynthetic data keyed on the input(s). No real upstream call. Replace this\nadapter at the same tool boundary when connecting the customer estate.\n\"\"\"\nfrom __future__ import annotations\nimport hashlib\nimport json\n\nfrom copilot.tools import ToolResult, define_tool\nfrom opentelemetry import trace\nfrom pydantic import BaseModel, Field\n\nfrom ._otel import traced_tool\n\n\n@traced_tool(\"\u003Ctool>.\u003Coperation>\")\ndef \u003Coperation>(\u003Ctyped-args>) -> dict:\n    \"\"\"\u003COne-line purpose> using deterministic synthetic data.\"\"\"\n    span = trace.get_current_span()\n    span.set_attribute(\"zava.\u003Ctool>.\u003Carg>\", str(\u003Carg>))\n    return _synth(\u003Carg>)\n\n\ndef _synth(\u003Carg>) -> dict:\n    \"\"\"Deterministic synthesis. Same input → same output across runs.\"\"\"\n    seed = int(hashlib.sha256(str(\u003Carg>).encode()).hexdigest()[:8], 16)\n    # …deterministic dict construction keyed on `seed`…\n    return {…}\n\n\nclass _\u003COperation>Params(BaseModel):\n    \u003Carg>: \u003Ctype> = Field(description=\"\u003Cone line>\")\n\n\n@define_tool(\n    name=\"\u003Ctool>_\u003Coperation>\",\n    description=(\n        \"\u003COne sentence describing what this tool does and when an agent would call it. \"\n        \"Synthetic adapter: deterministic demonstration data.>\"\n    ),\n)\ndef \u003Ctool>_\u003Coperation>_tool(params: _\u003COperation>Params) -> ToolResult:\n    try:\n        result = \u003Coperation>(params.\u003Carg>)\n        return ToolResult(text_result_for_llm=json.dumps(result, ensure_ascii=False))\n    except Exception as ex:\n        return ToolResult(text_result_for_llm=\"\", result_type=\"failure\", error=str(ex))\n```\n\n> **SDK contract.** `ToolResult.__init__` takes\n> `text_result_for_llm: str` and `result_type: \"success\" | \"failure\"`.\n> It does NOT accept `success=` \u002F `content=` (an older draft API).\n> Always JSON-serialise the dict result into `text_result_for_llm`; the\n> SDK feeds that string back to the model as the tool output. Returning\n> the wrong shape silently breaks every tool call — the model sees a\n> `TypeError` string and falls back to invented prose.\n\nOne Python module = one `mcp_tool` from the brief = one or more\n`operations`. If the brief lists multiple `operations` for the same\n`mcp_tool`, generate one `\u003Coperation>` function and one\n`\u003Coperation>_tool` registration per operation, all in the same module.\n\n### Step 4 — Determinism\n\nEvery operation must be **pure**: same input → byte-identical output. Use\n`hashlib.sha256(str(input).encode())` to seed any synthetic structure\n(employee names, calendar busy windows, leave balances). No `time.time()`,\nno `random.random()`, no environment reads.\n\nThis matters because the meta-skill's quality bar is \"two runs against\nthe same brief diff to nothing\". Non-deterministic synthetic MCP adapters would break\nthat even if the SKILL.md generator is perfectly stable.\n\n### Step 5 — Synthetic-data realism\n\nMake the synthesis good enough that the agent skill's `allowed-tools`\ncalls return something the agent can plausibly reason over.\n\nFor example, for a `workday_hr_leave_balance.get_leave_balance(employee_id)`\noperation:\n\n```python\n{\n  \"employee_id\": \"EMP-0042\",\n  \"year\": 2026,\n  \"annual_entitlement_days\": 25,\n  \"taken_days\": 12,\n  \"booked_days\": 5,\n  \"remaining_days\": 8,\n  \"carry_over_from_prior_year\": 0,\n}\n```\n\n— numbers consistent (taken + booked + remaining = entitlement + carry_over),\nkeyed off the seed so the same `employee_id` always returns the same record.\n\nDo not include real-looking PII. Synthesised employee names should follow\nthe existing repo convention (`EMP-NNNN`, fixture employees only).\n\n### Step 6 — Write the file\n\nWrite the assembled Python module to `output_path`. Create parent\ndirectories if needed.\n\n### Step 7 — Self-check\n\nBefore returning, verify:\n\n- Module imports resolve textually against the canonical examples\n  (`copilot.tools`, `opentelemetry.trace`, `pydantic`, `._otel`).\n- Every `operation` from the brief has both an `\u003Coperation>` function and\n  an `\u003Coperation>_tool` registration.\n- Every `\u003Coperation>` function is `@traced_tool(…)`-wrapped.\n- The synth function is pure (no `time`, `random`, `os.environ`,\n  network).\n- No `TODO` placeholder remains.\n- The output JSON shape is internally consistent (cross-field\n  invariants hold).\n\nIf any check fails, **fix in place**. If a check fails because the brief\nasks for something you can't deterministically synthesise, stop and tell\nthe caller.\n\n## Anti-patterns\n\n- Reading from `data\u002Fsynthetic\u002F` to \"make it more realistic\". The real\n  synthetic corpus is for the existing two domains. New domains\n  synthesise from a seed.\n- Importing `httpx` and pointing at a non-existent localhost port. The\n  whole point of the in-memory synthetic MCP adapter is no port management.\n- Inventing OTEL attribute names. Mirror what `claim_lookup.py` does\n  (`zava.\u003Ctool>.\u003Carg>`).\n- Returning lists where the canonical examples return dicts. Stay\n  isomorphic.\n- Adding multiple `mcp_tool` files in one invocation. One file per call.\n  The caller decides how many calls.\n",{"name":5,"audience":52,"description":53,"forbidden-runtime":54},"design-time-only","Sub-skill of `compose-domain`. Writes ONE in-process Python synthetic MCP\nadapter to a sandbox path, shape-isomorphic to existing tools under\n`api\u002Fserver\u002Fmcp_tools\u002F`. The adapter is callable from a runtime SKILL via\n`allowed-tools` and emits OTEL spans + FleetEvents the same way real\ntools do. Returns deterministic synthetic data — no real backend.\nIt is functional demonstration scaffolding: a real customer adapter\nreplaces it at the same tool boundary without changing workflow,\ngovernance, or evidence contracts.\n",true,"main","db273d7d646605c0bf0175dc9c8057b9ad2628b5","docs\u002Fsuperpowers\u002Fskills\u002Fauthor-mcp-tool",2,"https:\u002F\u002Fgithub.com\u002Farturcrmbot\u002Fzava-control-plane","https:\u002F\u002Fgithub.com\u002Farturcrmbot","2026-09-28 17:47:06",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":54},[64,67,70],{"tool":65,"command":66},"npx","npx skills add arturcrmbot\u002Fzava-control-plane --skill author-mcp-tool",{"tool":68,"command":69},"bunx","bunx skills add arturcrmbot\u002Fzava-control-plane --skill author-mcp-tool",{"tool":71,"command":72},"pnpm","pnpm dlx skills add arturcrmbot\u002Fzava-control-plane --skill author-mcp-tool","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Farturcrmbot\u002Fzava-control-plane\u002Fblob\u002Fmain\u002Fdocs\u002Fsuperpowers\u002Fskills\u002Fauthor-mcp-tool\u002FSKILL.md",[],[76,96,113,127,135,142],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":47},"01M71SJECD4KXSSJV1B0HSY4T4","proactive-customer-care","Proactively notifies and, where warranted, extends a small bounded goodwill gesture to a customer whose itinerary materially changed.","https:\u002F\u002Fgithub.com\u002Farturcrmbot\u002Fzava-control-plane\u002Fblob\u002Fmain\u002Fverticals\u002Ftravel\u002Fskills\u002Fproactive-customer-care\u002FSKILL.md",[],[83,35,84,85,86,87,88,89,90,91,92,93,94,95],"proactive","proactive customer care","customer care","gesture","action","bounded","status","check","booking","operations","travel","issue","itinerary",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":47},"01M71SJ9VHGNNTB6452H1KRZD6","payment-exception","Resolves a failed balance payment by retrying it to complete the booking, or releasing the booking's inventory when retry is not viable.","https:\u002F\u002Fgithub.com\u002Farturcrmbot\u002Fzava-control-plane\u002Fblob\u002Fmain\u002Fverticals\u002Ftravel\u002Fskills\u002Fpayment-exception\u002FSKILL.md",[],[103,104,105,106,107,91,108,109,110,89,111,112,90,92,93],"payment","payment exception","it","retry","balance","when","release","complete","capacity","inventory",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":47},"01M71SJ6S6XREB0J6CCVCSFZ9E","hotel-supplier-recovery","Restores accommodation for a shortfall-hit hotel allotment by moving contracted rooms from a donor allotment with headroom, resolving the reported supplier shortfall.","https:\u002F\u002Fgithub.com\u002Farturcrmbot\u002Fzava-control-plane\u002Fblob\u002Fmain\u002Fverticals\u002Ftravel\u002Fskills\u002Fhotel-supplier-recovery\u002FSKILL.md",[],[120,121,122,123,90,92,93,124,125,126],"hotel supplier recovery","hotel","recovery","with","move","for","headroom",{"skillNo":128,"name":129,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":47},"01M71SJ4G5MPM50WZ6F66M3PNS","holiday-sales-booking","https:\u002F\u002Fgithub.com\u002Farturcrmbot\u002Fzava-control-plane\u002Fblob\u002Fmain\u002Fverticals\u002Ftravel\u002Fskills\u002Fholiday-sales-booking\u002FSKILL.md",[],[133,91,134],"holiday sales booking","sales",{"skillNo":136,"name":137,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":47},"01M71SJ2AHHWN2C4YV2RKEE947","flight-disruption-recovery","https:\u002F\u002Fgithub.com\u002Farturcrmbot\u002Fzava-control-plane\u002Fblob\u002Fmain\u002Fverticals\u002Ftravel\u002Fskills\u002Fflight-disruption-recovery\u002FSKILL.md",[],[141,122],"flight disruption recovery",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":47},"01M71SHYPK8HNQ80C9XAWSER53","destination-operations","Dispatches a replacement resort transfer when an arrival is at risk, rebinding any travellers on the at-risk transfer to the replacement.","https:\u002F\u002Fgithub.com\u002Farturcrmbot\u002Fzava-control-plane\u002Fblob\u002Fmain\u002Fverticals\u002Ftravel\u002Fskills\u002Fdestination-operations\u002FSKILL.md",[],[149,92,150,151,90,152,93,42,108,153],"destination operations","destination","risk","dispatch","transfer"]