菜单
Guardrails for edits to core/versioning/version-manager.js covering semver validation, deprecation, migrations, and compatibility rules. Use when changing version registration or migration handling.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/thefixer3x/onasis-gateway --skill version-manager命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use this skill when recording, recalling, or analyzing behavioral workflow patterns via the LanOnasis MaaS API. Trigger when the user or an agent wants to save a successful workflow for future reuse, recall past patterns before starting a task, analyze how Claude has handled similar tasks before, or when working with the `@lanonasis/mem-intel-sdk` behavior features. Also trigger when the user says things like "remember how I did this", "what's my usual pattern for X", "log this workflow", or "use my previous approach."
Use this skill when adding new methods, tools, or schema changes to the `@lanonasis/mem-intel-sdk`. Trigger when the user wants to extend the SDK with new capabilities, add a new MCP tool to mcp-core, add a new intelligence endpoint, or migrate the behavior_patterns schema. Also trigger when the user says things like "add a new tool to the SDK", "extend mem-intel-sdk", "add behavior X to the MCP server", or "update the SDK schema." Do NOT use for general behavior pattern recording/recall — use the behavior-memory skill for that.
Guardrails for edits to core/base-client.js covering auth injection, retries, circuit breaker behavior, and request/response events. Use when modifying the universal API client or its auth/retry/error handling.
正在显示 SKILL.md
基于 SOC 职业分类
| name | version-manager |
| description | Guardrails for edits to core/versioning/version-manager.js covering semver validation, deprecation, migrations, and compatibility rules. Use when changing version registration or migration handling. |
This skill applies when modifying the Version Manager (core/versioning/version-manager.js).
The Version Manager provides:
// MUST validate version format before registration
registerVersion(serviceId, version, config) {
if (!semver.valid(version)) {
throw new Error(`Invalid version format: ${version}`);
}
// Continue with registration
}
// MUST detect these as breaking changes:
const breakingChangeTypes = [
'endpoint_removed',
'method_changed',
'path_changed',
'required_parameter_added',
'required_parameter_removed',
'parameter_type_changed',
'auth_type_changed',
'baseUrl_changed'
];
// Compatibility MUST be false if any breaking changes exist
compatibility.compatible = compatibility.breakingChanges.length === 0;
// MUST include metadata on registration
this.supportedVersions.set(key, {
...config,
registeredAt: new Date(),
deprecated: false
});
// MUST create compatibility mappings
this.createCompatibilityMappings(serviceId, version, config);
// MUST emit registration event
this.emit('version:registered', { serviceId, version, config });
// MUST follow deprecation protocol
deprecateVersion(serviceId, version, reason) {
config.deprecated = true;
config.deprecationReason = reason;
config.deprecatedAt = new Date();
this.emit('version:deprecated', { serviceId, version, reason });
}
// MUST register handlers for version transitions
registerMigrationHandler(serviceId, fromVersion, toVersion, handler) {
const key = `${serviceId}:${fromVersion}->${toVersion}`;
this.migrationHandlers.set(key, handler);
}
// MUST emit events for version lifecycle
this.emit('version:registered', { serviceId, version, config });
this.emit('version:deprecated', { serviceId, version, reason });
this.emit('migration:completed', { serviceId, fromVersion, toVersion, data });
this.emit('migration:failed', { serviceId, fromVersion, toVersion, error });
Day 0: Mark as deprecated, emit 'version:deprecated' event
Day 1-7: Log warnings for all requests using deprecated version
Day 8-14: Return deprecation headers in responses
Day 15-29: Increase warning severity
Day 30+: Safe to remove (after migration verification)
| Change Type | Severity | Version Bump | Migration Required |
|---|---|---|---|
| Endpoint removed | BREAKING | Major | Yes |
| Method changed | BREAKING | Major | Yes |
| Path changed | BREAKING | Major | Yes |
| Required param added | BREAKING | Major | Yes |
| Required param removed | BREAKING | Major | Yes |
| Param type changed | BREAKING | Major | Yes |
| Auth type changed | BREAKING | Major | Yes |
| baseUrl_changed | BREAKING | Major | Yes |
| Optional param added | Compatible | Minor | No |
| New endpoint added | Compatible | Minor | No |
| Bug fix | Compatible | Patch | No |
REGISTERED -> ACTIVE -> DEPRECATED -> REMOVED
^ |
+-----------+ (rollback possible before deprecation)
| Component | Integration Method |
|---|---|
| Base Client | Version passed in request options |
| Metrics Collector | Version label in request metrics |
| REST API | /v{version}/ path prefix |
| MCP Server | Version header in tool calls |
| Vendor Abstraction | Version-specific vendor mappings |