pr-ruancat-repo

PR ruan-cat Repo

A skill for batch-initiating unified-content PRs to multiple fixed repositories.

Core strategy:SKILL.md Keep only the entry point, decision skeleton, and mandatory boundaries; all detailed rules such as the repository list, complexity assessment, hybrid execution strategy, script templates, and output templates are placed in references/, for ease of long-term maintenance.

Primary principles (CRITICAL)

In this skill,unified PR content must first invoke the git-commit skill to assist in generating commitMessage, then based on that commitMessage derive prTitle and prBody。
Do not skip the git-commit skill and directly hand-write the submission copy.

Before actually choosing the PR method,you must first assess the complexity of the target repositories and proactively ask the user for the paths of GitHub repositories already cloned locally. Local repositories can significantly improve scale identification, dependency judgment, branch status confirmation, and batch modification efficiency.

By default, prioritize the local Bash loop + GitHub API/MCP hybrid mode: local handles batch checking, modification, committing, and pushing; remote GitHub API/MCP handles PR queries, creation, status aggregation, and necessary remote metadata reading.

Forsimple batch PR scenarios(all target repositories have local paths, changes are unified, no repository-level customization is needed, and the user confirms the gh CLI is available), prioritize thescript automation mode—generate a one-off TypeScript script that can be executed locally (batch-pr.ts), replacing the AI's repository-by-repository invocation of the gh CLI / GitHub MCP, which can reduce token consumption by about 80–90%.

Quick entry

Target repository list:references/target-repos.md
Execution specifications, PR strategy, and output templates:references/workflow-and-template.md
Script automation mode templates:references/batch-pr-script.ts

Workflow

Phase 1: Task normalization (main Agent)

Read the user's goal and break it into a one-sentence description of the "unified change intent for this run".
Proactively ask the user for the paths of target repositories already cloned locally; if the user cannot provide them for the time being, fall back to remote repository metadata identification.
Read references/target-repos.mdto obtain the default repository set.
Merge user input constraints:
- If the user specifies a repository whitelist: take the intersection.
- If the user specifies excluded repositories: remove them from the set.
- If the user does not specify: use all enabled repositories.
According to references/workflow-and-template.md 's complexity assessment rules, mark each repository with its complexity and recommended execution mode.
Output the "execution list for this run" (repository list + local path availability + complexity + candidate source branch names) as input for subsequent scheduling.

Phase 2α: Unified content generation (coordinator Agent)

The coordinator produces and freezes the following 4 items in one go, to avoid semantic drift between repositories:

prTitle: PR title
prBody: PR body (Markdown)
commitMessage: commit message (must follow the git-commit specification)
sourceBranch: Source branch (consistent across all repositories)

Constraint:

commitMessage and prTitle must be semantically consistent (the title may be derived from the commit summary).
When not explicitly required, the body should focus on "what was done + why it was done + how to verify", avoiding repository-specific content.

git-commit usage conventions (mandatory)

pr-ruancat-repo When generating unified content, you must explicitly reuse the git-commit skill to generate commitMessage, and you are prohibited from writing it by hand based on experience.

Invocation timing

At the start of phase 2, first read the git-commit skill rules.
First produce commitMessage, then derive prTitle and prBody, ensuring the three are semantically consistent.

Generation requirements

The commit message must be in Chinese.
You must use Conventional Commits + Emoji:
- Normal:<emoji> type(scope): summary
- Breaking:<emoji> type(scope)!: summary
emoji and type must be based on commit-types.ts , and you must not invent types.
For breaking changes, the body must additionally include:
- BREAKING CHANGE: <迁移说明>

Semantic consistency rules

prTitle is derived by default from the title line of commitMessage (the emoji may be removed).
prBody must cover the commit's "changes + reasons + verification method".
A situation where the PR title conflicts with the commit meaning is not allowed.

Batch repository scenario constraints

A batch task generates only one unified commitMessage, which is reused by all sub-agents.
Sub-agents are not allowed to rewrite the commit text on their own; if a repository difference makes it unsuitable, the sub-agent should return the failure reason, and the main Agent decides whether to split the task.

Phase 2β: Scope exploration (main Agent)

After the unified content is frozen and before entering the execution phase, scope exploration must first be performed on the target repositories to produce structured scope analysis data.

Exploration goals

Perform the following scans on each target repository to generate scopeAnalysis JSON：

{
	"scopeAnalysis": {
		"repos": [
			{
				"repo": "ruan-cat/notes",
				"localPath": "D:/code/ruan-cat/notes",
				"status": "in-scope",
				"affectedFiles": [
					".github/workflows/ci.yaml",
					".github/workflows/vercel-deploy-tool.yaml"
				],
				"fileCount": 2,
				"observations": [
					"包含 release 工作流，需保留 registry-url"
				],
				"currentValues": ["22.14.0", "22.14.0"]
			}
		],
		"excludedRepos": [
			{
				"repo": "ruan-cat/mall-nuxt",
				"reason": "未在本地克隆"
			}
		],
		"totalFiles": 22,
		"totalOccurrences": 23,
		"specialPatterns": [
			"release 工作流需保留 registry-url",
			"lts/* 版本需要替换为具体版本号"
		],
		"transformations": [
			{
				"description": "替换所有 setup-node 的 node-version 为 24.18.0",
				"glob": ".github/workflows/*.{yml,yaml}",
				"search": "node-version:\\s*\\S+",
				"replace": "node-version: 24.18.0"
			}
		]
	}
}

Exploration steps

Verify local paths: Check each repository's localPath for existence. If it does not exist, add it to excludedRepos。
Scan target files: Scan relevant directories according to the task type. For example .github/workflows/*.{yml,yaml} find setup-node configuration.
grep search: Use grep -R -n to find target patterns, recording matching file paths and line numbers.
Count and categorize: Count the number of affected files, number of matches, and current value distribution.
Identify special patterns: Discover differences among repositories (such as release files having extra fields, some repositories using different version numbers, or inconsistent quote formats).
Summarize conversion rules: Abstract the exploration results into transformations[] rules (see the data contract below), for use by scripts. Each rule must include a human-readable description, an exact glob, a safe search regular expression, and a minimal-change replace。
Summary output: Produce the complete scopeAnalysis JSON。

Exclusion principles

Not cloned locally: add to excludedRepos, with the reason marked "not cloned"
Cloned but no target files: add to excludedRepos, with the reason noted as "already cloned, but no target file"
Insufficient permissions or unable to read: add excludedRepos, with the reason noted as "insufficient permissions/read failure"

Phase 2γ: Design Specification Generation (Main Agent)

Based on the unified content from Phase 2α and the scope exploration results from Phase 2β, generate the complete design specification document spec.md。

spec.md structure

# YYYY-MM-DD <仓库名> <任务名> 设计规格

## 1. 背景与目标

### 1.1 背景

{从阶段 2α 的统一内容中提取：为什么要做这次批量改动}

### 1.2 当前状态扫描

{从阶段 2β 的范围探索中提取：当前版本分布、扫描命令、扫描结论}

### 1.3 目标

{本次批量改动要达成的具体目标}

## 2. 改动范围

### 2.1 目标仓库

| 序号 | 仓库 | 本地路径 | 涉及文件数 |
| :--: | :--- | :------- | :--------: |
| ...  | ...  | ...      | ...        |

### 2.2 未包含的仓库

{本地未克隆或没有目标文件的仓库及原因}

### 2.3 涉及的文件

{具体的文件路径列表，含每个仓库的当前值/预期值/备注}

## 3. 替换策略

### 3.1 统一规则

{对所有仓库一致的替换规则}

### 3.2 特殊处理

{需要特殊处理的仓库或文件，例如 release 工作流保留 registry-url}

### 3.3 转换规则（pr-transform.json）

{从 scopeAnalysis.transformations[] 派生的 JSON 规则及说明}

## 4. 范围探索数据契约

{scopeAnalysis JSON 的完整内容或摘要}

## 5. 执行模式

推荐使用**脚本自动化模式**（生成 `batch-pr.ts` 由用户本地执行）。

## 6. 分支策略

- 来源分支：{sourceBranch}
- 目标分支探测：dev > main > master

## 7. Commit 与 PR 文案

### 7.1 Commit Message

{commitMessage}

### 7.2 PR 标题

{prTitle}

### 7.3 PR 正文

{prBody}

## 8. 验证方式

### 8.1 替换验证

{例如 grep 命令}

### 8.2 语法验证

{例如 YAML 语法检查方式}

### 8.3 PR 状态验证

{PR URL、状态汇总}

### 8.4 执行命令示例

{dry-run 和实际执行命令}

## 9. PR 合并与分支清理

### 9.1 合并命令

{`npx tsx batch-pr.ts merge` 等}

### 9.2 合并流程

{扫描 PR → rebase 合并 → 删除分支 → 验证 → 生成 merge-summary.md}

### 9.3 分支清理原则

{必须删除本次来源分支，不得删除默认分支和 GitHub Pages 源分支}

### 9.4 合并后状态

| 仓库 | PR | 目标分支 | 分支删除 |
| :--- | --- | :--- | :------: |
| ...  | ... | ...  | ...      |

## 10. 风险与回滚

| 序号 | 风险 | 影响 | 应对措施 |
| :--: | :--- | :--- | :------- |
| ...  | ...  | ...  | ...      |

## 11. 验收标准

- [ ] 验收项 1
- [ ] 验收项 2

Generation requirements

spec.md must be stored in the output directory of this task (the same directory as batch-pr.ts ).
The "replacement strategy" and "verification method" of spec.md must be derived directly from scopeAnalysis.transformations[] .
The "risks and rollback" of spec.md must cover the special patterns found in scopeAnalysis .
The "acceptance criteria" of spec.md must correspond one-to-one with transformations[] .
spec.md is the bridge between AI-generated scripts and user review—users can review spec.md to confirm whether the AI's understanding is correct.

Script Automation Mode

Script Automation Mode is introduced in v0.5.0 of this skill as alow-token-consumption execution approach, aimed at shifting simple batch PR operations from real-time AI orchestration to local one-time script execution.

This mode is triggered after Phase 2β (scope exploration) and Phase 2γ (design specification generation) are completed. The scopeAnalysis data provided by scope exploration (including the transformations[] rules) directly drives script generation, ensuring the script hasprecise file content transformation capabilitiesrather than merely whole-file copying.

Applicable conditions

When the following conditions areall satisfied, Script Automation Mode must be preferred:

All target repositories have local clones(the user has provided a local path mapping).
The changes are highly unified—all repositories have consistent modification semantics (for example: the same configuration file, the same copy update, the same dependency upgrade).
The user confirms that the gh CLI is installed and authenticated（gh auth status passed).
The user explicitly agrees to or does not object to the script execution plan(permission obtained after asking).
The complexity level is low or medium(not a high-complexity repository).

The following scenarios arenot suitablefor Script Automation Mode and should fall back to sub-agent scheduling:

Different repositories require different file modifications or different commit contents.
A repository requires manual build verification or context awareness (such as monorepo package dependency changes).
The user has not provided complete local paths, or some repositories can only be operated remotely.
The user does not have gh CLI or Node.js 18+ locally.

Quantified benefits

Metric	Sub-agent mode (18 repositories)	Script Automation Mode	Savings
Number of AI tool calls	90–180 times	0 times (execution phase)	~100%
AI token consumption	80k–150k	5k–15k	~80–90%
User waiting time	10–30 min (AI execution)	1–3 min (local)	~90%
Repeatable execution	Requires rescheduling	Can be rerun at will	—

Deliverables List

When script automation mode is selected, the AI generates the following files all at once in stage 3a,all placed in the batch-pr-<YYYY-MM-DD>/ working directory(the directory name cannot be omitted):

File	Purpose	Generator
`pr-config.json`	Repository list + local paths + PR metadata	AI
`pr-body.md`	PR body (Markdown, default)	AI
`commit-message.txt`	git commit message (plain text, default)	AI
`spec.md`	Complete design specification document	AI
`pr-transform.json`	File content conversion rules (if any)	AI
`batch-pr.ts`	Executable TypeScript script	AI
`README.md`	Usage instructions and execution guidance	AI
`changes/<repo_safe>/*`	Files to be modified shared across repositories (optional)	AI
`commit-message--<repo_safe>.txt`	per-repo differentiation commit (optional)	AI
`pr-body--<repo_safe>.md`	per-repo differentiation PR body (optional)	AI

The user only needs to execute npx tsx batch-pr.ts, and the script will automatically complete the git operations + PR creation for all repositories, and output execution-summary.md。

Comparison with sub-agent mode

┌─ 子代理模式（v0.4.0 默认） ─────────────────────┐
│  AI → 18× sub-agent → ~90 tool calls → 报告      │
│  Token 消耗: 高                                    │
│  容错: AI 可实时调整                               │
│  适用: 所有场景                                    │
└──────────────────────────────────────────────────┘

┌─ 脚本自动化模式（v0.5.0 新增） ──────────────────┐
│  AI → 1× 生成脚本 → 用户本地执行 → AI 读取报告    │
│  Token 消耗: 低                                    │
│  容错: 脚本内建错误处理 + 可重跑                   │
│  适用: 简单统一变更 + 全部本地路径                  │
└──────────────────────────────────────────────────┘

Stage 3a: Script generation (main Agent)

When stage 2 is complete and all applicable conditions of "script automation mode" are met, generate the deliverables according to the following steps:

Create the mandatory working directory：MustCreate the batch-pr-<YYYY-MM-DD>/ directory under the working directory or the current project root directory. All artifact files generated by the AI are written into this directory. The user subsequently executes the script in this directory.
Generate pr-config.json: contains the repository list, local paths, source branch names, and PR titles. The format is as follows:

Generate pr-config.json: contains the repository list, local paths, source branch names, and PR titles. The format is as follows:

{
	"repos": [
		{
			"repo": "ruan-cat/notes",
			"localPath": "D:/code/ruan-cat/notes",
			"sourceBranch": "feat/update-vitepress-config"
		}
	],
	"prTitle": "docs: 统一更新 Vitepress 配置",
	"sourceBranch": "feat/update-vitepress-config"
}

Generate pr-body.md: user-facing PR body Markdown. Focus on "what was changed + why it was changed + how to verify". The body is recommended to include:

## 改动内容

- 列出具体变更点

## 改动原因

- 说明业务或技术背景

## 验证方式

- 构建、测试或人工检查步骤

Generate commit-message.txt: write the commitMessage frozen in stage 2 into a plain text file,without Emoji（gh The PR title created by the CLI uses emoji independently, while the commit content remains clean). For example:feat(config): update vitepress base path configuration。
Generate batch-pr.ts: using references/batch-pr-script.ts as the reference template, generate acustomizedTypeScript script according to the actual situation of this task:
- The repository list in pr-config.json must be directly embedded into the script (or by reading pr-config.json ).
- Must hardcode prTitle and sourceBranch。
- By default, use the directory where the script itself is located as the working directory (resolved via import.meta.url ), ensuring that users executing from any directory will not read the wrong configuration.
- Optionally include support for the --workdir <path> parameter, used to override the default working directory.
- Must include robust error handling: scenarios such as a dirty working tree, rejected push, or an existing PR should be gracefully skipped and the reason recorded.
- Must support the --dry-run parameter for preview.
- Must write after execution is complete execution-summary.md。
- The transformations[] rules produced in Phase 2β must be integrated so that the script has inline search-and-replace capability rather than only whole-file copying. The transformation rules are stored in pr-transform.json file form in the same directory as the script.
- Must support per-repo differentiated files (commit-message--<repo_safe>.txt、pr-body--<repo_safe>.md), with read priority: per-repo file > general file.
- It is recommended to build in automatic cleanup of task-related residual changes: if all uncommitted files in the working tree are covered by the transformations[] rules, they can be safely git reset --hard HEAD and then rerun; otherwise, retain the skip behavior to avoid overwriting the user's real changes.

Generate pr-transform.json(if there are transformation rules): from scopeAnalysis.transformations[] write to an independent JSON file, with the following format:

{
	"transformations": [
		{
			"description": "替换所有 setup-node 的 node-version 为 24.18.0",
			"glob": ".github/workflows/*.{yml,yaml}",
			"search": "node-version:\\s*\\S+",
			"replace": "node-version: 24.18.0"
		}
	]
}

Generate per-repo differentiated files (optional): when a repository needs a different commit or PR body from other repositories, additionally generate override files according to the following naming rules:
```
commit-message--<repo_safe>.txt   # 例如：commit-message--ruan-cat__notes.txt
pr-body--<repo_safe>.md            # 例如：pr-body--ruan-cat__notes.md
```
where <repo_safe> is the / in the repo identifier replaced with __. When the script reads,it prioritizes the per-repo file, and falls back to the general file when it does not exist.
Generate files to be modified (optional): under the changes/ subdirectory, organize the files to be copied in <repo_safe> format:
```
changes/ruan-cat__notes/    # per-repo 优先
changes/ruan-cat__monorepo/ # per-repo 优先
```
The script execution order is: inline transformation → per-repo changes copy → general changes copy.
Verify artifacts：
- Ensure all files are in the same directory.
- Ensure pr-config.json paths inare all valid absolute paths。
- For batch-pr.ts do aquick syntax check(such as npx tsx --eval 'import "./batch-pr.ts"' or directly npx tsc --noEmit batch-pr.ts), to ensure there are no errors.

Phase 3b: User local execution

After generating the script, the main Agent outputs clear execution instructions to the user:

Inform the user of the directory where the artifacts are located (batch-pr-<YYYY-MM-DD>/）。
Suggested execution commands (the script by default reads the configuration in its own directory):
- cd batch-pr-<YYYY-MM-DD> && npx tsx batch-pr.ts --dry-run(preview first)
- cd batch-pr-<YYYY-MM-DD> && npx tsx batch-pr.ts(actual execution)
- Or from another directory via --workdir specify:npx tsx /path/to/batch-pr.ts --workdir ./batch-pr-<YYYY-MM-DD>
- Merge mode:npx tsx batch-pr.ts merge --dry-run preview,npx tsx batch-pr.ts merge actual merge
Inform the user of the expected results: after the script executes, it will generate execution-summary.md summary report; merge mode generates merge-summary.md。
Ask the user to provide feedback on the execution-summary.md content after execution, or to report the execution result.

During user execution, the AI Agent does not consume tokens—this is the core benefit of the script automation mode.

Phase 3c: Result collection and cleanup

After the user completes execution, read execution-summary.md(or have the user paste/provide its content), and enter Phase 4 result summary.

Working directory cleanup: after the user confirms the results are satisfactory, the batch-pr-<YYYY-MM-DD>/ temporary working directory can be deleted to free up space. The execution-summary.md produced by the script is recommended to be retained and archived.

Phase 3 (traditional): Concurrent scheduling (main Agent -> multiple sub-Agents)

Whenthe script automation mode is not suitable(conditions not met or user declines), fall back to this traditional mode. The scope exploration data from Phase 2β (scopeAnalysis) can still provide reference for subagents.

Decision point: Before entering this phase, you must explicitly choose "script mode" or "subagent mode". If script mode is chosen (Phase 3a→3b→3c), thenskip this phase。

Start one subagent per repository and execute concurrently. Each subagent strictly follows the same protocol:

Receive unified input:prTitle、prBody、commitMessage、sourceBranch。
Verify repository accessibility (local path, remote existence, permissions).
Choose the execution mode based on complexity and local path availability:
- Simple remote metadata tasks: can be completed remotely using GitHub API/MCP.
- Tasks requiring batch file modifications or verification: prefer local git/Bash loops, then use GitHub API/MCP to create PRs.
- High-complexity repositories: first inspect the build system, branches, dependencies, and scripts locally, then decide whether to split the PR.
Target branch decision (branch probing):

若存在 dev   -> target = dev
否则若存在 main -> target = main
否则若存在 master -> target = master
否则 -> 标记失败并返回（无法确定目标分支）

Create a PR (GitHub API/MCP; when necessary, use local git commit/push).
Return a standard result object:
- repo
- localPath
- executionMode
- complexity
- targetBranch
- status (success | failed)
- prUrl(on success)
- reason(on failure)

Phase 4: Result aggregation (main agent)

Aggregate the execution results of all repositories (from script mode or subagent mode).
Do not interrupt the global flow due to a single repository failure.
Output the report with "successes first, failures last".
The aggregation template uses references/workflow-and-template.md。
Additional output:
- Success count / failure count
- Retry suggestions for failed repositories (permission issues, branch does not exist, repository unreachable)

Phase 5: Wrap-up and traceability

Echo this unified input (title, source branch, commit summary) for user review.
If the user requests a second execution (retry failed repositories), rerun Phase 3 only for the failed repositories.
When merging PRs, prioritize maintaining a linear history:
- On the GitHub PR page, prefer rebase merging.
- For local merges, prefer methods that do not create extra merge nodes, such as git merge --ff-only。
After the PR is completed and confirmed merged, promptly delete the remote source branch and local source branch.
If the user requests scaling the default repositories up/down, prompt them to modify references/target-repos.md。

Subagent scheduling specification (must be followed)

Scheduling granularity

One subagent per repository to avoid state contamination between multiple repositories.
Subagents must not share mutable state; unified content is broadcast read-only by the main Agent.

Concurrency strategy

Default to "full concurrency".
If platform rate limits or permission risk controls are encountered, downgrade to "small-batch concurrency" (for example, 2-3 repositories per batch).

Idempotency and repeated execution

If the repository already has an unmerged PR from the same source branch to the same target branch:
- By default, return "already exists" and attach the existing PR link;
- Do not create a new PR repeatedly (unless the user explicitly requests creating a new one).

Data contract

Input contract

{
	"repo": "owner/name",
	"prTitle": "string",
	"prBody": "string",
	"commitMessage": "string",
	"sourceBranch": "string"
}

Output contract

{
	"repo": "owner/name",
	"localPath": "string | null",
	"executionMode": "remote-api|local-git|hybrid|script-auto",
	"complexity": "low|medium|high",
	"targetBranch": "dev|main|master|unknown",
	"status": "success|failed",
	"prUrl": "string | null",
	"reason": "string | null"
}

Scope exploration contract (scopeAnalysis)

{
	"scopeAnalysis": {
		"repos": [
			{
				"repo": "owner/name",
				"localPath": "absolute/path",
				"status": "in-scope|excluded",
				"excludeReason": "string | null",
				"affectedFiles": ["path/to/file.yml"],
				"fileCount": 3,
				"observations": ["特殊模式说明"],
				"currentValues": ["22.14.0"]
			}
		],
		"excludedRepos": [
			{
				"repo": "owner/name",
				"reason": "未克隆 / 无目标文件 / 权限不足"
			}
		],
		"totalFiles": 22,
		"totalOccurrences": 23,
		"specialPatterns": ["release 工作流需保留 registry-url"],
		"transformations": [
			{
				"description": "描述转换目的",
				"glob": ".github/workflows/*.{yml,yaml}",
				"search": "搜索正则",
				"replace": "替换字符串"
			}
		]
	}
}

Transformation rules contract (pr-transform.json)

{
	"transformations": [
		{
			"description": "人类可读的描述",
			"glob": "匹配文件的 glob 模式",
			"search": "搜索正则（不含 / 定界符）",
			"replace": "替换字符串（支持 $1 捕获组引用）"
		}
	]
}

Mandatory requirements

The complexity of the target repository must be evaluated first, then the PR execution approach can be decided.
You must proactively ask the user for the local cloned repository path; only downgrade to remote identification when it cannot be obtained.
Local git/Bash and GitHub API/MCP can be used in combination; do not use gh CLI as the only means.
The default efficient mode for batch cross-repository PRs is a local Bash loop + remote GitHub API/MCP.
The source branch name remains consistent across all repositories.
Failure in a single repository does not affect the overall task; continue processing the remaining repositories.
Branch merging should prioritize maintaining a linear history to avoid creating extra merge commits.
After PR merging is complete, the remote source branch and local source branch must be cleaned up promptly.
If the user requests "add/remove target repositories", only update references/target-repos.md, do not hardcode in SKILL.md .
Before each execution, you must first read references/target-repos.md and references/workflow-and-template.md。
Before each execution, you must first read git-commit skill and commit-types.ts, then generate commitMessage。
Before **Phase 2β (Scope Exploration)** is complete, it is forbidden to directly enter script generation or sub-agent scheduling. The file structure of the target repository must first be scanned to confirm the scope.
Before **Phase 2γ (Design Specification Generation)** is complete, it is forbidden to generate batch-pr.ts. Scripts must be generated according to the transformation rules defined in spec.md.
Script automation mode requirement: when generating batch-pr.ts , you must refer to references/batch-pr-script.ts, ensuring the script includes --dry-run support,--workdir parameters, graceful error handling,execution-summary.md output, and clear execution logs.
Script automation mode requirement: deliverablesmustbe placed in batch-pr-<YYYY-MM-DD>/ mandatory working directory; they are not allowed to be scattered in the project root directory.
Script automation mode requirement: when generating pr-config.json , all localPath must be verified to exist asabsolute paths, and forward slashes (/) must be used instead of backslashes (\）。
Script automation mode requirement: when generating commit-message.txt ,Emoji characters are not allowed, keep plain text format so shell commands can reference it directly.
Script automation mode requirement: if Phase 2β produced transformations[] rules, you must generate the pr-transform.json file, and cannot rely only on changes/ full-file copy. Transformation rules take precedence over full-file copy execution.

Maintenance rules

Add/remove repositories: modify references/target-repos.md
Adjust execution specifications or report structure: modify references/workflow-and-template.md
Update script templates or automation execution specifications: modify references/batch-pr-script.ts
This file only retains the entry point and workflow, and does not repeatedly maintain repository details.

About this skill

Primary principles (CRITICAL)

Quick entry

Workflow

Phase 1: Task normalization (main Agent)

Phase 2α: Unified content generation (coordinator Agent)

git-commit usage conventions (mandatory)

Invocation timing

Generation requirements

Semantic consistency rules

Batch repository scenario constraints

Phase 2β: Scope exploration (main Agent)

Exploration goals

Exploration steps

Exclusion principles

Phase 2γ: Design Specification Generation (Main Agent)

spec.md structure

Generation requirements

Script Automation Mode

Applicable conditions

Quantified benefits

Deliverables List

Comparison with sub-agent mode

Stage 3a: Script generation (main Agent)

Phase 3b: User local execution

Phase 3c: Result collection and cleanup

Phase 3 (traditional): Concurrent scheduling (main Agent -> multiple sub-Agents)

Phase 4: Result aggregation (main agent)

Phase 5: Wrap-up and traceability

Subagent scheduling specification (must be followed)

Scheduling granularity

Concurrency strategy

Idempotency and repeated execution

Data contract

Input contract

Output contract

Scope exploration contract (scopeAnalysis)

Transformation rules contract (pr-transform.json)

Mandatory requirements

Maintenance rules