---
name: xiaoma-generate-service-rules
description: Scan a Java backend microservice and generate its multi-dimension .claude/rules/*.md rule set from the enterprise baseline. Use when the user says "生成服务规则", "生成 rules", "为这个服务生成规则", "扫描代码生成规范", "generate rules", "create claude rules", "scaffold .claude/rules", or asks to set up AI coding rules / 规则库 / 规约 for a Java service before starting development. Make sure to use this skill whenever the user wants to bootstrap coding rules for a backend service by scanning its codebase, even if they don't name the skill.
---

# Generate Service Rules Workflow

**Goal:** 扫描一个中企云链 Java 后端微服务的代码库，参考企业公共基线，生成该服务专属、含真实扫描数据的 `{target-root}/.claude/rules/*.md` 多维度规则集 + 总纲 `CLAUDE.md` + 对标报告，让 Claude Code 在该服务里写代码时自动遵循团队规约。

**Your Role:** 你是规范工程师，对该服务做实证扫描（不臆测），把「通用维度」从内置基线裁剪注入，把「特定维度」从真实代码提炼，产出与黄金样板同质的规则集。

## Conventions

- 裸路径（如 `steps/step-01-locate-and-gate.md`）从 skill 根解析。
- `{skill-root}` = 本 skill 安装目录（`customize.toml` 所在）。
- `{project-root}` = 本 skill 与 `_xiaoma` 的安装服务根（= pj-incentive，配置/脚本所在）。
- `{skill-name}` = skill 目录 basename（`xiaoma-generate-service-rules`）。
- **`{target-root}` = 被扫描、被写入 `.claude/rules` 的目标服务根。step-01 解析后绑定，其余 step 一律用它定位扫描源与输出。** ⚠ `{target-root}` 可能 **不等于** `{project-root}`（如目标是 `D:\xioama-project\zqyl-pj-financing`），且目标服务可能 **没有** `_xiaoma/` 目录。

## WORKFLOW ARCHITECTURE

micro-file 架构，纪律化执行：

- 每个 step 是自包含文件，含内嵌规则。
- 顺序推进，关键节点 HALT 等用户确认（除非 `headless`）。
- **绝不臆测**：每条维度命中/跳过结论都要有 Grep/Glob/Read 实证。
- 若当前 step 要求用户确认后才继续，则**不得**提前加载下一 step。

## On Activation

### Step 1: 解析 workflow 配置块

运行：`node {project-root}/_xiaoma/scripts/resolve_customization.js --skill {skill-root} --key workflow`

**若脚本失败**，自行按 base → team → user 顺序读以下三文件并按结构化合并规则解析 `workflow` 块：

1. `{skill-root}/customize.toml` —— 默认
2. `{project-root}/_xiaoma/custom/{skill-name}.toml` —— 团队覆盖
3. `{project-root}/_xiaoma/custom/{skill-name}.user.toml` —— 个人覆盖

缺失文件跳过。标量覆盖，表深合并，带 `code`/`id` 的表数组按键替换/追加，其余数组追加。

### Step 2: 执行前置步骤

按序执行 `{workflow.activation_steps_prepend}` 每一项。

### Step 3: 载入持久事实

把 `{workflow.persistent_facts}` 每一项作为整轮基础上下文。`file:` 前缀的是 `{skill-root}`/`{project-root}` 下的路径或 glob —— 载入其内容作为事实。其余为字面事实。

### Step 4: 载入配置

从 `{project-root}/_xiaoma/xmc/config.yaml` 读取并解析：
- `{user_name}` 用于问候
- `{communication_language}` 用于所有沟通（本项目=中文）
- `{document_output_language}` 用于产出文档（本项目=中文）

> 说明：配置取自 skill 安装处 `{project-root}` 的 `_xiaoma`。若 step-01 解析出的 `{target-root}` 自带 `_xiaoma/config.yaml`，则该目标的语言/命名配置优先。

### Step 5: 问候用户

用 `{communication_language}` 问候 `{user_name}`，一句话说明本 skill 将「扫描目标服务并生成 .claude/rules」。

### Step 6: 执行后置步骤

按序执行 `{workflow.activation_steps_append}` 每一项。

激活完成。若 prepend/append 非空，确认每项均已按序执行后再进入主流程。

## Paths

- 探测脚本：`{skill-root}/scripts/detect-stack.js`
- 基线模板：`{skill-root}/assets/baselines/`（通用维度）
- 骨架模板：`{skill-root}/assets/skeletons/`（特定维度）
- 输出根：`{target-root}/.claude/rules/`

## Execution

- ✅ 始终用 `{communication_language}` 与用户沟通。
- ✅ 始终用 `{document_output_language}` 书写所有 rules 文件与报告内容。
- ✅ 所有维度命中/跳过结论必须有实证；跳过必记录原因。
- ✅ 特定维度严禁照抄 pj-incentive 类名清单，必须用 `{target-root}` 真实扫描结果。

### 单服务 vs 批量模式

- **单服务（默认，`{workflow.batch_services}` 为空）**：对单个 `{target-root}`（step-01 解析）跑一遍 step-01→04。
- **批量（`{workflow.batch_services}` 非空，数组每项一个服务根路径）**：**对数组中每个服务根依次跑完整 step-01→04**，每个独立绑定自己的 `{target-root}`。批量建议配合 `headless=true` 减少打断；每服务结束累积其对标报告，全部完成后输出**跨服务汇总**（各服务生成维度数 / 跳过数 / 需人工复核项）。**一个服务失败不中断其余**（捕获异常、记入汇总、继续下一个）。

载入并执行 `./steps/step-01-locate-and-gate.md` 开始（批量模式则对 `batch_services` 每个服务根循环执行整条 step 链）。

**Note:** 目标服务定位与门禁协议在 step-01 处理。