@zeyue0329/xiaoma-cli 1.13.0 → 1.15.0

package/CLAUDE.md

@@ -1,111 +0,0 @@
-# CLAUDE.md
-
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
-
-## Project Overview
-
-XiaoMa-CLI (`@zeyue0329/xiaoma-cli`) is an AI-driven agile development framework/CLI tool. It installs specialized AI agent personas, workflows, and skills into a user's project directory for use with AI IDEs (Claude Code, Cursor, etc.). Node.js v20+ required.
-
-## Common Commands
-
-```bash
-# Quality gate (run before commits — preferred over npm test)
-npm run quality
-
-# Individual checks
-npm run test:schemas        # Agent YAML schema validation (Zod-based)
-npm run test:install        # Installation component tests
-npm run test:refs           # Cross-file reference validation
-npm run validate:schemas    # Schema validation (separate from test)
-npm run validate:refs       # File reference validation (strict mode)
-npm run lint                # ESLint (JS + YAML), zero warnings allowed
-npm run lint:md             # Markdown linting
-npm run format:check        # Prettier check
-npm run format:fix          # Prettier auto-fix
-
-# Test coverage
-npm run test:coverage       # c8 coverage report for schema tests
-
-# Run the CLI locally
-npm run install:xiaoma      # Run install command
-npm run xiaoma:uninstall    # Run uninstall command
-
-# Run a single test file directly
-node test/test-agent-schema.js
-node test/test-file-refs-csv.js
-node test/test-installation-components.js
-```
-
-`npm run quality` order: format:check → lint → lint:md → validate:schemas → test:schemas → test:install → validate:refs.
-`npm test` order: test:schemas → test:refs → test:install → validate:schemas → lint → lint:md → format:check.
-
-## Architecture
-
-### Two-Layer Structure
-
-1. **`src/`** — Content modules (YAML agents, Markdown workflows, skills)
-2. **`tools/`** — CLI implementation (Node.js/CommonJS, installer, validators)
-
-### Module System
-
-Modules are defined by `module.yaml` files with configuration variables, prompts, and directory declarations. Variables use `{variable_name}` interpolation syntax and can reference each other (e.g., `{output_folder}` in path defaults). Core module variables (`user_name`, `communication_language`, etc.) are inherited by other modules:
-- **`src/core/`** — Shared skills and tasks (module code: `core`)
-- **`src/xmc/`** — XiaoMa Method module, the primary agile framework (module code: `xmc`)
-- **`src/utility/`** — Shared agent-components imported by other modules
-
-### Agent System (`src/xmc/agents/`)
-
-Agents are YAML files validated against a Zod schema (`tools/schema/`). Each agent defines:
-- `metadata` — id, name, title, icon, module, capabilities
-- `persona` — role, identity, communication_style, principles
-- `menu` — trigger commands pointing to workflow exec targets
-- `prompts` / `critical_actions` — optional
-
-### Workflow System (`src/xmc/workflows/`)
-
-Organized by development phase:
-- `1-analysis/` — Brainstorming, research, product brief
-- `2-plan-workflows/` — PRD creation/validation, UX design
-- `3-solutioning/` — Architecture, epics/stories, implementation readiness
-- `4-implementation/` — Sprint planning, story execution, code review, retros
-
-Additional workflow categories:
-- `5-full-pipeline/` — End-to-end automated pipelines from requirements to delivery
-- `xiaoma-quick-flow/` — Lightweight flows for smaller projects (quick-dev, quick-spec)
-- `xiaoma-document-project/`, `xiaoma-generate-project-context/`, `xiaoma-qa-generate-e2e-tests/` — Utility workflows
-
-Each workflow has: `workflow.md` (entry point with metadata), `steps/` or `steps-{variant}/` directories, and optional `templates/` and `data/` directories.
-
-### CLI (`tools/cli/`)
-
-- **Entry**: `xiaoma-cli.js` (Commander.js) → wrapped by `tools/xiaoma-npx-wrapper.js`
-- **Commands**: `tools/cli/commands/` — `install.js`, `status.js`, `uninstall.js`
-- **Shared lib**: `tools/cli/lib/` — config loading, file ops, UI helpers, YAML/XML utilities, agent analysis
-- **Installer** (`tools/cli/installers/lib/`): Layered architecture:
-  - `core/` — `installer.js` (main orchestrator), `manifest-generator.js`, `dependency-resolver.js`, `ide-config-manager.js`, `detector.js`
-  - `ide/` — IDE-specific adapters with `_base-ide.js` base class and `_config-driven.js` mixin; `manager.js` selects the right adapter
-  - `modules/` — `manager.js` and `external-manager.js` handle module discovery and external module loading
-  - `custom/` — `handler.js` for user-defined custom modules
-- **UI**: `@clack/prompts` for interactive terminal prompts
-
-### Skills (`src/core/skills/`)
-
-Reusable capabilities: `xiaoma-help`, `xiaoma-brainstorming`, `xiaoma-distillator`, `xiaoma-party-mode`, editorial review skills, etc.
-
-## Code Conventions
-
-- **JS**: CommonJS (`require`/`module.exports`) for all CLI/tool code
-- **YAML**: `.yaml` extension enforced by ESLint (not `.yml`); double quotes preferred
-- **Formatting**: Prettier with 140 char print width, 2-space indent, double quotes in YAML, single quotes in JS
-- **Linting**: ESLint flat config with unicorn, node, yml plugins; `--max-warnings=0`
-- **Schema validation**: Zod for agent YAML validation at `tools/schema/agent.js`
-- **Git hooks**: Husky + lint-staged (runs lint:fix and format:fix on staged files)
-- **Agent triggers**: Must match compound format `"<SHORTCUT> or fuzzy match on <kebab-case>"` where shortcut is auto-derived from the kebab trigger
-
-## Testing
-
-Tests are plain Node.js scripts (no test framework), located in `test/`:
-- `test-agent-schema.js` — Validates all agent YAML against Zod schema; 50 fixtures (18 valid, 32 invalid); targets 100% coverage
-- `test-installation-components.js` — Installation flow verification
-- `test-file-refs-csv.js` — Validates cross-file references in CSV data files
-- Fixtures in `test/fixtures/agent-schema/{valid,invalid}/`

package/README.md

@@ -1,128 +0,0 @@
-# XiaoMa CLI
-
-XiaoMa CLI 是一个 AI 驱动的敏捷开发框架工具。它将专业的 AI 智能体、结构化工作流和可复用技能安装到你的项目中，配合 AI IDE（Claude Code、Cursor 等）使用，实现从需求分析到交付的全生命周期敏捷开发。
-
-## 能力边界
-
-### XiaoMa CLI 能做什么
-
-**智能体协作**
-
-XiaoMa 提供 8 个专业智能体，覆盖敏捷开发的核心角色：
-
-| 智能体 | 角色 | 职责 |
-|--------|------|------|
-| Analyst | 分析师 | 需求调研、产品简报、竞品分析 |
-| PM | 产品经理 | PRD 编写、需求验证、产品规划 |
-| UX Designer | UX 设计师 | 用户体验设计、交互方案 |
-| Architect | 架构师 | 技术架构设计、方案评审 |
-| Dev | 开发者 | 故事实现、代码编写 |
-| QA | 测试工程师 | 测试策略、端到端测试生成 |
-| SM | Scrum Master | Sprint 规划、进度跟踪、回顾 |
-| Quick Flow Solo Dev | 独立开发者 | 快速流程，适合小型项目 |
-
-**结构化工作流（34+）**
-
-按开发阶段组织，覆盖完整的软件交付生命周期：
-
-- **分析阶段** — 需求管道、产品简报创建、市场调研
-- **规划阶段** — PRD 创建/编辑/验证、UX 设计
-- **方案阶段** — 架构设计、Epic 和 Story 拆分、实施就绪检查
-- **实施阶段** — Sprint 规划、Story 开发、代码评审、回顾、Sprint 状态跟踪
-- **全流程管道** — 端到端自动化，从需求到交付一键执行
-
-**可复用技能（11 个）**
-
-| 技能 | 用途 |
-|------|------|
-| `xiaoma-help` | 智能导航，告诉你下一步该做什么 |
-| `xiaoma-brainstorming` | 结构化头脑风暴 |
-| `xiaoma-party-mode` | 多智能体协作讨论 |
-| `xiaoma-distillator` | 信息提炼和摘要 |
-| `xiaoma-editorial-review-prose` | 文案内容审校 |
-| `xiaoma-editorial-review-structure` | 文档结构审校 |
-| `xiaoma-review-adversarial-general` | 对抗性审查 |
-| `xiaoma-review-edge-case-hunter` | 边界场景审查 |
-| `xiaoma-advanced-elicitation` | 高级需求引导 |
-| `xiaoma-index-docs` | 文档索引 |
-| `xiaoma-shard-doc` | 文档分片处理 |
-
-**规模自适应**
-
-根据项目复杂度自动调整规划深度——从小型 Bug 修复到企业级系统，无需手动配置。
-
-### XiaoMa CLI 不能做什么
-
-- **不是代码生成器** — 不会直接生成完整的应用代码，而是通过结构化流程引导你和 AI 协作产出高质量代码
-- **不替代 AI IDE** — 需要配合 Claude Code、Cursor 等 AI IDE 使用，本身不提供代码编辑能力
-- **不是项目管理工具** — 不替代 Jira、Linear 等，而是补充敏捷流程中的 AI 协作环节
-- **不处理部署运维** — 聚焦于开发生命周期，不涉及 CI/CD 管道配置、服务器部署等运维任务
-- **不支持非 Node.js 环境** — 安装工具本身需要 Node.js v20+（但生成的工作产物不限语言）
-
-## 安装与使用
-
-### 环境要求
-
-- [Node.js](https://nodejs.org) v20 或更高版本
-
-### 快速安装
-
-```bash
-npx xiaoma-cli install
-```
-
-按照交互式提示选择模块和目标 IDE，安装完成后在项目目录中打开你的 AI IDE 即可开始使用。
-
-### 非交互式安装（CI/CD）
-
-```bash
-npx xiaoma-cli install --directory /path/to/project --modules xmc --tools claude-code --yes
-```
-
-### CLI 命令
-
-| 命令 | 说明 |
-|------|------|
-| `npx xiaoma-cli install` | 安装 XiaoMa 到目标项目 |
-| `npx xiaoma-cli status` | 查看当前安装状态 |
-| `npx xiaoma-cli uninstall` | 卸载 XiaoMa |
-
-### 使用流程
-
-1. **安装** — 在项目中运行 `npx xiaoma-cli install`
-2. **启动 AI IDE** — 打开 Claude Code、Cursor 等，进入项目目录
-3. **获取指引** — 使用 `xiaoma-help` 了解当前可用的工作流和下一步操作
-4. **按阶段推进** — 从分析到实施，按工作流引导逐步完成开发
-
-### 使用示例
-
-```
-# 在 AI IDE 中使用以下命令
-
-# 获取帮助
-xiaoma-help
-
-# 获取特定场景的帮助
-xiaoma-help 我刚完成了架构设计，接下来该做什么？
-
-# 创建产品简报
-@analyst create-product-brief
-
-# 创建 PRD
-@pm create-prd
-
-# 架构设计
-@architect create-architecture
-
-# Sprint 规划
-@sm sprint-planning
-
-# 开发 Story
-@dev dev-story
-
-# 代码评审
-@dev code-review
-
-# 多智能体协作讨论
-xiaoma-party-mode
-```

package/demo/xiaoma-bug-circle-resolve/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-bug-circle-resolve
-description: '循环处理所有AI测试平台推送的新增状态Bug，每次处理前清空上下文避免噪声干扰，逐个调用xiaoma-bug-resolve技能修复，直到所有新增Bug处理完毕。Use when the user says "循环处理bug", "批量修复bug", "resolve all bugs", or "circle resolve bugs".'
----
-
-Follow the instructions in [workflow.md](workflow.md).

package/demo/xiaoma-bug-circle-resolve/workflow.md

@@ -1,254 +0,0 @@
-# Bug Circle Resolve Workflow
-
-**Goal:** 全自动循环处理**指定项目**下所有AI测试平台推送的新增状态(defect_status=0)Bug，无需任何人工介入，直到队列清空。
-
-**Your Role:** 你是Bug处理调度器。你的职责是：校验 jiraId 参数 → 查询当前项目的 Bug 队列 → 为每个Bug启动独立Agent子进程处理 → 确认处理结果 → 继续下一个 → 输出最终报告。全程无需用户参与。
-
-**所有输出使用简体中文。**
-
----
-
-## 参数说明
-
-本 skill 支持以下参数：
-
-| 参数 | 是否必填 | 传参形式 | 说明 | 示例 |
-|------|---------|---------|------|------|
-| `jiraId` | **必填** | **位置参数（唯一 token）** | JIRA 项目 ID，多项目共库场景下的硬隔离边界。**所有 `t_defect_info` 的 SELECT/UPDATE/COUNT 都必须带 `AND jira_id = '{{jiraId}}'`**，子 Agent 也必须继承此参数。 | `GYLPJ-1153` |
-
-### args 解析规则（Claude 必须严格遵守）
-
-把 skill 传入的 `args` 按空格切分成 token 列表后：
-1. 取**第一个 token**：
-   - 若**不含 `=`**，视为 `jiraId` 的值（位置参数语法，**推荐形式**）。
-   - 若形如 `jiraId=xxx`，解析为 `jiraId`（兼容旧语法）。
-   - 若形如 `otherKey=xxx`（任何其它键值对），说明位置参数缺失，视为**未提供 jiraId**。
-2. 本 skill 只接受 `jiraId` 一个参数。若 args 中出现任何第二个 token（无论形式），视为非法输入，立刻中断并提示用户只需传一个 jiraId。
-3. 若最终 `jiraId` 仍为空或空字符串，**立刻拒绝执行**，禁止开始循环（否则会把其他项目的 Bug 一并拉下来误改代码、误改状态）。
-
-### 调用示例
-
-```
-# 推荐：位置参数（最简洁）
-/xiaoma-bug-circle-resolve GYLPJ-1153
-
-# 兼容旧语法（仍可用）
-/xiaoma-bug-circle-resolve jiraId=GYLPJ-1153
-```
-
----
-
-## 核心架构：Agent 隔离处理
-
-**为什么不需要 `/clear`：** 每个Bug的分析和修复都委托给**独立的 Agent 子进程**。Agent 天然拥有隔离的上下文空间，处理完即释放，不会污染主对话。主对话只负责轻量的调度循环。
-
-```
-主对话（调度器，上下文极小）
-  ├── Agent #1 → 处理 Bug A（独立上下文，完成后释放）
-  ├── Agent #2 → 处理 Bug B（独立上下文，完成后释放）
-  ├── Agent #3 → 处理 Bug C（独立上下文，完成后释放）
-  └── ...直到队列清空
-```
-
----
-
-## 核心规则（严格遵守）
-
-1. **每个Bug由独立Agent处理** — 使用 Agent 工具启动 general-purpose 子进程，将Bug的完整信息和处理指令传给Agent，Agent独立完成分析、修复、验证、状态更新
-2. **主循环保持轻量** — 主对话只做：查询队列 → 启动Agent → 读取Agent结果 → 查询剩余 → 继续或结束
-3. **串行处理** — 一次处理一个Bug，等Agent完成后再处理下一个，避免并发修改冲突
-4. **全自动无人工介入** — 从开始到结束，用户无需执行任何命令
-
----
-
-## 数据库信息
-
-- **MySQL缺陷库**: `mcp__xiaoma-dev-mysql__mysql_query` — 查询/更新Bug状态
-- **Oracle业务库**: `mcp__oracle_zqyl_pj_incentive_test4__execute_query` — 验证业务数据
-- **缺陷表**: `t_defect_info`
-- **待处理条件**: `defect_status = 0 AND is_del = 0 AND jira_id = '{{jiraId}}'`（**jira_id 强制过滤**）
-- **状态枚举**: 0=新增, 1=已验证, 2=已修复, 3=非缺陷(测试误报)
-- **项目隔离字段**: `jira_id`（varchar(64)，JIRA 项目 ID），多项目共库时用于区分
-
----
-
-## WORKFLOW
-
-<workflow>
-
-<step n="1" goal="校验 jiraId 并检查当前项目下待处理Bug队列">
-
-  <action>**前置校验**：按本文件顶部的「args 解析规则」从 args 中解析出 `jiraId`。若未解析到（args 为空），立刻中断并输出：
-  `批量循环处理必须将 jiraId 作为第一个参数传入，例如：/xiaoma-bug-circle-resolve GYLPJ-1153`
-  禁止在没有 jiraId 的情况下继续执行任何 t_defect_info 查询或循环。
-  </action>
-
-  <action>查询当前项目（jiraId={{jiraId}}）缺陷统计：
-  ```sql
-  SELECT
-    SUM(CASE WHEN defect_status = 0 THEN 1 ELSE 0 END) as pending,
-    SUM(CASE WHEN defect_status = 2 THEN 1 ELSE 0 END) as fixed,
-    SUM(CASE WHEN defect_status = 3 THEN 1 ELSE 0 END) as false_positive,
-    COUNT(*) as total
-  FROM t_defect_info WHERE is_del = 0 AND jira_id = '{{jiraId}}';
-  ```
-  </action>
-
-  <check if="pending == 0">
-    <action>当前项目无待处理缺陷，直接进入 Step 3 输出最终报告</action>
-  </check>
-
-  <check if="pending > 0">
-    <action>查询当前项目下待处理缺陷列表：
-    ```sql
-    SELECT defect_id, title, severity, module_path
-    FROM t_defect_info
-    WHERE is_del = 0 AND defect_status = 0 AND jira_id = '{{jiraId}}'
-    ORDER BY create_time ASC;
-    ```
-    </action>
-
-    <action>向用户展示概况（必须包含"当前项目 jiraId：{{jiraId}}"一行）并告知即将开始全自动处理</action>
-    <action>进入 Step 2 开始循环</action>
-  </check>
-
-</step>
-
-<step n="2" goal="循环处理每个Bug（全自动）">
-
-  <!-- 循环开始：查询当前项目下最早的待处理Bug完整信息 -->
-  <action>查询当前项目（jiraId={{jiraId}}）下最早的一条待处理Bug的完整详情：
-  ```sql
-  SELECT * FROM t_defect_info
-  WHERE is_del = 0 AND defect_status = 0 AND jira_id = '{{jiraId}}'
-  ORDER BY create_time ASC LIMIT 1;
-  ```
-  </action>
-
-  <check if="无结果">
-    <action>队列已空，进入 Step 3</action>
-  </check>
-
-  <!-- 输出当前处理进度 -->
-  <action>输出：正在处理 {{defect_id}} — {{title}}</action>
-
-  <!-- 启动独立 Agent 处理这个Bug -->
-  <critical>
-  使用 Agent 工具启动一个 general-purpose 子进程来处理这个Bug。
-  Agent 的 prompt 必须包含以下完整信息，使其能独立工作：
-
-  1. **Bug完整信息 + 项目上下文**：将查询到的 defect_id, title, steps, module_path, url, error_front, error_apis, defect_type, severity **以及当前处理的 jiraId={{jiraId}}** 全部传给Agent。Agent 必须把 jiraId 视为硬约束，所有 SQL 都要带 `AND jira_id = '{{jiraId}}'`。
-  2. **处理指令**：按以下步骤执行——
-     a. 根据 module_path 和 url 定位代码（前端在 zqyl-manager/src/main/views/pjs/incentive/，后端在 zqyl-pj-incentive/src/main/）
-     b. 使用 Explore Agent 探索相关前端页面组件、后端Controller/Service/Mapper代码
-     c. 使用 Oracle MCP Server (mcp__oracle_zqyl_pj_incentive_test4__execute_query) 验证数据库数据
-     d. 分析根因，判定：真实缺陷 or 测试误报
-     e. 如为真实缺陷：使用 Edit 工具修复代码，修复范围限定在缺陷涉及的代码
-     f. 验证修复逻辑正确性
-     g. 使用 MySQL MCP Server (mcp__xiaoma-dev-mysql__mysql_query) 更新Bug状态（**UPDATE 必须带 jira_id 过滤**）：
-        - 真实缺陷已修复：
-          `UPDATE t_defect_info SET defect_status = 2 WHERE defect_id = '{{defect_id}}' AND jira_id = '{{jiraId}}' AND is_del = 0;`
-        - 测试误报：
-          `UPDATE t_defect_info SET defect_status = 3 WHERE defect_id = '{{defect_id}}' AND jira_id = '{{jiraId}}' AND is_del = 0;`
-     h. 返回处理结果摘要：defect_id、jiraId、判定结果、修改的文件列表、验证结果
-  3. **项目规范**：遵循 CLAUDE.md 编码规范，禁止Lombok、禁止MyBatis-Plus、返回ResultData等
-  4. **常见缺陷模式参考**：
-     - 模糊查询不符合预期 → SQL用 = 而非 LIKE，改为 LIKE '%' || #{param} || '%'
-     - 字段未显示/缺少列 → 前端 header 配置缺少字段
-     - 字段值展示错误 → prop映射错误或SQL字段别名错误
-     - 查询不出数据 → SQL条件逻辑错误、MQ消费时字段未映射
-     - 表头名称错误 → header label 配置错误
-     - 点击按钮报错 → 接口调用参数或后端异常
-  5. **代码结构映射**：
-     - 签发业务归属表 → 前端 issueAttribution/，后端 IssueAttributionController, IssueAttributionMapper.xml
-     - 背书业务归属表 → 前端 endorseAttribution/，后端 EndorseAttributionController
-     - 融资台账 → 前端 financeLedger/，后端 FinanceLedgerController
-  </critical>
-
-  <!-- Agent 完成后 -->
-  <action>读取 Agent 返回的处理结果摘要</action>
-  <action>输出该Bug的处理结果（简要一行）</action>
-
-  <!-- 检查是否还有剩余 -->
-  <action>查询当前项目下剩余待处理数量：
-  ```sql
-  SELECT COUNT(*) as remaining FROM t_defect_info
-  WHERE is_del = 0 AND defect_status = 0 AND jira_id = '{{jiraId}}';
-  ```
-  </action>
-
-  <check if="remaining > 0">
-    <action>继续循环 — 回到 Step 2 顶部处理下一个Bug</action>
-  </check>
-
-  <check if="remaining == 0">
-    <action>队列已空，进入 Step 3</action>
-  </check>
-
-</step>
-
-<step n="3" goal="输出最终处理报告">
-
-  <action>查询当前项目（jiraId={{jiraId}}）下所有缺陷的最终状态：
-  ```sql
-  SELECT defect_id, title,
-    CASE defect_status
-      WHEN 0 THEN '待处理'
-      WHEN 2 THEN '已修复'
-      WHEN 3 THEN '非缺陷(测试误报)'
-      ELSE '其他'
-    END as status_text,
-    update_time
-  FROM t_defect_info
-  WHERE is_del = 0 AND jira_id = '{{jiraId}}'
-  ORDER BY defect_status ASC, update_time DESC;
-  ```
-  </action>
-
-  <action>查询当前项目统计汇总：
-  ```sql
-  SELECT
-    SUM(CASE WHEN defect_status = 0 THEN 1 ELSE 0 END) as pending,
-    SUM(CASE WHEN defect_status = 2 THEN 1 ELSE 0 END) as fixed,
-    SUM(CASE WHEN defect_status = 3 THEN 1 ELSE 0 END) as false_positive
-  FROM t_defect_info WHERE is_del = 0 AND jira_id = '{{jiraId}}';
-  ```
-  </action>
-
-  <action>输出最终报告：
-
-  ```
-  ========================================
-  全部Bug处理完毕
-  ========================================
-
-  项目ID（jiraId）：{{jiraId}}
-
-  已修复: {{fixed}} 条
-  测试误报: {{false_positive}} 条
-  剩余待处理: {{pending}} 条
-
-  处理明细:
-  | 缺陷ID | 标题 | 处理结果 | 更新时间 |
-  |--------|------|---------|---------|
-  | ...    | ...  | ...     | ...     |
-
-  当前项目（{{jiraId}}）下新增状态的测试Bug已处理完毕，全程无需人工介入。
-  ```
-
-  </action>
-
-</step>
-
-</workflow>
-
----
-
-## 注意事项
-
-1. **jiraId 是硬隔离边界** — 批量循环处理必须指定 jiraId，**所有 `t_defect_info` 的 SELECT/UPDATE/COUNT 都必须带 `AND jira_id = '{{jiraId}}'`**，子 Agent 的 prompt 和 UPDATE 语句也必须继承该值，否则会跨项目误改代码和状态
-2. **Agent 隔离是关键** — 每个Bug在独立Agent子进程中处理，自带隔离上下文，无需 `/clear`，不会相互干扰
-3. **全自动** — 用户只需调用一次 `/xiaoma-bug-circle-resolve GYLPJ-1153`（首个位置参数即 jiraId），之后全程自动直到当前项目队列清空
-4. **串行安全** — 一次只处理一个Bug，避免并发修改同一文件产生冲突
-5. **容错** — Agent处理失败时Bug状态仍为0，下次循环自动重试
-6. **Agent prompt 质量** — 传给Agent的prompt必须包含Bug完整信息 + jiraId + 项目上下文 + 处理指令，使其能完全独立工作

package/demo/xiaoma-bug-resolve/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-bug-resolve
-description: 'Resolve AI test platform bugs: query MySQL for defects, analyze root cause, fix code, verify with Playwright, update bug status. Use when the user says "resolve bug", "fix test bug", or "处理测试bug".'
----
-
-Follow the instructions in [workflow.md](workflow.md).