leniu-dev 2.0.0

package/.cursor/skills/file-oss-management/references/service-impl.md

@@ -0,0 +1,104 @@
+# SysOssServiceImpl 完整实现
+
+> 位置：`ruoyi-modules/ruoyi-system/src/main/java/org/dromara/system/service/impl/SysOssServiceImpl.java`
+
+## 文件上传
+
+```java
+@RequiredArgsConstructor
+@Service
+public class SysOssServiceImpl implements ISysOssService {
+
+    private final SysOssMapper baseMapper;
+
+    @Override
+    public SysOssVo upload(MultipartFile file) {
+        if (ObjectUtil.isNull(file) || file.isEmpty()) {
+            throw new ServiceException("上传文件不能为空");
+        }
+
+        String originalfileName = file.getOriginalFilename();
+        String suffix = StringUtils.substring(originalfileName,
+                                             originalfileName.lastIndexOf("."),
+                                             originalfileName.length());
+
+        OssClient storage = OssFactory.instance();
+
+        UploadResult uploadResult;
+        try {
+            uploadResult = storage.uploadSuffix(file.getBytes(), suffix, file.getContentType());
+        } catch (IOException e) {
+            throw new ServiceException(e.getMessage());
+        }
+
+        SysOssExt ext1 = new SysOssExt();
+        ext1.setFileSize(file.getSize());
+        ext1.setContentType(file.getContentType());
+
+        return buildResultEntity(originalfileName, suffix,
+            storage.getConfigKey(), uploadResult, ext1);
+    }
+
+    private SysOssVo buildResultEntity(String originalfileName, String suffix,
+        String configKey, UploadResult uploadResult, SysOssExt ext1) {
+
+        SysOss oss = new SysOss();
+        oss.setUrl(uploadResult.getUrl());
+        oss.setFileSuffix(suffix);
+        oss.setFileName(uploadResult.getFilename());       // 小写 'n'
+        oss.setOriginalName(originalfileName);
+        oss.setService(configKey);
+        oss.setExt1(JsonUtils.toJsonString(ext1));
+
+        baseMapper.insert(oss);
+        SysOssVo sysOssVo = MapstructUtils.convert(oss, SysOssVo.class);
+        return this.matchingUrl(sysOssVo);
+    }
+}
+```
+
+## 文件下载
+
+```java
+@Override
+public void download(Long ossId, HttpServletResponse response) throws IOException {
+    SysOssVo sysOss = SpringUtils.getAopProxy(this).getById(ossId);
+    if (ObjectUtil.isNull(sysOss)) {
+        throw new ServiceException("文件数据不存在!");
+    }
+
+    FileUtils.setAttachmentResponseHeader(response, sysOss.getOriginalName());
+    response.setContentType(MediaType.APPLICATION_OCTET_STREAM_VALUE + "; charset=UTF-8");
+
+    OssClient storage = OssFactory.instance(sysOss.getService());
+    storage.download(sysOss.getFileName(),
+        response.getOutputStream(),
+        response::setContentLengthLong);
+}
+```
+
+## 文件删除
+
+```java
+@Override
+public Boolean deleteWithValidByIds(Collection<Long> ids, Boolean isValid) {
+    List<SysOss> list = baseMapper.selectByIds(ids);
+    for (SysOss sysOss : list) {
+        OssClient storage = OssFactory.instance(sysOss.getService());
+        storage.delete(sysOss.getUrl());
+    }
+    return baseMapper.deleteByIds(ids) > 0;
+}
+```
+
+## 私有桶预签名URL
+
+```java
+private SysOssVo matchingUrl(SysOssVo oss) {
+    OssClient storage = OssFactory.instance(oss.getService());
+    if (AccessPolicyType.PRIVATE == storage.getAccessPolicy()) {
+        oss.setUrl(storage.createPresignedGetUrl(oss.getFileName(), Duration.ofSeconds(120)));
+    }
+    return oss;
+}
+```

package/.cursor/skills/fix-bug/SKILL.md

@@ -0,0 +1,269 @@
+---
+name: fix-bug
+description: |
+  Bug 修复全流程编排。两阶段 Agent 排查 + 报告确认 + git-workflow 提交。
+
+  触发场景：
+  - 修复 Bug（含日志/traceId/数据库信息）
+  - 线上问题排查与修复
+  - 报表数据不正确需排查修复
+  - 接口返回异常需定位修复
+
+  触发词：修复bug、fix bug、修复、排查修复、线上修复、bug修复
+---
+
+# Bug 修复全流程
+
+## 核心原则
+
+**先判断复杂度，简单 Bug 直接修，复杂 Bug 走两阶段 Agent 排查。搞清原因后先出报告，用户确认后再修复代码。**
+
+## 步骤 0：复杂度判断（必须先做）
+
+```
+用户提供 Bug 线索
+  │
+  ├─ 简单 Bug？ ──→ 快速路径
+  │   - 明显的代码错误（NPE、空判断遗漏、拼写错误）
+  │   - 用户已明确指出问题和修改方案
+  │   - 单文件改动，逻辑清晰
+  │   - 不需要查数据库/日志验证
+  │
+  └─ 复杂 Bug？ ──→ Agent 路径（两阶段排查）
+      - 需要查日志确认线上行为（提供了 traceId）
+      - 需要查数据库验证数据正确性（提供了 DB 信息）
+      - 问题根因不明确，需要多维度分析
+      - 涉及多模块/多表关联的数据问题
+```
+
+## 快速路径（简单 Bug）
+
+```
+读代码 → 定位问题 → 输出排查报告 → 用户确认 → 修复 → git-workflow 提交
+```
+
+不启动 Agent，直接在主对话中完成。即使是简单 Bug，也先说明问题原因和修复方案，等用户确认再动手。
+
+## Agent 路径（复杂 Bug）
+
+```
+步骤 1：收集信息（从用户消息中提取）
+  - traceId / 错误日志
+  - 数据库环境（host/port/库名）
+  - Loki 日志环境
+  - Bug 描述 / 期望行为
+
+步骤 2（阶段一）：并行启动 Agent
+  ├── bug-analyzer: 读代码分析根因
+  ├── loki-runner: 查 Loki 日志（有 traceId 时）
+  └── mysql-runner: 查数据库验证数据（有 DB 信息时）
+
+步骤 3（阶段二）：日志驱动二次查询
+  从 loki-runner 结果中提取：
+  ├── 表名（INSERT/UPDATE/DELETE/FROM/JOIN 后面的表名）
+  ├── 数据 ID（id=xxx、orderId=xxx 等）
+  ├── 租户 ID（tenantId、MERCHANT-ID 请求头）
+  └── SQL 语句片段
+  如果提取到有效的表名+ID → 自动启动 mysql-runner 二次查询
+
+步骤 4：汇总所有结果 → 输出排查报告（见下方模板）
+
+步骤 5：⏸️ 等待用户确认修复方案
+
+步骤 6：用户确认后 → 修复代码
+
+步骤 7：走 git-workflow 提交
+```
+
+## 排查报告模板（必须输出）
+
+无论简单还是复杂 Bug，修复代码前**必须先输出报告**：
+
+```markdown
+## 🔍 Bug 排查报告
+
+### 问题描述
+{用户报告的现象}
+
+### 根因分析
+{代码层面的根本原因，指出具体文件和行号}
+
+### 数据验证（如有）
+{从日志/数据库中发现的关键数据，证实根因}
+
+### 修复方案
+- 修改文件：`xxx.java` 第 N 行
+- 修改内容：{具体改动描述}
+- 影响范围：{改动是否影响其他功能}
+
+### 风险评估
+- 低/中/高
+- {风险说明}
+
+---
+确认修复请回复"修"，需要调整方案请说明。
+```
+
+**⚠️ 禁止跳过报告直接修改代码。必须等用户明确确认后才能开始修复。**
+
+## 阶段二：日志驱动二次查询
+
+当阶段一的 loki-runner 返回日志后，主会话检查日志内容：
+
+```
+loki-runner 返回日志
+  │
+  ├─ 日志中包含 SQL/表名/数据ID？
+  │   │
+  │   ├─ 阶段一已启动 mysql-runner？
+  │   │   → 检查是否需要追加查询（不同的表或ID）
+  │   │   → 需要则启动新的 mysql-runner 查询
+  │   │
+  │   └─ 阶段一未启动 mysql-runner？
+  │       → 从日志提取表名+ID+租户ID
+  │       → 自动启动 mysql-runner 二次查询
+  │
+  └─ 日志中无数据库相关信息？
+      → 跳过，直接汇总现有结果
+```
+
+### 日志中常见的可提取信息
+
+| 日志模式 | 提取内容 | 查询方式 |
+|---------|---------|---------|
+| `INSERT INTO order_info` | 表名 order_info | `SELECT * FROM order_info WHERE id = ?` |
+| `UPDATE account SET balance=` | 表名 account | `SELECT * FROM account WHERE id = ?` |
+| `orderId=123456` | 数据 ID | 按 ID 查对应表 |
+| `MERCHANT-ID: 100` | 租户 ID | 切换到对应租户库查询 |
+| `Duplicate entry 'xxx'` | 唯一键冲突 | 查重复数据 |
+| `Data truncation` | 字段溢出 | 查表结构 `DESC table_name` |
+
+## Agent 启动规则
+
+### 阶段一：必须并行（单条消息多个 Agent tool call）
+
+```
+# 正确：一条消息同时启动
+Agent(bug-analyzer, "分析 xxx 代码的 bug...")
+Agent(loki-runner, "查询 traceId xxx 的日志...")
+Agent(mysql-runner, "查询 xxx 数据库验证...")
+
+# 错误：串行启动（等一个完再启动下一个）
+```
+
+### 阶段二：按需启动（阶段一结果返回后）
+
+```
+# 从 loki-runner 结果中发现了表名和数据ID
+Agent(mysql-runner, "根据日志发现涉及 order_info 表，查询 id=xxx 的数据...")
+```
+
+### 各 Agent 职责
+
+| Agent | subagent_type | 职责 | 输入 |
+|-------|---------------|------|------|
+| 代码分析 | `bug-analyzer` | 读代码、分析根因、给修复方案 | Bug 描述 + 相关文件路径 |
+| 数据库验证 | `mysql-runner` | 查数据验证业务逻辑 | DB 连接信息 + 验证 SQL |
+| 日志查询 | `loki-runner` | 查 Loki 日志看线上行为 | Loki 环境 + traceId |
+
+### Agent 信息来源
+
+**配置文件优先**，不存在时自动创建模板并提示用户填写：
+
+| 配置 | 文件路径 |
+|------|---------|
+| MySQL | `.claude/mysql-config.json` |
+| Loki | `.claude/skills/loki-log-query/environments.json` |
+
+**配置获取流程**：
+```
+需要连 MySQL/Loki？
+  │
+  ├─ 配置文件存在且有有效凭证？ → 直接使用
+  │
+  ├─ 配置文件存在但是占位符？ → 提示用户填写敏感信息，等用户确认后继续
+  │
+  └─ 配置文件不存在？ → 创建模板文件（占位符） → 提示用户填写 → 等确认后继续
+```
+
+**敏感信息由用户手动填写，禁止 AI 将对话中的密码/token 写入配置文件。**
+
+### 按信息量决定启动哪些 Agent
+
+| 用户提供的信息 | 阶段一启动 | 阶段二（日志驱动） |
+|---------------|-----------|-----------------|
+| 只有 Bug 描述 | bug-analyzer | — |
+| Bug 描述 + traceId | bug-analyzer + loki-runner | 日志中有表名/ID → mysql-runner |
+| Bug 描述 + DB 信息 | bug-analyzer + mysql-runner | — |
+| Bug 描述 + traceId + DB 信息 | 全部 | 日志中有新表/ID → mysql-runner 追加查询 |
+
+## SQL 报表 Bug 专项流程
+
+当 Bug 涉及 **SQL 查询逻辑错误**（SUM/GROUP BY/CASE WHEN/金额计算等），启用以下验证流程：
+
+### 修复前：建立基线
+
+```
+1. 读取当前 Mapper XML，理解现有 SQL 逻辑
+2. 如果有已修复的参考查询（如同模块的明细查询），先读取其 SQL 逻辑作为正确参考
+3. 查库获取当前错误结果作为"修复前基线"（可选，用户提供 DB 时执行）
+```
+
+### 修复后：交叉验证（必须执行）
+
+**两步验证法**（以本项目销售汇总修复为典型案例）：
+
+```
+步骤 1：直接执行修改后的 SQL，验证基本逻辑
+  - 检查各记录类型是否正确处理（称重/按份、正向/逆向、入库/出库）
+  - 检查特殊值：NULL 处理、除零保护、边界条件
+
+步骤 2：交叉对比验证
+  - 方法 A：用已修复的明细查询做 SUM 汇总
+  - 方法 B：执行修改后的汇总查询
+  - 对比 A vs B：总计必须完全一致
+  - 按维度对比（按商品/按门店等）：逐行 MATCH/DIFF
+```
+
+### 验证 SQL 模板
+
+```sql
+-- 交叉验证：明细汇总 vs 汇总查询
+SELECT '明细汇总' as source, SUM(saleNum), SUM(cost), ...
+FROM (/* 明细查询逐行 */) detail
+UNION ALL
+SELECT '汇总查询' as source, ...
+FROM /* 汇总查询 */;
+
+-- 按维度逐行对比
+SELECT COALESCE(d.name, s.name) as name,
+       d.detail_value, s.summary_value,
+       CASE WHEN d.detail_value = s.summary_value THEN 'MATCH' ELSE 'DIFF' END as result
+FROM (/* 明细按维度 GROUP BY */) d
+LEFT JOIN (/* 汇总按维度 GROUP BY */) s ON d.id = s.id;
+```
+
+### SQL 修改注意事项
+
+| 规则 | 说明 |
+|------|------|
+| **保留 WHERE 条件** | 新增/修改查询必须包含与现有查询相同的过滤条件 |
+| **GROUP BY 优先** | 优先添加字段到 GROUP BY，不用 ANY_VALUE() |
+| **JOIN 一致性** | 主查询和合计查询的 JOIN 必须一致（如 drp_unit） |
+| **IFNULL 保护** | 除法运算中的分母必须用 IFNULL 防止除零 |
+| **业务类型分支** | CASE WHEN 必须覆盖所有业务类型（称重/按份、入库/出库等） |
+
+## 提交规则
+
+修复完成后，**必须调用 `Skill(git-workflow)` 再执行 git 操作**。
+
+禁止：
+- 直接 `git commit && git push` 跳过技能
+- 在 Agent 内部执行 git 操作
+
+## 注意
+
+- 简单 Bug 不要过度编排，直接修就行（但仍需先报告再修复）
+- 如果用户没提供 DB/Loki 信息但 Bug 涉及数据问题，主动询问
+- 与 `bug-detective` 技能的区别：`bug-detective` 是排查指南，`fix-bug` 是全流程编排（包含排查+修复+提交）
+- SQL 报表 Bug 修复后**必须执行交叉验证**，不能只看"能跑"就提交

package/.cursor/skills/git-workflow/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: git-workflow
+description: |
+  通用 Git 工作流指南。涵盖分支策略、提交规范、PR 流程、冲突解决等。
+  触发场景：Git 操作、分支管理、提交规范、代码合并。
+  触发词：Git、分支、提交、合并、rebase、PR。
+  注意：如果项目有专属技能（如 `leniu-git-workflow`），优先使用专属版本。
+---
+
+# Git 工作流指南
+
+> 通用模板。如果项目有专属技能（如 `leniu-git-workflow`），优先使用。
+
+## 核心规范
+
+### 分支策略（Git Flow）
+
+```
+main (production)
+│
+├── hotfix/fix-payment-bug     ← 紧急修复，从 main 拉出
+│
+develop (integration)
+│
+├── feature/order-export       ← 功能开发，从 develop 拉出
+├── feature/user-profile       ← 并行开发
+│
+└── release/v1.2.0             ← 发布准备，从 develop 拉出
+```
+
+| 分支类型 | 来源 | 合并目标 | 命名 |
+|---------|------|---------|------|
+| `main` | - | - | `main` |
+| `develop` | `main` | `main` | `develop` |
+| `feature/*` | `develop` | `develop` | `feature/功能描述` |
+| `release/*` | `develop` | `main` + `develop` | `release/v1.x.x` |
+| `hotfix/*` | `main` | `main` + `develop` | `hotfix/问题描述` |
+
+### 简化策略（GitHub Flow，适合小团队）
+
+```
+main
+├── feature/order-export
+├── fix/login-error
+└── chore/upgrade-deps
+```
+
+- 只有 `main` 一个长期分支
+- 所有开发从 `main` 拉分支，完成后通过 PR 合并回 `main`
+
+### 提交规范（Conventional Commits）
+
+```
+<type>(<scope>): <subject>
+```
+
+| type | 说明 | 示例 |
+|------|------|------|
+| `feat` | 新功能 | `feat(order): 新增订单导出` |
+| `fix` | 修复 Bug | `fix(auth): 修复 token 过期未刷新` |
+| `docs` | 文档 | `docs: 更新 API 文档` |
+| `style` | 格式 | `style: 统一缩进为 4 空格` |
+| `refactor` | 重构 | `refactor(user): 拆分用户服务` |
+| `perf` | 性能 | `perf(query): 优化列表查询 N+1` |
+| `test` | 测试 | `test(order): 补充订单创建单测` |
+| `chore` | 构建/工具 | `chore: 升级 Spring Boot 3.2` |
+| `ci` | CI/CD | `ci: 添加 GitHub Actions 流水线` |
+
+**规则**：
+- subject 使用中文或英文，但全项目统一
+- 不超过 72 字符
+- 不以句号结尾
+- 使用祈使语气（"添加"而非"添加了"）
+
+### 提交行为规范
+
+1. **只提交当前会话的改动**：精确 `git add` 修改的文件，不要 `git add .`
+2. **不提交配置文件**：排除 `.env*`、`application-*.yml` 等环境配置
+3. **默认只提交到本地**：执行 `git add` + `git commit`，不自动 push
+4. **明确指定才推送**：只有用户明确说"推送"、"push"时才执行 `git push`
+
+## 代码示例
+
+### 常用 Git 操作
+
+```bash
+# 创建功能分支
+git checkout develop
+git pull origin develop
+git checkout -b feature/order-export
+
+# 开发完成，合并前更新
+git fetch origin
+git rebase origin/develop
+
+# 解决冲突后继续
+git add .
+git rebase --continue
+
+# 推送并创建 PR
+git push -u origin feature/order-export
+gh pr create --base develop --title "feat(order): 新增订单导出功能"
+```
+
+### 常用 Git 修复操作
+
+```bash
+# 修改最后一次提交信息
+git commit --amend -m "fix(order): 修复订单金额计算"
+
+# 撤销最后一次提交（保留修改）
+git reset --soft HEAD~1
+
+# 暂存当前修改
+git stash
+git stash pop
+
+# 挑选某个提交到当前分支
+git cherry-pick <commit-hash>
+
+# 查看某个文件的修改历史
+git log --oneline -20 -- path/to/file
+```
+
+### PR / Code Review 规范
+
+1. **PR 大小**：单个 PR 不超过 400 行变更（不含自动生成代码）
+2. **PR 描述**：说明改了什么、为什么改、如何测试
+3. **自查清单**：
+   - [ ] 代码能编译通过
+   - [ ] 新功能有对应测试
+   - [ ] 没有遗留 TODO / 调试代码
+   - [ ] 数据库变更有迁移脚本
+4. **Review 要点**：
+   - 逻辑正确性 > 代码风格
+   - 关注边界条件和异常处理
+   - 检查安全隐患（SQL 注入、XSS 等）
+
+### .gitignore 推荐配置
+
+```gitignore
+# IDE
+.idea/
+*.iml
+.vscode/
+*.swp
+
+# Build
+target/
+build/
+dist/
+node_modules/
+
+# Environment
+.env
+.env.local
+*.local
+
+# OS
+.DS_Store
+Thumbs.db
+
+# Logs
+*.log
+logs/
+```
+
+## 常见错误
+
+| 错误 | 正确做法 |
+|------|---------|
+| 直接在 main 上开发 | 创建功能分支 |
+| 提交信息写"update"、"fix bug" | 按 Conventional Commits 规范 |
+| 一个 PR 包含多个不相关改动 | 拆分为多个 PR |
+| `git push --force` 到公共分支 | 只对个人分支 force push |
+| 提交 .env、密钥文件 | 加入 .gitignore |
+| merge 前不更新目标分支 | 先 rebase/merge 最新代码 |
+| 忽略 CI 失败直接合并 | 修复 CI 后再合并 |
+| `git add .` 一把梭 | 精确添加修改的业务文件 |

package/.cursor/skills/jenkins-deploy/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: jenkins-deploy
+description: |
+  Jenkins + Portainer 自动打包部署技能。通过 Python 脚本调用 Jenkins API 构建项目，并触发 Portainer Webhook/Update 完成容器更新。
+
+  触发场景：
+  - 需要将代码打包部署到 dev/test 环境
+  - 需要触发 Jenkins 构建 core 或 api 项目
+  - 需要更新 Portainer 容器服务
+  - 需要查看或修改构建配置（分支、环境、模式）
+  - 定制项目的打包部署
+
+  触发词：打包、部署、Jenkins、构建、Portainer、发布到dev、发布到test、更新环境、自动部署
+---
+
+# Jenkins + Portainer 自动打包部署
+
+## 架构
+
+```
+技能目录（随框架更新，不复制到项目）:
+  ~/.claude/skills/jenkins-deploy/assets/jk_build.py     ← 构建脚本
+
+全局配置（一次性配置，所有项目共享）:
+  ~/.claude/jenkins-config.json                           ← 凭证（Jenkins/Portainer）
+
+项目本地（自动生成）:
+  jenkins/last_cd_env.json                                ← 构建状态（环境、分支、模式）
+```
+
+脚本按 **本地 `.claude/` > 全局 `~/.claude/`** 优先级查找 `jenkins-config.json`。
+
+## 构建模式
+
+| 模式 | 说明 | 执行步骤 |
+|------|------|---------|
+| `0` | 只构建 | 构建 core + api，不更新 Portainer |
+| `1` | 全构建+更新 | 构建 core + api → 触发 Portainer 更新 |
+| `2` | 构建 api+更新 | 跳过 core，构建 api → 触发 Portainer 更新 |
+| `3` | 只更新 | 不构建，直接触发 Portainer 更新 |
+
+## 环境支持
+
+| 环境 | 前缀 | Portainer 更新方式 |
+|------|------|-------------------|
+| dev1~15 | `dev` | Webhook 触发 |
+| dev16~43 | `dev` | Force Update（xnzn-dev.xnzn.net） |
+| dev44+ | `dev` | 只支持模式 0（手动更新） |
+| test | `test` | Webhook 触发 |
+
+## 使用方式
+
+### 运行构建脚本
+
+```bash
+python ~/.claude/skills/jenkins-deploy/assets/jk_build.py
+```
+
+脚本交互式询问：模式 → 环境 → core 分支 → api 分支 → 定制工程文件夹
+
+### 通过 AI 辅助部署
+
+当用户说"打包到 devX"时：
+
+1. 读取 `jenkins/last_cd_env.json` 获取上次参数
+2. 确认参数：环境、分支、模式
+3. 修改 `jenkins/last_cd_env.json` 写入新参数
+4. 执行 `python ~/.claude/skills/jenkins-deploy/assets/jk_build.py`
+
+## 配置文件
+
+### jenkins-config.json（凭证，全局）
+
+位置：`~/.claude/jenkins-config.json`（或本地 `.claude/jenkins-config.json`）
+
+模板：`.claude/skills/jenkins-deploy/assets/env_param.template.json`
+
+> **注意**：此文件包含敏感凭证，不要将内容输出到对话中。
+
+### last_cd_env.json（构建状态，项目本地）
+
+位置：`jenkins/last_cd_env.json`（脚本自动创建，无需手动初始化）
+
+```json
+{
+  "build_mode": "1",
+  "cd_env": "dev1",
+  "core_param_branch": "master",
+  "api_param_branch": "master",
+  "api_param_folder": null
+}
+```
+
+## 定制项目
+
+指定 `api_param_folder` 后，Jenkins Job 路径变为：
+
+```
+{folder_name}/dev-后端-core
+{folder_name}/dev-后端-api
+```
+
+## 首次初始化（团队成员）
+
+只需一步：配置全局凭证文件。
+
+```bash
+# 方式 1：从团队成员拷贝
+cp /path/to/teammate/jenkins-config.json ~/.claude/jenkins-config.json
+
+# 方式 2：从模板创建，手动填写凭证
+cp ~/.claude/skills/jenkins-deploy/assets/env_param.template.json ~/.claude/jenkins-config.json
+# 然后替换 __JENKINS_*__ 和 __PORTAINER_*__ 占位符
+```
+
+### AI 初始化行为
+
+当技能被触发但 `jenkins-config.json` 不存在时：
+1. 提示"检测到尚未配置 Jenkins 凭证"
+2. 询问是否从模板创建
+3. 复制模板到 `~/.claude/jenkins-config.json`
+4. 提示用户填写凭证（或拷贝已有配置）
+
+## 依赖
+
+```bash
+pip install python-jenkins requests
+```
+
+## 注意
+
+- 本技能用于 dev/test 环境部署，**不涉及生产环境**
+- 如果是 Git 提交/分支管理，请使用 `git-workflow` 技能
+- 如果是代码构建错误排查，请使用 `bug-detective` 技能