syncing-submodules

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Intelligent Submodule Sync System

智能子模块同步系统

This skill provides a sophisticated framework for syncing components from git submodules while ensuring consistency, avoiding duplicates, and maintaining quality.

本技能提供了一套成熟的框架，用于同步git子模块中的组件，同时确保一致性、避免重复并维持质量。

Core Principles

核心原则

No Duplicates - Same concept should exist only once
No Near-Duplicates - Similar concepts should be merged
Quality Over Quantity - Better to have fewer excellent components than many mediocre ones
Semantic Analysis - Compare meaning, not just names
Synthesis Over Copying - Create superior merged versions

无重复 - 同一概念仅保留一份
无近似重复 - 相似概念应进行合并
质量优先于数量 - 宁少勿滥，优先保留优质组件
语义分析 - 比较内容含义，而非仅名称
合成而非复制 - 创建更优的合并版本

Phase 1: Deep Discovery

第一阶段：深度发现

1.1 Scan All Submodules

1.1 扫描所有子模块

bash

undefined

bash

undefined

Update submodules

更新子模块

git submodule update --remote --merge

Create inventory

创建清单

for submodule in submodules//; do echo "=== $submodule ===" find "$submodule" -name "SKILL.md" -o -name ".md" -path "/commands/" -o -name ".md" -path "/agents/*" done

undefined

for submodule in submodules//; do echo "=== $submodule ===" find "$submodule" -name "SKILL.md" -o -name ".md" -path "/commands/" -o -name ".md" -path "/agents/*" done

undefined

1.2 Extract Component Metadata

1.2 提取组件元数据

For EACH discovered component, extract:

yaml

component:
  name: "component-name"
  type: "skill|agent|command|hook"
  source: "submodule-name"
  path: "full/path/to/file"

  # Deep analysis fields
  primary_purpose: "One sentence describing main function"
  keywords: ["keyword1", "keyword2", "keyword3"]
  capabilities: ["capability1", "capability2"]
  target_audience: "who uses this"
  domain: "core|engineering|data|devops|design|product|github"

针对每个发现的组件，提取如下元数据：

yaml

component:
  name: "component-name"
  type: "skill|agent|command|hook"
  source: "submodule-name"
  path: "full/path/to/file"

  # 深度分析字段
  primary_purpose: "一句话描述主要功能"
  keywords: ["keyword1", "keyword2", "keyword3"]
  capabilities: ["capability1", "capability2"]
  target_audience: "目标用户"
  domain: "core|engineering|data|devops|design|product|github"

Phase 2: Semantic Similarity Analysis

第二阶段：语义相似度分析

2.1 Similarity Detection Matrix

2.1 相似度检测矩阵

For each pair of components (existing + new), calculate similarity:

Similarity Type	Weight	Detection Method
Name Similarity	15%	Levenshtein distance, common prefixes
Keyword Overlap	25%	Jaccard similarity of extracted keywords
Purpose Overlap	30%	Semantic comparison of descriptions
Capability Overlap	30%	Function/feature comparison

针对每一对组件（现有组件+新组件），计算相似度：

相似度类型	权重	检测方法
名称相似度	15%	编辑距离、共同前缀
关键词重叠度	25%	提取关键词的杰卡德相似度
用途重叠度	30%	描述内容的语义比较
能力重叠度	30%	功能/特性比较

2.2 Similarity Thresholds

2.2 相似度阈值

Score	Classification	Action
90-100%	Duplicate	Keep best, discard other
70-89%	Near-Duplicate	Merge into single component
50-69%	Related	Consider consolidation
30-49%	Tangentially Related	Keep separate, cross-reference
0-29%	Distinct	Add if quality threshold met

分数	分类	操作
90-100%	重复项	保留优质版本，舍弃其他
70-89%	近似重复项	合并为单一组件
50-69%	相关项	考虑整合
30-49%	弱相关项	单独保留，添加交叉引用
0-29%	完全不同	若达到质量阈值则添加

2.3 Semantic Comparison Checklist

2.3 语义比较检查表

When comparing two similar components:

markdown

undefined

比较两个相似组件时使用：

markdown

undefined

Comparison: [Component A] vs [Component B]

对比：[组件A] vs [组件B]

Purpose Analysis

用途分析

A's purpose: ___
B's purpose: ___
Overlap: ___% | Distinct: ___%

A的用途: ___
B的用途: ___
重叠度: ___% | 差异度: ___%

Content Comparison

内容对比

Aspect	Component A	Component B	Better
Completeness	1-10	1-10	A/B
Clarity	1-10	1-10	A/B
Examples	count	count	A/B
Edge cases	count	count	A/B
Actionability	1-10	1-10	A/B

维度	组件A	组件B	更优选项
完整性	1-10	1-10	A/B
清晰度	1-10	1-10	A/B
示例数量	count	count	A/B
边缘案例覆盖	count	count	A/B
可操作性	1-10	1-10	A/B

Unique Features

独有特性

Only in A: ___
Only in B: ___

仅A具备: ___
仅B具备: ___

Decision: [KEEP_A | KEEP_B | MERGE | KEEP_BOTH]

决策: [保留A | 保留B | 合并 | 同时保留]

Rationale: ___

理由: ___

---

---

Phase 3: Quality Scoring

第三阶段：质量评分

3.1 Component Quality Rubric

3.1 组件质量评估标准

Score each component 0-100:

Criterion	Weight	Scoring
Completeness	20%	Covers topic thoroughly
Clarity	20%	Easy to understand and follow
Actionability	15%	Provides concrete steps
Examples	15%	Has good, relevant examples
Edge Cases	10%	Handles exceptions
Formatting	10%	Proper markdown, structure
CSO Optimization	10%	Good trigger phrases in description

对每个组件进行0-100分评分：

评估维度	权重	评分标准
完整性	20%	全面覆盖主题内容
清晰度	20%	易于理解和遵循
可操作性	15%	提供具体执行步骤
示例质量	15%	具备优质、相关的示例
边缘案例处理	10%	覆盖异常场景
格式规范	10%	正确使用Markdown格式，结构清晰
CSO优化	10%	描述中包含优质触发短语

3.2 Quality Thresholds

3.2 质量阈值

Score	Quality Level	Action
80-100	Excellent	Add/keep as-is
60-79	Good	Add with minor improvements
40-59	Mediocre	Only add if fills gap, improve first
0-39	Poor	Do not add

分数	质量等级	操作
80-100	优秀	直接添加/保留
60-79	良好	添加并进行小幅优化
40-59	一般	仅在填补空白时添加，且需先优化
0-39	较差	不添加

Phase 4: Conflict Resolution

第四阶段：冲突解决

4.1 Same Concept, Different Names

4.1 同一概念，不同名称

Example: "verification" vs "validation" vs "checking-work"

Resolution Process:

Identify all variants
Analyze each for unique value
Choose canonical name (most intuitive)
Merge all content into canonical
Ensure description covers ALL trigger phrases

示例："verification" vs "validation" vs "checking-work"

解决流程:

识别所有变体
分析每个变体的独特价值
选择标准名称（最直观的）
将所有内容合并到标准名称下
确保描述涵盖所有触发短语

4.2 Same Name, Different Purposes

4.2 同一名称，不同用途

Example: Two "debug" commands doing different things

Resolution Process:

Determine which aligns with ltk's existing conventions
Rename the other to be more specific
Or merge if they're complementary

示例：两个名为"debug"的命令功能不同

解决流程:

判断哪个符合ltk的现有惯例
将另一个重命名为更具体的名称
若互补则进行合并

4.3 Conflicting Advice

4.3 冲突建议

Example: One says "always use X", another says "never use X"

Resolution Process:

Identify the CONTEXT for each piece of advice
Create nuanced guidance with conditions
Add examples for each scenario
Document when each applies

示例：一个建议“始终使用X”，另一个建议“永远不要使用X”

解决流程:

识别每条建议的适用场景
创建带有条件的细致指导
为每个场景添加示例
记录各建议的适用情况

4.4 Decision Tree

4.4 决策树

Is this component new to ltk?
├── YES → Quality score >= 60?
│   ├── YES → Add with ltk conventions
│   └── NO → Skip or improve first
│
└── NO → Similar exists in ltk
    ├── Similarity >= 90% (Duplicate)
    │   └── Compare quality scores → Keep better one
    │
    ├── Similarity 70-89% (Near-Duplicate)
    │   └── Merge: combine best of both
    │
    ├── Similarity 50-69% (Related)
    │   └── Evaluate: consolidate or keep separate?
    │
    └── Similarity < 50% (Distinct enough)
        └── Quality score >= 60? → Add

该组件是否为ltk新增？
├── 是 → 质量评分 >=60？
│   ├── 是 → 按照ltk惯例添加
│   └── 否 → 跳过或先优化
│
└── 否 → ltk中存在相似组件
    ├── 相似度 >=90%（重复项）
    │   └── 比较质量评分 → 保留更优版本
    │
    ├── 相似度70-89%（近似重复项）
    │   └── 合并：整合两者的优势
    │
    ├── 相似度50-69%（相关项）
    │   └── 评估：整合还是单独保留？
    │
    └── 相似度 <50%（差异足够大）
        └── 质量评分 >=60？ → 添加

Phase 5: Domain-Specific Placement

第五阶段：特定领域放置

5.1 Domain Classification

5.1 领域分类

Domain	Plugin	Indicators
Context/Memory/Agents	ltk-core	"context", "memory", "agent", "prompt", "LLM"
Code/Testing/Architecture	ltk-engineering	"code", "test", "refactor", "architecture"
Data/ML/Analytics	ltk-data	"data", "SQL", "ML", "analytics", "database"
Infrastructure/Security	ltk-devops	"deploy", "k8s", "docker", "security", "CI/CD"
UI/UX/Accessibility	ltk-design	"design", "UI", "UX", "accessibility", "CSS"
Marketing/Sales/Business	ltk-product	"marketing", "sales", "SEO", "content", "business"
Git/GitHub/PRs	ltk-github	"git", "PR", "commit", "GitHub", "branch"

领域	插件	识别关键词
上下文/记忆/Agent	ltk-core	"context", "memory", "agent", "prompt", "LLM"
代码/测试/架构	ltk-engineering	"code", "test", "refactor", "architecture"
数据/ML/分析	ltk-data	"data", "SQL", "ML", "analytics", "database"
基础设施/安全	ltk-devops	"deploy", "k8s", "docker", "security", "CI/CD"
UI/UX/无障碍	ltk-design	"design", "UI", "UX", "accessibility", "CSS"
营销/销售/业务	ltk-product	"marketing", "sales", "SEO", "content", "business"
Git/GitHub/PR	ltk-github	"git", "PR", "commit", "GitHub", "branch"

5.2 Cross-Domain Components

5.2 跨领域组件

Some components span domains. Place in PRIMARY domain, cross-reference in others:

yaml

undefined

部分组件跨多个领域。放置在主要领域，并在其他领域添加交叉引用：

yaml

undefined

In primary location

在主要位置

name: component-name related:

ltk-engineering/skills/related-skill
ltk-devops/agents/related-agent

---

name: component-name related:

ltk-engineering/skills/related-skill
ltk-devops/agents/related-agent

---

Phase 6: Merge Strategies

第六阶段：合并策略

6.1 Skill Merge Template

6.1 技能合并模板

markdown

---
name: merged-skill-name
description: [Combined CSO-optimized description covering ALL trigger phrases]
version: 1.0.0
sources: [source1, source2]  # Attribution
---

markdown

---
name: merged-skill-name
description: [整合所有触发短语的CSO优化描述]
version: 1.0.0
sources: [source1, source2]  # 来源归属
---

[Skill Title]

[技能标题]

[Best introduction from all sources]

[从所有来源中选取的最佳介绍]

[Section from Source A - if superior]

[来源A的章节 - 若更优]

[Content]

[内容]

[Section from Source B - if unique]

[来源B的章节 - 若独有]

[Content]

[内容]

[Merged section - combining both]

[合并章节 - 整合两者优势]

[Synthesized content taking best from each]

undefined

[综合两者精华的内容]

undefined

6.2 Agent Merge Strategy

6.2 Agent合并策略

markdown

---
agent: merged-agent-name
description: |
  [Combined description with all use cases]
  <example>...</example>
  <example>...</example>  # Include examples from ALL sources
model: [keep more capable model]
tools: [union of all tools needed]
color: [consistent with ltk conventions]
sources: [source1, source2]
---

markdown

---
agent: merged-agent-name
description: |
  [整合所有使用场景的描述]
  <example>...</example>
  <example>...</example>  # 包含所有来源的示例
model: [保留功能更强的模型]
tools: [整合所有所需工具]
color: [符合ltk惯例]
sources: [source1, source2]
---

[Agent Title]

[Agent标题]

[Synthesized capabilities from all sources]

[整合所有来源的能力描述]

Workflow

工作流程

[Best workflow, enhanced with steps from other sources]

undefined

[最佳工作流程，结合其他来源的步骤进行增强]

undefined

6.3 Command Merge Strategy

6.3 命令合并策略

Commands should generally NOT be merged - they're distinct actions. Instead:

Keep the more complete version
Add unique features from other version
Ensure no naming conflicts

命令通常不应合并——它们是独立的操作。替代方案：

保留更完整的版本
添加其他版本的独有特性
确保无命名冲突

Phase 7: Deduplication Audit

第七阶段：去重审计

7.1 Pre-Sync Audit

7.1 同步前审计

Before syncing, audit EXISTING ltk components:

bash

undefined

同步前，审计现有ltk组件：

bash

undefined

Find potential duplicates by keyword analysis

通过关键词分析发现潜在重复项

for skill in plugins//skills//SKILL.md; do echo "=== $skill ===" grep -i "description:" "$skill" done | sort | uniq -c | sort -rn

undefined

for skill in plugins//skills//SKILL.md; do echo "=== $skill ===" grep -i "description:" "$skill" done | sort | uniq -c | sort -rn

undefined

7.2 Duplicate Detection Patterns

7.2 重复项检测模式

Pattern	Likely Duplicate
Same verb + noun	"code review" / "reviewing code"
Synonym usage	"validate" / "verify" / "check"
Same domain + action	"git commit" / "committing changes"
Acronym vs full	"TDD" / "test driven development"

模式	可能为重复项
相同动词+名词	"code review" / "reviewing code"
使用同义词	"validate" / "verify" / "check"
同一领域+相同操作	"git commit" / "committing changes"
缩写与全称	"TDD" / "test driven development"

7.3 Post-Sync Verification

7.3 同步后验证

After sync, verify no duplicates introduced:

bash

undefined

同步后，验证未引入重复项：

bash

undefined

Check for duplicate skill names

检查重复的技能名称

find plugins -name "SKILL.md" -exec basename {} ; | sort | uniq -c | sort -rn | head -20

Check for duplicate agent names

检查重复的Agent名称

find plugins//agents -name ".md" -exec basename {} .md ; | sort | uniq -c | sort -rn | head -20

Check for duplicate command names

检查重复的命令名称

find plugins//commands -name ".md" -exec basename {} .md ; | sort | uniq -c | sort -rn | head -20

---

find plugins//commands -name ".md" -exec basename {} .md ; | sort | uniq -c | sort -rn | head -20

---

Phase 8: Output Report Format

第八阶段：输出报告格式

markdown

undefined

markdown

undefined

Submodule Sync Report

子模块同步报告

Date: YYYY-MM-DD Submodules Analyzed: N Components Discovered: N Components Added: N Components Merged: N Duplicates Removed: N

日期: YYYY-MM-DD 分析的子模块数量: N 发现的组件数量: N 添加的组件数量: N 合并的组件数量: N 移除的重复项数量: N

Similarity Analysis Summary

相似度分析摘要

Comparison	Similarity	Decision
A vs B	85%	Merged → A
C vs D	95%	Duplicate, kept C
E vs F	45%	Kept both

对比项	相似度	决策
A vs B	85%	合并 → A
C vs D	95%	重复项，保留C
E vs F	45%	同时保留

Quality Scores

质量评分

Component	Source	Score	Decision
skill-x	submodule-1	82	Added
agent-y	submodule-2	55	Improved, then added
command-z	submodule-3	35	Rejected (low quality)

组件	来源	分数	决策
skill-x	submodule-1	82	添加
agent-y	submodule-2	55	优化后添加
command-z	submodule-3	35	拒绝（质量过低）

Components Added

添加的组件

Type	Name	Domain	Source	Notes
skill	name	ltk-core	sub1	New capability

类型	名称	领域	来源	备注
skill	name	ltk-core	sub1	新增能力

Components Merged

合并的组件

Result	Sources	Merge Strategy
skill-a	skill-a1 + skill-a2	Combined best sections

结果	来源	合并策略
skill-a	skill-a1 + skill-a2	整合最优章节

Duplicates Resolved

已解决的重复项

Kept	Removed	Reason
A (ltk)	A' (submodule)	ltk version more complete

保留项	移除项	原因
A (ltk)	A' (submodule)	ltk版本更完整

Rejected (Quality)

因质量拒绝的组件

Component	Source	Score	Reason
skill-x	sub3	35	Poor formatting, incomplete

组件	来源	分数	原因
skill-x	sub3	35	格式混乱，内容不完整

Action Items

行动项

Remember

注意事项

Always do semantic analysis - Names can be deceiving
Quality gates are mandatory - Don't add mediocre content
Merge > Add - Prefer enhancing existing over adding similar
Attribution matters - Credit sources
Test after sync - Verify nothing broke
Document decisions - Future you will thank present you

始终进行语义分析 - 名称可能具有误导性
质量检查是强制性的 - 不要添加平庸内容
优先合并而非添加 - 优先增强现有组件而非添加相似组件
归属很重要 - 注明来源
同步后测试 - 验证未出现问题
记录决策 - 未来的你会感谢现在的你