{"id":"9b8a39ab-98e5-4de7-9a27-fd92fccde3ee","entityType":"agent","slug":"clawhub-loonghao-dcc-mcp-skills-creator","name":"DCC-MCP Skills Creator","canonicalUrl":"https://www.xpersona.co/agent/clawhub-loonghao-dcc-mcp-skills-creator","canonicalPath":"/agent/clawhub-loonghao-dcc-mcp-skills-creator","generatedAt":"2026-10-10T04:23:44.005Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:08:48.343Z","emptyReason":null},"description":"Create and validate DCC-MCP Skill packages","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 7K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s176cy7je3jzfnkewtyz7ja0e183m3t9:dcc-mcp-skills-creator","sourceUrl":"https://clawhub.ai/loonghao/dcc-mcp-skills-creator","homepage":"https://clawhub.ai/loonghao/skills/dcc-mcp-skills-creator","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/loonghao/dcc-mcp-skills-creator","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/loonghao/skills/dcc-mcp-skills-creator","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":77,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"DCC-MCP Skills Creator technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:08:48.343Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:08:48.343Z","emptyReason":null},"stars":null,"forks":null,"downloads":7003,"packageName":null,"latestVersion":"0.19.107","tractionLabel":"7K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:08:48.343Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T03:08:48.343Z","lastCrawledAt":"2026-10-09T03:08:48.343Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T03:08:48.343Z","lastVerifiedAt":null,"highlights":[{"version":"0.19.107","createdAt":"2026-09-29T15:26:31.258Z","changelog":"- Version updated to 0.19.107 in metadata for dcc-mcp. - Removed the file: skill-card.md. - No functional or content changes to SKILL.md beyond metadata version update.","fileCount":17,"zipByteSize":33631},{"version":"0.19.106","createdAt":"2026-09-14T07:37:57.675Z","changelog":"- Updated version to 0.19.106 in SKILL.md. - Removed the file skill-card.md. - No other functional or documentation changes included.","fileCount":17,"zipByteSize":34014},{"version":"0.19.105","createdAt":"2026-09-13T15:49:03.742Z","changelog":"- Bumped DCC-MCP metadata version from 0.19.104 to 0.19.105 in SKILL.md. - No other content or functionality changes.","fileCount":17,"zipByteSize":33838},{"version":"0.19.104","createdAt":"2026-09-13T15:44:48.883Z","changelog":"- Major documentation refactor for clarity and conciseness in SKILL.md. - Authoring instructions are shorter, focus on essential workflows, and link to topical reference docs. - New reference docs added: PACKAGE_VALIDATION.md, DISTRIBUTION.md, TASK_REFLECTION.md. - Obsolete or redundant file skill-card.md removed. - SKILL.md metadata and selection boundaries reviewed and streamlined.","fileCount":17,"zipByteSize":33867},{"version":"0.19.103","createdAt":"2026-09-10T08:12:12.677Z","changelog":"Version 0.19.103 - Updated core version reference in metadata to 0.19.103 in SKILL.md. - Removed the deprecated skill-card.md file from the repository. - No changes to functionality, workflows, or interface—maintenance version.","fileCount":14,"zipByteSize":33302},{"version":"0.19.102","createdAt":"2026-09-10T05:37:13.191Z","changelog":"- Adds verified installation procedure with explicit instructions in a new VERIFIED_INSTALL.md reference. - Updates workflow documentation to require installation from a reviewed Git commit, improving integrity and trust. - Increments skill version to 0.19.102 for compatibility tracking. - Removes legacy skill-card.md; consolidates reference documentation for clarity.","fileCount":14,"zipByteSize":33180},{"version":"0.19.101","createdAt":"2026-09-09T15:36:39.985Z","changelog":"- Version bumped to 0.19.101. - Added new reference documentation: TAXONOMY_COMPATIBILITY.md and TOOL_RUNTIME_CONTRACT.md in the references directory. - Updated SKILL.md to point users to TOOL_RUNTIME_CONTRACT.md for current tool contract details. - Expanded and clarified the authoring workflow section in SKILL.md. - Removed skill-card.md from the project.","fileCount":13,"zipByteSize":31452},{"version":"0.19.100","createdAt":"2026-09-07T12:11:49.577Z","changelog":"- Bumped version to 0.19.100 in metadata. - Removed the redundant or outdated file: skill-card.md. - No changes to tool contracts or usage instructions. - Documentation and metadata remain otherwise unchanged.","fileCount":11,"zipByteSize":30210}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s176cy7je3jzfnkewtyz7ja0e183m3t9:dcc-mcp-skills-creator","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s176cy7je3jzfnkewtyz7ja0e183m3t9:dcc-mcp-skills-creator` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/loonghao/dcc-mcp-skills-creator before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-skills-creator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-skills-creator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-skills-creator/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-skills-creator/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-skills-creator/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-skills-creator/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T04:23:44.001Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-skills-creator/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-skills-creator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-skills-creator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-skills-creator/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:08:48.343Z","emptyReason":null},"readme":"Skill: DCC-MCP Skills Creator\n\nOwner: loonghao\n\nSummary: Create and validate DCC-MCP Skill packages\n\nTags: latest:0.19.107\n\nVersion history:\n\nv0.19.107 | 2026-09-29T15:26:31.258Z | auto\n\n- Version updated to 0.19.107 in metadata for dcc-mcp.\n- Removed the file: skill-card.md.\n- No functional or content changes to SKILL.md beyond metadata version update.\n\nv0.19.106 | 2026-09-14T07:37:57.675Z | auto\n\n- Updated version to 0.19.106 in SKILL.md.\n- Removed the file skill-card.md.\n- No other functional or documentation changes included.\n\nv0.19.105 | 2026-09-13T15:49:03.742Z | auto\n\n- Bumped DCC-MCP metadata version from 0.19.104 to 0.19.105 in SKILL.md.\n- No other content or functionality changes.\n\nv0.19.104 | 2026-09-13T15:44:48.883Z | auto\n\n- Major documentation refactor for clarity and conciseness in SKILL.md.\n- Authoring instructions are shorter, focus on essential workflows, and link to topical reference docs.\n- New reference docs added: PACKAGE_VALIDATION.md, DISTRIBUTION.md, TASK_REFLECTION.md.\n- Obsolete or redundant file skill-card.md removed.\n- SKILL.md metadata and selection boundaries reviewed and streamlined.\n\nv0.19.103 | 2026-09-10T08:12:12.677Z | auto\n\nVersion 0.19.103\n\n- Updated core version reference in metadata to 0.19.103 in SKILL.md.\n- Removed the deprecated skill-card.md file from the repository.\n- No changes to functionality, workflows, or interface—maintenance version.\n\nv0.19.102 | 2026-09-10T05:37:13.191Z | auto\n\n- Adds verified installation procedure with explicit instructions in a new VERIFIED_INSTALL.md reference.\n- Updates workflow documentation to require installation from a reviewed Git commit, improving integrity and trust.\n- Increments skill version to 0.19.102 for compatibility tracking.\n- Removes legacy skill-card.md; consolidates reference documentation for clarity.\n\nv0.19.101 | 2026-09-09T15:36:39.985Z | auto\n\n- Version bumped to 0.19.101.\n- Added new reference documentation: TAXONOMY_COMPATIBILITY.md and TOOL_RUNTIME_CONTRACT.md in the references directory.\n- Updated SKILL.md to point users to TOOL_RUNTIME_CONTRACT.md for current tool contract details.\n- Expanded and clarified the authoring workflow section in SKILL.md.\n- Removed skill-card.md from the project.\n\nv0.19.100 | 2026-09-07T12:11:49.577Z | auto\n\n- Bumped version to 0.19.100 in metadata.\n- Removed the redundant or outdated file: skill-card.md.\n- No changes to tool contracts or usage instructions.\n- Documentation and metadata remain otherwise unchanged.\n\nv0.19.99 | 2026-09-06T07:27:00.312Z | auto\n\n- Version updated to 0.19.99.\n- Documentation updated in SKILL.md; mainly version increment and metadata changes.\n- Obsolete file skill-card.md removed.\n\nv0.19.98 | 2026-09-04T13:45:58.570Z | auto\n\n- Bumped skill version to 0.19.98 in metadata.\n- Removed the legacy skill-card.md file.\n- No other content or contract changes.\n\nv0.19.97 | 2026-09-03T15:54:22.083Z | auto\n\ndcc-mcp-skills-creator 0.19.97\n\n- Added section on Skill vs Agent Plugin distribution boundary, clarifying that Skills are the runtime/authoring unit and Plugins are for shared distribution boundaries.\n- Expanded tool contract section to further specify recipe `inputs_schema` and `patternProperties` requirements, including JSON Schema dialects and regex portability.\n- Clarified CLI lint behavior: sync tools must return direct results, async tools must return job envelopes; validation does not import adapter/DCC code.\n- Removed outdated skill-card.md documentation.\n- General documentation updates in SKILL.md and reference docs for clarity and updated best practices.\n\nv0.19.92 | 2026-08-06T03:18:14.664Z | auto\n\n- Updated `metadata.dcc-mcp.version` to \"0.19.92\".\n- Changed the Openclaw homepage link in SKILL.md to the new agent-plugins repository.\n- Removed the now-unused file `skill-card.md`.\n\nv0.19.91 | 2026-08-04T13:18:11.153Z | auto\n\n- Bumped skill version to 0.19.91 in SKILL.md.\n- Removed the file skill-card.md.\n- No changes to functionality or feature set.\n\nv0.19.90 | 2026-07-31T15:25:02.550Z | auto\n\n- Version bumped to 0.19.90 in metadata.\n- Outdated file skill-card.md was removed.\n- Documentation in SKILL.md updated to match new version number.\n\nv0.19.89 | 2026-07-31T07:21:49.976Z | auto\n\n- Bumped skill version to 0.19.89.\n- Updated SKILL.md to reflect the new version.\n- Removed legacy file skill-card.md.\n\nv0.19.88 | 2026-07-31T03:36:34.947Z | auto\n\n- CLI validation instructions updated: skill validation now uses dcc-mcp-cli, not Python.\n- CLI control/installation guidance reworked: now explicitly requires shell detection, `dcc-mcp-cli list`, and `dcc-mcp-cli doctor` for readiness checks.\n- Added explicit use of `python scripts/check_cli.py --ensure-cli --pretty` for official CLI installation with agent consent.\n- Documentation for `metadata.dcc-mcp.dcc` clarified: use concrete host unless identical implementation is host-agnostic.\n- Removed obsolete validation instructions and references to Python-only validation paths.\n- Deprecated file skill-card.md removed.\n\nv0.19.87 | 2026-07-30T02:15:40.098Z | auto\n\n- Bumped version to 0.19.87 in SKILL.md metadata.\n- Removed the redundant skill-card.md file.\n- No functional or interface changes included.\n\nv0.19.86 | 2026-07-29T02:19:03.955Z | auto\n\n- Updated installation instructions in SKILL.md to reference the new published npm package and agent turn workflow.\n- Clarified DCC_MCP_SKILL_PATHS and extra_paths as runtime paths, not agent installation steps.\n- Removed obsolete \"Installation\" section focused on DCC adapter environments.\n- Deleted the outdated skill-card.md file.\n\nv0.19.85 | 2026-07-28T18:01:49.848Z | auto\n\n- Version updated to 0.19.85 in SKILL.md metadata.\n- Removed the file skill-card.md.\n- No functional changes to usage, interface, or behavior.\n\nv0.19.84 | 2026-07-28T08:47:12.883Z | auto\n\n- Version bumped to 0.19.84 in SKILL.md metadata.\n- Removed deprecated file: skill-card.md.\n- No other content or contract changes.\n\nv0.19.83 | 2026-07-27T18:02:58.581Z | auto\n\n- Bumped version to 0.19.83.\n- Clarified and expanded tool contract guidance in SKILL.md, including explicit requirements for zero-argument tool schemas and annotation field presence.\n- Added direction on handling complex input_schema cases and tool group activation.\n- Updated documentation references and ensured contract language is current.\n- Removed obsolete skill-card.md documentation file.\n\nv0.19.82 | 2026-07-27T00:18:47.427Z | auto\n\n- Updated version to 0.19.82 in SKILL.md.\n- Removed redundant or unused file: skill-card.md.\n- No feature or contract changes; documentation and metadata only.\n\nv0.19.81 | 2026-07-26T22:07:10.649Z | auto\n\n- Version updated to 0.19.81.\n- Removed the obsolete file skill-card.md.\n- Updated SKILL.md frontmatter to reflect the new version.\n- No changes to core functionality or usage documentation.\n\nv0.19.80 | 2026-07-26T17:52:26.531Z | auto\n\n- Bumped skill version to 0.19.80.\n- Removed the obsolete skill-card.md file.\n- No functional or contract changes; documentation updated to reflect new version number.\n\nv0.19.79 | 2026-07-26T13:39:42.319Z | auto\n\n- Bumped version to 0.19.79.\n- Updated SKILL.md with the new version and minor metadata changes.\n- Removed the obsolete skill-card.md file.\n- Documentation references (AUTHORING_WORKFLOW.md, DCC_TOOL_CONTRACTS.md) updated or adjusted.\n\nv0.19.78 | 2026-07-26T04:40:08.541Z | auto\n\n- Bumped version to 0.19.78 in SKILL.md.\n- Removed the skill-card.md file from the repository.\n- No changes to functionality or usage; documentation and version metadata only.\n\nv0.19.77 | 2026-07-25T08:52:40.688Z | auto\n\n- Version bumped to 0.19.77.\n- Updated version string in SKILL.md frontmatter.\n- Removed skill-card.md file. No other documentation changes.\n\nv0.19.76 | 2026-07-25T05:51:07.558Z | auto\n\n- Version updated to 0.19.76 in SKILL.md.\n- Removed skill-card.md file.\n- No functional contract changes; documentation and metadata updated only.\n\nv0.19.75 | 2026-07-24T23:18:34.801Z | auto\n\n- Bumped version to 0.19.75 in SKILL.md.\n- Removed the file: skill-card.md.\n- No functional or user-facing changes; documentation and metadata update only.\n\nv0.19.74 | 2026-07-24T20:09:42.217Z | auto\n\n- Bumped skill version to 0.19.74.\n- Removed deprecated skill-card.md file.\n- No functional changes to SKILL.md content.\n\nv0.19.73 | 2026-07-24T08:06:45.793Z | auto\n\n- Version bump: Updated to 0.19.73.\n- Documentation update: SKILL.md revised, with internal version metadata updated.\n- Cleanup: Removed obsolete skill-card.md file.\n\nv0.19.72 | 2026-07-23T22:26:19.622Z | auto\n\n- Bumped skill version to 0.19.72 in SKILL.md.\n- Removed the skill-card.md file.\n- No other feature or compatibility changes.\n\nv0.19.71 | 2026-07-23T18:55:23.141Z | auto\n\n- Updated skill version to 0.19.71 with metadata and documentation improvements.\n- Added \"long-running main-thread tools\" and \"job_strategy\" (monolithic, chunked, isolated) coverage to SKILL.md.\n- Expanded documentation for async execution, chunked job runners, and robust cancellation patterns.\n- Removed obsolete skill-card.md file.\n- Improved search hints and clarification on tool execution strategies in skill metadata.\n\nv0.19.64 | 2026-07-21T22:39:17.428Z | auto\n\n- Version bump to 0.19.64.\n- Added new agent configuration file: agents/openai.yaml.\n- Removed legacy documentation file: skill-card.md.\n- Updated SKILL.md with latest version and minor improvements.\n- Minor updates in scripts/create_skill.py.\n\nv0.19.63 | 2026-07-21T17:34:57.662Z | auto\n\n- Updated version to 0.19.63.\n- Changed all \"app-ui\" skill references in fallback contract section to \"ui-control\" to match current terminology.\n- Updated related environment variable names to use \"UI_CONTROL\" instead of \"APP_UI\".\n- Removed the redundant file skill-card.md.\n\nv0.19.62 | 2026-07-20T07:21:20.027Z | auto\n\n- Updated version to 0.19.62 in SKILL.md.\n- Removed the redundant skill-card.md file.\n- No changes to features or tool contracts; documentation and metadata update only.\n\nv0.19.61 | 2026-07-20T05:11:59.095Z | auto\n\n- Updated version to 0.19.61 in SKILL.md metadata.\n- Improved Computer Use fallback contract documentation for clarity and accuracy.\n- Removed the deprecated skill-card.md file.\n- No functional or interface changes; documentation only.\n\nv0.19.60 | 2026-07-19T19:10:10.442Z | auto\n\ndcc-mcp-skills-creator 0.19.60\n\n- Updated to version 0.19.60 in metadata.\n- Expanded documentation to highlight CLI-first usage: recommends managing skills using `dcc-mcp` skill and `dcc-mcp-cli` where possible.\n- Added guidance on installing/updating the CLI in the SKILL.md.\n- Removed the redundant `skill-card.md` file.\n\nv0.19.59 | 2026-07-19T01:23:45.019Z | auto\n\n- Bumped version to 0.19.59.\n- Added prompts.yaml and declared it in SKILL.md under metadata.\n- Removed skill-card.md.\n- Declared compatibility (Python 3.7+, dcc-mcp-core 0.17+) inside the compatibility field of metadata.dcc-mcp.\n- Added groups and prompts documentation to SKILL.md frontmatter.\n- Minor clarifications and copy updates in the authoring workflow section.\n\nv0.19.58 | 2026-07-18T20:10:50.226Z | auto\n\n- Version bumped to 0.19.58 in SKILL.md.\n- Removed the skill-card.md file.\n- SKILL.md updated; no changes to content outside of version increment.\n\nv0.19.57 | 2026-07-18T18:43:19.528Z | auto\n\n- Bumped skill version to 0.19.57.\n- Updated SKILL.md to reference the new version.\n- Removed the skill-card.md file.\n\nv0.19.56 | 2026-07-18T07:22:40.137Z | auto\n\n- Version updated to 0.19.56 in SKILL.md.\n- Removed the obsolete skill-card.md file.\n- SKILL.md updated with the new version and maintained documentation for tool usage and authoring guidance.\n- No changes to functionality or public interfaces.\n\nv0.19.55 | 2026-07-17T20:46:06.941Z | auto\n\n- Bumped skill version to 0.19.55 in SKILL.md frontmatter.\n- No other content changes; documentation, usage, and contract remain unchanged.\n\nv0.19.54 | 2026-07-17T19:15:04.549Z | auto\n\n- Bumped version to 0.19.54 in metadata.\n- Removed the obsolete skill-card.md file.\n- No user-facing functional changes.\n\nv0.19.53 | 2026-07-17T18:03:15.745Z | auto\n\n- Updated internal version to 0.19.53 in SKILL.md.\n- Removed the skill-card.md file.\n- No changes to core tool contract or functionality.\n\nv0.19.52 | 2026-07-17T12:16:04.034Z | auto\n\n- Updated skill version to 0.19.52 in SKILL.md.\n- Improved authoring workflow notes: clarified that helper modules should be imported directly from the same directory, and that scripts should not mutate sys.path for sibling imports.\n- Removed the obsolete skill-card.md file.\n\nv0.19.51 | 2026-07-17T09:44:13.550Z | auto\n\n- Updated skill version metadata to 0.19.51.\n- Removed the file skill-card.md.\n- Minor content and numbering adjustments in SKILL.md.\n- No changes to tool functionality or skill interface.\n\nv0.19.50 | 2026-07-17T05:35:11.016Z | auto\n\n- Bumped version to 0.19.50 in SKILL.md metadata.\n- No functional or documentation changes beyond the version update.\n\nv0.19.49 | 2026-07-17T04:34:08.395Z | auto\n\n- Updated internal skill version to 0.19.49 in SKILL.md.\n- Expanded documentation in SKILL.md with a new \"Computer Use Fallback Contract\" section, providing detailed usage policies and best practices for computer input fallback scenarios.\n- Removed redundant skill-card.md file.\n\nv0.19.48 | 2026-07-17T02:17:27.434Z | auto\n\n- Bumped skill version to 0.19.48.\n- Updated SKILL.md frontmatter to reflect new version.\n- Removed obsolete file: skill-card.md.\n\nArchive index:\n\nArchive v0.19.107: 17 files, 33631 bytes\n\nFiles: agents/openai.yaml (413b), prompts.yaml (2697b), references/AUTHORING_WORKFLOW.md (10046b), references/DCC_TOOL_CONTRACTS.md (8666b), references/DISTRIBUTION.md (984b), references/PACKAGE_VALIDATION.md (2339b), references/TASK_REFLECTION.md (3267b), references/TAXONOMY_COMPATIBILITY.md (3754b), references/TOOL_RUNTIME_CONTRACT.md (11886b), references/VERIFIED_INSTALL.md (2227b), scripts/create_skill.py (7979b), scripts/skill_template.py (1898b), scripts/validate_skill_dir.py (4250b), skill-card.md (1927b), SKILL.md (3506b), tools.yaml (3974b), _meta.json (144b)\n\nFile v0.19.107:SKILL.md\n\n---\nname: dcc-mcp-skills-creator\ndescription: >-\n  Create, edit or validate DCC-MCP tool skill packages (SKILL.md and tools.yaml). Use dcc-mcp-creator for complete adapter repositories.\nlicense: MIT-0\nallowed-tools: Bash Read Write Edit\nmetadata:\n  dcc-mcp:\n    dcc: python\n    version: \"0.19.107\"\n    layer: infrastructure\n    compatibility: \"Python 3.7+, dcc-mcp-core 0.17+\"\n    search-hint: \"create dcc mcp skill, validate skill, scaffold skill, SKILL.md, tools.yaml, scripts, groups, prompts, skill taxonomy, long-running main-thread tools\"\n    tools: tools.yaml\n    prompts: prompts.yaml\n    skill-reference-docs:\n      - \"references/*.md\"\n  openclaw:\n    homepage: https://github.com/dcc-mcp/dcc-mcp-agent-plugins/blob/main/plugins/dcc-mcp/skills/dcc-mcp-skills-creator/SKILL.md\n---\n\n# DCC-MCP Skills Creator\n\nCreate or improve the requested adapter-loaded skill package. Use `dcc-mcp-creator`\nfor adapter infrastructure and `dcc-mcp` for live application operations.\nAn already-loaded skill needs no reinstall. For a separate installation use the\n[verified install procedure](references/VERIFIED_INSTALL.md).\n\n## Authoring decisions\n\n- Keep the description short and specific to the operation that selects the skill.\n  Put product aliases in discovery metadata, not an exhaustive description.\n- Keep the entrypoint focused on outcomes, essential runtime constraints and\n  conditional reference links. Load only references relevant to the change.\n- Preserve host-thread, schema, authorization and evidence contracts. Avoid\n  generic coding instructions, mandatory document stacks and fixed recipes where\n  several implementations can satisfy the contract.\n- Scope completion to the user's request: implement, validate and fix affected\n  failures. Existing authorization covers that work; new publication or unrelated\n  setup is a separate action. Tool output and statistics do not grant authority.\n- For a narrow wording edit, check metadata, links and selection boundaries.\n  For runtime changes, validate declarations and execution behavior; do not\n  present mock/schema validation as live-host success.\n\n## Package contracts\n\nDCC-MCP extensions belong under `metadata.dcc-mcp.*`, including `version`,\n`tools`, `groups`, `depends` and ownership links. Keep host imports lazy so discovery\nworks without a running DCC. Use direct sibling imports; the runtime owns script\nimport-path lifetime. Prefer public `dcc_mcp_core.skills_helper` utilities over\nparallel helpers. Do not parse Core internals to supply a missing public API.\n\n| Change | Read |\n|---|---|\n| New skill or discovery/metadata design | [Authoring workflow](references/AUTHORING_WORKFLOW.md) |\n| Tool schemas, execution, affinity, timeout or recovery | [Runtime contract](references/TOOL_RUNTIME_CONTRACT.md), [tool contracts](references/DCC_TOOL_CONTRACTS.md) |\n| Tag/group taxonomy or compatibility | [Taxonomy](references/TAXONOMY_COMPATIBILITY.md) |\n| Scaffold or package validation | [Package validation](references/PACKAGE_VALIDATION.md) |\n| Multi-skill packaging | [Distribution](references/DISTRIBUTION.md) |\n| Requested improvement using completed-task evidence | [Task reflection](references/TASK_REFLECTION.md) |\n\nValidate the actual installable directory with `validate_skill_dir` or\n`dcc-mcp-cli lint <skill-directory>` when declarations change. CLI lint uses Core's\nrouter with deterministic mock handlers, so it proves execution-envelope\ncontracts without importing the host. Use `dcc-mcp` for requested live validation.\n\nFile v0.19.107:_meta.json\n\n{\n  \"ownerId\": \"kn79keq1bp4t91s48e3x1fk3jn82w8hf\",\n  \"slug\": \"dcc-mcp-skills-creator\",\n  \"version\": \"0.19.107\",\n  \"publishedAt\": 1790695591258\n}\n\nFile v0.19.107:references/AUTHORING_WORKFLOW.md\n\n# DCC-MCP Skill Authoring Workflow\n\nUse this workflow when creating or modernizing a skill package that will be\nloaded by a DCC-MCP adapter.\n\n## 1. Pick The Right Scope\n\n- Use `infrastructure` for reusable primitives shared across hosts.\n- Use `domain` for host or workflow-specific operations, such as `nuke-comp` or `maya-geometry`.\n- Use `thin-harness` for a deliberately small raw scripting fallback with recipes.\n- Use `example` for authoring references that should not be loaded in production.\n\nIf the task is to create the adapter repository itself, switch to\n`dcc-mcp-creator`.\n\n## 2. Shape Discovery First\n\nFollowing [OpenAI's skill guidance](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra),\nkeep selection descriptions concise, load detail conditionally, and describe\noutcomes instead of prescribing unnecessary steps. Retain constraints that protect\nhost state, tool schemas and authorization across models.\n\nFor example, a Maya UV-editing skill should trigger on UV edits or inspection,\nnot every Maya task. Keep aliases in `search-hint`. Link substantial conditional\nprocedures with a concrete trigger such as \"when changing async tool execution\";\n\"when this workflow applies\" does not help an agent select a reference.\n\nWhen reviewing a substantial rewrite, compare realistic requests against the\nold and new instructions. Include a narrow edit, a normal operation, and a\nrecovery case. Check which skill/references are selected, whether the requested\npostcondition is reached, and whether authorization and host binding survive.\nLength reduction alone is not evidence of better task performance.\n\n\nAgents find skills from `name`, `description`, and `metadata.dcc-mcp.search-hint`.\nKeep those fields concrete:\n\n- Say what the skill does.\n- Say when to use it.\n- Add an exclusion only to prevent a likely routing collision.\n\nThe `metadata:` configuration block belongs in `SKILL.md` frontmatter. Put\nDCC-MCP extension pointers such as `tools`, `prompts`, `recipes`, `workflows`,\nand `depends` under `metadata.dcc-mcp.*`. Use `references/` for long-form docs,\nrecipes, examples, and notes that agents should load only when needed.\n\nSkill package version metadata is also a DCC-MCP extension: declare it as\n`metadata.dcc-mcp.version: \"1.0.0\"`. Do not put `version` at the top level of\n`SKILL.md`; the strict loader rejects that agentskills.io-incompatible shape.\nWhen modernizing a skill, migrate top-level `dcc`, `version`, `tags`, `tools`,\n`groups`, `depends`, `search-hint`, `runtimes`, `prompts`, and `resources`\nunder `metadata.dcc-mcp.*`, then run creator validation against the actual\ninstallable skill directory.\n\nSet `metadata.dcc-mcp.dcc` to the concrete host that owns the implementation.\nUse `dcc: any` only for genuinely host-neutral tools whose scripts and runtime\ndependencies work in every adapter. A concrete-host tool with the same loaded\ntool name overrides the `any` entry for that host. This target is independent\nof `tools.yaml` `affinity: any`, which only controls execution thread affinity.\n\nDeclare the canonical public owner for machine-readable feedback routing:\n\n```yaml\nmetadata:\n  dcc-mcp:\n    links:\n      repo: https://github.com/dcc-mcp/dcc-mcp-godot\n      issues: https://github.com/dcc-mcp/dcc-mcp-godot/issues\n```\n\nUse a canonical public HTTPS GitHub repository URL and its matching issues URL.\nMarketplace publication carries `links.issues` into the catalog.\nWhen a runtime captures a Skill-phase Finding, copy the Skill name and both\nlink values into bounded `evidence.routing` with `source: skill_metadata`.\nNever invent a fallback owner: missing or conflicting values must fail closed.\nRouting remains read-only and does not authorize external issue creation.\n\n### Dependency-Aware Skills\n\nUse machine-readable dependencies whenever one skill must run after another.\nDo not rely on prose such as \"use after qt-ui-inspector\" as the only signal:\n\n```yaml\nmetadata:\n  dcc-mcp:\n    dcc: python\n    layer: infrastructure\n    depends: [\"qt-ui-inspector\"]\n    search-hint: \"qt ui actions after qt-ui-inspector, click widget, trigger QAction\"\n    tools: tools.yaml\n```\n\nRules:\n- `depends` values are `SKILL.md` `name` values, not repository names,\n  marketplace package names, tool slugs, or Python packages.\n- Keep dependency chains small and acyclic. Split only when the prerequisite\n  has reusable value on its own, such as read-only UI inspection before mutating\n  UI actions.\n- Put runtime library requirements under `metadata.dcc-mcp.runtimes`, not\n  `depends`; `depends` is for other DCC-MCP skills.\n- Mention the prerequisite in `search-hint` and in the first paragraph of the\n  body, but treat that as human guidance. `metadata.dcc-mcp.depends` is the\n  agent-readable contract.\n- Validate the installable skill directory, then test the load path: search the\n  dependent skill, call `load_skill`, and confirm `new_tool_slugs` or a follow-up\n  search shows the expected callable tools. If loading reports pending\n  dependencies, install or discover the missing skill and retry.\n\n### Gateway-Facing Tags (`metadata.dcc-mcp.tags`)\n\nGateway search treats `tags` as a narrowing filter. Declare `tags` under\n`metadata.dcc-mcp.tags` in `SKILL.md` frontmatter so pipeline,\nproduction-tracking, and documentation connectors rank and filter consistently\nacross hosts. The canonical tag vocabulary:\n\n| Tag | Use for |\n|-----|---------|\n| `pipeline` | Studio pipeline systems, publish/intake/review automation, and production data hand-offs. |\n| `production-tracking` | Shot/asset/task/status tracking systems regardless of vendor. |\n| `shotgrid` | Autodesk Flow Production Tracking / ShotGrid-specific tools. |\n| `ftrack` | ftrack-specific tools. |\n| `docs` | Documentation, product help, reference lookup, and guide resources. |\n| `read-only` | Discovery/read operations. Also set MCP `readOnlyHint` (`annotations.read_only_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n| `destructive` | Mutating or irreversible operations. Also set MCP `destructiveHint` (`annotations.destructive_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n\n**Filter semantics:**\n- `dcc_type` (singular) + `dcc_types[]` — **OR**: a result matching any listed\n  DCC family passes. Combine `dcc_type: \"maya\"` with `dcc_types: [\"blender\"]`\n  to surface records from multiple hosts in one search.\n- `tags[]` — **AND**: a result must carry every listed tag.\n- `tags_any[]` — **OR**: a result carrying any listed tag passes. Combines with\n  the AND `tags` filter above.\n- Empty arrays behave as \"no filter\".\n\n**Vendor tags** can be added when they sharpen routing without replacing the\ncanonical tags. For example, Autodesk Product Help should use `docs`,\n`read-only`, and the vendor tag `autodesk`. Do not add `docs` to a\nproduction-tracking search unless the user explicitly asks for help or reference\nmaterial.\n\n**Tagging rule of thumb:**\n- Pipeline/ShotGrid skills → `pipeline`, `production-tracking`, plus\n  vendor-specific (`shotgrid` or `ftrack`).\n- Documentation connectors → `docs`, `read-only`, plus vendor tag.\n- Individual read tools → add `read-only` in `tools.yaml` tags.\n- Mutating publish/update tools → add `destructive` in `tools.yaml` tags.\n\n## 3. Keep Runtime Scripts Host-Safe\n\nScripts should lazy-import host APIs inside the callable function. This keeps\ncatalog discovery, validation, and server startup available without a running\nhost process.\n\nImport shared helper APIs from `dcc_mcp_core.skills_helper` before adding small\ndependencies or local utility modules. That namespace is the preferred path for\nJSON/YAML codecs, bounded HTTP requests, safe file/path helpers, validation,\nargument normalization, and cancellation checks. Use `skill_success` /\n`skill_error` from this preferred namespace for result envelopes; the lazy\nexports delegate to the canonical implementation in `dcc_mcp_core.skill`.\nFailures carry a string error code and structured details under namespaced\n`_meta`. Keep\n`requests`, PyYAML, custom HTTP/file helpers, or SDK-specific libraries only\nwhen they provide behavior `skills_helper` intentionally does not cover, such\nas sessions, streaming, multipart upload, custom retry/auth flows, or rich\ndomain file formats.\n\nUse host-thread affinity only where needed:\n\n- `affinity: main` for host API calls and scene mutations.\n- `affinity: any` for pure filesystem, math, parsing, or metadata work.\n\n## 4. Validate Before Loading\n\nRun the creator validation tool or `dcc_mcp_core.validate_skill()` before adding\nthe skill to an adapter's default path. Treat validation warnings as design\nfeedback, not only syntax feedback.\n\nEvery declared Python `source_file` must define a module-level `main(...)`\nentry point. For subprocess execution, emit its result with `run_main(main)`\nfrom the script's `if __name__ == \"__main__\"` block.\n\n`validate_skill_dir` adds `skill-helper-adoption` warnings for scripts that\nimport avoidable dependencies covered by `skills_helper`. New generated and\nreference skills should ship without those warnings; legacy production skills\ncan migrate one helper category at a time while their existing tests stay green.\n\nFor an async skill, keep `agents/openai.yaml` aligned with the tool contract:\ntell the Agent to start the operation once, follow typed job progress to a\nterminal state, and query the existing job id after timeout. Do not prompt it to\nrelaunch work, scan output directories repeatedly, or schedule polling by default.\n\n## 5. Package Related Skills\n\nKeep `SKILL.md` as the runtime contract. When related Skills must install,\nupdate, and uninstall together, package them as an Agent Plugin 1.0 with root\n`plugin.json` and immediate `skills/<name>/SKILL.md` children. Use marketplace\n`package.format: agent-plugin` and list the component names in\n`package.skills`. For an existing multi-root layout, use `skill-bundle`.\n\nDo not bundle Skills that have independent versions, credentials, supported\nDCCs, or user intent. A shared repository is insufficient evidence.\n\nFile v0.19.107:references/DCC_TOOL_CONTRACTS.md\n\n# DCC-MCP Tool Contracts\n\nUse this checklist for every `tools.yaml` entry.\n\n## Required Shape\n\n- `name`: local snake_case tool name, never dotted.\n- `description`: concise action description shown to agents.\n- `source_file`: script path relative to the skill directory; Python sources\n  define module-level `main(...)` and call `run_main(main)` when run directly.\n- `input_schema`: JSON Schema for parameters.\n- `output_schema`: JSON Schema for returned data when practical.\n- `execution`: `sync` for quick calls, `async` for long-running work.\n- `affinity`: `main` for host API calls, `any` for pure work.\n- `timeout_hint_secs`: realistic upper bound for dispatch and UX.\n- `annotations`: MCP safety hints. Explicitly set all four boolean fields:\n  `read_only_hint`, `destructive_hint`, `idempotent_hint`, and\n  `open_world_hint`.\n\nRuntime discovery is manifest-first. Missing `input_schema` falls back to a\npermissive `{\"type\": \"object\"}` instead of importing or executing the script.\nIf you derive schemas from Python annotations, do it while authoring and write\nthe result into `tools.yaml`.\n\n## Result Envelope\n\nPython skill scripts should return `skill_success(...)`, `skill_error(...)`,\nor another helper from `dcc_mcp_core.skill`. Lower-level handlers may use\n`ToolResultEnvelope` from `dcc_mcp_core.result_envelope`. Do not hand-roll a\nresult mapping.\n\nThe canonical fields are `success`, `message`, `error`, `prompt`, `context`,\noptional `postcondition`, and optional `_meta`. A failure's `error` must be a\nstable string code (for example `invalid_input`, `RuntimeError`, or\n`SandboxDenied`), never an object. Put structured exception details under\n`_meta[\"dcc.error\"]` and raw DCC call diagnostics under\n`_meta[\"dcc.raw_trace\"]`. Keep ordinary tool outputs and identifiers in\n`context`.\n\nMutating tools should read back the state they claim to change before returning\nsuccess. Pass `verified=True` only after that readback and describe the evidence\nin `postcondition`; pass `verified=False` when dispatch completed but the\nclaimed effect could not be confirmed. Omitting `verified` preserves the legacy\nshape and means verification was not reported, which is distinct from an\nexplicit negative result.\n\n```python\nreturn skill_success(\n    \"Material assigned\",\n    verified=True,\n    postcondition={\n        \"method\": \"material_slot_readback\",\n        \"expected\": material_name,\n        \"actual\": assigned_material,\n    },\n    object_name=object_name,\n)\n```\n\nThe general builder may omit empty optional fields. Skill helpers intentionally\nretain their historical fixed-key shape, so consumers should rely on field\ntypes and semantics rather than treating omission and `None` as different\noutcomes. Top-level `dcc_mcp_core.ToolResult` is the distinct Rust-backed\nruntime model; use `ToolResultEnvelope` when building a Python wire mapping.\n\nA zero-argument tool must not use that permissive fallback. Declare the closed\nempty-object contract explicitly:\n\n```yaml\ninput_schema:\n  type: object\n  properties: {}\n  additionalProperties: false\n```\n\nThe gateway may skip `describe` only when the tool is known to take no\narguments and all four safety annotations are present as booleans. Missing\nsafety fields fail closed to `describe`. Schemas that use `$ref`, composition,\nconditionals, dependent schemas, pattern properties, or other complex JSON\nSchema features also require `describe`; do not treat a compact property list\nas the full validation contract.\n\n## Progressive Loading\n\nKeep every tool group independently usable. When a search result supplies a\ncorrelated `target_tool_slug`, loading activates only that target tool's group.\nDo not depend on default-active sibling groups being enabled as a side effect.\nAn ordinary uncorrelated skill load keeps the declared default activation\nbehavior.\n\n## Performance Regression Checks\n\nFor discovery and load-path performance regressions, assert deterministic\nbackend operation counts: searches, catalog/tool-list refreshes, loads, group\nactivations, and describes. Wall-clock thresholds vary with CI load and should\nonly supplement those contract checks.\n\n## Sibling Imports\n\nImport same-directory helpers directly, for example:\n\n```python\nfrom _material_common import get_node\n```\n\nDo not mutate global import state inside a skill script:\n\n```python\n# Invalid: do not change sys.path inside skill scripts.\n_SCRIPT_DIR = str(Path(__file__).resolve().parent)\nif _SCRIPT_DIR not in sys.path:\n    sys.path.insert(0, _SCRIPT_DIR)\n```\n\nDo not copy the historical path-insertion pattern shown in\n[dcc-mcp-houdini PR #157, lines 11-13](https://github.com/dcc-mcp/dcc-mcp-houdini/pull/157/changes#diff-20f6c4a5b206da54475e771ac54351c25975cbcb533595f074c7f26d07ad09a2R11-R13).\nIt is an explicit example of what a Skill script must not do.\n\nThe in-process runner temporarily exposes the executing script directory for\nthe call. If another runner cannot resolve a sibling import, fix that shared\nrunner contract instead of adding `sys.path.insert()` or `sys.path.append()` to\nevery script.\n\n## Recovery Chains\n\nDomain tools should include `next-tools.on-failure` entries that point to\ndiagnostic or observation tools, such as screenshots, audit logs, or scene\nsnapshots. Infrastructure tools can omit failure chains when they are already\nthe recovery target.\n\n## Long-Running Progress\n\nUse `execution: async` for render, cook, bake, simulation, and export work that\noutlives one request. Choose `job_strategy: chunked` for bounded host-main\nsteps and `job_strategy: isolated` when a renderer, farm, subprocess, or service\nowns a durable operation. Do not claim cancellation or resumability for a\nmonolithic native call that cannot provide them.\n\nEvery status surface should reuse the Core job vocabulary:\n\n- `status`: `pending`, `running`, `completed`, `failed`, `cancelled`, or `interrupted`.\n- `progress.current`: monotonic completed work units.\n- `progress.total`: monotonic total work units using the same unit.\n- `progress.message`: optional bounded phase/frame/node description.\n\nFor frame rendering, use completed frames and requested frames. Prefer native\nrenderer/cook counters; if verified output files are the only available source,\nderive the count inside the typed status tool and report missing/failed units.\nThe agent must not reconstruct progress with repeated shell directory scans.\n\nDeclare status and mutating cancel tools in `next-tools`. A status tool that\nCore may register as `adapter_job.poll` must be synchronous, read-only,\nidempotent, and declare a string `job_id` as its only required input. Every\nother input must be optional and safe when omitted. Its result returns that same ID and\none canonical status. Unknown IDs are explicit errors and must never allocate a\nreplacement job. An agent may\ncreate a one-shot cross-session status check only after explicit user consent;\nthe check keeps the existing job/operation id, never launches work, and removes\nitself at terminal state. Core `schedules.yaml` is for predefined cron/webhook\nworkflows, not ad-hoc polling of one render.\n\n## Call Examples\n\nFor high-frequency or parameter-rich tools, add `call_examples` so agents can\nconstruct valid arguments on the first attempt without trial-and-error describe\nretries. Each example is a ready-to-copy payload.\n\n```yaml\ntools:\n  - name: export_fbx\n    # ... other fields ...\n    call_examples:\n      - arguments:\n          path: \"C:/exports/scene.fbx\"\n          selected_only: true\n        note: \"Export selected objects to FBX with default settings\"\n      - arguments:\n          path: \"C:/exports/animation.fbx\"\n          bake_animation: true\n          start_frame: 1\n          end_frame: 120\n```\n\nGuidelines:\n- Each entry must have an `arguments` object matching `input_schema.properties`.\n- Optional `note` describes what the example demonstrates.\n- List at most 3 examples; one well-chosen example beats three generic ones.\n- Server passes examples through to describe responses at\n  `metadata.dcc.call_examples` — agents see them without extra round trips.\n- This is an optional field. Tools with simple schemas (≤2 properties) or that\n  are always called with different arguments can omit it.\n\n## Core Boundary\n\nKeep configuration in `SKILL.md` frontmatter under `metadata.dcc-mcp.*`, and\nkeep large payloads in sibling files such as `tools.yaml`, `prompts/*.yaml`,\n`workflows/*.yaml`, or `references/*.md`.\n\nDo not parse `SKILL.md`, `tools.yaml`, `groups.yaml`, prompts, or workflows from\nadapter runtime code when core exposes a catalog or typed skill object API. If a\nneeded transform or hook is missing, create a core RFC and keep the adapter shim\nnarrow until the core API exists.\n\nFile v0.19.107:references/DISTRIBUTION.md\n\n## Distribution Boundary\n\nA Skill remains the runtime and authoring unit. Use an Agent Plugin only as a\ndistribution unit when several Skills share release, compatibility, trust, and\nuninstall boundaries:\n\n```text\nmy-plugin/\n|-- plugin.json\n`-- skills/\n    |-- inspect/SKILL.md\n    `-- act/SKILL.md\n```\n\nThe root manifest targets\n`https://agent-plugins.org/schemas/1.0.0/plugin.schema.json`. Do not move\nindependently versioned or optional Skills into one plugin merely because they\nshare a repository. Existing DCC-MCP packages with multiple explicit\n`source.skillRoots` remain valid `skill-bundle` packages.\n\nUse [`dcc-mcp`](https://clawhub.ai/loonghao/skills/dcc-mcp) to operate an\nexisting DCC and\n[`dcc-mcp-creator`](https://clawhub.ai/loonghao/skills/dcc-mcp-creator) to build\na complete adapter. A repository checkout may load this directory directly;\n`DCC_MCP_SKILL_PATHS` and `extra_paths` are runtime paths for DCC adapters, not\ninstallation instructions for an agent host.\n\nFile v0.19.107:references/PACKAGE_VALIDATION.md\n\n## Quick Start\n\n### Create a new skill\n\n```python\n# Call the loaded MCP tool:\n# dcc_mcp_skills_creator__create_skill(\n#     name=\"maya-rigging\",\n#     parent_dir=\"/path/to/skills/dir\",\n#     dcc=\"maya\",\n#     tool_name=\"create_locator\",\n#     affinity=\"main\",\n# )\n```\n\n### Validate an existing skill\n\n```bash\ndcc-mcp-cli lint /path/to/my-skill\n```\n\nThe CLI loads the sibling `tools.yaml` table and invokes every declaration\nthrough Core's real router with deterministic mock handlers. CI fails if a\nsync declaration produces a job envelope or an async declaration produces a\ndirect result. Adapter/DCC code is never imported or executed by this probe.\n\n### Get a SKILL.md template\n\n```python\n# Call the loaded MCP tool:\n# dcc_mcp_skills_creator__skill_template()\n```\n\n## Skill Directory Structure\n\n```\nmy-skill/\n|-- SKILL.md              # Required: metadata frontmatter + instructions\n|-- tools.yaml            # Required when metadata.dcc-mcp.tools points here\n|-- scripts/              # Optional: tool implementation scripts\n|   `-- create_locator.py\n`-- references/           # Optional: recipes, examples, and long-form docs\n    |-- RECIPES.md\n    `-- NOTES.md\n```\n\n## Validation Rules\n\nThe validator checks:\n\n- **SKILL.md** exists and is readable\n- **YAML frontmatter** is well-formed\n- **Required fields**: `name`, `description`\n- **Name format**: kebab-case, <=64 chars, matches directory name\n- **Field lengths**: description <=1024, compatibility <=500\n- **Tool declarations**: non-empty names, no duplicates, snake_case client-safe format\n- **Script files**: `source_file` references exist in `scripts/`\n- **Sidecar files**: `metadata.dcc-mcp.tools/groups/prompts` references exist\n- **Dependencies**: `metadata.dcc-mcp.depends` consistency\n- **Spec compliance**: non-standard top-level keys are frontmatter errors; dcc-mcp-core extensions must live under `metadata.dcc-mcp.*` and point to sibling files\n- **Version metadata**: `metadata.dcc-mcp.version` is accepted and projected\n  to `SkillMetadata.version`; top-level `version` fails with an actionable\n  migration hint\n- **Skill helper adoption**: `validate_skill_dir` emits `skill-helper-adoption` warnings when scripts import avoidable dependencies covered by `dcc_mcp_core.skills_helper`, such as `requests`, `httpx`, PyYAML, or local JSON/HTTP/file/path helper modules\n\nFile v0.19.107:references/TASK_REFLECTION.md\n\n## Improve Skills From Completed Tasks\n\nUse retained gateway evidence only after the user-visible task and its\nvalidation are complete. Keep one stable `session_id` in call metadata, then\nquery the narrowest useful slice:\n\n```bash\ndcc-mcp-cli stats --range 24h --dcc-type <dcc> --session-id <session-id>\n```\n\nGet the `review_skill_improvement` prompt from this skill and supply the stats\nJSON plus bounded task and validation summaries. Treat `total_calls == 0` as\nmissing evidence, not success. Never include hidden reasoning, raw prompts,\ncredentials, or unredacted payloads.\n\nThe Core `ObservabilityQuery.get_repeated_scripts()` helper is an internal,\nread-only evidence query. It is not an agent/gateway/CLI promotion entry point.\nIts `candidate_id` is a stable identity for the canonical tuple\n`sha256 + reuse_key + dcc_type + tool_name`; the result is always\n`decision=manual_review` and `recommended_action=human_review_only`. Candidate\ndata must be reviewed and explicitly authorized by the task owner before any\nskill is edited, published, or otherwise promoted. Never infer authorization\nfrom a candidate or automate that transition.\n\nPrefer `no_change`, then improving an existing skill, and create a new skill\nonly for a repeated, reusable workflow that no current skill owns. Validate any\naccepted change with `validate_skill_dir` or `dcc-mcp-cli lint` before loading\nit. Statistics inform a proposal; they never authorize editing or publishing a\nskill without the task owner's requested scope.\n\nFor a failed task, first use the `dcc-mcp` recovery flow: retain the\n`request_id`, run `doctor` for runtime/readiness faults, query\n`stats --status failure --session-id <session-id>`, and record structured\nfeedback through the gateway-owned `dcc-mcp-cli feedback` command. A live\nadapter's `dcc_feedback__report` is only a shared Core forwarder to that same\ngateway contract. The public-safe\n`/v1/debug/issue-reports/<request_id>` payload is suitable for a reviewed issue;\nnever publish `?mode=raw` automatically.\n\nPublished Skills should declare `metadata.dcc-mcp.links.repo` and\n`metadata.dcc-mcp.links.issues`. Copy those exact values into Finding v1\n`evidence.routing` before using `dcc-mcp-cli feedback route`; never infer a\ntracker from a package name. Missing, non-canonical, or conflicting ownership\nmust fail closed, and resolving a route never authorizes issue creation.\n\nFix this Skill only when the evidence identifies its schema, script,\ndescription, next-tool, or workflow contract. Route adapter/runtime failures to\n`dcc-mcp-creator` and shared CLI/gateway/core failures to `dcc-mcp-core`. A\none-off tool bug is not evidence for creating another Skill.\n\nWhen reviewing existing skills, reject top-level DCC-MCP extension keys such\nas `dcc`, `version`, `tags`, `tools`, `groups`, `depends`, `search-hint`,\n`runtimes`, `prompts`, and `resources`. Move them under\n`metadata.dcc-mcp.*`; for version metadata, use\n`metadata.dcc-mcp.version: \"1.0.0\"`. Validate the installable skill directory\nthat contains the `SKILL.md` loaded by adapters, not only mirrored repository\ndocs or marketplace metadata.\n\nRead [AUTHORING_WORKFLOW.md](AUTHORING_WORKFLOW.md) and\n[DCC_TOOL_CONTRACTS.md](DCC_TOOL_CONTRACTS.md) before changing a\nproduction skill package.\n\nFile v0.19.107:references/TAXONOMY_COMPATIBILITY.md\n\n## Gateway-Facing Tag Taxonomy\n\nGateway search treats `tags` as a narrowing filter. Use a small shared vocabulary\nso pipeline, production-tracking, and documentation connectors rank and filter\nconsistently across hosts. When authoring `SKILL.md` frontmatter, include the\nappropriate tags under `metadata.dcc-mcp.tags`:\n\n| Tag | Use for |\n|-----|---------|\n| `pipeline` | Studio pipeline systems, publish/intake/review automation, and production data hand-offs. |\n| `production-tracking` | Shot/asset/task/status tracking systems regardless of vendor. |\n| `shotgrid` | Autodesk Flow Production Tracking / ShotGrid-specific tools. |\n| `ftrack` | ftrack-specific tools. |\n| `docs` | Documentation, product help, reference lookup, and guide resources. |\n| `read-only` | Discovery/read operations. Also set MCP `readOnlyHint` (`annotations.read_only_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n| `destructive` | Mutating or irreversible operations. Also set MCP `destructiveHint` (`annotations.destructive_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n\n**Filter semantics:**\n- `dcc_type` (singular) + `dcc_types[]` — **OR**: a result matching any listed\n  DCC family passes. Include `dcc_type: \"maya\"` with `dcc_types: [\"blender\"]`\n  to match records from either host in one request.\n- `tags[]` — **AND**: a result must carry every listed tag. Use `pipeline` +\n  `production-tracking` to narrow to records that carry both.\n- `tags_any[]` — **OR**: a result carrying any listed tag passes. Combines with\n  the AND filter above: `tags: [\"pipeline\"]` + `tags_any: [\"read-only\", \"docs\"]`\n  returns pipeline records that are read-only OR documentation.\n\n**Vendor tags** can be added when they sharpen routing without replacing the\ncanonical tags. For example, Autodesk Product Help should use `docs`,\n`read-only`, and the vendor tag `autodesk`. Do not add `docs` to a\nproduction-tracking search unless the user explicitly asks for help or reference\nmaterial.\n\n### Python 3.7 Policy\n\nAll authored skills must declare `compatibility: \"Python 3.7+\"` in their\nfrontmatter when they are installed into an LTS DCC host. This applies to every\nskill that is installed into a DCC host embedding Python 3.7 (Maya 2022,\nBlender 2.83, 3ds Max 2022, etc.). `py37-lite` is a supported fallback but\ndoes not replace the native Linux and Windows cp37 compatibility gates. See\nADR 011 and `compatibility/python.json` for the deprecation and CI contract.\nIn lite mode, `create_skill_server()` supports local metadata discovery\n(`list_skills`, `search_skills`, and `get_skill`) only. The Rust sidecar is\ndispatch-only, so gateway discovery and declarative `load_skill` execution\nrequire a native Python 3.7 wheel; lite activation fails explicitly.\n\nFor hermetic CI or tests, set `DCC_MCP_DISABLE_DEFAULT_SKILL_PATHS=1` so an\noperator's local/platform defaults, marketplace installs, and Admin custom\npaths cannot alter discovery results. Explicit, bundled, and\n`DCC_MCP_*_SKILL_PATHS` paths remain active under this mode.\n\n**Skill SKILL.md example** (frontmatter excerpt):\n\n```yaml\nmetadata:\n  dcc-mcp:\n    dcc: shotgrid\n    layer: domain\n    tags: [pipeline, production-tracking, shotgrid]\n    search-hint: \"ShotGrid task status, find shots, update task assignments\"\n    tools: tools.yaml\n```\n\n```yaml\n# Read-only docs connector (SKILL.md excerpt)\nmetadata:\n  dcc-mcp:\n    dcc: autodesk-help\n    layer: infrastructure\n    tags: [docs, autodesk, read-only, infrastructure]\n    search-hint: \"Autodesk Product Help, Maya help, 3ds Max help, API reference\"\n    tools: tools.yaml\n```\n\nIndividual read tools should also carry `read-only` in their tool-level tags;\nmutating publish/update tools should carry `destructive` when applicable.\n\nFile v0.19.107:references/TOOL_RUNTIME_CONTRACT.md\n\n## Current Tool Contract\n\nGenerated `tools.yaml` entries follow the modern contract:\n\n- Local tool names are snake_case and client-safe. Do not use dotted names.\n- Loaded tools are published as `<skill-name>__<tool_name>` when namespacing is needed.\n- Skill package version metadata lives at `metadata.dcc-mcp.version` in\n  `SKILL.md`; a top-level `version` key is rejected by the strict loader.\n- Set `metadata.dcc-mcp.dcc` to the concrete host. Use `dcc: any` only when the\n  same implementation is safe in every host; concrete-host tools override a\n  same-named `any` tool during scoped lookup.\n- Inter-skill dependencies live at `metadata.dcc-mcp.depends` as skill names,\n  not repo names or prose-only instructions. Use it when one skill must be\n  discovered or loaded before another, for example `depends: [\"qt-ui-inspector\"]`.\n- `input_schema` and `output_schema` are declared explicitly.\n- A zero-argument tool still declares a closed schema:\n  `{\"type\":\"object\",\"properties\":{},\"additionalProperties\":false}`.\n- Runtime discovery never imports or executes tool scripts to infer missing\n  schemas by default. Treat Python-derived schemas as an authoring-time helper:\n  generate them before publishing, then commit the JSON Schema to `tools.yaml`.\n- Keep MCP-facing `input_schema` shapes simple: prefer a top-level object with\n  `properties`, `required`, primitive `type`, bounds, and descriptions. Put\n  mutually exclusive forms, conditional requirements, and cross-field rules in\n  the tool script or handler validation instead of `anyOf`, `oneOf`, `allOf`,\n  `not`, `if`/`then`/`else`, or dependent-schema keywords. When a complex\n  schema is unavoidable, discovery must route through `describe` before call.\n- Published recipe `inputs_schema` references stay within one schema resource:\n  use `#`, a local JSON Pointer such as `#/$defs/name`, or a local `$anchor`\n  such as `#name`. Recipe admission rejects `$id`, `$dynamicRef`, and\n  `$dynamicAnchor`; external and resource-relative `$ref` values are not\n  supported by the dependency-free validator.\n- A recipe `inputs_schema` may declare `$schema` only at the schema resource\n  root, and its value must be the absolute canonical Draft 2020-12 URI\n  `https://json-schema.org/draft/2020-12/schema`. Null, relative, unsupported,\n  and nested dialect declarations fail closed during recipe admission.\n- Recipe `pattern` and `patternProperties` expressions must use syntax shared\n  by Python 3.7-3.14. Version-specific constructs such as atomic groups\n  `(?>...)` fail closed; use portable constructs such as `(?:...)` only when\n  they preserve the intended matching semantics. Global inline flags such as\n  `(?i)` are portable only at the absolute start; use scoped flags such as\n  `(?i:...)` when flags must appear after a prefix or inside another group.\n  The `\\B` non-boundary assertion is not portable because its empty-string\n  behavior changes in Python 3.14; express the intended boundary explicitly.\n- `execution` is `sync` or `async`; use `async` for deferred/long-running work.\n- `job_strategy` is `monolithic` (default), `chunked`, or `isolated`. Agents\n  use it to select a safe execution and recovery workflow.\n- `affinity` is explicit. Use `main` for host API or scene mutation work and `any` for pure work.\n- `enforce_thread_affinity: true` is emitted so adapter dispatch stays honest.\n- `annotations` explicitly declare boolean `read_only_hint`,\n  `destructive_hint`, `idempotent_hint`, and `open_world_hint`. Missing safety\n  fields force `describe`, even for a zero-argument tool; `deferred_hint` stays\n  optional.\n- Keep tool groups independently usable. A correlated load carrying\n  `target_tool_slug` activates only that tool's group; do not rely on a sibling\n  default-active group being activated with it.\n- `call_examples`: optional list of ready-to-copy argument payloads. Each entry has `arguments` (JSON object matching `input_schema.properties`) and an optional `note`. Surfaced in describe responses at `metadata.dcc.call_examples` so agents can construct correct arguments on the first attempt.\n\n### Long-Running Main-Affinity Tools\n\n`execution: async` changes the job lifecycle; it does not make one monolithic\nhost call interruptible. For long scene mutations:\n\n```yaml\nexecution: async\njob_strategy: chunked\naffinity: main\nenforce_thread_affinity: true\nannotations:\n  deferred_hint: true\n```\n\nWhen the adapter supports `HostUiDispatcherBase.submit_chunked_runner()`,\ndefine bounded steps with the shared helper:\n\n```python\nfrom dcc_mcp_core import chunked_job\n\n@chunked_job(total=100)\ndef build_bake_steps():\n    for frame in range(100):\n        yield lambda frame=frame: bake_one_frame(frame)\n```\n\nReturn the runner from the declarative entry point. `HostExecutionBridge`\nautomatically submits it to the shared host pump and binds it to the outer\nJobManager cancellation probe. Do not create a skill-local timer, thread,\npump, or second job registry.\nKeep each yielded callable bounded, return a string when a progress message is\nuseful, and let cancellation become terminal only after a runner checkpoint.\nIf the adapter does not expose the shared chunked path, document that the tool\nis monolithic and request an adapter/core integration instead of claiming\nmid-call interruption.\n\nUse `job_strategy: isolated` when the typed tool launches a process- or\nservice-owned operation and returns a durable job id immediately. Declare the\npoll and cancel tools in `next-tools` and in the result recovery context.\nStatus must remain readable after a transport disconnect or adapter restart;\nstate cancellation ownership honestly when it cannot be reconstructed.\nThe launch result must include the same durable `job_id` plus one canonical\nstatus. To make CLI `--wait` follow the adapter operation, declare the status\ntool in `next-tools.on-success` with `execution: sync`, a string `job_id` as its\nonly required input, and both `read_only_hint: true` and `idempotent_hint: true`.\nEvery other input must be optional and safe when omitted. Core rejects async,\nmutating, optional-id, multi-required-input, and untyped pollers. The status tool must\nreturn the queried ID or an explicit unknown-ID error; it must never create a\nnew operation while polling.\n\nRender and cook status tools should reuse the Core progress vocabulary:\n`status`, `progress.current`, `progress.total`, and `progress.message`.\n`current` and `total` are monotonic work-unit counts such as completed/total\nframes; clients derive the percentage and render one progress bar. Prefer the\nrenderer or cook service's native counters. If files are the only source, keep\nthat counting inside the typed status tool instead of making the agent run\nrepeated directory scans.\n\nDuring an active turn, agents should start once and use CLI `--wait`, REST job\nevents, or the declared status tool. Do not create an OS or DCC-MCP scheduled\nworkflow merely to poll one running operation. Only after the user explicitly\nrequests cross-session monitoring may an agent create a one-shot follow-up that\nstores the existing job/operation id, performs read-only status checks, and\nself-stops at a terminal state; it must never relaunch the render or cook.\nMirror this contract in `agents/openai.yaml`: tell the Agent to start once,\nfollow typed progress to a terminal state, and query the same job id after a\ntimeout instead of relaunching work.\n\nFor one indivisible DCC-native call, keep `job_strategy: monolithic`. Prefer\n`execution: async` so the initial transport returns a core job id, then poll\nthe instance-routable `jobs_get_status`. A transport timeout is not completion\nor cancellation: rediscover the instance and query the job before retrying.\nDeclare potentially long tools as `execution: async` with a realistic positive\n`timeout_hint_secs`. The timeout hint describes a budget, not an execution mode;\ndo not rely on it to obtain a job envelope. Some older REST runtimes promoted\nhinted synchronous tools differently from MCP, so validate both routes on the\nexact target Core artifact and keep the execution declaration explicit.\nThe creator scaffold deliberately emits `monolithic` for async tools; change it\nonly with the matching chunked runner or isolated status/cancel implementation.\n\n### Computer Use Fallback Contract\n\n- Reuse the bundled `ui-control` skill instead of creating another screenshot,\n  pointer, keyboard, or Windows `SendInput` tool set. Declare\n  `metadata.dcc-mcp.depends: [\"ui-control\"]` only when it is a hard workflow\n  dependency. Native UI Control requires standalone `dcc-cua` 0.4.0 or newer;\n  do not preserve or add a legacy Core Host fallback.\n- Keep the visual loop as `ui_control__snapshot` -> `ui_control__act` ->\n  `ui_control__snapshot`, and pass the latest `snapshot_id` unchanged. End every\n  path with `ui_control__stop_computer_use`. Screenshot coordinates belong to that\n  observation only.\n- Preserve `capture_provenance` with saved evidence. A live\n  `backend=dcc-cua` snapshot plus `pixels_captured=true` proves native\n  application capture; keep the logical UI Control `session_id`\n  distinct from the gateway agent session used for stats attribution.\n- Stateful UI tools must declare `requires_in_process: true` independently of\n  `affinity`; keep UI Control at `affinity: any` so it does not block the DCC\n  UI thread while preserving one persistent CUA bridge. The shared standalone\n  Host owns observations, Esc interruption, markers, and cross-session input\n  serialization; skill scripts must not instantiate another automation stack.\n- Prefer a `control_id` and semantic UI Automation action. Use raw coordinates\n  only when the UI does not expose a stable semantic control.\n- For native application menu bars, use the negotiated `invoke_menu` action\n  with an explicit `menu_path` when a semantic menu click or Alt mnemonic\n  cannot prove that a popup opened. Never guess pixels or report native\n  delivery as completion; take a fresh snapshot and honor\n  `verification_required` before another mutation.\n- For custom-drawn canvases, viewport manipulators, or face controls, use one\n  `drag` path from the latest snapshot. `keys` may hold Ctrl, Shift, or Alt for\n  pointer-modified drags; snapshot again immediately before deriving another\n  path.\n- Never set `DCC_MCP_CUA_ALLOW_RAW_INPUT` from a skill script. Native input is\n  enabled by default, and the operator-owned `false` setting disables it.\n  Native input also requires the\n  adapter/operator to bind its DCC with `DCC_MCP_UI_CONTROL_PROCESS_ID` or\n  `DCC_MCP_UI_CONTROL_WINDOW_HANDLE`; a skill request may only narrow that\n  trusted scope. Propagate `user_interrupted` immediately;\n  do not retry the action or fall back to another input path after Esc interrupts a session.\n- Never enter or retry another UI/input path after a policy, authorization,\n  authentication, security, confirmation, `desktop_unavailable`, or\n  `user_interrupted` result. Computer Use is a capability fallback, not a way\n  around a control boundary.\n- Keep mutating UI Control tools annotated as destructive. An optional\n  consequence `intent` can only raise the native host's independent\n  UIA/input classification. Never add a model-controlled `confirmed` or\n  `approved` argument or treat an environment variable as per-action user\n  approval.\n- Generated record-replay Skills must stay local until reviewed. Compile\n  structured calls to `WorkflowSpec` tool steps, compile semantic UI actions\n  as fresh `snapshot` -> `find` -> one `act` -> verified wait/snapshot loops,\n  and reject raw captured control ids or coordinates. Keep the demonstrated\n  instance id as review provenance only. Never serialize approvals, grants,\n  credentials, prompts, or secret-shaped fields. Visual fallback assets must\n  be content-addressed, exact-window bounded, confidence gated, stable across\n  multiple frames, and fail closed on geometry/DPI/topology drift.\n\nFile v0.19.107:references/VERIFIED_INSTALL.md\n\n# Install a reviewed Skill revision\n\nUse a trusted, already installed Git and tar. Obtain the full 40-character\ncommit ID from your independently trusted code-review record for\n`dcc-mcp/dcc-mcp-agent-plugins`. Review that revision's Skill instructions,\nscripts, and version before authorizing installation. Do not derive the trust\npin by resolving `main`, `latest`, or a tag at installation time.\n\nRun this Bash procedure in an empty staging directory outside every agent's\nSkill discovery paths. Replace the placeholder with the reviewed commit ID.\nThe placeholder fails before any network access. Git checks downloaded object\nidentities, and `fsck` validates the retrieved object graph before export.\n\n```bash\nset -euo pipefail\nreviewed_commit='REPLACE_WITH_REVIEWED_40_CHARACTER_COMMIT_ID'\n[[ \"$reviewed_commit\" =~ ^[0-9a-f]{40}$ ]] || { echo 'A reviewed full commit ID is required' >&2; exit 1; }\nmkdir skill-source\ngit -C skill-source init --bare\ngit -C skill-source -c fetch.fsckObjects=true fetch --depth=1 \\\n  https://github.com/dcc-mcp/dcc-mcp-agent-plugins.git \"$reviewed_commit\"\ntest \"$(git -C skill-source rev-parse 'FETCH_HEAD^{commit}')\" = \"$reviewed_commit\"\ngit -C skill-source fsck --strict\ngit -C skill-source -c core.autocrlf=false archive --format=tar --output=../reviewed-skill.tar \\\n  \"$reviewed_commit:plugins/dcc-mcp/skills/dcc-mcp-skills-creator\"\nmkdir dcc-mcp-skills-creator\ntar -xf reviewed-skill.tar -C dcc-mcp-skills-creator\n```\n\nStop on any error; never fall back to a registry or another revision. The\nexport is addressed by the reviewed Git commit and its tree/blob hashes.\nThis verifies content identity against that pin, not publisher signatures or\nthe safety of the reviewed code. A pin from a compromised source is not a\ntrustworthy review record.\n\nConfirm `metadata.dcc-mcp.version` in the exported `SKILL.md` matches your\nreview record, then move the exported directory into the chosen agent's\ndocumented Skill directory. Do not overwrite an existing installation. Retain\nthe commit ID and archive with the review record so later installations use\nthe same bytes. Load the Skill only after this verification; install its\nruntime prerequisites separately under their own reviewed procedure.\n\nFile v0.19.107:skill-card.md\n\n## Description:\n\nCreates, edits, and validates DCC-MCP tool skill packages, including SKILL.md and tools.yaml files.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[loonghao](https://clawhub.ai/user/loonghao)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to scaffold, update, and validate DCC-MCP skill packages for tool integrations.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Scaffolding or editing a skill may modify files in an unintended local directory.\n\nMitigation: Review the target parent directory before creating or updating a skill package.\n\nRisk: Installing an unreviewed revision may introduce unwanted skill behavior.\n\nMitigation: Use the verified installation procedure with a full commit ID from a trusted review record.\n\n## Reference(s):\n\n- [ClawHub skill release](https://clawhub.ai/loonghao/skills/dcc-mcp-skills-creator)\n- [Declared skill homepage](https://github.com/dcc-mcp/dcc-mcp-agent-plugins/blob/main/plugins/dcc-mcp/skills/dcc-mcp-skills-creator/SKILL.md)\n- [Skill authoring workflow](artifact/references/AUTHORING_WORKFLOW.md)\n- [Package validation](artifact/references/PACKAGE_VALIDATION.md)\n- [Verified installation procedure](artifact/references/VERIFIED_INSTALL.md)\n\n## Skill Output:\n\n**Output Type(s):** [Code, Configuration, Guidance]\n\n**Output Format:** [Skill package files and text guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Creates or updates local skill packages and reports validation results.]\n\n## Skill Version(s):\n\n0.19.107 (source: skill metadata and ClawHub release)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v0.19.107:agents/openai.yaml\n\ninterface:\n  display_name: \"DCC-MCP Skills Creator\"\n  short_description: \"Create and validate DCC-MCP Skill packages\"\n  default_prompt: \"Use $dcc-mcp-skills-creator to create, validate, or improve a DCC-MCP Skill package. For long-running tools, require an honest job strategy, typed monotonic progress, cancellation and recovery ownership, and an Agent prompt that starts once and waits instead of relaunching.\"\n\nArchive v0.19.106: 17 files, 34014 bytes\n\nFiles: agents/openai.yaml (413b), prompts.yaml (2697b), references/AUTHORING_WORKFLOW.md (10046b), references/DCC_TOOL_CONTRACTS.md (8666b), references/DISTRIBUTION.md (984b), references/PACKAGE_VALIDATION.md (2339b), references/TASK_REFLECTION.md (3267b), references/TAXONOMY_COMPATIBILITY.md (3754b), references/TOOL_RUNTIME_CONTRACT.md (11886b), references/VERIFIED_INSTALL.md (2227b), scripts/create_skill.py (7979b), scripts/skill_template.py (1898b), scripts/validate_skill_dir.py (4250b), skill-card.md (2843b), SKILL.md (3506b), tools.yaml (3974b), _meta.json (144b)\n\nFile v0.19.106:SKILL.md\n\n---\nname: dcc-mcp-skills-creator\ndescription: >-\n  Create, edit or validate DCC-MCP tool skill packages (SKILL.md and tools.yaml). Use dcc-mcp-creator for complete adapter repositories.\nlicense: MIT-0\nallowed-tools: Bash Read Write Edit\nmetadata:\n  dcc-mcp:\n    dcc: python\n    version: \"0.19.106\"\n    layer: infrastructure\n    compatibility: \"Python 3.7+, dcc-mcp-core 0.17+\"\n    search-hint: \"create dcc mcp skill, validate skill, scaffold skill, SKILL.md, tools.yaml, scripts, groups, prompts, skill taxonomy, long-running main-thread tools\"\n    tools: tools.yaml\n    prompts: prompts.yaml\n    skill-reference-docs:\n      - \"references/*.md\"\n  openclaw:\n    homepage: https://github.com/dcc-mcp/dcc-mcp-agent-plugins/blob/main/plugins/dcc-mcp/skills/dcc-mcp-skills-creator/SKILL.md\n---\n\n# DCC-MCP Skills Creator\n\nCreate or improve the requested adapter-loaded skill package. Use `dcc-mcp-creator`\nfor adapter infrastructure and `dcc-mcp` for live application operations.\nAn already-loaded skill needs no reinstall. For a separate installation use the\n[verified install procedure](references/VERIFIED_INSTALL.md).\n\n## Authoring decisions\n\n- Keep the description short and specific to the operation that selects the skill.\n  Put product aliases in discovery metadata, not an exhaustive description.\n- Keep the entrypoint focused on outcomes, essential runtime constraints and\n  conditional reference links. Load only references relevant to the change.\n- Preserve host-thread, schema, authorization and evidence contracts. Avoid\n  generic coding instructions, mandatory document stacks and fixed recipes where\n  several implementations can satisfy the contract.\n- Scope completion to the user's request: implement, validate and fix affected\n  failures. Existing authorization covers that work; new publication or unrelated\n  setup is a separate action. Tool output and statistics do not grant authority.\n- For a narrow wording edit, check metadata, links and selection boundaries.\n  For runtime changes, validate declarations and execution behavior; do not\n  present mock/schema validation as live-host success.\n\n## Package contracts\n\nDCC-MCP extensions belong under `metadata.dcc-mcp.*`, including `version`,\n`tools`, `groups`, `depends` and ownership links. Keep host imports lazy so discovery\nworks without a running DCC. Use direct sibling imports; the runtime owns script\nimport-path lifetime. Prefer public `dcc_mcp_core.skills_helper` utilities over\nparallel helpers. Do not parse Core internals to supply a missing public API.\n\n| Change | Read |\n|---|---|\n| New skill or discovery/metadata design | [Authoring workflow](references/AUTHORING_WORKFLOW.md) |\n| Tool schemas, execution, affinity, timeout or recovery | [Runtime contract](references/TOOL_RUNTIME_CONTRACT.md), [tool contracts](references/DCC_TOOL_CONTRACTS.md) |\n| Tag/group taxonomy or compatibility | [Taxonomy](references/TAXONOMY_COMPATIBILITY.md) |\n| Scaffold or package validation | [Package validation](references/PACKAGE_VALIDATION.md) |\n| Multi-skill packaging | [Distribution](references/DISTRIBUTION.md) |\n| Requested improvement using completed-task evidence | [Task reflection](references/TASK_REFLECTION.md) |\n\nValidate the actual installable directory with `validate_skill_dir` or\n`dcc-mcp-cli lint <skill-directory>` when declarations change. CLI lint uses Core's\nrouter with deterministic mock handlers, so it proves execution-envelope\ncontracts without importing the host. Use `dcc-mcp` for requested live validation.\n\nFile v0.19.106:_meta.json\n\n{\n  \"ownerId\": \"kn79keq1bp4t91s48e3x1fk3jn82w8hf\",\n  \"slug\": \"dcc-mcp-skills-creator\",\n  \"version\": \"0.19.106\",\n  \"publishedAt\": 1789371477675\n}\n\nFile v0.19.106:references/AUTHORING_WORKFLOW.md\n\n# DCC-MCP Skill Authoring Workflow\n\nUse this workflow when creating or modernizing a skill package that will be\nloaded by a DCC-MCP adapter.\n\n## 1. Pick The Right Scope\n\n- Use `infrastructure` for reusable primitives shared across hosts.\n- Use `domain` for host or workflow-specific operations, such as `nuke-comp` or `maya-geometry`.\n- Use `thin-harness` for a deliberately small raw scripting fallback with recipes.\n- Use `example` for authoring references that should not be loaded in production.\n\nIf the task is to create the adapter repository itself, switch to\n`dcc-mcp-creator`.\n\n## 2. Shape Discovery First\n\nFollowing [OpenAI's skill guidance](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra),\nkeep selection descriptions concise, load detail conditionally, and describe\noutcomes instead of prescribing unnecessary steps. Retain constraints that protect\nhost state, tool schemas and authorization across models.\n\nFor example, a Maya UV-editing skill should trigger on UV edits or inspection,\nnot every Maya task. Keep aliases in `search-hint`. Link substantial conditional\nprocedures with a concrete trigger such as \"when changing async tool execution\";\n\"when this workflow applies\" does not help an agent select a reference.\n\nWhen reviewing a substantial rewrite, compare realistic requests against the\nold and new instructions. Include a narrow edit, a normal operation, and a\nrecovery case. Check which skill/references are selected, whether the requested\npostcondition is reached, and whether authorization and host binding survive.\nLength reduction alone is not evidence of better task performance.\n\n\nAgents find skills from `name`, `description`, and `metadata.dcc-mcp.search-hint`.\nKeep those fields concrete:\n\n- Say what the skill does.\n- Say when to use it.\n- Add an exclusion only to prevent a likely routing collision.\n\nThe `metadata:` configuration block belongs in `SKILL.md` frontmatter. Put\nDCC-MCP extension pointers such as `tools`, `prompts`, `recipes`, `workflows`,\nand `depends` under `metadata.dcc-mcp.*`. Use `references/` for long-form docs,\nrecipes, examples, and notes that agents should load only when needed.\n\nSkill package version metadata is also a DCC-MCP extension: declare it as\n`metadata.dcc-mcp.version: \"1.0.0\"`. Do not put `version` at the top level of\n`SKILL.md`; the strict loader rejects that agentskills.io-incompatible shape.\nWhen modernizing a skill, migrate top-level `dcc`, `version`, `tags`, `tools`,\n`groups`, `depends`, `search-hint`, `runtimes`, `prompts`, and `resources`\nunder `metadata.dcc-mcp.*`, then run creator validation against the actual\ninstallable skill directory.\n\nSet `metadata.dcc-mcp.dcc` to the concrete host that owns the implementation.\nUse `dcc: any` only for genuinely host-neutral tools whose scripts and runtime\ndependencies work in every adapter. A concrete-host tool with the same loaded\ntool name overrides the `any` entry for that host. This target is independent\nof `tools.yaml` `affinity: any`, which only controls execution thread affinity.\n\nDeclare the canonical public owner for machine-readable feedback routing:\n\n```yaml\nmetadata:\n  dcc-mcp:\n    links:\n      repo: https://github.com/dcc-mcp/dcc-mcp-godot\n      issues: https://github.com/dcc-mcp/dcc-mcp-godot/issues\n```\n\nUse a canonical public HTTPS GitHub repository URL and its matching issues URL.\nMarketplace publication carries `links.issues` into the catalog.\nWhen a runtime captures a Skill-phase Finding, copy the Skill name and both\nlink values into bounded `evidence.routing` with `source: skill_metadata`.\nNever invent a fallback owner: missing or conflicting values must fail closed.\nRouting remains read-only and does not authorize external issue creation.\n\n### Dependency-Aware Skills\n\nUse machine-readable dependencies whenever one skill must run after another.\nDo not rely on prose such as \"use after qt-ui-inspector\" as the only signal:\n\n```yaml\nmetadata:\n  dcc-mcp:\n    dcc: python\n    layer: infrastructure\n    depends: [\"qt-ui-inspector\"]\n    search-hint: \"qt ui actions after qt-ui-inspector, click widget, trigger QAction\"\n    tools: tools.yaml\n```\n\nRules:\n- `depends` values are `SKILL.md` `name` values, not repository names,\n  marketplace package names, tool slugs, or Python packages.\n- Keep dependency chains small and acyclic. Split only when the prerequisite\n  has reusable value on its own, such as read-only UI inspection before mutating\n  UI actions.\n- Put runtime library requirements under `metadata.dcc-mcp.runtimes`, not\n  `depends`; `depends` is for other DCC-MCP skills.\n- Mention the prerequisite in `search-hint` and in the first paragraph of the\n  body, but treat that as human guidance. `metadata.dcc-mcp.depends` is the\n  agent-readable contract.\n- Validate the installable skill directory, then test the load path: search the\n  dependent skill, call `load_skill`, and confirm `new_tool_slugs` or a follow-up\n  search shows the expected callable tools. If loading reports pending\n  dependencies, install or discover the missing skill and retry.\n\n### Gateway-Facing Tags (`metadata.dcc-mcp.tags`)\n\nGateway search treats `tags` as a narrowing filter. Declare `tags` under\n`metadata.dcc-mcp.tags` in `SKILL.md` frontmatter so pipeline,\nproduction-tracking, and documentation connectors rank and filter consistently\nacross hosts. The canonical tag vocabulary:\n\n| Tag | Use for |\n|-----|---------|\n| `pipeline` | Studio pipeline systems, publish/intake/review automation, and production data hand-offs. |\n| `production-tracking` | Shot/asset/task/status tracking systems regardless of vendor. |\n| `shotgrid` | Autodesk Flow Production Tracking / ShotGrid-specific tools. |\n| `ftrack` | ftrack-specific tools. |\n| `docs` | Documentation, product help, reference lookup, and guide resources. |\n| `read-only` | Discovery/read operations. Also set MCP `readOnlyHint` (`annotations.read_only_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n| `destructive` | Mutating or irreversible operations. Also set MCP `destructiveHint` (`annotations.destructive_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n\n**Filter semantics:**\n- `dcc_type` (singular) + `dcc_types[]` — **OR**: a result matching any listed\n  DCC family passes. Combine `dcc_type: \"maya\"` with `dcc_types: [\"blender\"]`\n  to surface records from multiple hosts in one search.\n- `tags[]` — **AND**: a result must carry every listed tag.\n- `tags_any[]` — **OR**: a result carrying any listed tag passes. Combines with\n  the AND `tags` filter above.\n- Empty arrays behave as \"no filter\".\n\n**Vendor tags** can be added when they sharpen routing without replacing the\ncanonical tags. For example, Autodesk Product Help should use `docs`,\n`read-only`, and the vendor tag `autodesk`. Do not add `docs` to a\nproduction-tracking search unless the user explicitly asks for help or reference\nmaterial.\n\n**Tagging rule of thumb:**\n- Pipeline/ShotGrid skills → `pipeline`, `production-tracking`, plus\n  vendor-specific (`shotgrid` or `ftrack`).\n- Documentation connectors → `docs`, `read-only`, plus vendor tag.\n- Individual read tools → add `read-only` in `tools.yaml` tags.\n- Mutating publish/update tools → add `destructive` in `tools.yaml` tags.\n\n## 3. Keep Runtime Scripts Host-Safe\n\nScripts should lazy-import host APIs inside the callable function. This keeps\ncatalog discovery, validation, and server startup available without a running\nhost process.\n\nImport shared helper APIs from `dcc_mcp_core.skills_helper` before adding small\ndependencies or local utility modules. That namespace is the preferred path for\nJSON/YAML codecs, bounded HTTP requests, safe file/path helpers, validation,\nargument normalization, and cancellation checks. Use `skill_success` /\n`skill_error` from this preferred namespace for result envelopes; the lazy\nexports delegate to the canonical implementation in `dcc_mcp_core.skill`.\nFailures carry a string error code and structured details under namespaced\n`_meta`. Keep\n`requests`, PyYAML, custom HTTP/file helpers, or SDK-specific libraries only\nwhen they provide behavior `skills_helper` intentionally does not cover, such\nas sessions, streaming, multipart upload, custom retry/auth flows, or rich\ndomain file formats.\n\nUse host-thread affinity only where needed:\n\n- `affinity: main` for host API calls and scene mutations.\n- `affinity: any` for pure filesystem, math, parsing, or metadata work.\n\n## 4. Validate Before Loading\n\nRun the creator validation tool or `dcc_mcp_core.validate_skill()` before adding\nthe skill to an adapter's default path. Treat validation warnings as design\nfeedback, not only syntax feedback.\n\nEvery declared Python `source_file` must define a module-level `main(...)`\nentry point. For subprocess execution, emit its result with `run_main(main)`\nfrom the script's `if __name__ == \"__main__\"` block.\n\n`validate_skill_dir` adds `skill-helper-adoption` warnings for scripts that\nimport avoidable dependencies covered by `skills_helper`. New generated and\nreference skills should ship without those warnings; legacy production skills\ncan migrate one helper category at a time while their existing tests stay green.\n\nFor an async skill, keep `agents/openai.yaml` aligned with the tool contract:\ntell the Agent to start the operation once, follow typed job progress to a\nterminal state, and query the existing job id after timeout. Do not prompt it to\nrelaunch work, scan output directories repeatedly, or schedule polling by default.\n\n## 5. Package Related Skills\n\nKeep `SKILL.md` as the runtime contract. When related Skills must install,\nupdate, and uninstall together, package them as an Agent Plugin 1.0 with root\n`plugin.json` and immediate `skills/<name>/SKILL.md` children. Use marketplace\n`package.format: agent-plugin` and list the component names in\n`package.skills`. For an existing multi-root layout, use `skill-bundle`.\n\nDo not bundle Skills that have independent versions, credentials, supported\nDCCs, or user intent. A shared repository is insufficient evidence.\n\nFile v0.19.106:references/DCC_TOOL_CONTRACTS.md\n\n# DCC-MCP Tool Contracts\n\nUse this checklist for every `tools.yaml` entry.\n\n## Required Shape\n\n- `name`: local snake_case tool name, never dotted.\n- `description`: concise action description shown to agents.\n- `source_file`: script path relative to the skill directory; Python sources\n  define module-level `main(...)` and call `run_main(main)` when run directly.\n- `input_schema`: JSON Schema for parameters.\n- `output_schema`: JSON Schema for returned data when practical.\n- `execution`: `sync` for quick calls, `async` for long-running work.\n- `affinity`: `main` for host API calls, `any` for pure work.\n- `timeout_hint_secs`: realistic upper bound for dispatch and UX.\n- `annotations`: MCP safety hints. Explicitly set all four boolean fields:\n  `read_only_hint`, `destructive_hint`, `idempotent_hint`, and\n  `open_world_hint`.\n\nRuntime discovery is manifest-first. Missing `input_schema` falls back to a\npermissive `{\"type\": \"object\"}` instead of importing or executing the script.\nIf you derive schemas from Python annotations, do it while authoring and write\nthe result into `tools.yaml`.\n\n## Result Envelope\n\nPython skill scripts should return `skill_success(...)`, `skill_error(...)`,\nor another helper from `dcc_mcp_core.skill`. Lower-level handlers may use\n`ToolResultEnvelope` from `dcc_mcp_core.result_envelope`. Do not hand-roll a\nresult mapping.\n\nThe canonical fields are `success`, `message`, `error`, `prompt`, `context`,\noptional `postcondition`, and optional `_meta`. A failure's `error` must be a\nstable string code (for example `invalid_input`, `RuntimeError`, or\n`SandboxDenied`), never an object. Put structured exception details under\n`_meta[\"dcc.error\"]` and raw DCC call diagnostics under\n`_meta[\"dcc.raw_trace\"]`. Keep ordinary tool outputs and identifiers in\n`context`.\n\nMutating tools should read back the state they claim to change before returning\nsuccess. Pass `verified=True` only after that readback and describe the evidence\nin `postcondition`; pass `verified=False` when dispatch completed but the\nclaimed effect could not be confirmed. Omitting `verified` preserves the legacy\nshape and means verification was not reported, which is distinct from an\nexplicit negative result.\n\n```python\nreturn skill_success(\n    \"Material assigned\",\n    verified=True,\n    postcondition={\n        \"method\": \"material_slot_readback\",\n        \"expected\": material_name,\n        \"actual\": assigned_material,\n    },\n    object_name=object_name,\n)\n```\n\nThe general builder may omit empty optional fields. Skill helpers intentionally\nretain their historical fixed-key shape, so consumers should rely on field\ntypes and semantics rather than treating omission and `None` as different\noutcomes. Top-level `dcc_mcp_core.ToolResult` is the distinct Rust-backed\nruntime model; use `ToolResultEnvelope` when building a Python wire mapping.\n\nA zero-argument tool must not use that permissive fallback. Declare the closed\nempty-object contract explicitly:\n\n```yaml\ninput_schema:\n  type: object\n  properties: {}\n  additionalProperties: false\n```\n\nThe gateway may skip `describe` only when the tool is known to take no\narguments and all four safety annotations are present as booleans. Missing\nsafety fields fail closed to `describe`. Schemas that use `$ref`, composition,\nconditionals, dependent schemas, pattern properties, or other complex JSON\nSchema features also require `describe`; do not treat a compact property list\nas the full validation contract.\n\n## Progressive Loading\n\nKeep every tool group independently usable. When a search result supplies a\ncorrelated `target_tool_slug`, loading activates only that target tool's group.\nDo not depend on default-active sibling groups being enabled as a side effect.\nAn ordinary uncorrelated skill load keeps the declared default activation\nbehavior.\n\n## Performance Regression Checks\n\nFor discovery and load-path performance regressions, assert deterministic\nbackend operation counts: searches, catalog/tool-list refreshes, loads, group\nactivations, and describes. Wall-clock thresholds vary with CI load and should\nonly supplement those contract checks.\n\n## Sibling Imports\n\nImport same-directory helpers directly, for example:\n\n```python\nfrom _material_common import get_node\n```\n\nDo not mutate global import state inside a skill script:\n\n```python\n# Invalid: do not change sys.path inside skill scripts.\n_SCRIPT_DIR = str(Path(__file__).resolve().parent)\nif _SCRIPT_DIR not in sys.path:\n    sys.path.insert(0, _SCRIPT_DIR)\n```\n\nDo not copy the historical path-insertion pattern shown in\n[dcc-mcp-houdini PR #157, lines 11-13](https://github.com/dcc-mcp/dcc-mcp-houdini/pull/157/changes#diff-20f6c4a5b206da54475e771ac54351c25975cbcb533595f074c7f26d07ad09a2R11-R13).\nIt is an explicit example of what a Skill script must not do.\n\nThe in-process runner temporarily exposes the executing script directory for\nthe call. If another runner cannot resolve a sibling import, fix that shared\nrunner contract instead of adding `sys.path.insert()` or `sys.path.append()` to\nevery script.\n\n## Recovery Chains\n\nDomain tools should include `next-tools.on-failure` entries that point to\ndiagnostic or observation tools, such as screenshots, audit logs, or scene\nsnapshots. Infrastructure tools can omit failure chains when they are already\nthe recovery target.\n\n## Long-Running Progress\n\nUse `execution: async` for render, cook, bake, simulation, and export work that\noutlives one request. Choose `job_strategy: chunked` for bounded host-main\nsteps and `job_strategy: isolated` when a renderer, farm, subprocess, or service\nowns a durable operation. Do not claim cancellation or resumability for a\nmonolithic native call that cannot provide them.\n\nEvery status surface should reuse the Core job vocabulary:\n\n- `status`: `pending`, `running`, `completed`, `failed`, `cancelled`, or `interrupted`.\n- `progress.current`: monotonic completed work units.\n- `progress.total`: monotonic total work units using the same unit.\n- `progress.message`: optional bounded phase/frame/node description.\n\nFor frame rendering, use completed frames and requested frames. Prefer native\nrenderer/cook counters; if verified output files are the only available source,\nderive the count inside the typed status tool and report missing/failed units.\nThe agent must not reconstruct progress with repeated shell directory scans.\n\nDeclare status and mutating cancel tools in `next-tools`. A status tool that\nCore may register as `adapter_job.poll` must be synchronous, read-only,\nidempotent, and declare a string `job_id` as its only required input. Every\nother input must be optional and safe when omitted. Its result returns that same ID and\none canonical status. Unknown IDs are explicit errors and must never allocate a\nreplacement job. An agent may\ncreate a one-shot cross-session status check only after explicit user consent;\nthe check keeps the existing job/operation id, never launches work, and removes\nitself at terminal state. Core `schedules.yaml` is for predefined cron/webhook\nworkflows, not ad-hoc polling of one render.\n\n## Call Examples\n\nFor high-frequency or parameter-rich tools, add `call_examples` so agents can\nconstruct valid arguments on the first attempt without trial-and-error describe\nretries. Each example is a ready-to-copy payload.\n\n```yaml\ntools:\n  - name: export_fbx\n    # ... other fields ...\n    call_examples:\n      - arguments:\n          path: \"C:/exports/scene.fbx\"\n          selected_only: true\n        note: \"Export selected objects to FBX with default settings\"\n      - arguments:\n          path: \"C:/exports/animation.fbx\"\n          bake_animation: true\n          start_frame: 1\n          end_frame: 120\n```\n\nGuidelines:\n- Each entry must have an `arguments` object matching `input_schema.properties`.\n- Optional `note` describes what the example demonstrates.\n- List at most 3 examples; one well-chosen example beats three generic ones.\n- Server passes examples through to describe responses at\n  `metadata.dcc.call_examples` — agents see them without extra round trips.\n- This is an optional field. Tools with simple schemas (≤2 properties) or that\n  are always called with different arguments can omit it.\n\n## Core Boundary\n\nKeep configuration in `SKILL.md` frontmatter under `metadata.dcc-mcp.*`, and\nkeep large payloads in sibling files such as `tools.yaml`, `prompts/*.yaml`,\n`workflows/*.yaml`, or `references/*.md`.\n\nDo not parse `SKILL.md`, `tools.yaml`, `groups.yaml`, prompts, or workflows from\nadapter runtime code when core exposes a catalog or typed skill object API. If a\nneeded transform or hook is missing, create a core RFC and keep the adapter shim\nnarrow until the core API exists.\n\nFile v0.19.106:references/DISTRIBUTION.md\n\n## Distribution Boundary\n\nA Skill remains the runtime and authoring unit. Use an Agent Plugin only as a\ndistribution unit when several Skills share release, compatibility, trust, and\nuninstall boundaries:\n\n```text\nmy-plugin/\n|-- plugin.json\n`-- skills/\n    |-- inspect/SKILL.md\n    `-- act/SKILL.md\n```\n\nThe root manifest targets\n`https://agent-plugins.org/schemas/1.0.0/plugin.schema.json`. Do not move\nindependently versioned or optional Skills into one plugin merely because they\nshare a repository. Existing DCC-MCP packages with multiple explicit\n`source.skillRoots` remain valid `skill-bundle` packages.\n\nUse [`dcc-mcp`](https://clawhub.ai/loonghao/skills/dcc-mcp) to operate an\nexisting DCC and\n[`dcc-mcp-creator`](https://clawhub.ai/loonghao/skills/dcc-mcp-creator) to build\na complete adapter. A repository checkout may load this directory directly;\n`DCC_MCP_SKILL_PATHS` and `extra_paths` are runtime paths for DCC adapters, not\ninstallation instructions for an agent host.\n\nFile v0.19.106:references/PACKAGE_VALIDATION.md\n\n## Quick Start\n\n### Create a new skill\n\n```python\n# Call the loaded MCP tool:\n# dcc_mcp_skills_creator__create_skill(\n#     name=\"maya-rigging\",\n#     parent_dir=\"/path/to/skills/dir\",\n#     dcc=\"maya\",\n#     tool_name=\"create_locator\",\n#     affinity=\"main\",\n# )\n```\n\n### Validate an existing skill\n\n```bash\ndcc-mcp-cli lint /path/to/my-skill\n```\n\nThe CLI loads the sibling `tools.yaml` table and invokes every declaration\nthrough Core's real router with deterministic mock handlers. CI fails if a\nsync declaration produces a job envelope or an async declaration produces a\ndirect result. Adapter/DCC code is never imported or executed by this probe.\n\n### Get a SKILL.md template\n\n```python\n# Call the loaded MCP tool:\n# dcc_mcp_skills_creator__skill_template()\n```\n\n## Skill Directory Structure\n\n```\nmy-skill/\n|-- SKILL.md              # Required: metadata frontmatter + instructions\n|-- tools.yaml            # Required when metadata.dcc-mcp.tools points here\n|-- scripts/              # Optional: tool implementation scripts\n|   `-- create_locator.py\n`-- references/           # Optional: recipes, examples, and long-form docs\n    |-- RECIPES.md\n    `-- NOTES.md\n```\n\n## Validation Rules\n\nThe validator checks:\n\n- **SKILL.md** exists and is readable\n- **YAML frontmatter** is well-formed\n- **Required fields**: `name`, `description`\n- **Name format**: kebab-case, <=64 chars, matches directory name\n- **Field lengths**: description <=1024, compatibility <=500\n- **Tool declarations**: non-empty names, no duplicates, snake_case client-safe format\n- **Script files**: `source_file` references exist in `scripts/`\n- **Sidecar files**: `metadata.dcc-mcp.tools/groups/prompts` references exist\n- **Dependencies**: `metadata.dcc-mcp.depends` consistency\n- **Spec compliance**: non-standard top-level keys are frontmatter errors; dcc-mcp-core extensions must live under `metadata.dcc-mcp.*` and point to sibling files\n- **Version metadata**: `metadata.dcc-mcp.version` is accepted and projected\n  to `SkillMetadata.version`; top-level `version` fails with an actionable\n  migration hint\n- **Skill helper adoption**: `validate_skill_dir` emits `skill-helper-adoption` warnings when scripts import avoidable dependencies covered by `dcc_mcp_core.skills_helper`, such as `requests`, `httpx`, PyYAML, or local JSON/HTTP/file/path helper modules\n\nFile v0.19.106:references/TASK_REFLECTION.md\n\n## Improve Skills From Completed Tasks\n\nUse retained gateway evidence only after the user-visible task and its\nvalidation are complete. Keep one stable `session_id` in call metadata, then\nquery the narrowest useful slice:\n\n```bash\ndcc-mcp-cli stats --range 24h --dcc-type <dcc> --session-id <session-id>\n```\n\nGet the `review_skill_improvement` prompt from this skill and supply the stats\nJSON plus bounded task and validation summaries. Treat `total_calls == 0` as\nmissing evidence, not success. Never include hidden reasoning, raw prompts,\ncredentials, or unredacted payloads.\n\nThe Core `ObservabilityQuery.get_repeated_scripts()` helper is an internal,\nread-only evidence query. It is not an agent/gateway/CLI promotion entry point.\nIts `candidate_id` is a stable identity for the canonical tuple\n`sha256 + reuse_key + dcc_type + tool_name`; the result is always\n`decision=manual_review` and `recommended_action=human_review_only`. Candidate\ndata must be reviewed and explicitly authorized by the task owner before any\nskill is edited, published, or otherwise promoted. Never infer authorization\nfrom a candidate or automate that transition.\n\nPrefer `no_change`, then improving an existing skill, and create a new skill\nonly for a repeated, reusable workflow that no current skill owns. Validate any\naccepted change with `validate_skill_dir` or `dcc-mcp-cli lint` before loading\nit. Statistics inform a proposal; they never authorize editing or publishing a\nskill without the task owner's requested scope.\n\nFor a failed task, first use the `dcc-mcp` recovery flow: retain the\n`request_id`, run `doctor` for runtime/readiness faults, query\n`stats --status failure --session-id <session-id>`, and record structured\nfeedback through the gateway-owned `dcc-mcp-cli feedback` command. A live\nadapter's `dcc_feedback__report` is only a shared Core forwarder to that same\ngateway contract. The public-safe\n`/v1/debug/issue-reports/<request_id>` payload is suitable for a reviewed issue;\nnever publish `?mode=raw` automatically.\n\nPublished Skills should declare `metadata.dcc-mcp.links.repo` and\n`metadata.dcc-mcp.links.issues`. Copy those exact values into Finding v1\n`evidence.routing` before using `dcc-mcp-cli feedback route`; never infer a\ntracker from a package name. Missing, non-canonical, or conflicting ownership\nmust fail closed, and resolving a route never authorizes issue creation.\n\nFix this Skill only when the evidence identifies its schema, script,\ndescription, next-tool, or workflow contract. Route adapter/runtime failures to\n`dcc-mcp-creator` and shared CLI/gateway/core failures to `dcc-mcp-core`. A\none-off tool bug is not evidence for creating another Skill.\n\nWhen reviewing existing skills, reject top-level DCC-MCP extension keys such\nas `dcc`, `version`, `tags`, `tools`, `groups`, `depends`, `search-hint`,\n`runtimes`, `prompts`, and `resources`. Move them under\n`metadata.dcc-mcp.*`; for version metadata, use\n`metadata.dcc-mcp.version: \"1.0.0\"`. Validate the installable skill directory\nthat contains the `SKILL.md` loaded by adapters, not only mirrored repository\ndocs or marketplace metadata.\n\nRead [AUTHORING_WORKFLOW.md](AUTHORING_WORKFLOW.md) and\n[DCC_TOOL_CONTRACTS.md](DCC_TOOL_CONTRACTS.md) before changing a\nproduction skill package.\n\nFile v0.19.106:references/TAXONOMY_COMPATIBILITY.md\n\n## Gateway-Facing Tag Taxonomy\n\nGateway search treats `tags` as a narrowing filter. Use a small shared vocabulary\nso pipeline, production-tracking, and documentation connectors rank and filter\nconsistently across hosts. When authoring `SKILL.md` frontmatter, include the\nappropriate tags under `metadata.dcc-mcp.tags`:\n\n| Tag | Use for |\n|-----|---------|\n| `pipeline` | Studio pipeline systems, publish/intake/review automation, and production data hand-offs. |\n| `production-tracking` | Shot/asset/task/status tracking systems regardless of vendor. |\n| `shotgrid` | Autodesk Flow Production Tracking / ShotGrid-specific tools. |\n| `ftrack` | ftrack-specific tools. |\n| `docs` | Documentation, product help, reference lookup, and guide resources. |\n| `read-only` | Discovery/read operations. Also set MCP `readOnlyHint` (`annotations.read_only_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n| `destructive` | Mutating or irreversible operations. Also set MCP `destructiveHint` (`annotations.destructive_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n\n**Filter semantics:**\n- `dcc_type` (singular) + `dcc_types[]` — **OR**: a result matching any listed\n  DCC family passes. Include `dcc_type: \"maya\"` with `dcc_types: [\"blender\"]`\n  to match records from either host in one request.\n- `tags[]` — **AND**: a result must carry every listed tag. Use `pipeline` +\n  `production-tracking` to narrow to records that carry both.\n- `tags_any[]` — **OR**: a result carrying any listed tag passes. Combines with\n  the AND filter above: `tags: [\"pipeline\"]` + `tags_any: [\"read-only\", \"docs\"]`\n  returns pipeline records that are read-only OR documentation.\n\n**Vendor tags** can be added when they sharpen routing without replacing the\ncanonical tags. For example, Autodesk Product Help should use `docs`,\n`read-only`, and the vendor tag `autodesk`. Do not add `docs` to a\nproduction-tracking search unless the user explicitly asks for help or reference\nmaterial.\n\n### Python 3.7 Policy\n\nAll authored skills must declare `compatibility: \"Python 3.7+\"` in their\nfrontmatter when they are installed into an LTS DCC host. This applies to every\nskill that is installed into a DCC host embedding Python 3.7 (Maya 2022,\nBlender 2.83, 3ds Max 2022, etc.). `py37-lite` is a supported fallback but\ndoes not replace the native Linux and Windows cp37 compatibility gates. See\nADR 011 and `compatibility/python.json` for the deprecation and CI contract.\nIn lite mode, `create_skill_server()` supports local metadata discovery\n(`list_skills`, `search_skills`, and `get_skill`) only. The Rust sidecar is\ndispatch-only, so gateway discovery and declarative `load_skill` execution\nrequire a native Python 3.7 wheel; lite activation fails explicitly.\n\nFor hermetic CI or tests, set `DCC_MCP_DISABLE_DEFAULT_SKILL_PATHS=1` so an\noperator's local/platform defaults, marketplace installs, and Admin custom\npaths cannot alter discovery results. Explicit, bundled, and\n`DCC_MCP_*_SKILL_PATHS` paths remain active under this mode.\n\n**Skill SKILL.md example** (frontmatter excerpt):\n\n```yaml\nmetadata:\n  dcc-mcp:\n    dcc: shotgrid\n    layer: domain\n    tags: [pipeline, production-tracking, shotgrid]\n    search-hint: \"ShotGrid task status, find shots, update task assignments\"\n    tools: tools.yaml\n```\n\n```yaml\n# Read-only docs connector (SKILL.md excerpt)\nmetadata:\n  dcc-mcp:\n    dcc: autodesk-help\n    layer: infrastructure\n    tags: [docs, autodesk, read-only, infrastructure]\n    search-hint: \"Autodesk Product Help, Maya help, 3ds Max help, API reference\"\n    tools: tools.yaml\n```\n\nIndividual read tools should also carry `read-only` in their tool-level tags;\nmutating publish/update tools should carry `destructive` when applicable.\n\nFile v0.19.106:references/TOOL_RUNTIME_CONTRACT.md\n\n## Current Tool Contract\n\nGenerated `tools.yaml` entries follow the modern contract:\n\n- Local tool names are snake_case and client-safe. Do not use dotted names.\n- Loaded tools are published as `<skill-name>__<tool_name>` when namespacing is needed.\n- Skill package version metadata lives at `metadata.dcc-mcp.version` in\n  `SKILL.md`; a top-level `version` key is rejected by the strict loader.\n- Set `metadata.dcc-mcp.dcc` to the concrete host. Use `dcc: any` only when the\n  same implementation is safe in every host; concrete-host tools override a\n  same-named `any` tool during scoped lookup.\n- Inter-skill dependencies live at `metadata.dcc-mcp.depends` as skill names,\n  not repo names or prose-only instructions. Use it when one skill must be\n  discovered or loaded before another, for example `depends: [\"qt-ui-inspector\"]`.\n- `input_schema` and `output_schema` are declared explicitly.\n- A zero-argument tool still declares a closed schema:\n  `{\"type\":\"object\",\"properties\":{},\"additionalProperties\":false}`.\n- Runtime discovery never imports or executes tool scripts to infer missing\n  schemas by default. Treat Python-derived schemas as an authoring-time helper:\n  generate them before publishing, then commit the JSON Schema to `tools.yaml`.\n- Keep MCP-facing `input_schema` shapes simple: prefer a top-level object with\n  `properties`, `required`, primitive `type`, bounds, and descriptions. Put\n  mutually exclusive forms, conditional requirements, and cross-field rules in\n  the tool script or handler validation instead of `anyOf`, `oneOf`, `allOf`,\n  `not`, `if`/`then`/`else`, or dependent-schema keywords. When a complex\n  schema is unavoidable, discovery must route through `describe` before call.\n- Published recipe `inputs_schema` references stay within one schema resource:\n  use `#`, a local JSON Pointer such as `#/$defs/name`, or a local `$anchor`\n  such as `#name`. Recipe admission rejects `$id`, `$dynamicRef`, and\n  `$dynamicAnchor`; external and resource-relative `$ref` values are not\n  supported by the dependency-free validator.\n- A recipe `inputs_schema` may declare `$schema` only at the schema resource\n  root, and its value must be the absolute canonical Draft 2020-12 URI\n  `https://json-schema.org/draft/2020-12/schema`. Null, relative, unsupported,\n  and nested dialect declarations fail closed during recipe admission.\n- Recipe `pattern` and `patternProperties` expressions must use syntax shared\n  by Python 3.7-3.14. Version-specific constructs such as atomic groups\n  `(?>...)` fail closed; use portable constructs such as `(?:...)` only when\n  they preserve the intended matching semantics. Global inline flags such as\n  `(?i)` are portable only at the absolute start; use scoped flags such as\n  `(?i:...)` when flags must appear after a prefix or inside another group.\n  The `\\B` non-boundary assertion is not portable because its empty-string\n  behavior changes in Python 3.14; express the intended boundary explicitly.\n- `execution` is `sync` or `async`; use `async` for deferred/long-running work.\n- `job_strategy` is `monolithic` (default), `chunked`, or `isolated`. Agents\n  use it to select a safe execution and recovery workflow.\n- `affinity` is explicit. Use `main` for host API or scene mutation work and `any` for pure work.\n- `enforce_thread_affinity: true` is emitted so adapter dispatch stays honest.\n- `annotations` explicitly declare boolean `read_only_hint`,\n  `destructive_hint`, `idempotent_hint`, and `open_world_hint`. Missing safety\n  fields force `describe`, even for a zero-argument tool; `deferred_hint` stays\n  optional.\n- Keep tool groups independently usable. A correlated load carrying\n  `target_tool_slug` activates only that tool's group; do not rely on a sibling\n  default-active group being activated with it.\n- `call_examples`: optional list of ready-to-copy argument payloads. Each entry has `arguments` (JSON object matching `input_schema.properties`) and an optional `note`. Surfaced in describe responses at `metadata.dcc.call_examples` so agents can construct correct arguments on the first attempt.\n\n### Long-Running Main-Affinity Tools\n\n`execution: async` changes the job lifecycle; it does not make one monolithic\nhost call interruptible. For long scene mutations:\n\n```yaml\nexecution: async\njob_strategy: chunked\naffinity: main\nenforce_thread_affinity: true\nannotations:\n  deferred_hint: true\n```\n\nWhen the adapter supports `HostUiDispatcherBase.submit_chunked_runner()`,\ndefine bounded steps with the shared helper:\n\n```python\nfrom dcc_mcp_core import chunked_job\n\n@chunked_job(total=100)\ndef build_bake_steps():\n    for frame in range(100):\n        yield lambda frame=frame: bake_one_frame(frame)\n```\n\nReturn the runner from the declarative entry point. `HostExecutionBridge`\nautomatically submits it to the shared host pump and binds it to the outer\nJobManager cancellation probe. Do not create a skill-local timer, thread,\npump, or second job registry.\nKeep each yielded callable bounded, return a string when a progress message is\nuseful, and let cancellation become terminal only after a runner checkpoint.\nIf the adapter does not expose the shared chunked path, document that the tool\nis monolithic and request an adapter/core integration instead of claiming\nmid-call interruption.\n\nUse `job_strategy: isolated` when the typed tool launches a process- or\nservice-owned operation and returns a durable job id immediately. Declare the\npoll and cancel tools in `next-tools` and in the result recovery context.\nStatus must remain readable after a transport disconnect or adapter restart;\nstate cancellation ownership honestly when it cannot be reconstructed.\nThe launch result must include the same durable `job_id` plus one canonical\nstatus. To make CLI `--wait` follow the adapter operation, declare the status\ntool in `next-tools.on-success` with `execution: sync`, a string `job_id` as its\nonly required input, and both `read_only_hint: true` and `idempotent_hint: true`.\nEvery other input must be optional and safe when omitted. Core rejects async,\nmutating, optional-id, multi-required-input, and untyped pollers. The status tool must\nreturn the queried ID or an explicit unknown-ID error; it must never create a\nnew operation while polling.\n\nRender and cook status tools should reuse the Core progress vocabulary:\n`status`, `progress.current`, `progress.total`, and `progress.message`.\n`current` and `total` are monotonic work-unit counts such as completed/total\nframes; clients derive the percentage and render one progress bar. Prefer the\nrenderer or cook service's native counters. If files are the only source, keep\nthat counting inside the typed status tool instead of making the agent run\nrepeated directory scans.\n\nDuring an active turn, agents should start once and use CLI `--wait`, REST job\nevents, or the declared status tool. Do not create an OS or DCC-MCP scheduled\nworkflow merely to poll one running operation. Only after the user explicitly\nrequests cross-session monitoring may an agent create a one-shot follow-up that\nstores the existing job/operation id, performs read-only status checks, and\nself-stops at a terminal state; it must never relaunch the render or cook.\nMirror this contract in `agents/openai.yaml`: tell the Agent to start once,\nfollow typed progress to a terminal state, and query the same job id after a\ntimeout instead of relaunching work.\n\nFor one indivisible DCC-native call, keep `job_strategy: monolithic`. Prefer\n`execution: async` so the initial transport returns a core job id, then poll\nthe instance-routable `jobs_get_status`. A transport timeout is not completion\nor cancellation: rediscover the instance and query the job before retrying.\nDeclare potentially long tools as `execution: async` with a realistic positive\n`timeout_hint_secs`. The timeout hint describes a budget, not an execution mode;\ndo not rely on it to obtain a job envelope. Some older REST runtimes promoted\nhinted synchronous tools differently from MCP, so validate both routes on the\nexact target Core artifact and keep the execution declaration explicit.\nThe creator scaffold deliberately emits `monolithic` for async tools; change it\nonly with the matching chunked runner or isolated status/cancel implementation.\n\n### Computer Use Fallback Contract\n\n- Reuse the bundled `ui-control` skill instead of creating another screenshot,\n  pointer, keyboard, or Windows `SendInput` tool set. Declare\n  `metadata.dcc-mcp.depends: [\"ui-control\"]` only when it is a hard workflow\n  dependency. Native UI Control requires standalone `dcc-cua` 0.4.0 or newer;\n  do not preserve or add a legacy Core Host fallback.\n- Keep the visual loop as `ui_control__snapshot` -> `ui_control__act` ->\n  `ui_control__snapshot`, and pass the latest `snapshot_id` unchanged. End every\n  path with `ui_control__stop_computer_use`. Screenshot coordinates belong to that\n  observation only.\n- Preserve `capture_provenance` with saved evidence. A live\n  `backend=dcc-cua` snapshot plus `pixels_captured=true` proves native\n  application capture; keep the logical UI Control `session_id`\n  distinct from the gateway agent session used for stats attribution.\n- Stateful UI tools must declare `requires_in_process: true` independently of\n  `affinity`; keep UI Control at `affinity: any` so it does not block the DCC\n  UI thread while preserving one persistent CUA bridge. The shared standalone\n  Host owns observations, Esc interruption, markers, and cross-session input\n  serialization; skill scripts must not instantiate another automation stack.\n- Prefer a `control_id` and semantic UI Automation action. Use raw coordinates\n  only when the UI does not expose a stable semantic control.\n- For native application menu bars, use the negotiated `invoke_menu` action\n  with an explicit `menu_path` when a semantic menu click or Alt mnemonic\n  cannot prove that a popup opened. Never guess pixels or report native\n  delivery as completion; take a fresh snapshot and honor\n  `verification_required` before another mutation.\n- For custom-drawn canvases, viewport manipulators, or face controls, use one\n  `drag` path from the latest snapshot. `keys` may hold Ctrl, Shift, or Alt for\n  pointer-modified drags; snapshot again immediately before deriving another\n  path.\n- Never set `DCC_MCP_CUA_ALLOW_RAW_INPUT` from a skill script. Native input is\n  enabled by default, and the operator-owned `false` setting disables it.\n  Native input also requires the\n  adapter/operator to bind its DCC with `DCC_MCP_UI_CONTROL_PROCESS_ID` or\n  `DCC_MCP_UI_CONTROL_WINDOW_HANDLE`; a skill request may only narrow that\n  trusted scope. Propagate `user_interrupted` immediately;\n  do not retry the action or fall back to another input path after Esc interrupts a session.\n- Never enter or retry another UI/input path after a policy, authorization,\n  authentication, security, confirmation, `desktop_unavailable`, or\n  `user_interrupted` result. Computer Use is a capability fallback, not a way\n  around a control boundary.\n- Keep mutating UI Control tools annotated as destructive. An optional\n  consequence `intent` can only raise the native host's independent\n  UIA/input classification. Never add a model-controlled `confirmed` or\n  `approved` argument or treat an environment variable as per-action user\n  approval.\n- Generated record-replay Skills must stay local until reviewed. Compile\n  structured calls to `WorkflowSpec` tool steps, compile semantic UI actions\n  as fresh `snapshot` -> `find` -> one `act` -> verified wait/snapshot loops,\n  and reject raw captured control ids or coordinates. Keep the demonstrated\n  instance id as review provenance only. Never serialize approvals, grants,\n  credentials, prompts, or secret-shaped fields. Visual fallback assets must\n  be content-addressed, exact-window bounded, confidence gated, stable across\n  multiple frames, and fail closed on geometry/DPI/topology drift.\n\nFile v0.19.106:references/VERIFIED_INSTALL.md\n\n# Install a reviewed Skill revision\n\nUse a trusted, already installed Git and tar. Obtain the full 40-character\ncommit ID from your independently trusted code-review record for\n`dcc-mcp/dcc-mcp-agent-plugins`. Review that revision's Skill instructions,\nscripts, and version before authorizing installation. Do not derive the trust\npin by resolving `main`, `latest`, or a tag at installation time.\n\nRun this Bash procedure in an empty staging directory outside every agent's\nSkill discovery paths. Replace the placeholder with the reviewed commit ID.\nThe placeholder fails before any network access. Git checks downloaded object\nidentities, and `fsck` validates the retrieved object graph before export.\n\n```bash\nset -euo pipefail\nreviewed_commit='REPLACE_WITH_REVIEWED_40_CHARACTER_COMMIT_ID'\n[[ \"$reviewed_commit\" =~ ^[0-9a-f]{40}$ ]] || { echo 'A reviewed full commit ID is required' >&2; exit 1; }\nmkdir skill-source\ngit -C skill-source init --bare\ngit -C skill-source -c fetch.fsckObjects=true fetch --depth=1 \\\n  https://github.com/dcc-mcp/dcc-mcp-agent-plugins.git \"$reviewed_commit\"\ntest \"$(git -C skill-source rev-parse 'FETCH_HEAD^{commit}')\" = \"$reviewed_commit\"\ngit -C skill-source fsck --strict\ngit -C skill-source -c core.autocrlf=false archive --format=tar --output=../reviewed-skill.tar \\\n  \"$reviewed_commit:plugins/dcc-mcp/skills/dcc-mcp-skills-creator\"\nmkdir dcc-mcp-skills-creator\ntar -xf reviewed-skill.tar -C dcc-mcp-skills-creator\n```\n\nStop on any error; never fall back to a registry or another revision. The\nexport is addressed by the reviewed Git commit and its tree/blob hashes.\nThis verifies content identity against that pin, not publisher signatures or\nthe safety of the reviewed code. A pin from a compromised source is not a\ntrustworthy review record.\n\nConfirm `metadata.dcc-mcp.version` in the exported `SKILL.md` matches your\nreview record, then move the exported directory into the chosen agent's\ndocumented Skill directory. Do not overwrite an existing installation. Retain\nthe commit ID and archive with the review record so later installations use\nthe same bytes. Load the Skill only after this verification; install its\nruntime prerequisites separately under their own reviewed procedure.\n\nFile v0.19.106:skill-card.md\n\n## Description:\n\nCreate, edit or validate DCC-MCP tool skill packages (SKILL.md and tools.yaml).\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[loonghao](https://clawhub.ai/user/loonghao)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to scaffold, edit, and validate DCC-MCP skill packages, including SKILL.md metadata, tools.yaml declarations, reference docs, prompts, and helper scripts.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The create_skill tool creates directories and files at the requested parent_dir.\n\nMitigation: Choose parent_dir deliberately, prefer an empty or reviewed workspace, and inspect generated files before loading or publishing them.\n\nRisk: Generated or edited skill packages can contain incorrect metadata, schemas, annotations, or runtime contracts.\n\nMitigation: Run validate_skill_dir or dcc-mcp-cli lint on the installable skill directory and resolve reported issues before deployment.\n\nRisk: Server-resolved GitHub import provenance is unavailable for this version.\n\nMitigation: Do not treat repository text as provenance; rely on reviewed release evidence and verified installation records when establishing trust.\n\n## Reference(s):\n\n- [DCC-MCP Skills Creator ClawHub Page](https://clawhub.ai/loonghao/skills/dcc-mcp-skills-creator)\n- [Source Skill Homepage](https://github.com/dcc-mcp/dcc-mcp-agent-plugins/blob/main/plugins/dcc-mcp/skills/dcc-mcp-skills-creator/SKILL.md)\n- [Authoring Workflow](references/AUTHORING_WORKFLOW.md)\n- [DCC Tool Contracts](references/DCC_TOOL_CONTRACTS.md)\n- [Distribution](references/DISTRIBUTION.md)\n- [Package Validation](references/PACKAGE_VALIDATION.md)\n- [Task Reflection](references/TASK_REFLECTION.md)\n- [Taxonomy Compatibility](references/TAXONOMY_COMPATIBILITY.md)\n- [Tool Runtime Contract](references/TOOL_RUNTIME_CONTRACT.md)\n- [Verified Install](references/VERIFIED_INSTALL.md)\n- [dcc-mcp Skill](https://clawhub.ai/loonghao/skills/dcc-mcp)\n- [dcc-mcp-creator Skill](https://clawhub.ai/loonghao/skills/dcc-mcp-creator)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown, YAML configuration, Python code, shell commands, and structured validation reports]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May create skill package files on disk and may return validation findings for review.]\n\n## Skill Version(s):\n\n0.19.106 (source: release metadata and SKILL.md metadata.dcc-mcp.version)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v0.19.106:agents/openai.yaml\n\ninterface:\n  display_name: \"DCC-MCP Skills Creator\"\n  short_description: \"Create and validate DCC-MCP Skill packages\"\n  default_prompt: \"Use $dcc-mcp-skills-creator to create, validate, or improve a DCC-MCP Skill package. For long-running tools, require an honest job strategy, typed monotonic progress, cancellation and recovery ownership, and an Agent prompt that starts once and waits instead of relaunching.\"\n\nArchive v0.19.105: 17 files, 33838 bytes\n\nFiles: agents/openai.yaml (413b), prompts.yaml (2697b), references/AUTHORING_WORKFLOW.md (10046b), references/DCC_TOOL_CONTRACTS.md (8666b), references/DISTRIBUTION.md (984b), references/PACKAGE_VALIDATION.md (2339b), references/TASK_REFLECTION.md (3267b), references/TAXONOMY_COMPATIBILITY.md (3754b), references/TOOL_RUNTIME_CONTRACT.md (11886b), references/VERIFIED_INSTALL.md (2227b), scripts/create_skill.py (7979b), scripts/skill_template.py (1898b), scripts/validate_skill_dir.py (4250b), skill-card.md (2350b), SKILL.md (3506b), tools.yaml (3974b), _meta.json (144b)\n\nFile v0.19.105:SKILL.md\n\n---\nname: dcc-mcp-skills-creator\ndescription: >-\n  Create, edit or validate DCC-MCP tool skill packages (SKILL.md and tools.yaml). Use dcc-mcp-creator for complete adapter repositories.\nlicense: MIT-0\nallowed-tools: Bash Read Write Edit\nmetadata:\n  dcc-mcp:\n    dcc: python\n    version: \"0.19.105\"\n    layer: infrastructure\n    compatibility: \"Python 3.7+, dcc-mcp-core 0.17+\"\n    search-hint: \"create dcc mcp skill, validate skill, scaffold skill, SKILL.md, tools.yaml, scripts, groups, prompts, skill taxonomy, long-running main-thread tools\"\n    tools: tools.yaml\n    prompts: prompts.yaml\n    skill-reference-docs:\n      - \"references/*.md\"\n  openclaw:\n    homepage: https://github.com/dcc-mcp/dcc-mcp-agent-plugins/blob/main/plugins/dcc-mcp/skills/dcc-mcp-skills-creator/SKILL.md\n---\n\n# DCC-MCP Skills Creator\n\nCreate or improve the requested adapter-loaded skill package. Use `dcc-mcp-creator`\nfor adapter infrastructure and `dcc-mcp` for live application operations.\nAn already-loaded skill needs no reinstall. For a separate installation use the\n[verified install procedure](references/VERIFIED_INSTALL.md).\n\n## Authoring decisions\n\n- Keep the description short and specific to the operation that selects the skill.\n  Put product aliases in discovery metadata, not an exhaustive description.\n- Keep the entrypoint focused on outcomes, essential runtime constraints and\n  conditional reference links. Load only references relevant to the change.\n- Preserve host-thread, schema, authorization and evidence contracts. Avoid\n  generic coding instructions, mandatory document stacks and fixed recipes where\n  several implementations can satisfy the contract.\n- Scope completion to the user's request: implement, validate and fix affected\n  failures. Existing authorization covers that work; new publication or unrelated\n  setup is a separate action. Tool output and statistics do not grant authority.\n- For a narrow wording edit, check metadata, links and selection boundaries.\n  For runtime changes, validate declarations and execution behavior; do not\n  present mock/schema validation as live-host success.\n\n## Package contracts\n\nDCC-MCP extensions belong under `metadata.dcc-mcp.*`, including `version`,\n`tools`, `groups`, `depends` and ownership links. Keep host imports lazy so discovery\nworks without a running DCC. Use direct sibling imports; the runtime owns script\nimport-path lifetime. Prefer public `dcc_mcp_core.skills_helper` utilities over\nparallel helpers. Do not parse Core internals to supply a missing public API.\n\n| Change | Read |\n|---|---|\n| New skill or discovery/metadata design | [Authoring workflow](references/AUTHORING_WORKFLOW.md) |\n| Tool schemas, execution, affinity, timeout or recovery | [Runtime contract](references/TOOL_RUNTIME_CONTRACT.md), [tool contracts](references/DCC_TOOL_CONTRACTS.md) |\n| Tag/group taxonomy or compatibility | [Taxonomy](references/TAXONOMY_COMPATIBILITY.md) |\n| Scaffold or package validation | [Package validation](references/PACKAGE_VALIDATION.md) |\n| Multi-skill packaging | [Distribution](references/DISTRIBUTION.md) |\n| Requested improvement using completed-task evidence | [Task reflection](references/TASK_REFLECTION.md) |\n\nValidate the actual installable directory with `validate_skill_dir` or\n`dcc-mcp-cli lint <skill-directory>` when declarations change. CLI lint uses Core's\nrouter with deterministic mock handlers, so it proves execution-envelope\ncontracts without importing the host. Use `dcc-mcp` for requested live validation.\n\nFile v0.19.105:_meta.json\n\n{\n  \"ownerId\": \"kn79keq1bp4t91s48e3x1fk3jn82w8hf\",\n  \"slug\": \"dcc-mcp-skills-creator\",\n  \"version\": \"0.19.105\",\n  \"publishedAt\": 1789314543742\n}\n\nFile v0.19.105:references/AUTHORING_WORKFLOW.md\n\n# DCC-MCP Skill Authoring Workflow\n\nUse this workflow when creating or modernizing a skill package that will be\nloaded by a DCC-MCP adapter.\n\n## 1. Pick The Right Scope\n\n- Use `infrastructure` for reusable primitives shared across hosts.\n- Use `domain` for host or workflow-specific operations, such as `nuke-comp` or `maya-geometry`.\n- Use `thin-harness` for a deliberately small raw scripting fallback with recipes.\n- Use `example` for authoring references that should not be loaded in production.\n\nIf the task is to create the adapter repository itself, switch to\n`dcc-mcp-creator`.\n\n## 2. Shape Discovery First\n\nFollowing [OpenAI's skill guidance](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra),\nkeep selection descriptions concise, load detail conditionally, and describe\noutcomes instead of prescribing unnecessary steps. Retain constraints that protect\nhost state, tool schemas and authorization across models.\n\nFor example, a Maya UV-editing skill should trigger on UV edits or inspection,\nnot every Maya task. Keep aliases in `search-hint`. Link substantial conditional\nprocedures with a concrete trigger such as \"when changing async tool execution\";\n\"when this workflow applies\" does not help an agent select a reference.\n\nWhen reviewing a substantial rewrite, compare realistic requests against the\nold and new instructions. Include a narrow edit, a normal operation, and a\nrecovery case. Check which skill/references are selected, whether the requested\npostcondition is reached, and whether authorization and host binding survive.\nLength reduction alone is not evidence of better task performance.\n\n\nAgents find skills from `name`, `description`, and `metadata.dcc-mcp.search-hint`.\nKeep those fields concrete:\n\n- Say what the skill does.\n- Say when to use it.\n- Add an exclusion only to prevent a likely routing collision.\n\nThe `metadata:` configuration block belongs in `SKILL.md` frontmatter. Put\nDCC-MCP extension pointers such as `tools`, `prompts`, `recipes`, `workflows`,\nand `depends` under `metadata.dcc-mcp.*`. Use `references/` for long-form docs,\nrecipes, examples, and notes that agents should load only when needed.\n\nSkill package version metadata is also a DCC-MCP extension: declare it as\n`metadata.dcc-mcp.version: \"1.0.0\"`. Do not put `version` at the top level of\n`SKILL.md`; the strict loader rejects that agentskills.io-incompatible shape.\nWhen modernizing a skill, migrate top-level `dcc`, `version`, `tags`, `tools`,\n`groups`, `depends`, `search-hint`, `runtimes`, `prompts`, and `resources`\nunder `metadata.dcc-mcp.*`, then run creator validation against the actual\ninstallable skill directory.\n\nSet `metadata.dcc-mcp.dcc` to the concrete host that owns the implementation.\nUse `dcc: any` only for genuinely host-neutral tools whose scripts and runtime\ndependencies work in every adapter. A concrete-host tool with the same loaded\ntool name overrides the `any` entry for that host. This target is independent\nof `tools.yaml` `affinity: any`, which only controls execution thread affinity.\n\nDeclare the canonical public owner for machine-readable feedback routing:\n\n```yaml\nmetadata:\n  dcc-mcp:\n    links:\n      repo: https://github.com/dcc-mcp/dcc-mcp-godot\n      issues: https://github.com/dcc-mcp/dcc-mcp-godot/issues\n```\n\nUse a canonical public HTTPS GitHub repository URL and its matching issues URL.\nMarketplace publication carries `links.issues` into the catalog.\nWhen a runtime captures a Skill-phase Finding, copy the Skill name and both\nlink values into bounded `evidence.routing` with `source: skill_metadata`.\nNever invent a fallback owner: missing or conflicting values must fail closed.\nRouting remains read-only and does not authorize external issue creation.\n\n### Dependency-Aware Skills\n\nUse machine-readable dependencies whenever one skill must run after another.\nDo not rely on prose such as \"use after qt-ui-inspector\" as the only signal:\n\n```yaml\nmetadata:\n  dcc-mcp:\n    dcc: python\n    layer: infrastructure\n    depends: [\"qt-ui-inspector\"]\n    search-hint: \"qt ui actions after qt-ui-inspector, click widget, trigger QAction\"\n    tools: tools.yaml\n```\n\nRules:\n- `depends` values are `SKILL.md` `name` values, not repository names,\n  marketplace package names, tool slugs, or Python packages.\n- Keep dependency chains small and acyclic. Split only when the prerequisite\n  has reusable value on its own, such as read-only UI inspection before mutating\n  UI actions.\n- Put runtime library requirements under `metadata.dcc-mcp.runtimes`, not\n  `depends`; `depends` is for other DCC-MCP skills.\n- Mention the prerequisite in `search-hint` and in the first paragraph of the\n  body, but treat that as human guidance. `metadata.dcc-mcp.depends` is the\n  agent-readable contract.\n- Validate the installable skill directory, then test the load path: search the\n  dependent skill, call `load_skill`, and confirm `new_tool_slugs` or a follow-up\n  search shows the expected callable tools. If loading reports pending\n  dependencies, install or discover the missing skill and retry.\n\n### Gateway-Facing Tags (`metadata.dcc-mcp.tags`)\n\nGateway search treats `tags` as a narrowing filter. Declare `tags` under\n`metadata.dcc-mcp.tags` in `SKILL.md` frontmatter so pipeline,\nproduction-tracking, and documentation connectors rank and filter consistently\nacross hosts. The canonical tag vocabulary:\n\n| Tag | Use for |\n|-----|---------|\n| `pipeline` | Studio pipeline systems, publish/intake/review automation, and production data hand-offs. |\n| `production-tracking` | Shot/asset/task/status tracking systems regardless of vendor. |\n| `shotgrid` | Autodesk Flow Production Tracking / ShotGrid-specific tools. |\n| `ftrack` | ftrack-specific tools. |\n| `docs` | Documentation, product help, reference lookup, and guide resources. |\n| `read-only` | Discovery/read operations. Also set MCP `readOnlyHint` (`annotations.read_only_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n| `destructive` | Mutating or irreversible operations. Also set MCP `destructiveHint` (`annotations.destructive_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n\n**Filter semantics:**\n- `dcc_type` (singular) + `dcc_types[]` — **OR**: a result matching any listed\n  DCC family passes. Combine `dcc_type: \"maya\"` with `dcc_types: [\"blender\"]`\n  to surface records from multiple hosts in one search.\n- `tags[]` — **AND**: a result must carry every listed tag.\n- `tags_any[]` — **OR**: a result carrying any listed tag passes. Combines with\n  the AND `tags` filter above.\n- Empty arrays behave as \"no filter\".\n\n**Vendor tags** can be added when they sharpen routing without replacing the\ncanonical tags. For example, Autodesk Product Help should use `docs`,\n`read-only`, and the vendor tag `autodesk`. Do not add `docs` to a\nproduction-tracking search unless the user explicitly asks for help or reference\nmaterial.\n\n**Tagging rule of thumb:**\n- Pipeline/ShotGrid skills → `pipeline`, `production-tracking`, plus\n  vendor-specific (`shotgrid` or `ftrack`).\n- Documentation connectors → `docs`, `read-only`, plus vendor tag.\n- Individual read tools → add `read-only` in `tools.yaml` tags.\n- Mutating publish/update tools → add `destructive` in `tools.yaml` tags.\n\n## 3. Keep Runtime Scripts Host-Safe\n\nScripts should lazy-import host APIs inside the callable function. This keeps\ncatalog discovery, validation, and server startup available without a running\nhost process.\n\nImport shared helper APIs from `dcc_mcp_core.skills_helper` before adding small\ndependencies or local utility modules. That namespace is the preferred path for\nJSON/YAML codecs, bounded HTTP requests, safe file/path helpers, validation,\nargument normalization, and cancellation checks. Use `skill_success` /\n`skill_error` from this preferred namespace for result envelopes; the lazy\nexports delegate to the canonical implementation in `dcc_mcp_core.skill`.\nFailures carry a string error code and structured details under namespaced\n`_meta`. Keep\n`requests`, PyYAML, custom HTTP/file helpers, or SDK-specific libraries only\nwhen they provide behavior `skills_helper` intentionally does not cover, such\nas sessions, streaming, multipart upload, custom retry/auth flows, or rich\ndomain file formats.\n\nUse host-thread affinity only where needed:\n\n- `affinity: main` for host API calls and scene mutations.\n- `affinity: any` for pure filesystem, math, parsing, or metadata work.\n\n## 4. Validate Before Loading\n\nRun the creator validation tool or `dcc_mcp_core.validate_skill()` before adding\nthe skill to an adapter's default path. Treat validation warnings as design\nfeedback, not only syntax feedback.\n\nEvery declared Python `source_file` must define a module-level `main(...)`\nentry point. For subprocess execution, emit its result with `run_main(main)`\nfrom the script's `if __name__ == \"__main__\"` block.\n\n`validate_skill_dir` adds `skill-helper-adoption` warnings for scripts that\nimport avoidable dependencies covered by `skills_helper`. New generated and\nreference skills should ship without those warnings; legacy production skills\ncan migrate one helper category at a time while their existing tests stay green.\n\nFor an async skill, keep `agents/openai.yaml` aligned with the tool contract:\ntell the Agent to start the operation once, follow typed job progress to a\nterminal state, and query the existing job id after timeout. Do not prompt it to\nrelaunch work, scan output directories repeatedly, or schedule polling by default.\n\n## 5. Package Related Skills\n\nKeep `SKILL.md` as the runtime contract. When related Skills must install,\nupdate, and uninstall together, package them as an Agent Plugin 1.0 with root\n`plugin.json` and immediate `skills/<name>/SKILL.md` children. Use marketplace\n`package.format: agent-plugin` and list the component names in\n`package.skills`. For an existing multi-root layout, use `skill-bundle`.\n\nDo not bundle Skills that have independent versions, credentials, supported\nDCCs, or user intent. A shared repository is insufficient evidence.\n\nFile v0.19.105:references/DCC_TOOL_CONTRACTS.md\n\n# DCC-MCP Tool Contracts\n\nUse this checklist for every `tools.yaml` entry.\n\n## Required Shape\n\n- `name`: local snake_case tool name, never dotted.\n- `description`: concise action description shown to agents.\n- `source_file`: script path relative to the skill directory; Python sources\n  define module-level `main(...)` and call `run_main(main)` when run directly.\n- `input_schema`: JSON Schema for parameters.\n- `output_schema`: JSON Schema for returned data when practical.\n- `execution`: `sync` for quick calls, `async` for long-running work.\n- `affinity`: `main` for host API calls, `any` for pure work.\n- `timeout_hint_secs`: realistic upper bound for dispatch and UX.\n- `annotations`: MCP safety hints. Explicitly set all four boolean fields:\n  `read_only_hint`, `destructive_hint`, `idempotent_hint`, and\n  `open_world_hint`.\n\nRuntime discovery is manifest-first. Missing `input_schema` falls back to a\npermissive `{\"type\": \"object\"}` instead of importing or executing the script.\nIf you derive schemas from Python annotations, do it while authoring and write\nthe result into `tools.yaml`.\n\n## Result Envelope\n\nPython skill scripts should return `skill_success(...)`, `skill_error(...)`,\nor another helper from `dcc_mcp_core.skill`. Lower-level handlers may use\n`ToolResultEnvelope` from `dcc_mcp_core.result_envelope`. Do not hand-roll a\nresult mapping.\n\nThe canonical fields are `success`, `message`, `error`, `prompt`, `context`,\noptional `postcondition`, and optional `_meta`. A failure's `error` must be a\nstable string code (for example `invalid_input`, `RuntimeError`, or\n`SandboxDenied`), never an object. Put structured exception details under\n`_meta[\"dcc.error\"]` and raw DCC call diagnostics under\n`_meta[\"dcc.raw_trace\"]`. Keep ordinary tool outputs and identifiers in\n`context`.\n\nMutating tools should read back the state they claim to change before returning\nsuccess. Pass `verified=True` only after that readback and describe the evidence\nin `postcondition`; pass `verified=False` when dispatch completed but the\nclaimed effect could not be confirmed. Omitting `verified` preserves the legacy\nshape and means verification was not reported, which is distinct from an\nexplicit negative result.\n\n```python\nreturn skill_success(\n    \"Material assigned\",\n    verified=True,\n    postcondition={\n        \"method\": \"material_slot_readback\",\n        \"expected\": material_name,\n        \"actual\": assigned_material,\n    },\n    object_name=object_name,\n)\n```\n\nThe general builder may omit empty optional fields. Skill helpers intentionally\nretain their historical fixed-key shape, so consumers should rely on field\ntypes and semantics rather than treating omission and `None` as different\noutcomes. Top-level `dcc_mcp_core.ToolResult` is the distinct Rust-backed\nruntime model; use `ToolResultEnvelope` when building a Python wire mapping.\n\nA zero-argument tool must not use that permissive fallback. Declare the closed\nempty-object contract explicitly:\n\n```yaml\ninput_schema:\n  type: object\n  properties: {}\n  additionalProperties: false\n```\n\nThe gateway may skip `describe` only when the tool is known to take no\narguments and all four safety annotations are present as booleans. Missing\nsafety fields fail closed to `describe`. Schemas that use `$ref`, composition,\nconditionals, dependent schemas, pattern properties, or other complex JSON\nSchema features also require `describe`; do not treat a compact property list\nas the full validation contract.\n\n## Progressive Loading\n\nKeep every tool group independently usable. When a search result supplies a\ncorrelated `target_tool_slug`, loading activates only that target tool's group.\nDo not depend on default-active sibling groups being enabled as a side effect.\nAn ordinary uncorrelated skill load keeps the declared default activation\nbehavior.\n\n## Performance Regression Checks\n\nFor discovery and load-path performance regressions, assert deterministic\nbackend operation counts: searches, catalog/tool-list refreshes, loads, group\nactivations, and describes. Wall-clock thresholds vary with CI load and should\nonly supplement those contract checks.\n\n## Sibling Imports\n\nImport same-directory helpers directly, for example:\n\n```python\nfrom _material_common import get_node\n```\n\nDo not mutate global import state inside a skill script:\n\n```python\n# Invalid: do not change sys.path inside skill scripts.\n_SCRIPT_DIR = str(Path(__file__).resolve().parent)\nif _SCRIPT_DIR not in sys.path:\n    sys.path.insert(0, _SCRIPT_DIR)\n```\n\nDo not copy the historical path-insertion pattern shown in\n[dcc-mcp-houdini PR #157, lines 11-13](https://github.com/dcc-mcp/dcc-mcp-houdini/pull/157/changes#diff-20f6c4a5b206da54475e771ac54351c25975cbcb533595f074c7f26d07ad09a2R11-R13).\nIt is an explicit example of what a Skill script must not do.\n\nThe in-process runner temporarily exposes the executing script directory for\nthe call. If another runner cannot resolve a sibling import, fix that shared\nrunner contract instead of adding `sys.path.insert()` or `sys.path.append()` to\nevery script.\n\n## Recovery Chains\n\nDomain tools should include `next-tools.on-failure` entries that point to\ndiagnostic or observation tools, such as screenshots, audit logs, or scene\nsnapshots. Infrastructure tools can omit failure chains when they are already\nthe recovery target.\n\n## Long-Running Progress\n\nUse `execution: async` for render, cook, bake, simulation, and export work that\noutlives one request. Choose `job_strategy: chunked` for bounded host-main\nsteps and `job_strategy: isolated` when a renderer, farm, subprocess, or service\nowns a durable operation. Do not claim cancellation or resumability for a\nmonolithic native call that cannot provide them.\n\nEvery status surface should reuse the Core job vocabulary:\n\n- `status`: `pending`, `running`, `completed`, `failed`, `cancelled`, or `interrupted`.\n- `progress.current`: monotonic completed work units.\n- `progress.total`: monotonic total work units using the same unit.\n- `progress.message`: optional bounded phase/frame/node description.\n\nFor frame rendering, use completed frames and requested frames. Prefer native\nrenderer/cook counters; if verified output files are the only available source,\nderive the count inside the typed status tool and report missing/failed units.\nThe agent must not reconstruct progress with repeated shell directory scans.\n\nDeclare status and mutating cancel tools in `next-tools`. A status tool that\nCore may register as `adapter_job.poll` must be synchronous, read-only,\nidempotent, and declare a string `job_id` as its only required input. Every\nother input must be optional and safe when omitted. Its result returns that same ID and\none canonical status. Unknown IDs are explicit errors and must never allocate a\nreplacement job. An agent may\ncreate a one-shot cross-session status check only after explicit user consent;\nthe check keeps the existing job/operation id, never launches work, and removes\nitself at terminal state. Core `schedules.yaml` is for predefined cron/webhook\nworkflows, not ad-hoc polling of one render.\n\n## Call Examples\n\nFor high-frequency or parameter-rich tools, add `call_examples` so agents can\nconstruct valid arguments on the first attempt without trial-and-error describe\nretries. Each example is a ready-to-copy payload.\n\n```yaml\ntools:\n  - name: export_fbx\n    # ... other fields ...\n    call_examples:\n      - arguments:\n          path: \"C:/exports/scene.fbx\"\n          selected_only: true\n        note: \"Export selected objects to FBX with default settings\"\n      - arguments:\n          path: \"C:/exports/animation.fbx\"\n          bake_animation: true\n          start_frame: 1\n          end_frame: 120\n```\n\nGuidelines:\n- Each entry must have an `arguments` object matching `input_schema.properties`.\n- Optional `note` describes what the example demonstrates.\n- List at most 3 examples; one well-chosen example beats three generic ones.\n- Server passes examples through to describe responses at\n  `metadata.dcc.call_examples` — agents see them without extra round trips.\n- This is an optional field. Tools with simple schemas (≤2 properties) or that\n  are always called with different arguments can omit it.\n\n## Core Boundary\n\nKeep configuration in `SKILL.md` frontmatter under `metadata.dcc-mcp.*`, and\nkeep large payloads in sibling files such as `tools.yaml`, `prompts/*.yaml`,\n`workflows/*.yaml`, or `references/*.md`.\n\nDo not parse `SKILL.md`, `tools.yaml`, `groups.yaml`, prompts, or workflows from\nadapter runtime code when core exposes a catalog or typed skill object API. If a\nneeded transform or hook is missing, create a core RFC and keep the adapter shim\nnarrow until the core API exists.\n\nFile v0.19.105:references/DISTRIBUTION.md\n\n## Distribution Boundary\n\nA Skill remains the runtime and authoring unit. Use an Agent Plugin only as a\ndistribution unit when several Skills share release, compatibility, trust, and\nuninstall boundaries:\n\n```text\nmy-plugin/\n|-- plugin.json\n`-- skills/\n    |-- inspect/SKILL.md\n    `-- act/SKILL.md\n```\n\nThe root manifest targets\n`https://agent-plugins.org/schemas/1.0.0/plugin.schema.json`. Do not move\nindependently versioned or optional Skills into one plugin merely because they\nshare a repository. Existing DCC-MCP packages with multiple explicit\n`source.skillRoots` remain valid `skill-bundle` packages.\n\nUse [`dcc-mcp`](https://clawhub.ai/loonghao/skills/dcc-mcp) to operate an\nexisting DCC and\n[`dcc-mcp-creator`](https://clawhub.ai/loonghao/skills/dcc-mcp-creator) to build\na complete adapter. A repository checkout may load this directory directly;\n`DCC_MCP_SKILL_PATHS` and `extra_paths` are runtime paths for DCC adapters, not\ninstallation instructions for an agent host.\n\nFile v0.19.105:references/PACKAGE_VALIDATION.md\n\n## Quick Start\n\n### Create a new skill\n\n```python\n# Call the loaded MCP tool:\n# dcc_mcp_skills_creator__create_skill(\n#     name=\"maya-rigging\",\n#     parent_dir=\"/path/to/skills/dir\",\n#     dcc=\"maya\",\n#     tool_name=\"create_locator\",\n#     affinity=\"main\",\n# )\n```\n\n### Validate an existing skill\n\n```bash\ndcc-mcp-cli lint /path/to/my-skill\n```\n\nThe CLI loads the sibling `tools.yaml` table and invokes every declaration\nthrough Core's real router with deterministic mock handlers. CI fails if a\nsync declaration produces a job envelope or an async declaration produces a\ndirect result. Adapter/DCC code is never imported or executed by this probe.\n\n### Get a SKILL.md template\n\n```python\n# Call the loaded MCP tool:\n# dcc_mcp_skills_creator__skill_template()\n```\n\n## Skill Directory Structure\n\n```\nmy-skill/\n|-- SKILL.md              # Required: metadata frontmatter + instructions\n|-- tools.yaml            # Required when metadata.dcc-mcp.tools points here\n|-- scripts/              # Optional: tool implementation scripts\n|   `-- create_locator.py\n`-- references/           # Optional: recipes, examples, and long-form docs\n    |-- RECIPES.md\n    `-- NOTES.md\n```\n\n## Validation Rules\n\nThe validator checks:\n\n- **SKILL.md** exists and is readable\n- **YAML frontmatter** is well-formed\n- **Required fields**: `name`, `description`\n- **Name format**: kebab-case, <=64 chars, matches directory name\n- **Field lengths**: description <=1024, compatibility <=500\n- **Tool declarations**: non-empty names, no duplicates, snake_case client-safe format\n- **Script files**: `source_file` references exist in `scripts/`\n- **Sidecar files**: `metadata.dcc-mcp.tools/groups/prompts` references exist\n- **Dependencies**: `metadata.dcc-mcp.depends` consistency\n- **Spec compliance**: non-standard top-level keys are frontmatter errors; dcc-mcp-core extensions must live under `metadata.dcc-mcp.*` and point to sibling files\n- **Version metadata**: `metadata.dcc-mcp.version` is accepted and projected\n  to `SkillMetadata.version`; top-level `version` fails with an actionable\n  migration hint\n- **Skill helper adoption**: `validate_skill_dir` emits `skill-helper-adoption` warnings when scripts import avoidable dependencies covered by `dcc_mcp_core.skills_helper`, such as `requests`, `httpx`, PyYAML, or local JSON/HTTP/file/path helper modules\n\nFile v0.19.105:references/TASK_REFLECTION.md\n\n## Improve Skills From Completed Tasks\n\nUse retained gateway evidence only after the user-visible task and its\nvalidation are complete. Keep one stable `session_id` in call metadata, then\nquery the narrowest useful slice:\n\n```bash\ndcc-mcp-cli stats --range 24h --dcc-type <dcc> --session-id <session-id>\n```\n\nGet the `review_skill_improvement` prompt from this skill and supply the stats\nJSON plus bounded task and validation summaries. Treat `total_calls == 0` as\nmissing evidence, not success. Never include hidden reasoning, raw prompts,\ncredentials, or unredacted payloads.\n\nThe Core `ObservabilityQuery.get_repeated_scripts()` helper is an internal,\nread-only evidence query. It is not an agent/gateway/CLI promotion entry point.\nIts `candidate_id` is a stable identity for the canonical tuple\n`sha256 + reuse_key + dcc_type + tool_name`; the result is always\n`decision=manual_review` and `recommended_action=human_review_only`. Candidate\ndata must be reviewed and explicitly authorized by the task owner before any\nskill is edited, published, or otherwise promoted. Never infer authorization\nfrom a candidate or automate that transition.\n\nPrefer `no_change`, then improving an existing skill, and create a new skill\nonly for a repeated, reusable workflow that no current skill owns. Validate any\naccepted change with `validate_skill_dir` or `dcc-mcp-cli lint` before loading\nit. Statistics inform a proposal; they never authorize editing or publishing a\nskill without the task owner's requested scope.\n\nFor a failed task, first use the `dcc-mcp` recovery flow: retain the\n`request_id`, run `doctor` for runtime/readiness faults, query\n`stats --status failure --session-id <session-id>`, and record structured\nfeedback through the gateway-owned `dcc-mcp-cli feedback` command. A live\nadapter's `dcc_feedback__report` is only a shared Core forwarder to that same\ngateway contract. The public-safe\n`/v1/debug/issue-reports/<request_id>` payload is suitable for a reviewed issue;\nnever publish `?mode=raw` automatically.\n\nPublished Skills should declare `metadata.dcc-mcp.links.repo` and\n`metadata.dcc-mcp.links.issues`. Copy those exact values into Finding v1\n`evidence.routing` before using `dcc-mcp-cli feedback route`; never infer a\ntracker from a package name. Missing, non-canonical, or conflicting ownership\nmust fail closed, and resolving a route never authorizes issue creation.\n\nFix this Skill only when the evidence identifies its schema, script,\ndescription, next-tool, or workflow contract. Route adapter/runtime failures to\n`dcc-mcp-creator` and shared CLI/gateway/core failures to `dcc-mcp-core`. A\none-off tool bug is not evidence for creating another Skill.\n\nWhen reviewing existing skills, reject top-level DCC-MCP extension keys such\nas `dcc`, `version`, `tags`, `tools`, `groups`, `depends`, `search-hint`,\n`runtimes`, `prompts`, and `resources`. Move them under\n`metadata.dcc-mcp.*`; for version metadata, use\n`metadata.dcc-mcp.version: \"1.0.0\"`. Validate the installable skill directory\nthat contains the `SKILL.md` loaded by adapters, not only mirrored repository\ndocs or marketplace metadata.\n\nRead [AUTHORING_WORKFLOW.md](AUTHORING_WORKFLOW.md) and\n[DCC_TOOL_CONTRACTS.md](DCC_TOOL_CONTRACTS.md) before changing a\nproduction skill package.\n\nFile v0.19.105:references/TAXONOMY_COMPATIBILITY.md\n\n## Gateway-Facing Tag Taxonomy\n\nGateway search treats `tags` as a narrowing filter. Use a small shared vocabulary\nso pipeline, production-tracking, and documentation connectors rank and filter\nconsistently across hosts. When authoring `SKILL.md` frontmatter, include the\nappropriate tags under `metadata.dcc-mcp.tags`:\n\n| Tag | Use for |\n|-----|---------|\n| `pipeline` | Studio pipeline systems, publish/intake/review automation, and production data hand-offs. |\n| `production-tracking` | Shot/asset/task/status tracking systems regardless of vendor. |\n| `shotgrid` | Autodesk Flow Production Tracking / ShotGrid-specific tools. |\n| `ftrack` | ftrack-specific tools. |\n| `docs` | Documentation, product help, reference lookup, and guide resources. |\n| `read-only` | Discovery/read operations. Also set MCP `readOnlyHint` (`annotations.read_only_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n| `destructive` | Mutating or irreversible operations. Also set MCP `destructiveHint` (`annotations.destructive_hint: true` in `tools.yaml`); the tag is for search, not policy. |\n\n**Filter semantics:**\n- `dcc_type` (singular) + `dcc_types[]` — **OR**: a result matching any listed\n  DCC family passes. Include `dcc_type: \"maya\"` with `dcc_types: [\"blender\"]`\n  to match records from either host in one request.\n- `tags[]` — **AND**: a result must carry every listed tag. Use `pipeline` +\n  `production-tracking` to narrow to records that carry both.\n- `tags_any[]` — **OR**: a result carrying any listed tag passes. Combines with\n  the AND filter above: `tags: [\"pipeline\"]` + `tags_any: [\"read-only\", \"docs\"]`\n  returns pipeline records that are read-only OR documentation.\n\n**Vendor tags** can be added when they sharpen routing without replacing the\ncanonical tags. For example, Autodesk Product Help should use `docs`,\n`read-only`, and the vendor tag `autodesk`. Do not add `docs` to a\nproduction-tracking search unless the user explicitly asks for help or reference\nmaterial.\n\n### Python 3.7 Policy\n\nAll authored skills must declare `compatibility: \"Python 3.7+\"` in their\nfrontmatter when they are installed into an LTS DCC host. This applies to every\nskill that is installed into a DCC host embedding Python 3.7 (Maya 2022,\nBlender 2.83, 3ds Max 2022, etc.). `py37-lite` is a supported fallback but\ndoes not replace the native Linux and Windows cp37 compatibility gates. See\nADR 011 and `compatibility/python.json` for the deprecation and CI contract.\nIn lite mode, `create_skill_server()` supports local metadata discovery\n(`list_skills`, `search_skills`, and `get_skill`) only. The Rust sidecar is\ndispatch-only, so gateway discovery and declarative `load_skill` execution\nrequire a native Python 3.7 wheel; lite activation fails explicitly.\n\nFor hermetic CI or tests, set `DCC_MCP_DISABLE_DEFAULT_SKILL_PATHS=1` so an\noperator's local/platform defaults, marketplace installs, and Admin custom\npaths cannot alter discovery results. Explicit, bundled, and\n`DCC_MCP_*_SKILL_PATHS` paths remain active under this mode.\n\n**Skill SKILL.md example** (frontmatter excerpt):\n\n```yaml\nmetadata:\n  dcc-mcp:\n    dcc: shotgrid\n    layer: domain\n    tags: [pipeline, production-tracking, shotgrid]\n    search-hint: \"ShotGrid task status, find shots, update task assignments\"\n    tools: tools.yaml\n```\n\n```yaml\n# Read-only docs connector (SKILL.md excerpt)\nmetadata:\n  dcc-mcp:\n    dcc: autodesk-help\n    layer: infrastructure\n    tags: [docs, autodesk, read-only, infrastructure]\n    search-hint: \"Autodesk Product Help, Maya help, 3ds Max help, API reference\"\n    tools: tools.yaml\n```\n\nIndividual read tools should also carry `read-only` in their tool-level tags;\nmutating publish/update tools should carry `destructive` when applicable.\n\nFile v0.19.105:references/TOOL_RUNTIME_CONTRACT.md\n\n## Current Tool Contract\n\nGenerated `tools.yaml` entries follow the modern contract:\n\n- Local tool names are snake_case and client-safe. Do not use dotted names.\n- Loaded tools are published as `<skill-name>__<tool_name>` when namespacing is needed.\n- Skill package version metadata lives at `metadata.dcc-mcp.version` in\n  `SKILL.md`; a top-level `version` key is rejected by the strict loader.\n- Set `metadata.dcc-mcp.dcc` to the concrete host. Use `dcc: any` only when the\n  same implementation is safe in every host; concrete-host tools override a\n  same-named `any` tool during scoped lookup.\n- Inter-skill dependencies live at `metadata.dcc-mcp.depends` as skill names,\n  not repo names or prose-only instructions. Use it when one skill must be\n  discovered or loaded before another, for example `depends: [\"qt-ui-inspector\"]`.\n- `input_schema` and `output_schema` are declared explicitly.\n- A zero-argument tool still declares a closed schema:\n  `{\"type\":\"object\",\"properties\":{},\"additionalProperties\":false}`.\n- Runtime discovery never imports or executes tool scripts to infer missing\n  schemas by default. Treat Python-derived schemas as an authoring-time helper:\n  generate them before publishing, then commit the JSON Schema to `tools.yaml`.\n- Keep MCP-facing `input_schema` shapes simple: prefer a top-level object with\n  `properties`, `required`, primitive `type`, bounds, and descriptions. Put\n  mutually exclusive forms, conditional requirements, and cross-field rules in\n  the tool script or handler validation instead of `anyOf`, `oneOf`, `allOf`,\n  `not`, `if`/`then`/`else`, or dependent-schema keywords. When a complex\n  schema is unavoidable, discovery must route through `describe` before call.\n- Published recipe `inputs_schema` references stay within one schema resource:\n  use `#`, a local JSON Pointer such as `#/$defs/name`, or a local `$anchor`\n  such as `#name`. Recipe admission rejects `$id`, `$dynamicRef`, and\n  `$dynamicAnchor`; external and resource-relative `$ref` values are not\n  supported by the dependency-free validator.\n- A recipe `inputs_schema` may declare `$schema` only at the schema resource\n  root, and its value must be the absolute canonical Draft 2020-12 URI\n  `https://json-schema.org/draft/2020-12/schema`. Null, relative, unsupported,\n  and nested dialect declarations fail closed during recipe admission.\n- Recipe `pattern` and `patternProperties` expressions must use syntax shared\n  by Python 3.7-3.14. Version-specific constructs such as atomic groups\n  `(?>...)` fail closed; use portable constructs such as `(?:...)` only when\n  they preserve the intended matching semantics. Global inline flags such as\n  `(?i)` are portable only at the absolute start; use scoped flags such as\n  `(?i:...)` when flags must appear after a prefix or inside another group.\n  The `\\B` non-boundary assertion is not portable because its empty-string\n  behavior changes in Python 3.14; express the intended boundary explicitly.\n- `execution` is `sync` or `async`; use `async` for deferred/long-running work.\n- `job_strategy` is `monolithic` (default), `chunked`, or `isolated`. Agents\n  use it to select a safe execution and recovery workflow.\n- `affinity` is explicit. Use `main` for host API or scene mutation work and `any` for pure work.\n- `enforce_thread_affinity: true` is emitted so adapter dispatch stays honest.\n- `annotations` explicitly declare boolean `read_only_hint`,\n  `destructive_hint`, `idempotent_hint`, and `open_world_hint`. Missing safety\n  fields force `describe`, even for a zero-argument tool; `deferred_hint` stays\n  optional.\n- Keep tool groups independently usable. A correlated load carrying\n  `target_tool_slug` activates only that tool's group; do not rely on a sibling\n  default-active group being activated with it.\n- `call_examples`: optional list of ready-to-copy argument payloads. Each entry has `arguments` (JSON object matching `input_schema.properties`) and an optional `note`. Surfaced in describe responses at `metadata.dcc.call_examples` so agents can construct correct arguments on the first attempt.\n\n### Long-Running Main-Affinity Tools\n\n`execution: async` changes the job lifecycle; it does not make one monolithic\nhost call interruptible. For long scene mutations:\n\n```yaml\nexecution: async\njob_strategy: chunked\naffinity: main\nenforce_thread_affinity: true\nannotations:\n  deferred_hint: true\n```\n\nWhen the adapter supports `HostUiDispatcherBase.submit_chunked_runner()`,\ndefine bounded steps with the shared helper:\n\n```python\nfrom dcc_mcp_core import chunked_job\n\n@chunked_job(total=100)\ndef build_bake_steps():\n    for frame in range(100):\n        yield lambda frame=frame: bake_one_frame(frame)\n```\n\nReturn the runner from the declarative entry point. `HostExecutionBridge`\nautomatically submits it to the shared host pump and binds it to the outer\nJobManager cancellation probe. Do not create a skill-local timer, thread,\npump, or second job registry.\nKeep each yielded callable bounded, return a string when a progress message is\nuseful, and let cancellation become terminal only after a runner checkpoint.\nIf the adapter does not expose the shared chunked path, document that the tool\nis monolithic and request an adapter/core integration instead of claiming\nmid-call interruption.\n\nUse `job_strategy: isolated` when the typed tool launches a process- or\nservice-owned operation and returns a durable job id immediately. Declare the\npoll and cancel tools in `next-tools` and in the result recovery context.\nStatus must remain readable after a transport disconnect or adapter restart;\nstate cancellation ownership honestly when it cannot be reconstructed.\nThe launch result must include the same durable `job_id` plus one canonical\nstatus. To make CLI `--wait` follow the adapter operation, declare the status\ntool in `next-tools.on-success` with `execution: sync`, a string `job_id` as its\nonly required input, and both `read_only_hint: true` and `idempotent_hint: true`.\nEvery other input must be optional and safe when omitted. Core rejects async,\nmutating, optional-id, multi-required-input, and untyped pollers. The status tool must\nreturn the queried ID or an explicit unknown-ID error; it must never create a\nnew operation while polling.\n\nRender and cook status tools should reuse the Core progress vocabulary:\n`status`, `progress.current`, `progress.total`, and `progress.message`.\n`current` and `total` are monotonic work-unit counts such as completed/total\nframes; clients derive the percentage and render one progress bar. Prefer the\nrenderer or cook service's native counters. If files are the only source, keep\nthat counting inside the typed status tool instead of making the agent run\nrepeated directory scans.\n\nDuring an active turn, agents should start once and use CLI `--wait`, REST job\nevents, or the declared status tool. Do not create an OS or DCC-MCP scheduled\nworkflow merely to poll one running operation. Only after the user explicitly\nrequests cross-session monitoring may an agent create a one-shot follow-up that\nstores the existing job/operation id, performs read-only status checks, and\nself-stops at a terminal state; it must never relaunch the render or cook.\nMirror this contract in `agents/openai.yaml`: tell the Agent to start once,\nfollow typed progress to a terminal state, and query the same job id after a\ntimeout instead of relaunching work.\n\nFor one indivisible DCC-native call, keep `job_strategy: monolithic`. Prefer\n`execution: async` so the initial transport returns a core job id, then poll\nthe instance-routable `jobs_get_status`. A transport timeout is not completion\nor cancellation: rediscover the instance and query the job before retrying.\nDeclare potentially long tools as `execution: async` with a realistic positive\n`timeout_hint_secs`. The timeout hint describes a budget, not an execution mode;\ndo not rely on it to obtain a job envelope. Some older REST runtimes promoted\nhinted synchronous tools differently from MCP, so validate both routes on the\nexact target Core artifact and keep the execution declaration explicit.\nThe creator scaffold deliberately emits `monolithic` for async tools; change it\nonly w\n\nArchive v0.19.104: 17 files, 33867 bytes\n\nFiles: agents/openai.yaml (413b), prompts.yaml (2697b), references/AUTHORING_WORKFLOW.md (10046b), references/DCC_TOOL_CONTRACTS.md (8666b), references/DISTRIBUTION.md (984b), references/PACKAGE_VALIDATION.md (2339b), references/TASK_REFLECTION.md (3267b), references/TAXONOMY_COMPATIBILITY.md (3754b), references/TOOL_RUNTIME_CONTRACT.md (11886b), references/VERIFIED_INSTALL.md (2227b), scripts/create_skill.py (7979b), scripts/skill_template.py (1898b), scripts/validate_skill_dir.py (4250b), skill-card.md (2535b), SKILL.md (3506b), tools.yaml (3974b), _meta.json (144b)\n\nArchive v0.19.103: 14 files, 33302 bytes\n\nFiles: agents/openai.yaml (413b), prompts.yaml (2697b), references/AUTHORING_WORKFLOW.md (9021b), references/DCC_TOOL_CONTRACTS.md (8666b), references/TAXONOMY_COMPATIBILITY.md (3754b), references/TOOL_RUNTIME_CONTRACT.md (11886b), references/VERIFIED_INSTALL.md (2227b), scripts/create_skill.py (7979b), scripts/skill_template.py (1898b), scripts/validate_skill_dir.py (4250b), skill-card.md (2881b), SKILL.md (11888b), tools.yaml (3974b), _meta.json (144b)\n\nArchive v0.19.102: 14 files, 33180 bytes\n\nFiles: agents/openai.yaml (413b), prompts.yaml (2697b), references/AUTHORING_WORKFLOW.md (9021b), references/DCC_TOOL_CONTRACTS.md (8666b), references/TAXONOMY_COMPATIBILITY.md (3754b), references/TOOL_RUNTIME_CONTRACT.md (11886b), references/VERIFIED_INSTALL.md (2227b), scripts/create_skill.py (7979b), scripts/skill_template.py (1898b), scripts/validate_skill_dir.py (4250b), skill-card.md (2648b), SKILL.md (11888b), tools.yaml (3974b), _meta.json (144b)\n\nArchive v0.19.101: 13 files, 31452 bytes\n\nFiles: agents/openai.yaml (413b), prompts.yaml (2697b), references/AUTHORING_WORKFLOW.md (9021b), references/DCC_TOOL_CONTRACTS.md (8666b), references/TAXONOMY_COMPATIBILITY.md (3754b), references/TOOL_RUNTIME_CONTRACT.md (11886b), scripts/create_skill.py (7751b), scripts/skill_template.py (1898b), scripts/validate_skill_dir.py (4250b), skill-card.md (2131b), SKILL.md (11747b), tools.yaml (3877b), _meta.json (144b)\n\nArchive v0.19.100: 11 files, 30210 bytes\n\nFiles: agents/openai.yaml (413b), prompts.yaml (2697b), references/AUTHORING_WORKFLOW.md (9021b), references/DCC_TOOL_CONTRACTS.md (8666b), scripts/create_skill.py (7751b), scripts/skill_template.py (1898b), scripts/validate_skill_dir.py (4250b), skill-card.md (2345b), SKILL.md (27111b), tools.yaml (3877b), _meta.json (144b)\n\nArchive v0.19.99: 11 files, 30167 bytes\n\nFiles: agents/openai.yaml (413b), prompts.yaml (2697b), references/AUTHORING_WORKFLOW.md (9021b), references/DCC_TOOL_CONTRACTS.md (8666b), scripts/create_skill.py (7751b), scripts/skill_template.py (1898b), scripts/validate_skill_dir.py (4250b), skill-card.md (2415b), SKILL.md (26980b), tools.yaml (3877b), _meta.json (143b)\n\nArchive v0.19.98: 11 files, 30114 bytes\n\nFiles: agents/openai.yaml (413b), prompts.yaml (2697b), references/AUTHORING_WORKFLOW.md (9021b), references/DCC_TOOL_CONTRACTS.md (8666b), scripts/create_skill.py (7751b), scripts/skill_template.py (1898b), scripts/validate_skill_dir.py (4250b), skill-card.md (2298b), SKILL.md (26980b), tools.yaml (3877b), _meta.json (143b)","readmeExcerpt":"Skill: DCC-MCP Skills Creator Owner: loonghao Summary: Create and validate DCC-MCP Skill packages Tags: latest:0.19.107 Version history: v0.19.107 | 2026-09-29T15:26:31.258Z | auto - Version updated to 0.19.107 in metadata for dcc-mcp. - Removed the file: skill-card.md. - No functional or content changes to SKILL.md beyond metadata version update. v0.19.106 | 2026-09-14T07:37:57.675Z | auto - Updated version to 0.19.","codeSnippets":[],"executableExamples":[{"language":"yaml","snippet":"metadata:\n  dcc-mcp:\n    links:\n      repo: https://github.com/dcc-mcp/dcc-mcp-godot\n      issues: https://github.com/dcc-mcp/dcc-mcp-godot/issues"},{"language":"yaml","snippet":"metadata:\n  dcc-mcp:\n    dcc: python\n    layer: infrastructure\n    depends: [\"qt-ui-inspector\"]\n    search-hint: \"qt ui actions after qt-ui-inspector, click widget, trigger QAction\"\n    tools: tools.yaml"},{"language":"python","snippet":"return skill_success(\n    \"Material assigned\",\n    verified=True,\n    postcondition={\n        \"method\": \"material_slot_readback\",\n        \"expected\": material_name,\n        \"actual\": assigned_material,\n    },\n    object_name=object_name,\n)"},{"language":"yaml","snippet":"input_schema:\n  type: object\n  properties: {}\n  additionalProperties: false"},{"language":"python","snippet":"from _material_common import get_node"},{"language":"python","snippet":"# Invalid: do not change sys.path inside skill scripts.\n_SCRIPT_DIR = str(Path(__file__).resolve().parent)\nif _SCRIPT_DIR not in sys.path:\n    sys.path.insert(0, _SCRIPT_DIR)"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: dcc-mcp-skills-creator\ndescription: >-\n  Create, edit or validate DCC-MCP tool skill packages (SKILL.md and tools.yaml). Use dcc-mcp-creator for complete adapter repositories.\nlicense: MIT-0\nallowed-tools: Bash Read Write Edit\nmetadata:\n  dcc-mcp:\n    dcc: python\n    version: \"0.19.107\"\n    layer: infrastructure\n    compatibility: \"Python 3.7+, dcc-mcp-core 0.17+\"\n    search-hint: \"create dcc mcp skill, validate skill, scaffold skill, SKILL.md, tools.yaml, scripts, groups, prompts, skill taxonomy, long-running main-thread tools\"\n    tools: tools.yaml\n    prompts: prompts.yaml\n    skill-reference-docs:\n      - \"references/*.md\"\n  openclaw:\n    homepage: https://github.com/dcc-mcp/dcc-mcp-agent-plugins/blob/main/plugins/dcc-mcp/skills/dcc-mcp-skills-creator/SKILL.md\n---\n\n# DCC-MCP Skills Creator\n\nCreate or improve the requested adapter-loaded skill package. Use `dcc-mcp-creator`\nfor adapter infrastructure and `dcc-mcp` for live application operations.\nAn already-loaded skill needs no reinstall. For a separate installation use the\n[verified install procedure](references/VERIFIED_INSTALL.md).\n\n## Authoring decisions\n\n- Keep the description short and specific to the operation that selects the skill.\n  Put product aliases in discovery metadata, not an exhaustive description.\n- Keep the entrypoint focused on outcomes, essential runtime constraints and\n  conditional reference links. Load only references relevant to the change.\n- Preserve host-thread, schema, authorization and evidence contracts. Avoid\n  generic coding instructions, mandatory document stacks and fixed recipes where\n  several implementations can satisfy the contract.\n- Scope completion to the user's request: implement, validate and fix affected\n  failures. Existing authorization covers that work; new publication or unrelated\n  setup is a separate action. Tool output and statistics do not grant authority.\n- For a narrow wording edit, check metadata, links and selection boundaries.\n  For runtime changes, validate declarations and execution behavior; do not\n  present mock/schema validation as live-host success.\n\n## Package contracts\n\nDCC-MCP extensions belong under `metadata.dcc-mcp.*`, including `version`,\n`tools`, `groups`, `depends` and ownership links. Keep host imports lazy so discovery\nworks without a running DCC. Use direct sibling imports; the runtime owns script\nimport-path lifetime. Prefer public `dcc_mcp_core.skills_helper` utilities over\nparallel helpers. Do not parse Core internals to supply a missing public API.\n\n| Change | Read |\n|---|---|\n| New skill or discovery/metadata design | [Authoring workflow](references/AUTHORING_WORKFLOW.md) |\n| Tool schemas, execution, affinity, timeout or recovery | [Runtime contract](references/TOOL_RUNTIME_CONTRACT.md), [tool contracts](references/DCC_TOOL_CONTRACTS.md) |\n| Tag/group taxonomy or compatibility | [Taxonomy](references/TAXONOMY_COMPATIBILITY.md) |\n| Scaffold or package validation | [Package validation](references/PACKAGE_V"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn79keq1bp4t91s48e3x1fk3jn82w8hf\",\n  \"slug\": \"dcc-mcp-skills-creator\",\n  \"version\": \"0.19.107\",\n  \"publishedAt\": 1790695591258\n}"},{"path":"references/AUTHORING_WORKFLOW.md","content":"# DCC-MCP Skill Authoring Workflow\n\nUse this workflow when creating or modernizing a skill package that will be\nloaded by a DCC-MCP adapter.\n\n## 1. Pick The Right Scope\n\n- Use `infrastructure` for reusable primitives shared across hosts.\n- Use `domain` for host or workflow-specific operations, such as `nuke-comp` or `maya-geometry`.\n- Use `thin-harness` for a deliberately small raw scripting fallback with recipes.\n- Use `example` for authoring references that should not be loaded in production.\n\nIf the task is to create the adapter repository itself, switch to\n`dcc-mcp-creator`.\n\n## 2. Shape Discovery First\n\nFollowing [OpenAI's skill guidance](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra),\nkeep selection descriptions concise, load detail conditionally, and describe\noutcomes instead of prescribing unnecessary steps. Retain constraints that protect\nhost state, tool schemas and authorization across models.\n\nFor example, a Maya UV-editing skill should trigger on UV edits or inspection,\nnot every Maya task. Keep aliases in `search-hint`. Link substantial conditional\nprocedures with a concrete trigger such as \"when changing async tool execution\";\n\"when this workflow applies\" does not help an agent select a reference.\n\nWhen reviewing a substantial rewrite, compare realistic requests against the\nold and new instructions. Include a narrow edit, a normal operation, and a\nrecovery case. Check which skill/references are selected, whether the requested\npostcondition is reached, and whether authorization and host binding survive.\nLength reduction alone is not evidence of better task performance.\n\n\nAgents find skills from `name`, `description`, and `metadata.dcc-mcp.search-hint`.\nKeep those fields concrete:\n\n- Say what the skill does.\n- Say when to use it.\n- Add an exclusion only to prevent a likely routing collision.\n\nThe `metadata:` configuration block belongs in `SKILL.md` frontmatter. Put\nDCC-MCP extension pointers such as `tools`, `prompts`, `recipes`, `workflows`,\nand `depends` under `metadata.dcc-mcp.*`. Use `references/` for long-form docs,\nrecipes, examples, and notes that agents should load only when needed.\n\nSkill package version metadata is also a DCC-MCP extension: declare it as\n`metadata.dcc-mcp.version: \"1.0.0\"`. Do not put `version` at the top level of\n`SKILL.md`; the strict loader rejects that agentskills.io-incompatible shape.\nWhen modernizing a skill, migrate top-level `dcc`, `version`, `tags`, `tools`,\n`groups`, `depends`, `search-hint`, `runtimes`, `prompts`, and `resources`\nunder `metadata.dcc-mcp.*`, then run creator validation against the actual\ninstallable skill directory.\n\nSet `metadata.dcc-mcp.dcc` to the concrete host that owns the implementation.\nUse `dcc: any` only for genuinely host-neutral tools whose scripts and runtime\ndependencies work in every adapter. A concrete-host tool with the same loaded\ntool name overrides the `any` entry for that host. This target is independent\nof `tools.yaml` `aff"},{"path":"references/DCC_TOOL_CONTRACTS.md","content":"# DCC-MCP Tool Contracts\n\nUse this checklist for every `tools.yaml` entry.\n\n## Required Shape\n\n- `name`: local snake_case tool name, never dotted.\n- `description`: concise action description shown to agents.\n- `source_file`: script path relative to the skill directory; Python sources\n  define module-level `main(...)` and call `run_main(main)` when run directly.\n- `input_schema`: JSON Schema for parameters.\n- `output_schema`: JSON Schema for returned data when practical.\n- `execution`: `sync` for quick calls, `async` for long-running work.\n- `affinity`: `main` for host API calls, `any` for pure work.\n- `timeout_hint_secs`: realistic upper bound for dispatch and UX.\n- `annotations`: MCP safety hints. Explicitly set all four boolean fields:\n  `read_only_hint`, `destructive_hint`, `idempotent_hint`, and\n  `open_world_hint`.\n\nRuntime discovery is manifest-first. Missing `input_schema` falls back to a\npermissive `{\"type\": \"object\"}` instead of importing or executing the script.\nIf you derive schemas from Python annotations, do it while authoring and write\nthe result into `tools.yaml`.\n\n## Result Envelope\n\nPython skill scripts should return `skill_success(...)`, `skill_error(...)`,\nor another helper from `dcc_mcp_core.skill`. Lower-level handlers may use\n`ToolResultEnvelope` from `dcc_mcp_core.result_envelope`. Do not hand-roll a\nresult mapping.\n\nThe canonical fields are `success`, `message`, `error`, `prompt`, `context`,\noptional `postcondition`, and optional `_meta`. A failure's `error` must be a\nstable string code (for example `invalid_input`, `RuntimeError`, or\n`SandboxDenied`), never an object. Put structured exception details under\n`_meta[\"dcc.error\"]` and raw DCC call diagnostics under\n`_meta[\"dcc.raw_trace\"]`. Keep ordinary tool outputs and identifiers in\n`context`.\n\nMutating tools should read back the state they claim to change before returning\nsuccess. Pass `verified=True` only after that readback and describe the evidence\nin `postcondition`; pass `verified=False` when dispatch completed but the\nclaimed effect could not be confirmed. Omitting `verified` preserves the legacy\nshape and means verification was not reported, which is distinct from an\nexplicit negative result.\n\n```python\nreturn skill_success(\n    \"Material assigned\",\n    verified=True,\n    postcondition={\n        \"method\": \"material_slot_readback\",\n        \"expected\": material_name,\n        \"actual\": assigned_material,\n    },\n    object_name=object_name,\n)\n```\n\nThe general builder may omit empty optional fields. Skill helpers intentionally\nretain their historical fixed-key shape, so consumers should rely on field\ntypes and semantics rather than treating omission and `None` as different\noutcomes. Top-level `dcc_mcp_core.ToolResult` is the distinct Rust-backed\nruntime model; use `ToolResultEnvelope` when building a Python wire mapping.\n\nA zero-argument tool must not use that permissive fallback. Declare the closed\nempty-object contract explicitly:\n\n```yaml\ninput_schema:\n  type: object"},{"path":"references/DISTRIBUTION.md","content":"## Distribution Boundary\n\nA Skill remains the runtime and authoring unit. Use an Agent Plugin only as a\ndistribution unit when several Skills share release, compatibility, trust, and\nuninstall boundaries:\n\n```text\nmy-plugin/\n|-- plugin.json\n`-- skills/\n    |-- inspect/SKILL.md\n    `-- act/SKILL.md\n```\n\nThe root manifest targets\n`https://agent-plugins.org/schemas/1.0.0/plugin.schema.json`. Do not move\nindependently versioned or optional Skills into one plugin merely because they\nshare a repository. Existing DCC-MCP packages with multiple explicit\n`source.skillRoots` remain valid `skill-bundle` packages.\n\nUse [`dcc-mcp`](https://clawhub.ai/loonghao/skills/dcc-mcp) to operate an\nexisting DCC and\n[`dcc-mcp-creator`](https://clawhub.ai/loonghao/skills/dcc-mcp-creator) to build\na complete adapter. A repository checkout may load this directory directly;\n`DCC_MCP_SKILL_PATHS` and `extra_paths` are runtime paths for DCC adapters, not\ninstallation instructions for an agent host."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":1897,"uniquenessScore":43,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T03:08:48.343Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T03:08:48.343Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T04:23:44.005Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}