mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-06 09:13:31 +08:00
feat: add agent-sort selective install workflow
This commit is contained in:
Affaan Mustafa
215
.agents/skills/agent-sort/SKILL.md
Normal file
215
.agents/skills/agent-sort/SKILL.md
Normal file
@@ -0,0 +1,215 @@
|
||||
---
|
||||
name: agent-sort
|
||||
description: Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Agent Sort
|
||||
|
||||
Use this skill when a repo needs a project-specific ECC surface instead of the default full install.
|
||||
|
||||
The goal is not to guess what "feels useful." The goal is to classify ECC components with evidence from the actual codebase.
|
||||
|
||||
## When to Use
|
||||
|
||||
- A project only needs a subset of ECC and full installs are too noisy
|
||||
- The repo stack is clear, but nobody wants to hand-curate skills one by one
|
||||
- A team wants a repeatable install decision backed by grep evidence instead of opinion
|
||||
- You need to separate always-loaded daily workflow surfaces from searchable library/reference surfaces
|
||||
- A repo has drifted into the wrong language, rule, or hook set and needs cleanup
|
||||
|
||||
## Non-Negotiable Rules
|
||||
|
||||
- Use the current repository as the source of truth, not generic preferences
|
||||
- Every DAILY decision must cite concrete repo evidence
|
||||
- LIBRARY does not mean "delete"; it means "keep accessible without loading by default"
|
||||
- Do not install hooks, rules, or scripts that the current repo cannot use
|
||||
- Prefer ECC-native surfaces; do not introduce a second install system
|
||||
|
||||
## Outputs
|
||||
|
||||
Produce these artifacts in order:
|
||||
|
||||
1. DAILY inventory
|
||||
2. LIBRARY inventory
|
||||
3. install plan
|
||||
4. verification report
|
||||
5. optional `skill-library` router if the project wants one
|
||||
|
||||
## Classification Model
|
||||
|
||||
Use two buckets only:
|
||||
|
||||
- `DAILY`
|
||||
- should load every session for this repo
|
||||
- strongly matched to the repo's language, framework, workflow, or operator surface
|
||||
- `LIBRARY`
|
||||
- useful to retain, but not worth loading by default
|
||||
- should remain reachable through search, router skill, or selective manual use
|
||||
|
||||
## Evidence Sources
|
||||
|
||||
Use repo-local evidence before making any classification:
|
||||
|
||||
- file extensions
|
||||
- package managers and lockfiles
|
||||
- framework configs
|
||||
- CI and hook configs
|
||||
- build/test scripts
|
||||
- imports and dependency manifests
|
||||
- repo docs that explicitly describe the stack
|
||||
|
||||
Useful commands include:
|
||||
|
||||
```bash
|
||||
rg --files
|
||||
rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
|
||||
cat package.json
|
||||
cat pyproject.toml
|
||||
cat Cargo.toml
|
||||
cat pubspec.yaml
|
||||
cat go.mod
|
||||
```
|
||||
|
||||
## Parallel Review Passes
|
||||
|
||||
If parallel subagents are available, split the review into these passes:
|
||||
|
||||
1. Agents
|
||||
- classify `agents/*`
|
||||
2. Skills
|
||||
- classify `skills/*`
|
||||
3. Commands
|
||||
- classify `commands/*`
|
||||
4. Rules
|
||||
- classify `rules/*`
|
||||
5. Hooks and scripts
|
||||
- classify hook surfaces, MCP health checks, helper scripts, and OS compatibility
|
||||
6. Extras
|
||||
- classify contexts, examples, MCP configs, templates, and guidance docs
|
||||
|
||||
If subagents are not available, run the same passes sequentially.
|
||||
|
||||
## Core Workflow
|
||||
|
||||
### 1. Read the repo
|
||||
|
||||
Establish the real stack before classifying anything:
|
||||
|
||||
- languages in use
|
||||
- frameworks in use
|
||||
- primary package manager
|
||||
- test stack
|
||||
- lint/format stack
|
||||
- deployment/runtime surface
|
||||
- operator integrations already present
|
||||
|
||||
### 2. Build the evidence table
|
||||
|
||||
For every candidate surface, record:
|
||||
|
||||
- component path
|
||||
- component type
|
||||
- proposed bucket
|
||||
- repo evidence
|
||||
- short justification
|
||||
|
||||
Use this format:
|
||||
|
||||
```text
|
||||
skills/frontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | core frontend stack
|
||||
skills/django-patterns | skill | LIBRARY | no .py files, no pyproject.toml | not active in this repo
|
||||
rules/typescript/* | rules | DAILY | package.json + tsconfig.json | active TS repo
|
||||
rules/python/* | rules | LIBRARY | zero Python source files | keep accessible only
|
||||
```
|
||||
|
||||
### 3. Decide DAILY vs LIBRARY
|
||||
|
||||
Promote to `DAILY` when:
|
||||
|
||||
- the repo clearly uses the matching stack
|
||||
- the component is general enough to help every session
|
||||
- the repo already depends on the corresponding runtime or workflow
|
||||
|
||||
Demote to `LIBRARY` when:
|
||||
|
||||
- the component is off-stack
|
||||
- the repo might need it later, but not every day
|
||||
- it adds context overhead without immediate relevance
|
||||
|
||||
### 4. Build the install plan
|
||||
|
||||
Translate the classification into action:
|
||||
|
||||
- DAILY skills -> install or keep in `.claude/skills/`
|
||||
- DAILY commands -> keep as explicit shims only if still useful
|
||||
- DAILY rules -> install only matching language sets
|
||||
- DAILY hooks/scripts -> keep only compatible ones
|
||||
- LIBRARY surfaces -> keep accessible through search or `skill-library`
|
||||
|
||||
If the repo already uses selective installs, update that plan instead of creating another system.
|
||||
|
||||
### 5. Create the optional library router
|
||||
|
||||
If the project wants a searchable library surface, create:
|
||||
|
||||
- `.claude/skills/skill-library/SKILL.md`
|
||||
|
||||
That router should contain:
|
||||
|
||||
- a short explanation of DAILY vs LIBRARY
|
||||
- grouped trigger keywords
|
||||
- where the library references live
|
||||
|
||||
Do not duplicate every skill body inside the router.
|
||||
|
||||
### 6. Verify the result
|
||||
|
||||
After the plan is applied, verify:
|
||||
|
||||
- every DAILY file exists where expected
|
||||
- stale language rules were not left active
|
||||
- incompatible hooks were not installed
|
||||
- the resulting install actually matches the repo stack
|
||||
|
||||
Return a compact report with:
|
||||
|
||||
- DAILY count
|
||||
- LIBRARY count
|
||||
- removed stale surfaces
|
||||
- open questions
|
||||
|
||||
## Handoffs
|
||||
|
||||
If the next step is interactive installation or repair, hand off to:
|
||||
|
||||
- `configure-ecc`
|
||||
|
||||
If the next step is overlap cleanup or catalog review, hand off to:
|
||||
|
||||
- `skill-stocktake`
|
||||
|
||||
If the next step is broader context trimming, hand off to:
|
||||
|
||||
- `strategic-compact`
|
||||
|
||||
## Output Format
|
||||
|
||||
Return the result in this order:
|
||||
|
||||
```text
|
||||
STACK
|
||||
- language/framework/runtime summary
|
||||
|
||||
DAILY
|
||||
- always-loaded items with evidence
|
||||
|
||||
LIBRARY
|
||||
- searchable/reference items with evidence
|
||||
|
||||
INSTALL PLAN
|
||||
- what should be installed, removed, or routed
|
||||
|
||||
VERIFICATION
|
||||
- checks run and remaining gaps
|
||||
```
|
||||
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — Agent Instructions
|
||||
|
||||
This is a **production-ready AI coding plugin** providing 39 specialized agents, 178 skills, 72 commands, and automated hook workflows for software development.
|
||||
This is a **production-ready AI coding plugin** providing 39 specialized agents, 179 skills, 73 commands, and automated hook workflows for software development.
|
||||
|
||||
**Version:** 1.10.0
|
||||
|
||||
@@ -146,8 +146,8 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
|
||||
|
||||
```
|
||||
agents/ — 39 specialized subagents
|
||||
skills/ — 178 workflow skills and domain knowledge
|
||||
commands/ — 72 slash commands
|
||||
skills/ — 179 workflow skills and domain knowledge
|
||||
commands/ — 73 slash commands
|
||||
hooks/ — Trigger-based automations
|
||||
rules/ — Always-follow guidelines (common + per-language)
|
||||
scripts/ — Cross-platform Node.js utilities
|
||||
|
||||
10
README.md
10
README.md
@@ -236,7 +236,7 @@ For manual install instructions see the README in the `rules/` folder. When copy
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**That's it!** You now have access to 39 agents, 178 skills, and 72 legacy command shims.
|
||||
**That's it!** You now have access to 39 agents, 179 skills, and 73 legacy command shims.
|
||||
|
||||
### Multi-model commands require additional setup
|
||||
|
||||
@@ -1153,8 +1153,8 @@ The configuration is automatically detected from `.opencode/opencode.json`.
|
||||
| Feature | Claude Code | OpenCode | Status |
|
||||
|---------|-------------|----------|--------|
|
||||
| Agents | PASS: 39 agents | PASS: 12 agents | **Claude Code leads** |
|
||||
| Commands | PASS: 72 commands | PASS: 31 commands | **Claude Code leads** |
|
||||
| Skills | PASS: 178 skills | PASS: 37 skills | **Claude Code leads** |
|
||||
| Commands | PASS: 73 commands | PASS: 31 commands | **Claude Code leads** |
|
||||
| Skills | PASS: 179 skills | PASS: 37 skills | **Claude Code leads** |
|
||||
| Hooks | PASS: 8 event types | PASS: 11 events | **OpenCode has more!** |
|
||||
| Rules | PASS: 29 rules | PASS: 13 instructions | **Claude Code leads** |
|
||||
| MCP Servers | PASS: 14 servers | PASS: Full | **Full parity** |
|
||||
@@ -1262,8 +1262,8 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
|
||||
| Feature | Claude Code | Cursor IDE | Codex CLI | OpenCode |
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **Agents** | 39 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
|
||||
| **Commands** | 72 | Shared | Instruction-based | 31 |
|
||||
| **Skills** | 178 | Shared | 10 (native format) | 37 |
|
||||
| **Commands** | 73 | Shared | Instruction-based | 31 |
|
||||
| **Skills** | 179 | Shared | 10 (native format) | 37 |
|
||||
| **Hook Events** | 8 types | 15 types | None yet | 11 types |
|
||||
| **Hook Scripts** | 20+ scripts | 16 scripts (DRY adapter) | N/A | Plugin hooks |
|
||||
| **Rules** | 34 (common + lang) | 34 (YAML frontmatter) | Instruction-based | 13 instructions |
|
||||
|
||||
@@ -106,7 +106,7 @@ cp -r everything-claude-code/rules/perl ~/.claude/rules/
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**完成！** 你现在可以使用 39 个代理、178 个技能和 72 个命令。
|
||||
**完成！** 你现在可以使用 39 个代理、179 个技能和 73 个命令。
|
||||
|
||||
### multi-* 命令需要额外配置
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ Public ECC plugin repo for agents, skills, commands, hooks, rules, install surfa
|
||||
|
||||
- Default branch: `main`
|
||||
- Public release surface is aligned at `v1.10.0`
|
||||
- Public catalog truth is `39` agents, `72` commands, and `163` skills
|
||||
- Public catalog truth is `39` agents, `73` commands, and `179` skills
|
||||
- Public plugin slug is now `ecc`; legacy `everything-claude-code` install paths remain supported for compatibility
|
||||
- Release discussion: `#1272`
|
||||
- ECC 2.0 exists in-tree and builds, but it is still alpha rather than GA
|
||||
@@ -158,4 +158,5 @@ Keep this file detailed for only the current sprint, blockers, and next actions.
|
||||
- 2026-04-05: Continued `#1213` cleanup by removing stale references to the deleted `project-guidelines-example` skill from exported inventory/docs and marking `continuous-learning` v1 as a supported legacy path with an explicit handoff to `continuous-learning-v2`.
|
||||
- 2026-04-05: Removed the last orphaned localized `project-guidelines-example` docs from `docs/ko-KR` and `docs/zh-CN`. The template now lives only in `docs/examples/project-guidelines-template.md`, which matches the current repo surface and avoids shipping translated docs for a deleted skill.
|
||||
- 2026-04-05: Added `docs/HERMES-OPENCLAW-MIGRATION.md` as the current public migration guide for issue `#1051`. It reframes Hermes/OpenClaw as source systems to distill from, not the final runtime, and maps scheduler, dispatch, memory, skill, and service layers onto the ECC-native surfaces and ECC 2.0 backlog that already exist.
|
||||
- 2026-04-05: Landed `skills/agent-sort` and the legacy `/agent-sort` shim from issue `#916` as an ECC-native selective-install workflow. It classifies agents, skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using concrete repo evidence, then hands off installation changes to `configure-ecc` instead of inventing a parallel installer. Catalog truth is now `39` agents, `73` commands, and `179` skills.
|
||||
- 2026-04-05: Direct-ported the safe README-only `#1285` slice into `main` instead of merging the branch: added a small `Community Projects` section so downstream teams can link public work built on ECC without changing install, security, or runtime surfaces. Rejected `#1286` at review because it adds an external third-party GitHub Action (`hashgraph-online/codex-plugin-scanner`) that does not meet the current supply-chain policy.
|
||||
|
||||
23
commands/agent-sort.md
Normal file
23
commands/agent-sort.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
description: Legacy slash-entry shim for the agent-sort skill. Prefer the skill directly.
|
||||
---
|
||||
|
||||
# Agent Sort (Legacy Shim)
|
||||
|
||||
Use this only if you still invoke `/agent-sort`. The maintained workflow lives in `skills/agent-sort/SKILL.md`.
|
||||
|
||||
## Canonical Surface
|
||||
|
||||
- Prefer the `agent-sort` skill directly.
|
||||
- Keep this file only as a compatibility entry point.
|
||||
|
||||
## Arguments
|
||||
|
||||
`$ARGUMENTS`
|
||||
|
||||
## Delegation
|
||||
|
||||
Apply the `agent-sort` skill.
|
||||
- Classify ECC surfaces with concrete repo evidence.
|
||||
- Keep the result to DAILY vs LIBRARY.
|
||||
- If an install change is needed afterward, hand off to `configure-ecc` instead of re-implementing install logic here.
|
||||
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — 智能体指令
|
||||
|
||||
这是一个**生产就绪的 AI 编码插件**，提供 39 个专业代理、178 项技能、72 条命令以及自动化钩子工作流，用于软件开发。
|
||||
这是一个**生产就绪的 AI 编码插件**，提供 39 个专业代理、179 项技能、73 条命令以及自动化钩子工作流，用于软件开发。
|
||||
|
||||
**版本:** 1.10.0
|
||||
|
||||
@@ -147,8 +147,8 @@
|
||||
|
||||
```
|
||||
agents/ — 39 个专业子代理
|
||||
skills/ — 178 个工作流技能和领域知识
|
||||
commands/ — 72 个斜杠命令
|
||||
skills/ — 179 个工作流技能和领域知识
|
||||
commands/ — 73 个斜杠命令
|
||||
hooks/ — 基于触发的自动化
|
||||
rules/ — 始终遵循的指导方针（通用 + 每种语言）
|
||||
scripts/ — 跨平台 Node.js 实用工具
|
||||
|
||||
@@ -209,7 +209,7 @@ npx ecc-install typescript
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**搞定！** 你现在可以使用 39 个智能体、178 项技能和 72 个命令了。
|
||||
**搞定！** 你现在可以使用 39 个智能体、179 项技能和 73 个命令了。
|
||||
|
||||
***
|
||||
|
||||
@@ -1095,8 +1095,8 @@ opencode
|
||||
| 功能特性 | Claude Code | OpenCode | 状态 |
|
||||
|---------|-------------|----------|--------|
|
||||
| 智能体 | PASS: 39 个 | PASS: 12 个 | **Claude Code 领先** |
|
||||
| 命令 | PASS: 72 个 | PASS: 31 个 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 178 项 | PASS: 37 项 | **Claude Code 领先** |
|
||||
| 命令 | PASS: 73 个 | PASS: 31 个 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 179 项 | PASS: 37 项 | **Claude Code 领先** |
|
||||
| 钩子 | PASS: 8 种事件类型 | PASS: 11 种事件 | **OpenCode 更多！** |
|
||||
| 规则 | PASS: 29 条 | PASS: 13 条指令 | **Claude Code 领先** |
|
||||
| MCP 服务器 | PASS: 14 个 | PASS: 完整 | **完全对等** |
|
||||
@@ -1207,8 +1207,8 @@ ECC 是**第一个最大化利用每个主要 AI 编码工具的插件**。以
|
||||
| 功能特性 | Claude Code | Cursor IDE | Codex CLI | OpenCode |
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **智能体** | 39 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
|
||||
| **命令** | 72 | 共享 | 基于指令 | 31 |
|
||||
| **技能** | 178 | 共享 | 10 (原生格式) | 37 |
|
||||
| **命令** | 73 | 共享 | 基于指令 | 31 |
|
||||
| **技能** | 179 | 共享 | 10 (原生格式) | 37 |
|
||||
| **钩子事件** | 8 种类型 | 15 种类型 | 暂无 | 11 种类型 |
|
||||
| **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | N/A | 插件钩子 |
|
||||
| **规则** | 34 (通用 + 语言) | 34 (YAML 前页) | 基于指令 | 13 条指令 |
|
||||
|
||||
@@ -198,6 +198,7 @@
|
||||
"kind": "skills",
|
||||
"description": "Evaluation, TDD, verification, learning, and compaction skills.",
|
||||
"paths": [
|
||||
"skills/agent-sort",
|
||||
"skills/ai-regression-testing",
|
||||
"skills/configure-ecc",
|
||||
"skills/code-tour",
|
||||
|
||||
215
skills/agent-sort/SKILL.md
Normal file
215
skills/agent-sort/SKILL.md
Normal file
@@ -0,0 +1,215 @@
|
||||
---
|
||||
name: agent-sort
|
||||
description: Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Agent Sort
|
||||
|
||||
Use this skill when a repo needs a project-specific ECC surface instead of the default full install.
|
||||
|
||||
The goal is not to guess what "feels useful." The goal is to classify ECC components with evidence from the actual codebase.
|
||||
|
||||
## When to Use
|
||||
|
||||
- A project only needs a subset of ECC and full installs are too noisy
|
||||
- The repo stack is clear, but nobody wants to hand-curate skills one by one
|
||||
- A team wants a repeatable install decision backed by grep evidence instead of opinion
|
||||
- You need to separate always-loaded daily workflow surfaces from searchable library/reference surfaces
|
||||
- A repo has drifted into the wrong language, rule, or hook set and needs cleanup
|
||||
|
||||
## Non-Negotiable Rules
|
||||
|
||||
- Use the current repository as the source of truth, not generic preferences
|
||||
- Every DAILY decision must cite concrete repo evidence
|
||||
- LIBRARY does not mean "delete"; it means "keep accessible without loading by default"
|
||||
- Do not install hooks, rules, or scripts that the current repo cannot use
|
||||
- Prefer ECC-native surfaces; do not introduce a second install system
|
||||
|
||||
## Outputs
|
||||
|
||||
Produce these artifacts in order:
|
||||
|
||||
1. DAILY inventory
|
||||
2. LIBRARY inventory
|
||||
3. install plan
|
||||
4. verification report
|
||||
5. optional `skill-library` router if the project wants one
|
||||
|
||||
## Classification Model
|
||||
|
||||
Use two buckets only:
|
||||
|
||||
- `DAILY`
|
||||
- should load every session for this repo
|
||||
- strongly matched to the repo's language, framework, workflow, or operator surface
|
||||
- `LIBRARY`
|
||||
- useful to retain, but not worth loading by default
|
||||
- should remain reachable through search, router skill, or selective manual use
|
||||
|
||||
## Evidence Sources
|
||||
|
||||
Use repo-local evidence before making any classification:
|
||||
|
||||
- file extensions
|
||||
- package managers and lockfiles
|
||||
- framework configs
|
||||
- CI and hook configs
|
||||
- build/test scripts
|
||||
- imports and dependency manifests
|
||||
- repo docs that explicitly describe the stack
|
||||
|
||||
Useful commands include:
|
||||
|
||||
```bash
|
||||
rg --files
|
||||
rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
|
||||
cat package.json
|
||||
cat pyproject.toml
|
||||
cat Cargo.toml
|
||||
cat pubspec.yaml
|
||||
cat go.mod
|
||||
```
|
||||
|
||||
## Parallel Review Passes
|
||||
|
||||
If parallel subagents are available, split the review into these passes:
|
||||
|
||||
1. Agents
|
||||
- classify `agents/*`
|
||||
2. Skills
|
||||
- classify `skills/*`
|
||||
3. Commands
|
||||
- classify `commands/*`
|
||||
4. Rules
|
||||
- classify `rules/*`
|
||||
5. Hooks and scripts
|
||||
- classify hook surfaces, MCP health checks, helper scripts, and OS compatibility
|
||||
6. Extras
|
||||
- classify contexts, examples, MCP configs, templates, and guidance docs
|
||||
|
||||
If subagents are not available, run the same passes sequentially.
|
||||
|
||||
## Core Workflow
|
||||
|
||||
### 1. Read the repo
|
||||
|
||||
Establish the real stack before classifying anything:
|
||||
|
||||
- languages in use
|
||||
- frameworks in use
|
||||
- primary package manager
|
||||
- test stack
|
||||
- lint/format stack
|
||||
- deployment/runtime surface
|
||||
- operator integrations already present
|
||||
|
||||
### 2. Build the evidence table
|
||||
|
||||
For every candidate surface, record:
|
||||
|
||||
- component path
|
||||
- component type
|
||||
- proposed bucket
|
||||
- repo evidence
|
||||
- short justification
|
||||
|
||||
Use this format:
|
||||
|
||||
```text
|
||||
skills/frontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | core frontend stack
|
||||
skills/django-patterns | skill | LIBRARY | no .py files, no pyproject.toml | not active in this repo
|
||||
rules/typescript/* | rules | DAILY | package.json + tsconfig.json | active TS repo
|
||||
rules/python/* | rules | LIBRARY | zero Python source files | keep accessible only
|
||||
```
|
||||
|
||||
### 3. Decide DAILY vs LIBRARY
|
||||
|
||||
Promote to `DAILY` when:
|
||||
|
||||
- the repo clearly uses the matching stack
|
||||
- the component is general enough to help every session
|
||||
- the repo already depends on the corresponding runtime or workflow
|
||||
|
||||
Demote to `LIBRARY` when:
|
||||
|
||||
- the component is off-stack
|
||||
- the repo might need it later, but not every day
|
||||
- it adds context overhead without immediate relevance
|
||||
|
||||
### 4. Build the install plan
|
||||
|
||||
Translate the classification into action:
|
||||
|
||||
- DAILY skills -> install or keep in `.claude/skills/`
|
||||
- DAILY commands -> keep as explicit shims only if still useful
|
||||
- DAILY rules -> install only matching language sets
|
||||
- DAILY hooks/scripts -> keep only compatible ones
|
||||
- LIBRARY surfaces -> keep accessible through search or `skill-library`
|
||||
|
||||
If the repo already uses selective installs, update that plan instead of creating another system.
|
||||
|
||||
### 5. Create the optional library router
|
||||
|
||||
If the project wants a searchable library surface, create:
|
||||
|
||||
- `.claude/skills/skill-library/SKILL.md`
|
||||
|
||||
That router should contain:
|
||||
|
||||
- a short explanation of DAILY vs LIBRARY
|
||||
- grouped trigger keywords
|
||||
- where the library references live
|
||||
|
||||
Do not duplicate every skill body inside the router.
|
||||
|
||||
### 6. Verify the result
|
||||
|
||||
After the plan is applied, verify:
|
||||
|
||||
- every DAILY file exists where expected
|
||||
- stale language rules were not left active
|
||||
- incompatible hooks were not installed
|
||||
- the resulting install actually matches the repo stack
|
||||
|
||||
Return a compact report with:
|
||||
|
||||
- DAILY count
|
||||
- LIBRARY count
|
||||
- removed stale surfaces
|
||||
- open questions
|
||||
|
||||
## Handoffs
|
||||
|
||||
If the next step is interactive installation or repair, hand off to:
|
||||
|
||||
- `configure-ecc`
|
||||
|
||||
If the next step is overlap cleanup or catalog review, hand off to:
|
||||
|
||||
- `skill-stocktake`
|
||||
|
||||
If the next step is broader context trimming, hand off to:
|
||||
|
||||
- `strategic-compact`
|
||||
|
||||
## Output Format
|
||||
|
||||
Return the result in this order:
|
||||
|
||||
```text
|
||||
STACK
|
||||
- language/framework/runtime summary
|
||||
|
||||
DAILY
|
||||
- always-loaded items with evidence
|
||||
|
||||
LIBRARY
|
||||
- searchable/reference items with evidence
|
||||
|
||||
INSTALL PLAN
|
||||
- what should be installed, removed, or routed
|
||||
|
||||
VERIFICATION
|
||||
- checks run and remaining gaps
|
||||
```
|
||||
Reference in New Issue
Block a user