agent-sort

Name: agent-sort
Author: affaan-m

1.2kinstalls35kforks

How to install agent-sort?

affaan-m/ecc/agent-sort

$npx -y skills add affaan-m/ECC --skill agent-sort

Installs into the current project.

Summary

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 b

Files · 1

View on GitHub

SKILL.md

1	# Agent Sort
2
3	Use this skill when a repo needs a project-specific ECC surface instead of the default full install.
4
5	The goal is not to guess what "feels useful." The goal is to classify ECC components with evidence from the actual codebase.
6
7	## When to Use
8
9	- A project only needs a subset of ECC and full installs are too noisy
10	- The repo stack is clear, but nobody wants to hand-curate skills one by one
11	- A team wants a repeatable install decision backed by grep evidence instead of opinion
12	- You need to separate always-loaded daily workflow surfaces from searchable library/reference surfaces
13	- A repo has drifted into the wrong language, rule, or hook set and needs cleanup
14
15	## Non-Negotiable Rules
16
17	- Use the current repository as the source of truth, not generic preferences
18	- Every DAILY decision must cite concrete repo evidence
19	- LIBRARY does not mean "delete"; it means "keep accessible without loading by default"
20	- Do not install hooks, rules, or scripts that the current repo cannot use
21	- Prefer ECC-native surfaces; do not introduce a second install system
22
23	## Outputs
24
25	Produce these artifacts in order:
26
27	1. DAILY inventory
28	2. LIBRARY inventory
29	3. install plan
30	4. verification report
31	5. optional `skill-library` router if the project wants one
32
33	## Classification Model
34
35	Use two buckets only:
36
37	- `DAILY`
38	- should load every session for this repo
39	- strongly matched to the repo's language, framework, workflow, or operator surface
40	- `LIBRARY`
41	- useful to retain, but not worth loading by default
42	- should remain reachable through search, router skill, or selective manual use
43
44	## Evidence Sources
45
46	Use repo-local evidence before making any classification:
47
48	- file extensions
49	- package managers and lockfiles
50	- framework configs
51	- CI and hook configs
52	- build/test scripts
53	- imports and dependency manifests
54	- repo docs that explicitly describe the stack
55
56	Useful commands include:
57
58	```bash
59	rg --files
60	rg -n "typescript\|react\|next\|supabase\|django\|spring\|flutter\|swift"
61	cat package.json
62	cat pyproject.toml
63	cat Cargo.toml
64	cat pubspec.yaml
65	cat go.mod
66	```
67
68	## Parallel Review Passes
69
70	If parallel subagents are available, split the review into these passes:
71
72	1. Agents
73	- classify `agents/*`
74	2. Skills
75	- classify `skills/*`
76	3. Commands
77	- classify `commands/*`
78	4. Rules
79	- classify `rules/*`
80	5. Hooks and scripts
81	- classify hook surfaces, MCP health checks, helper scripts, and OS compatibility
82	6. Extras
83	- classify contexts, examples, MCP configs, templates, and guidance docs
84
85	If subagents are not available, run the same passes sequentially.
86
87	## Core Workflow
88
89	### 1. Read the repo
90
91	Establish the real stack before classifying anything:
92
93	- languages in use
94	- frameworks in use
95	- primary package manager
96	- test stack
97	- lint/format stack
98	- deployment/runtime surface
99	- operator integrations already present
100
101	### 2. Build the evidence table
102
103	For every candidate surface, record:
104
105	- component path
106	- component type
107	- proposed bucket
108	- repo evidence
109	- short justification
110
111	Use this format:
112
113	```text
114	skills/frontend-patterns \| skill \| DAILY \| 84 .tsx files, next.config.ts present \| core frontend stack
115	skills/django-patterns \| skill \| LIBRARY \| no .py files, no pyproject.toml \| not active in this repo
116	rules/typescript/* \| rules \| DAILY \| package.json + tsconfig.json \| active TS repo
117	rules/python/* \| rules \| LIBRARY \| zero Python source files \| keep accessible only
118	```
119
120	### 3. Decide DAILY vs LIBRARY
121
122	Promote to `DAILY` when:
123
124	- the repo clearly uses the matching stack
125	- the component is general enough to help every session
126	- the repo already depends on the corresponding runtime or workflow
127
128	Demote to `LIBRARY` when:
129
130	- the component is off-stack
131	- the repo might need it later, but not every day
132	- it adds context overhead without immediate relevance
133
134	### 4. Build the install plan
135
136	Translate the classification into action:
137
138	- DAILY skills -> install or keep in `.claude/skills/`
139	- DAILY commands -> keep as explicit shims only if still useful
140	- DAILY rules -> install only matching language sets
141	- DAILY hooks/scripts -> keep only compatible ones
142	- LIBRARY surfaces -> keep accessible through search or `skill-library`
143
144	If the repo already uses selective installs, update that plan instead of creating another system.
145
146	### 5. Create the optional library router
147
148	If the project wants a searchable library surface, create:
149
150	- `.claude/skills/skill-library/SKILL.md`
151
152	That router should contain:
153
154	- a short explanation of DAILY vs LIBRARY
155	- grouped trigger keywords
156	- where the library references live
157
158	Do not duplicate every skill body inside the router.
159
160	### 6. Verify the result
161
162	After th

People who liked this also viewed

6 picks

Type

agent-sort

1.2kinstalls35kforks

View on GitHub

How to install agent-sort?

affaan-m/ecc/agent-sort

$npx -y skills add affaan-m/ECC --skill agent-sort

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Agent Sort
2
3	Use this skill when a repo needs a project-specific ECC surface instead of the default full install.
4
5	The goal is not to guess what "feels useful." The goal is to classify ECC components with evidence from the actual codebase.
6
7	## When to Use
8
9	- A project only needs a subset of ECC and full installs are too noisy
10	- The repo stack is clear, but nobody wants to hand-curate skills one by one
11	- A team wants a repeatable install decision backed by grep evidence instead of opinion
12	- You need to separate always-loaded daily workflow surfaces from searchable library/reference surfaces
13	- A repo has drifted into the wrong language, rule, or hook set and needs cleanup
14
15	## Non-Negotiable Rules
16
17	- Use the current repository as the source of truth, not generic preferences
18	- Every DAILY decision must cite concrete repo evidence
19	- LIBRARY does not mean "delete"; it means "keep accessible without loading by default"
20	- Do not install hooks, rules, or scripts that the current repo cannot use
21	- Prefer ECC-native surfaces; do not introduce a second install system
22
23	## Outputs
24
25	Produce these artifacts in order:
26
27	1. DAILY inventory
28	2. LIBRARY inventory
29	3. install plan
30	4. verification report
31	5. optional `skill-library` router if the project wants one
32
33	## Classification Model
34
35	Use two buckets only:
36
37	- `DAILY`
38	- should load every session for this repo
39	- strongly matched to the repo's language, framework, workflow, or operator surface
40	- `LIBRARY`
41	- useful to retain, but not worth loading by default
42	- should remain reachable through search, router skill, or selective manual use
43
44	## Evidence Sources
45
46	Use repo-local evidence before making any classification:
47
48	- file extensions
49	- package managers and lockfiles
50	- framework configs
51	- CI and hook configs
52	- build/test scripts
53	- imports and dependency manifests
54	- repo docs that explicitly describe the stack
55
56	Useful commands include:
57
58	```bash
59	rg --files
60	rg -n "typescript\|react\|next\|supabase\|django\|spring\|flutter\|swift"
61	cat package.json
62	cat pyproject.toml
63	cat Cargo.toml
64	cat pubspec.yaml
65	cat go.mod
66	```
67
68	## Parallel Review Passes
69
70	If parallel subagents are available, split the review into these passes:
71
72	1. Agents
73	- classify `agents/*`
74	2. Skills
75	- classify `skills/*`
76	3. Commands
77	- classify `commands/*`
78	4. Rules
79	- classify `rules/*`
80	5. Hooks and scripts
81	- classify hook surfaces, MCP health checks, helper scripts, and OS compatibility
82	6. Extras
83	- classify contexts, examples, MCP configs, templates, and guidance docs
84
85	If subagents are not available, run the same passes sequentially.
86
87	## Core Workflow
88
89	### 1. Read the repo
90
91	Establish the real stack before classifying anything:
92
93	- languages in use
94	- frameworks in use
95	- primary package manager
96	- test stack
97	- lint/format stack
98	- deployment/runtime surface
99	- operator integrations already present
100
101	### 2. Build the evidence table
102
103	For every candidate surface, record:
104
105	- component path
106	- component type
107	- proposed bucket
108	- repo evidence
109	- short justification
110
111	Use this format:
112
113	```text
114	skills/frontend-patterns \| skill \| DAILY \| 84 .tsx files, next.config.ts present \| core frontend stack
115	skills/django-patterns \| skill \| LIBRARY \| no .py files, no pyproject.toml \| not active in this repo
116	rules/typescript/* \| rules \| DAILY \| package.json + tsconfig.json \| active TS repo
117	rules/python/* \| rules \| LIBRARY \| zero Python source files \| keep accessible only
118	```
119
120	### 3. Decide DAILY vs LIBRARY
121
122	Promote to `DAILY` when:
123
124	- the repo clearly uses the matching stack
125	- the component is general enough to help every session
126	- the repo already depends on the corresponding runtime or workflow
127
128	Demote to `LIBRARY` when:
129
130	- the component is off-stack
131	- the repo might need it later, but not every day
132	- it adds context overhead without immediate relevance
133
134	### 4. Build the install plan
135
136	Translate the classification into action:
137
138	- DAILY skills -> install or keep in `.claude/skills/`
139	- DAILY commands -> keep as explicit shims only if still useful
140	- DAILY rules -> install only matching language sets
141	- DAILY hooks/scripts -> keep only compatible ones
142	- LIBRARY surfaces -> keep accessible through search or `skill-library`
143
144	If the repo already uses selective installs, update that plan instead of creating another system.
145
146	### 5. Create the optional library router
147
148	If the project wants a searchable library surface, create:
149
150	- `.claude/skills/skill-library/SKILL.md`
151
152	That router should contain:
153
154	- a short explanation of DAILY vs LIBRARY
155	- grouped trigger keywords
156	- where the library references live
157
158	Do not duplicate every skill body inside the router.
159
160	### 6. Verify the result
161
162	After th

People who liked this also viewed

6 picks

Type