会话收尾 —— 在任意对话(含未走完十步循环的探索/调试/讨论 session)把"未交接成果" 固化为 handoff。**与十步循环正交平级的会话仪式**(非周期收尾): AI 先内省本对话出未完成线程 + 待固化经验, 再用机械 autofill 交叉核验补漏, 写 docs/handoff/。leaf — 终结于写交接, 不拖入十步循环。使用场景: "对话收尾" / "执行对话收尾" / "会话收尾" / "session closeout" / "收尾这次对话" / "写交接" / "写 handoff" / "收工" / "结束本次对话" / context 快满时主动收尾。不适用 (用 phase-d-closer): "Phase D" / "周期收尾" / "归档 Spec" / "更新 cycle 进度" —— 那是开发周期收尾, 不是会话收尾。

2026-07-191

git-remote-helper

10CG/aria-plugin

Git 多远程 parity 检测与 push 验证的共享基础设施。内部工具, 仅供其他 skills 引用。提供标准化 Bash/Python 执行脚本段 + 输出 JSON schema 契约。

2026-07-191

agent-router

10CG/aria-plugin

任务到 Agent 的智能路由器，根据任务类型、文件路径自动选择最合适的 Agent。使用场景：subagent-driver 需要为任务选择 Agent、不确定应该使用哪个 Agent

2026-07-121

aria-report

10CG/aria-plugin

向 Aria 维护团队报告 Bug 或提交功能建议。自动收集环境信息，自动路由到 Forgejo（内部用户）或 GitHub（外部用户）。使用场景："报告 bug"、"report an issue"、"提交功能建议"、 "aria 有个问题想反馈"、"feature request"、"提 issue"、 "反馈问题"、"report bug to aria"

2026-07-121

name	strategic-commit-orchestrator
description	基于AI-DDD v3.0.0的战略提交编排器，智能分析项目变更设计分组提交计划。使用场景：需要分组提交多个变更、跨模块协同开发、阶段性成果提交。
argument-hint	[--dry-run]
disable-model-invocation	false
user-invocable	true
allowed-tools	Bash, Read, Grep, Task

Strategic Commit Orchestrator

🚀 快速开始

我应该使用这个 Skill 吗？

决策树:

有多个提交需要分组？
  ├─ 是 → 使用本 skill
  │   └─ 主项目 + 子模块都有变更？
  │       ├─ 是 → 类型E 全项目流程
  │       └─ 否 → 跨多个模块？
  │           ├─ 是 → 跨模块流程
  │           └─ 否 → 单模块分组流程
  └─ 否 → 使用 commit-msg-generator

快速场景匹配:

场景	使用?	类型	说明
📁 创建多个架构文档	✅	B	文档批量提交
🔄 Backend + Mobile 协同开发	✅	D	跨模块提交
🎯 Phase/Cycle 结束里程碑	✅	B/D	阶段成果提交
🔧 大规模重构	✅	A/B	多文件分组
🌐 OpenSpec + Skills + Standards	✅	E	全项目变更
📦 主项目 + 子模块同时变更	✅	E	全项目变更
📝 单文件修改	❌	-	直接用 commit-msg-generator
🐛 单个 Bug 修复	❌	-	直接用 commit-msg-generator

快速示例

场景: Backend架构文档批量提交

步骤:
1. 分析变更 → 3个架构文档 (L0 + 2个L1)
2. 分组策略 → Group 1: L0, Group 2: L1文档
3. Subagent分配 → knowledge-manager
4. 执行策略 → 串行 (L0 → L1)
5. 并行执行提交

完整示例: EXAMPLES.md

🎯 核心价值

作为 Tech-Lead 级别 的战略提交编排工具，在复杂多模块变更场景下，提供智能的提交分组规划、Subagent 并行编排和项目进度感知能力。

核心能力:

✅ 支持 mobile/backend/frontend/shared 所有模块
✅ 基于AI-DDD v3.0.0核心标准
✅ 自动识别变更文件所属模块
✅ 智能分配专业 Subagent
✅ 并行执行提交，提升效率

📋 五种变更类型（核心）

✅ 使用前必读: 根据变更类型选择正确的处理方式

类型	特征	UPM处理	Phase/Cycle	示例
类型A	业务功能子模块变更	读取子模块UPM	使用实际进度	`mobile/`, `backend/`
类型B	主项目变更	读取主模块UPM	使用主模块进度	`docs/`, `.claude/skills/`, `scripts/**`
类型C	跨项目共享基础设施	无UPM	使用逻辑阶段	`standards/`, `.claude/agents/`
类型D	跨模块协同变更	读取主模块UPM	使用主模块进度	Backend + Mobile + API契约
类型E	全项目变更	混合策略	各自处理	主项目 + 子模块同时变更

详细识别规则: CHANGE_TYPES.md

🔄 基本使用流程

1. 识别变更类型 → A / B / C / D / E

2. 读取项目状态
   → 类型A: 读取子模块UPM
   → 类型B/D: 读取主模块UPM
   → 类型C: 跳过UPM，使用逻辑阶段
   → 类型E: 混合策略 (见下方说明)

3. 分析变更并分组
   → 按职责、依赖关系分组文件
   → 类型E: 先扫描所有子模块变更

4. 分配 Subagent
   → knowledge-manager / backend-architect / mobile-developer 等

5. 执行提交
   → 使用 Task 工具并行/串行执行

6. 验证结果
   → 检查 git log，确认提交成功

详细流程: ADVANCED_GUIDE.md - 标准工作流程

🤖 可用 Subagent

Subagent	专长领域	适用场景
knowledge-manager	架构文档、知识库	_ARCHITECTURE.md, docs/
backend-architect	后端系统、API	backend/*/.py, API实现
mobile-developer	Flutter/Dart、UI	mobile/lib/*/.dart
api-documenter	API文档、OpenAPI	shared/contracts/*.yaml
qa-engineer	测试、质量保证	test/*/_test.*
tech-lead	技术决策、重构	Skill开发, 重大重构
general-purpose	通用任务	配置修改, 简单更新

详细能力映射: ADVANCED_GUIDE.md - Subagent分配

⚙️ 执行策略

全并行 (Fast Track)

条件: 所有分组完全独立，无依赖
示例: 3个不同 Skill 的独立更新

阶段并行 (Phased)

条件: 存在阶段性依赖
示例: Phase 1: [A || B], Phase 2: [C]

串行 (Sequential)

条件: 强依赖关系，必须顺序执行
示例: API定义 → 实现 → 测试

混合 (Hybrid) ⭐ 最常用

条件: 部分并行 + 部分串行
执行: 灵活组合

详细策略: ADVANCED_GUIDE.md - 并行执行编排

📝 提交消息增强

基础格式

<type>(<scope>): <中文描述> / <English description>

<Body>

🤖 Executed-By: {subagent_type} subagent
📋 Context: {Phase}-{Cycle} {context}
🔗 Module: {module_name}

<Footer>

Phase/Cycle来源

类型A (业务功能子模块):
  → 从子模块 UPM 读取实际进度
  → 示例: Phase4-Cycle9

类型B (主项目变更):
  → 从主模块 UPM 读取实际进度
  → 示例: Phase2-Cycle3

类型C (跨项目共享基础设施):
  → 使用逻辑阶段描述（无UPM）
  → 示例: Phase1-Cycle1 standards-unification

类型D (跨模块协同变更):
  → 从主模块 UPM 读取
  → 示例: Phase3-Cycle7

类型E (全项目变更):
  → 子模块: 各自策略 (A/C)
  → 主项目: 读取主模块UPM
  → 示例: 主项目 Phase2-Cycle3 + standards Phase1-Cycle1

增强标记格式: commit-msg-generator/ENHANCED_MARKERS_SPEC.md

💡 最佳实践

分组原则

✅ 职责单一、大小适中（3-8文件）
✅ 逻辑完整、依赖清晰
❌ 避免过大分组（20+文件）
❌ 避免职责混杂

Agent选择

✅ 文档 → knowledge-manager
✅ 技术领域匹配 → 对应技术栈 agent
✅ 测试 → qa-engineer
❌ 避免全用 general-purpose

并行策略

✅ 不同端的独立功能可并行
❌ 同一文件的多次修改不可并行
❌ 有明确依赖关系的变更需串行

提交粒度

合适: 3-15个文件，单一变更类型
太粗: >50个文件，混合类型
太细: 每个文件单独提交

完整实践: ADVANCED_GUIDE.md - 最佳实践

🚨 故障处理

常见问题

问题	症状	快速解决
Git冲突	多个Task同时修改同一文件	暂停 → 解决冲突 → 重启
Task失败	Subagent超时/失败	AgentOutputTool查看输出
格式错误	Git hook拒绝提交	git commit --amend 修正

详细处理: ADVANCED_GUIDE.md - 故障处理

✅ 快速检查清单

执行前

执行后

git log 确认所有提交
提交消息格式正确
分支状态正常

完整清单: TROUBLESHOOTING.md - 检查清单

🔗 新技能协作 (v2.3.0)

新增于 v2.3.0 - 集成 enforcement-mechanism-redesign 新技能

技能协作图

strategic-commit-orchestrator
    │
    ├──> branch-manager v2.0.0
    │    └── 自动模式决策 + Worktree 信息
    │
    ├──> subagent-driver v1.0.0 (可选)
    │    └── 批量任务执行
    │
    └──> branch-finisher v1.0.0
         └── 4选项完成流程入口

与 branch-manager v2.0.0 协作

协作点:
  1. 模式感知:
     - 获取当前隔离模式 (Branch/Worktree)
     - Worktree 模式下调整提交策略

  2. Worktree 路径:
     - 获取 worktree_path (如果存在)
     - 确保在正确目录执行 git 操作

使用方式:
  # 获取 branch-manager 输出
  context:
    mode: "worktree"
    worktree_path: ".git/worktrees/TASK-001-xxx"
    branch_name: "feature/mobile/TASK-001-xxx"

  # 调整提交策略
  if mode == "worktree":
    # 确保在 worktree 目录执行
    git_cwd: worktree_path

与 subagent-driver v1.0.0 协作

协作点:
  1. 批量任务执行:
     - 大规模重构时使用 subagent-driver 执行
     - 利用 Fresh Subagent 隔离

  2. 任务间审查:
     - 复用 inter-task review 机制
     - 提交前验证代码质量

使用场景:
  - 类型A/D: 多子模块协同变更
  - 类型E: 全项目批量提交

示例:
  # 使用 subagent-driver 执行多组提交
  for group in commit_groups:
    subagent_driver.execute_task(
      task: f"提交 {group.name}",
      files: group.files,
      subagent: group.recommended_agent
    )

与 branch-finisher v1.0.0 协作

协作点:
  1. 完成流程入口:
     - 所有提交完成后调用 branch-finisher
     - 执行测试验证 + 4选项选择

  2. Worktree 清理:
     - 委托 branch-finisher 处理清理决策
     - 不直接清理 worktree

调用时机:
  after: 所有分组提交完成
  before: Phase C (PR 创建)

流程:
  1. strategic-commit-orchestrator 完成所有提交
     ↓
  2. 调用 branch-finisher
     ├── 测试前置验证
     └── 4选项完成流程
     ↓
  3. 根据用户选择
     ├── [1] → Phase C
     ├── [2] → 继续修改
     ├── [3] → 回滚
     └── [4] → 暂停

协作配置

collaboration_config:
  # branch-manager 协作
  branch_manager:
    enabled: true
    mode_aware: true        # 感知隔离模式
    worktree_support: true  # 支持 worktree 路径

  # subagent-driver 协作 (可选)
  subagent_driver:
    enabled: false          # 默认不启用
    use_for:
      - large_refactor      # 大规模重构
      - type_e_changes      # 类型E变更
    isolation_level: "L2"

  # branch-finisher 协作
  branch_finisher:
    enabled: true
    auto_call: true         # 自动调用
    call_after: "all_commits_done"

📚 相关文档

Skill 文档（按需加载）

文档	职责	加载场景
CHANGE_TYPES.md	变更类型识别	确定A/B/C/D/E类型
WORKFLOW_CORE.md	通用流程 (Phase 2-6)	每次提交
WORKFLOW_TYPE_A.md	子模块变更流程	类型A
WORKFLOW_TYPE_B.md	主项目变更流程	类型B
WORKFLOW_TYPE_C.md	跨项目共享流程	类型C
WORKFLOW_TYPE_D.md	跨模块协同流程	类型D
WORKFLOW_TYPE_E.md	全项目变更流程	类型E (v2.2.0新增)
SUBMODULE_GUIDE.md	子模块处理指南	类型E (v2.2.0新增)
TROUBLESHOOTING.md	故障处理+最佳实践	遇到问题时
EXAMPLES.md	完整工作流示例	学习参考
CHANGELOG.md	版本历史	了解变更

依赖 Skill

commit-msg-generator - v2.0.0

协作 Skill (v2.3.0 新增)

branch-manager - v2.0.0 (模式感知)
subagent-driver - v1.0.0 (批量执行)
branch-finisher - v1.0.0 (完成流程)

核心规范

Git提交消息: @standards/conventions/git-commit.md
AI-DDD进度管理: @standards/core/progress-management/ai-ddd-progress-management-core.md v1.0.0
UPM文档路径: @{module}/[docs/]project-planning/unified-progress-management.md

外部资源

Conventional Commits

💡 使用提示

首次使用: 阅读本文档了解决策树和变更类型
识别类型: CHANGE_TYPES.md 确定变更类型
执行流程: 加载对应 WORKFLOW_TYPE_*.md + WORKFLOW_CORE.md
查看示例: EXAMPLES.md 查看完整工作流
遇到问题: TROUBLESHOOTING.md

版本: 2.3.0 最后更新: 2026-01-21 Skill版本: 2.3.0 (新增新技能协作支持)