custom-skills-ecc-analyze

Custom Skills — ECC Analyze

Conduct a review of the ECC distribution list in two modes:

Mode A — Slimming down the existing list: Review the current distribution.yaml.enabled for overlap/quality issues, and output enabled_remove recommendations
Mode B — New item introduction assessment: Based on ecc-catalog.yaml and the scope of the last update, introduce newly added skills from ECC upstream, analyze applicable scenarios, and recommend which ones should be added to enabled

All output goes to upstream/reports/, without automatically modifying distribution.yaml。

How to choose a Mode

   ┌──────────────────────────────────────────────────────────┐
   │  使用者問題                            → 觸發 Mode       │
   ├──────────────────────────────────────────────────────────┤
   │  "分析 ECC 清單" / "瘦身 enabled"      → Mode A           │
   │  "上游新增了什麼" / "要不要加 XX"      → Mode B           │
   │  "全面審視 ECC"                        → A + B 都跑      │
   └──────────────────────────────────────────────────────────┘

Both Modes share the 5 quality buckets and guardrails of Step 5; the difference lies in the input side (existing list vs new list) and the direction of the output recommendations (remove vs add).

Mode A — Slimming down the existing list

Find skills that should be removed among those already enabled.

Workflow

┌────────────────────────────────────────────────────────────────────┐
│                  Mode A — Pruning Pipeline                         │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  1. 取集合          2. 標籤本地         3. 過濾 ECC                │
│  ┌──────────┐       ┌──────────┐       ┌──────────┐               │
│  │ enabled  │  ───▶ │ classify │  ───▶ │ keep ECC │               │
│  │ + local  │       │ local    │       │ in scope │               │
│  └──────────┘       │ by role  │       └──────────┘               │
│                     └──────────┘             │                     │
│                                              ▼                     │
│  4. 重疊比對       5. 品質分群         6. 報告                     │
│  ┌──────────┐      ┌──────────┐       ┌──────────┐                │
│  │ pair by  │ ───▶ │ 5 buckets│  ───▶ │ markdown │                │
│  │ purpose  │      │ A-E      │       │ + yaml   │                │
│  └──────────┘      └──────────┘       └──────────┘                │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

Step 1 — Fetch the sets

Read two sources:

# 第一方 skill collection
DISABLE_TELEMETRY=1 npx skills add ValorVie/ai-dev-skills --list

# ECC enabled 清單
uv run python -c "
import yaml
d = yaml.safe_load(open('upstream/distribution.yaml'))
print('\n'.join(d['distribute']['skills']['enabled']))
"

Also read the ECC skill descriptions (for semantic comparison):

ECC=~/.config/everything-claude-code/skills
for n in <names>; do
  desc=$(awk '/^description:/{sub(/^description:[ ]*/,""); print; exit}' "$ECC/$n/SKILL.md")
  echo "[ECC] $n :: $desc"
done

Why use descriptions instead of full text: the description is the skill's trigger condition and best represents the "usage scenario." To judge overlap, comparing "when to use" is more reliable than comparing "implementation details."

Step 2 — Label the roles of first-party skills

Group first-party skills by role, because only skills with the same role have a chance of overlapping with ECC:

   個人工具流          → custom-*
   framework workflow  → custom-skills-*
   個人化輸出          → wiki, work-log-*
   思考框架            → first-principles
   領域特化            → cloud-infra-security
   跨 AI 工具          → discuss-multi-ai

work-log-* is internal-only,will not overlap with ECC(ECC does not have these concepts).Step 4 only needs to compare the remaining groups。

Step 3 — Filter ECC

Exclude ECC skills that clearly do not need review:

Known as "ECC internal tools" (such as ecc-guide, nanoclaw-repl, hermes-imports) → leave for the Step 5 quality group to handle
Newly added upstream in ECC, not yet included in the catalog → skip (run ai-dev ecc audit to handle)

Step 4 — Overlap comparison

For each first-party skill, find 1-3 semantically closest ECC skills:

   ┌────────────────────────────────────────┐
   │  第一方 skill X                        │
   │  ↓ 在 ECC enabled 中找語意鄰近候選     │
   │  Y1, Y2, Y3                            │
   │                                        │
   │  針對每個 (X, Yk) 評估：              │
   │  - 觸發條件是否高度重疊？             │
   │  - 輸出產物是否相似？                 │
   │  - 抽象層級是否相同？                 │
   │                                        │
   │  分級：高 / 中 / 低-中 / 低           │
   └────────────────────────────────────────┘

Overlap strength criteria：

Strength	Criteria	Recommended action
High	Trigger conditions highly overlap, outputs similar, same level of abstraction	`enabled_remove` the weaker side
Medium	Trigger conditions partially overlap, different scope	Keep both, but note it
Low-Medium	Domains close, actual usage different	Keep
Low	Same keywords but fundamentally different	Keep

Decide which side should stay(in case of conflict):

The first-party version is more focused and not easily replaced by a general version → keep first-party, remove ECC
The ECC version can cover scenarios not handled locally → keep ECC, consider phasing out the local one
Both sides have unique value → keep both (no conflict)

Step 5 — Quality grouping (5 buckets)

Among ECC enabled,possibly should be removedgroup the items into five buckets:

A. Clearly deprecated

Criterion: description contains [DEPRECATED] / deprecated / legacy and similar wording. Action:must remove。

B. Highly niche language/framework

Criterion: description targets a specific framework/language, and that framework/language is any of the following:

GitHub star < 1k
Global dev share < 1%
Naming points to a region-specific tool (Cisco, Quarkus, etc.)

Action: ask the user whether they use that language/framework; if not → remove.

C. Academic/research-only

Criterion: description contains scientific, literature, patent, genomic, scholar and other academic vocabulary. Action: ask the user whether they do academic research; if not → remove the entire group.

D. Poor naming, low recognizability

Criterion:

Name is an abbreviation with no expansion (ck and similar)
Name is based on the author (santa-method, ralphinho-*）
Name is grandiose and inconsistent with the content (agentic-os is essentially file-memory)
description assumes the reader has already read some paper (no self-contained context)

Action: list them for the user to decide. default leans toward removal (vague trigger descriptions easily cause false triggers).

E. Marginal value / replaceable by built-ins

Criterion:

Functionality has been replaced by Claude Code / platform built-ins (/compact replaces strategic-compact）
A single principle made into an entire skill (can be expressed with a one-line rule)
Triggers only in extremely narrow scenarios (< 5% chance of use)
Multiple similar skills overlap with each other (motion-foundations × motion-advanced × motion-patterns × motion-ui）

Action: list as "marginal", with the rationale attached for the user to decide.

Step 6 — Report output (Mode A)

Output location：upstream/reports/ecc-skill-analysis-YYYY-MM-DD.md

Report structure：

# ECC Skill 分析報告 — 重疊與品質審視

- 日期、分析對象、比對基準、資料來源

## 一、與第一方 skill 的重疊性分析
  ### 第一方 skill 角色拆解（ASCII 圖）
  ### 重疊矩陣（表格：本地 | ECC 候選 | 強度 | 推薦動作 | 理由）
  ### 重疊小結（建議 enabled_remove 的 yaml 片段）

## 二、品質與通用性問題
  ### A. 明確 deprecated（表格）
  ### B. 高度小眾語言/框架（表格 + 移除建議欄）
  ### C. 學術/科研專用（表格）
  ### D. 命名劣質、辨識度低（表格 + 問題說明）
  ### E. 邊界價值 / 可被內建取代（表格 + 為何邊界）

## 三、建議的 ~/.config/ai-dev/ecc-profile.yaml
  （完整可貼入的 yaml，含中文註解分群）

## 四、後續
  - 重新評估週期
  - 觸發指令

Guidelines for writing the yaml block：

Use comments to group enabled_remove by source (overlap / deprecated / niche / academic / marginal / either-or)
For "either-or" items use # comments to list them for the user to uncomment,do not default to removal
Add the total distribution count change (before / after removal)

Mode B — New item adoption assessment

For skills newly added upstream in ECC, introduce the content, analyze applicable scenarios, and give adoption recommendations.

Workflow

┌────────────────────────────────────────────────────────────────────┐
│              Mode B — New Items Review Pipeline                    │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  1. 找新項目          2. 介紹內容        3. 適用度評估             │
│  ┌──────────┐         ┌──────────┐       ┌──────────┐             │
│  │ catalog  │ ───▶    │ read     │ ───▶  │ 通用度   │             │
│  │ diff /   │         │ SKILL.md │       │ 觸發頻率 │             │
│  │ added    │         │ desc +   │       │ 替代性   │             │
│  └──────────┘         │ 30 lines │       └──────────┘             │
│                       └──────────┘             │                   │
│                                                ▼                   │
│  4. 重疊檢查         5. 5 bucket 過濾    6. 三段建議               │
│  ┌──────────┐        ┌──────────┐       ┌──────────┐              │
│  │ 對比本地 │  ───▶  │ A-E 任一 │  ───▶ │ ✅ / ⚠️ / ❌  │            │
│  │ + enabled│        │ → 拒絕   │       │ + 理由   │              │
│  └──────────┘        └──────────┘       └──────────┘              │
│                                                │                   │
│                                                ▼                   │
│                                          7. 報告 +                 │
│                                            enabled patch          │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

Step 1 — Find new items

Any of the three sources can be used (choose by scenario):

Method A: use ai-dev ecc audit

ai-dev ecc audit
# 看 [NEW] 區段：ECC 有但 catalog 沒有的項目

Method B: the catalog's added field

If the catalog has already been supplemented with uncategorized by audit, compare added >= 上次評估日期：

uv run python -c "
import yaml
from datetime import date
last_review = '2026-05-12'   # 上次評估日，或從報告檔名取
cat = yaml.safe_load(open('upstream/ecc-catalog.yaml'))
new_items = []
for cat_key, cat_data in cat['categories'].items():
    for s in cat_data.get('skills') or []:
        added = s.get('added', '') if isinstance(s, dict) else ''
        if added >= last_review:
            new_items.append((cat_key, s['name'], added))
for c, n, a in sorted(new_items, key=lambda x: x[2]):
    print(f'{a}  [{c}]  {n}')
"

Method C: git log catalog changes

git log -p upstream/ecc-catalog.yaml | head -200

After confirming the new item list, note the scope and date cutoff.

Step 2 — Introduce each new item

For each new item, read its SKILL.md:

ECC=~/.config/everything-claude-code/skills
for n in <new-names>; do
  echo "=== $n ==="
  sed -n '1,40p' "$ECC/$n/SKILL.md"
  echo
done

Produce an introduction for each new item, including:

One-line summary (extracted from description)
Main functionality (grab the core concepts from the first 30 lines of SKILL.md)
Example use scenarios (from the "Use when..." section of the description or summarized yourself in 2-3 items)

Step 3 — Applicable scenario assessment (four dimensions)

Score each item 1-3:

Dimension	1 (low)	2 (medium)	3 (high)
Generality	Specific tool / framework	Specific tech stack	≥ 50% of projects applicable
Trigger frequency	Rare	A few times per month	Multiple times per week
Irreplaceability	Already built into the platform / available locally	Partially covered	No similar tool
Learning cost	Requires reading papers / extensive background	Medium	self-contained

Total score interpretation：

10-12 points → Strongly recommended
7-9 points → Conditional
≤ 6 points → Not recommended

This is a supporting framework, not a hard rule. If the description is vague (Group D) or the value is borderline (Group E), downgrade by one level directly.

Step 4 — Overlap check

Compare with existing enabled + local skills/ to find:

   新項目 X
   ├─ 與本地某個高度重疊？      → 「換手」或「不導入」
   ├─ 與某個 enabled 高度重疊？  → 「不導入」或「替換掉舊的」
   ├─ 補強某個既有？             → 「同時保留」並備註定位差異
   └─ 完全獨立？                 → 進入下一步

Step 5 — 5 quality bucket filters (shared with Mode A)

If any bucket hits, downgrade or reject:

A. Deprecated: description contains [DEPRECATED] / legacy → Reject
B. Highly niche language/framework: locked to a specific niche framework → ask whether that tech stack is used
C. Academic/research-specific: contains scientific / literature / patent vocabulary → ask whether it is for academic use
D. Poor naming, low recognizability: abbreviations no one understands / author naming / exaggerated / assumes reader background → do not adopt (vague trigger description easily misfires)
E. Borderline value: replaced by built-ins / a single principle turned into an entire skill / extremely narrow scenario → conditional or do not adopt

Step 6 — Three-tier recommendation

Classify each new item into one of the following three tiers:

✅ Strongly recommend adoption

General-purpose + high quality + no overlap + clear applicable scenarios
Add directly to "next commit add to distribute.skills.enabled」

⚠️ Conditional adoption

Limited scenarios but useful (e.g., only useful if you write Vue, only useful for e2e)
List the trigger conditions, let the user decide
Provide a "if you decide to adopt" patch snippet

❌ Do not recommend adoption

Include the reason (niche / overlap / quality bucket hit)
Note the conditions under which it might be re-evaluated in the future

Step 7 — Report output (Mode B)

Output location：upstream/reports/ecc-new-items-review-YYYY-MM-DD.md

Report structure：

# ECC 新項目導入評估 — YYYY-MM-DD

- 上次評估日、本次 cutoff、新項目數量、catalog 版本

## 一、新項目總覽（表格）
| 名稱 | category | added | 通用 | 頻率 | 替代性 | 學習 | 總分 | 建議 |
|------|----------|-------|------|------|--------|------|------|------|

## 二、強烈建議導入（N 個）
  ### <skill-name>
  - 一行摘要
  - 主要功能（2-4 點）
  - 適用情境（2-3 例）
  - 評分理由

## 三、條件性導入（N 個）
  ### <skill-name>
  - 一行摘要 + 觸發條件
  - 「若你 X 才有用」
  - 評分理由

## 四、不建議導入（N 個）
  ### <skill-name>
  - 為何不建議（命中哪個 bucket / 重疊誰）
  - 未來重新評估的條件（若有）

## 五、建議 patch（要加進 distribution.yaml.enabled）

  ```yaml
  # === <category> ===
  - <skill-1>
  - <skill-2>

Remember to also update the category count comment.

Six, Follow-up

Update the last evaluation date to this date, and the next cutoff starts from here


**patch 撰寫原則**：
- 只列「強烈建議」項目（條件性的留給使用者自行加）
- 按 `ecc-catalog.yaml` 的 category 分群
- 標註各 category 預期數量變化

---

# Guardrails（兩個 Mode 共用）

1. **不自動寫 `ecc-profile.yaml` / `distribution.yaml`**：只產報告，最終由使用者決定
2. **不刪除任何檔案**：建議僅以 yaml 片段表達
3. **資料來源以 description 為主**：必要時再讀 SKILL.md 前 30-50 行；避免讀整檔案（成本控制）
4. **每個判斷要有依據**：每個建議都附「為什麼」一句話，否則不列入
5. **新舊不混淆**：Mode A 處理既有 enabled，Mode B 處理新項目；同時跑時也分開報告

---

## 範例輸出

- **Mode A 完整實例**：[`upstream/reports/ecc-skill-analysis-2026-05-12.md`](https://github.com/ValorVie/custom-skills/blob/main/upstream/reports/ecc-skill-analysis-2026-05-12.md)
- Mode B 範例：首次執行後產出於 `upstream/reports/ecc-new-items-review-YYYY-MM-DD.md`

About this skill

How to choose a Mode

Workflow

Step 1 — Fetch the sets

Step 2 — Label the roles of first-party skills

Step 3 — Filter ECC

Step 4 — Overlap comparison

Step 5 — Quality grouping (5 buckets)

A. Clearly deprecated

B. Highly niche language/framework

C. Academic/research-only

D. Poor naming, low recognizability

E. Marginal value / replaceable by built-ins

Step 6 — Report output (Mode A)

Workflow

Step 1 — Find new items

Step 2 — Introduce each new item

Step 3 — Applicable scenario assessment (four dimensions)

Step 4 — Overlap check

Step 5 — 5 quality bucket filters (shared with Mode A)

Step 6 — Three-tier recommendation

✅ Strongly recommend adoption

⚠️ Conditional adoption

❌ Do not recommend adoption

Step 7 — Report output (Mode B)

Six, Follow-up