--- slug: "code-dev-v1" name: "code-dev-v1" version: 1.0.1 displayName: "结构化开发工具专业版" summary: "企业级版本化开发,支持多任务编排、发布管理、团队规范与交付审计。面向团队与企业的高级结构化开发工具,在免费版基础上扩展多任务编排、发布管理、团队规范等能力。核心能力: - 多任务并行编排与版" summary_zh: "企业级版本化开发,支持多任务编排、发布管理、团队规范与交付审计。面向团队与企业的高级结构化开发工具,在免费版基础上扩展多任务编排、发布管理、团队规范等能力。核心能力: - 多任务并行编排与版" license: "MIT" edition: "pro" description: |- 面向团队与企业的高级结构化开发工具,在免费版基础上扩展多任务编排、发布管理、团队规范等能力。核心能力: - 多任务并行编排与版本化检查点 - 发布版本管理与变更日志 - 团队编码规范与质量基线 - 交付审计与合规追踪 - 多环境配置与发布流水线 适用场景: - 企业级多功能版本化开发 - 团队协作与发布管理 - 合规审计与交付追踪 差异化: - 兼容免费版全部能力,无缝升级 - 支持版本化发布与变更日志 - 提供团队规范与审计追踪 - 优先技术支持与更新通道 tags: - 开发工具 - 结构化开发 - 企业级 - 版本管理 - 发布流程 - 代码生成 - 编程辅助 - true - 检查点 - 审计点 - bash tools: - read - exec - write - glob - grep homepage: "" category: "Development" --- # 结构化开发工具专业版 ## 付费版专享能力 | 能力 | 免费版 | 付费版 | |---|---|---| | 基础功能 | 支持 | 支持 | | 结构化开发工具专业版支持多任务编排 | 不支持 | 支持 | | 结构化开发工具专业版发布管理 | 不支持 | 支持 | | 代码静态分析与质量评分 | 不支持 | 支持 | | 依赖漏洞检测与升级建议 | 不支持 | 支持 | | 批量代码审查与报告生成 | 不支持 | 支持 | ## 核心能力 ### 1. 多任务版本化编排 ```text 版本 v2.1.0 开发编排: 功能A: 用户认证增强 ──┐ 功能B: 订单流程优化 ──┤── 集成测试 ── 发布 功能C: 性能优化 ──┘ ``` ```bash # 版本化多任务编排 请编排版本 v2.1.0 的开发任务: 任务1: 增强 JWT 认证 (优先级: 高, 无依赖) 任务2: 优化订单流程 (优先级: 中, 依赖: 任务1) 任务3: 数据库性能优化 (优先级: 中, 无依赖) 任务4: 集成测试 (优先级: 高, 依赖: 全部) 版本目标: v2.1.0 检查点: 每步创建版本化检查点 ```- 验证返回数据的完整性和格式正确性 - 参考`多任务版本化编排`的配置文档进行参数调优 ### 2. 发布版本管理 ```bash # 创建发布版本 请创建发布版本 v2.1.0 包含功能: - JWT 认证增强 - 订单流程优化 - 数据库性能优化 变更日志: 自动生成 标签: v2.1.0 ``` 版本管理能力: | 功能 | 说明 | |:-----|:-----| | 版本创建 | 按语义版本规范创建 | | 变更日志 | 自动生成 CHANGELOG | | 版本标签 | Git 标签管理 | | 发布检查 | 质量门禁通过才允许发布 | | 回滚支持 | 版本回滚与检查点恢复 | **输入**: 用户提供发布版本管理所需的指令和必要参数. ### 3. 团队编码规范 ```json { "team_standards": { "version_control": { "branch_naming": "feature/{version}-{feature}", "commit_format": "conventional", "pr_required": true, "min_reviewers": 2 }, "code_quality": { "test_coverage_min": 80, "max_complexity": 15, "lint_errors_max": 0, "type_check_required": true }, "release": { "versioning": "semantic", "changelog_required": true, "quality_gate_required": true, "audit_required": true } } } ``` **输入**: 用户提供团队编码规范所需的指令和必要参数. **处理**: 解析团队编码规范的输入参数,执行核心处理逻辑,返回结构化结果和执行状态. **输出**: 返回团队编码规范的处理结果,包含执行状态码、结果数据和执行日志. ### 4. 交付审计追踪 ```text 审计追踪链: 需求 → 规划 → 开发 → 验证 → 审查 → 发布 ↓ ↓ ↓ ↓ ↓ ↓ 审计点 审计点 审计点 审计点 审计点 审计点 ``` 审计记录包含: | 记录项 | 说明 | |---:|---:| | 版本号 | 语义版本标识 | | 任务清单 | 包含的所有任务 | | 变更文件 | 修改的文件列表 | | 质量报告 | 各项质量指标 | | 审查记录 | 代码审查详情 | | 发布决策 | 审批人与决策 | | 时间线 | 各阶段时间戳 | **输入**: 用户提供交付审计追踪所需的指令和必要参数. **处理**: 解析交付审计追踪的输入参数,执行核心处理逻辑,返回结构化结果和执行状态. **输出**: 返回交付审计追踪的处理结果,包含执行状态码、结果数据和执行日志. ### 5. 多环境发布流水线 ```text 开发 → 测试 → 预发布 → 生产 ↓ ↓ ↓ ↓ 验证 集成测试 灰度验证 全量发布 ``` **输入**: 用户提供多环境发布流水线所需的指令和必要参数. **处理**: 解析多环境发布流水线的输入参数,执行核心处理逻辑,返回结构化结果和执行状态. **输出**: 返回多环境发布流水线的处理结果,包含执行状态码、结果数据和执行日志。- 验证执行结果,确认输出符合预期格式 - 异常时参考错误处理章节进行恢复 - 关键参数: `多环境发布流水线` 选项 # ## 快速开始 1. 确认运行环境满足依赖说明中的要求 2. 在AI Agent对话中调用本技能,提供必要的输入参数 3. 检查输出结果,根据需要进行后续处理 > 详细的输入输出格式请参考下方章节说明。 ## 适用场景 ### 场景一: 企业级版本化发布 按版本规划开发,管理发布流程. ```bash # 版本化开发编排 请编排版本 v2.1.0 开发: 功能: 1. [auth] 增强 JWT 认证 (高优先级, 无依赖) 2. [order] 优化订单流程 (中优先级, 依赖: auth) 3. [perf] 数据库性能优化 (中优先级, 无依赖) 4. [test] 集成测试 (高优先级, 依赖: 全部) 版本目标: v2.1.0 检查点: 版本化,可回溯 完成后: 生成变更日志 ``` 输出示例: ```text 版本 v2.1.0 开发报告 ===================================== # ... 任务状态: 1. [auth] JWT 认证增强 ✅ 完成 (检查点: 5个) 2. [order] 订单流程优化 ✅ 完成 (检查点: 4个) 3. [perf] 性能优化 ✅ 完成 (检查点: 3个) 4. [test] 集成测试 ✅ 通过 (45/45) # ... 质量门禁: - 测试覆盖率: 87% ✅ (要求: 80%) - Lint: 0 错误 ✅ - 类型检查: 0 错误 ✅ - 复杂度: 最大 12 ✅ (限制: 15) # ... 变更日志: # ... ## 使用流程 # ... ### 优秀步: 初始化版本管理配置 # ... ```bash mkdir -p .code-toolkit/{audit,versions,changelogs,configs} cat > .code-toolkit/config.json << 'EOF' { "edition": "pro", "versioning": { "scheme": "semantic", "current_version": "2.0.0", "changelog_auto": true }, "workflow": { "parallel_tasks": 3, "checkpoints_versioned": true, "quality_gate_required": true }, "release": { "environments": ["dev", "test", "staging", "prod"], "auto_promote": false, "rollback_enabled": true }, "audit": { "enabled": true, "log_dir": ".code-toolkit/audit/", "retention_days": 365 } } EOF ``` # ... ### 第二步: 规划版本开发 # ... ```bash # 规划新版本 请规划版本 v2.1.0: 功能清单: [认证增强, 订单优化, 性能优化] 任务拆分: 自动 依赖分析: 自动 检查点: 版本化 ``` # ... ### 第三步: 执行与发布 # ... ```bash # 开发完成后 请执行版本 v2.1.0 发布检查: - 质量门禁: 全部通过 - 变更日志: 已生成 - 审计报告: 已生成 - 发布环境: staging → prod ``` # ... **结果验证**: 任务完成后,查看输出确认状态。成功时返回摘要和数据;失败时根据错误信息排查,参考恢复章节获取修复步骤. # ... # ... ## 输入格式 # ... | 参数名 | 类型 | 必填 | 说明 | |:---:|:---:|:---:|:---:| | content | string | 否 | code-dev-v1处理的内容输入 |, 默认: 全部维度 | | strict_level | string | 否 | 审查严格度, 可选: strict/normal/loose, 默认: normal | # ... ## 输出格式 # ... ```json { "success": true, "data": { "overall_grade": "A", "total_score": 92, "max_score": 100, "summary": "处理完成", "details": [ { "item": "代码风格", "status": "pass", "score": 95, "comment": "符合规范" }, { "item": "安全合规", "status": "warn", "score": 80, "comment": "符合规范" } ], "improvements": [ { "priority": "high", "suggestion": "建议优化", "expected_gain": "+5分" }, { "priority": "medium", "suggestion": "建议优化", "expected_gain": "+3分" } ] }, "error": null } ``` # ... ## 异常处理 # ... # ... | 错误场景 | 原因 | 处理方式 | |:------|------:|:------| | 配置错误 | 参数缺失或格式错误 | 检查依赖说明中的配置要求 | | 运行时错误 | 运行环境不满足 | 确认运行环境符合依赖说明 | | 网络错误 | 连接超时或不可达 | # ... ## 依赖说明 # ... ### 运行环境 # ... - **Agent 平台**: 支持读取 SKILL.md 的任意 AI Agent(Claude Code / Cursor / Codex / Gemini CLI 等) - **操作系统**: Windows / macOS / Linux - **Git**: 版本控制与发布管理 - **Python**: 3.8+(质量门禁脚本) # ... ### 依赖说明(补充) # ... | 依赖项 | 类型 | 是否必需 | 获取方式 | |---:|:---|---:|---:| | LLM API | API | 必需 | 由 Agent 内置 LLM 提供 | | Git | CLI 工具 | 版本管理必需 | 系统自带 | | Python 3.8+ | 运行时 | 质量脚本必需 | python.org | | ruff(可选) | Linter | 规范检查 | `pip install ruff` | | pytest(可选) | 测试框架 | 测试覆盖 | `pip install pytest` | | mypy(可选) | 类型检查 | 类型门禁 | `pip install mypy` | # ... ### API Key 配置 # ... - 本工具基于 Markdown 指令驱动,无需额外 API Key - 发布流程如需调用 CI/CD 服务,配置对应凭据: # ... ```bash export CODE_TOOLKIT_CI_TOKEN="your-ci-token" export CODE_TOOLKIT_RELEASE_WEBHOOK="https://hooks.example.com/release" ``` # ... ### 可用性分类 # ... - **分类**: MD+EXEC+SCRIPT+AUDIT(Markdown 指令 + 命令行执行 + 质量脚本 + 审计日志) - **说明**: 通过自然语言指令驱动 Agent 管理版本化开发流程,支持发布管理与合规审计 - **离线可用**: 核心工作流完全离线;CI/CD 集成需要网络连接 # ... ## 案例展示 # ... ### 企业级配置 # ... ```json { "edition": "pro", "organization": { "name": "开发团队", "team_members": ["dev-a", "dev-b", "dev-c"], "reviewers": ["review-a", "review-b"] }, "versioning": { "scheme": "semantic", "current_version": "2.0.0", "changelog_auto": true, "tag_on_release": true }, "workflow": { "parallel_tasks": 5, "checkpoints_versioned": true, "quality_gate_required": true, "auto_rollback_on_fail": true }, "standards": { "test_coverage_min": 80, "max_complexity": 15, "lint_errors_max": 0, "type_check_required": true, "security_scan": true }, "release": { "environments": ["dev", "test", "staging", "prod"], "quality_gate_required": true, "rollback_enabled": true, "audit_required": true }, "audit": { "enabled": true, "log_dir": ".code-toolkit/audit/", "retention_days": 365, "track_all_changes": true } } ``` # ... ### 变更日志配置 # ... ```json { "changelog": { "auto_generate": true, "format": "keepachangelog", "categories": { "added": "新增", "changed": "变更", "deprecated": "弃用", "removed": "移除", "fixed": "修复", "security": "安全" }, "output_file": "CHANGELOG.md" } } ``` # ... ## 常见问题 # ... ### Q1: 专业版是否兼容免费版的检查点? # ... 完全兼容。专业版使用相同的检查点格式,免费版的检查点可直接在专业版中使用. # ... ### Q2: 版本回滚会丢失数据吗? # ... 不会。回滚到之前的版本时,当前代码保留在单独分支,可随时恢复. # ... ### Q3: 变更日志如何自动生成? # ... 基于 Git 提交记录与任务描述,按 Keep a Changelog 格式自动分类生成. # ... ### Q4: 多环境发布如何管理? # ... 在配置中定义环境顺序(如 dev → test → staging → prod),每个环境需通过质量门禁才能晋升到下一环境. # ... ### Q5: 审计日志保留多久? # ... 默认保留 365 天,可通过配置调整。满足大多数合规审计要求. # ... ### Q6: 如何获得优先技术支持? # ... 专业版用户可通过专属通道提交问题,通常 1 个工作日内响应. # ... ## 错误处理 # ... # ... | 错误场景(续)| 原因 | 处理方式 | |:---------:|-----------|:----------| | LLM响应超时或无响应 | 网络延迟或模型负载过高 | ，请求；确认Agent平台LLM服务正常 | | 输入内容格式不正确 | 用户输入不符合skill预期格式 | 检查输入是否符合skill使用说明中的格式要求，参考示例章节 | | 执行结果与预期不符 | 指令描述不够明确或上下文不足 | 提供更详细的指令描述，补充必要的上下文信息 | | 命令执行失败 | 运行环境不满足要求或权限不足 | 确认运行环境符合依赖说明中的要求；检查命令权限设置 | # ... # ...