[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JCMYNETEHH3JX1804440PN":3,"skill-same:01M6JCMYNETEHH3JX1804440PN":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6JCMYNETEHH3JX1804440PN","agent-sort",null,"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.","S3YED\u002Fappie-kit","S3YED","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F62743867?v=4","01M6JBKBRRVP6KMS0VWZ27T3R6","01M6JBKBX0KG30284PW1DBYJT1",14,"MIT","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fecc\u002Fagent-sort\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"sort","agent sort","hooks","for","loading","sorting","full","commands","project","build","daily","review","evidence","use","install","repo","Rules","parallel","plan","library","2026-11-10 10:12:30",false,"---\nname: agent-sort\ndescription: 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.\norigin: ECC\n---\n\n# Agent Sort\n\nUse this skill when a repo needs a project-specific ECC surface instead of the default full install.\n\nThe goal is not to guess what \"feels useful.\" The goal is to classify ECC components with evidence from the actual codebase.\n\n## When to Use\n\n- A project only needs a subset of ECC and full installs are too noisy\n- The repo stack is clear, but nobody wants to hand-curate skills one by one\n- A team wants a repeatable install decision backed by grep evidence instead of opinion\n- You need to separate always-loaded daily workflow surfaces from searchable library\u002Freference surfaces\n- A repo has drifted into the wrong language, rule, or hook set and needs cleanup\n\n## Non-Negotiable Rules\n\n- Use the current repository as the source of truth, not generic preferences\n- Every DAILY decision must cite concrete repo evidence\n- LIBRARY does not mean \"delete\"; it means \"keep accessible without loading by default\"\n- Do not install hooks, rules, or scripts that the current repo cannot use\n- Prefer ECC-native surfaces; do not introduce a second install system\n\n## Outputs\n\nProduce these artifacts in order:\n\n1. DAILY inventory\n2. LIBRARY inventory\n3. install plan\n4. verification report\n5. optional `skill-library` router if the project wants one\n\n## Classification Model\n\nUse two buckets only:\n\n- `DAILY`\n  - should load every session for this repo\n  - strongly matched to the repo's language, framework, workflow, or operator surface\n- `LIBRARY`\n  - useful to retain, but not worth loading by default\n  - should remain reachable through search, router skill, or selective manual use\n\n## Evidence Sources\n\nUse repo-local evidence before making any classification:\n\n- file extensions\n- package managers and lockfiles\n- framework configs\n- CI and hook configs\n- build\u002Ftest scripts\n- imports and dependency manifests\n- repo docs that explicitly describe the stack\n\nUseful commands include:\n\n```bash\nrg --files\nrg -n \"typescript|react|next|supabase|django|spring|flutter|swift\"\ncat package.json\ncat pyproject.toml\ncat Cargo.toml\ncat pubspec.yaml\ncat go.mod\n```\n\n## Parallel Review Passes\n\nIf parallel subagents are available, split the review into these passes:\n\n1. Agents\n   - classify `agents\u002F*`\n2. Skills\n   - classify `skills\u002F*`\n3. Commands\n   - classify `commands\u002F*`\n4. Rules\n   - classify `rules\u002F*`\n5. Hooks and scripts\n   - classify hook surfaces, MCP health checks, helper scripts, and OS compatibility\n6. Extras\n   - classify contexts, examples, MCP configs, templates, and guidance docs\n\nIf subagents are not available, run the same passes sequentially.\n\n## Core Workflow\n\n### 1. Read the repo\n\nEstablish the real stack before classifying anything:\n\n- languages in use\n- frameworks in use\n- primary package manager\n- test stack\n- lint\u002Fformat stack\n- deployment\u002Fruntime surface\n- operator integrations already present\n\n### 2. Build the evidence table\n\nFor every candidate surface, record:\n\n- component path\n- component type\n- proposed bucket\n- repo evidence\n- short justification\n\nUse this format:\n\n```text\nskills\u002Ffrontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | core frontend stack\nskills\u002Fdjango-patterns   | skill | LIBRARY | no .py files, no pyproject.toml       | not active in this repo\nrules\u002Ftypescript\u002F*       | rules | DAILY | package.json + tsconfig.json            | active TS repo\nrules\u002Fpython\u002F*           | rules | LIBRARY | zero Python source files             | keep accessible only\n```\n\n### 3. Decide DAILY vs LIBRARY\n\nPromote to `DAILY` when:\n\n- the repo clearly uses the matching stack\n- the component is general enough to help every session\n- the repo already depends on the corresponding runtime or workflow\n\nDemote to `LIBRARY` when:\n\n- the component is off-stack\n- the repo might need it later, but not every day\n- it adds context overhead without immediate relevance\n\n### 4. Build the install plan\n\nTranslate the classification into action:\n\n- DAILY skills -> install or keep in `.claude\u002Fskills\u002F`\n- DAILY commands -> keep as explicit shims only if still useful\n- DAILY rules -> install only matching language sets\n- DAILY hooks\u002Fscripts -> keep only compatible ones\n- LIBRARY surfaces -> keep accessible through search or `skill-library`\n\nIf the repo already uses selective installs, update that plan instead of creating another system.\n\n### 5. Create the optional library router\n\nIf the project wants a searchable library surface, create:\n\n- `.claude\u002Fskills\u002Fskill-library\u002FSKILL.md`\n\nThat router should contain:\n\n- a short explanation of DAILY vs LIBRARY\n- grouped trigger keywords\n- where the library references live\n\nDo not duplicate every skill body inside the router.\n\n### 6. Verify the result\n\nAfter the plan is applied, verify:\n\n- every DAILY file exists where expected\n- stale language rules were not left active\n- incompatible hooks were not installed\n- the resulting install actually matches the repo stack\n\nReturn a compact report with:\n\n- DAILY count\n- LIBRARY count\n- removed stale surfaces\n- open questions\n\n## Handoffs\n\nIf the next step is interactive installation or repair, hand off to:\n\n- `configure-ecc`\n\nIf the next step is overlap cleanup or catalog review, hand off to:\n\n- `skill-stocktake`\n\nIf the next step is broader context trimming, hand off to:\n\n- `strategic-compact`\n\n## Output Format\n\nReturn the result in this order:\n\n```text\nSTACK\n- language\u002Fframework\u002Fruntime summary\n\nDAILY\n- always-loaded items with evidence\n\nLIBRARY\n- searchable\u002Freference items with evidence\n\nINSTALL PLAN\n- what should be installed, removed, or routed\n\nVERIFICATION\n- checks run and remaining gaps\n```\n","# Agent Sort\n\nUse this skill when a repo needs a project-specific ECC surface instead of the default full install.\n\nThe goal is not to guess what \"feels useful.\" The goal is to classify ECC components with evidence from the actual codebase.\n\n## When to Use\n\n- A project only needs a subset of ECC and full installs are too noisy\n- The repo stack is clear, but nobody wants to hand-curate skills one by one\n- A team wants a repeatable install decision backed by grep evidence instead of opinion\n- You need to separate always-loaded daily workflow surfaces from searchable library\u002Freference surfaces\n- A repo has drifted into the wrong language, rule, or hook set and needs cleanup\n\n## Non-Negotiable Rules\n\n- Use the current repository as the source of truth, not generic preferences\n- Every DAILY decision must cite concrete repo evidence\n- LIBRARY does not mean \"delete\"; it means \"keep accessible without loading by default\"\n- Do not install hooks, rules, or scripts that the current repo cannot use\n- Prefer ECC-native surfaces; do not introduce a second install system\n\n## Outputs\n\nProduce these artifacts in order:\n\n1. DAILY inventory\n2. LIBRARY inventory\n3. install plan\n4. verification report\n5. optional `skill-library` router if the project wants one\n\n## Classification Model\n\nUse two buckets only:\n\n- `DAILY`\n  - should load every session for this repo\n  - strongly matched to the repo's language, framework, workflow, or operator surface\n- `LIBRARY`\n  - useful to retain, but not worth loading by default\n  - should remain reachable through search, router skill, or selective manual use\n\n## Evidence Sources\n\nUse repo-local evidence before making any classification:\n\n- file extensions\n- package managers and lockfiles\n- framework configs\n- CI and hook configs\n- build\u002Ftest scripts\n- imports and dependency manifests\n- repo docs that explicitly describe the stack\n\nUseful commands include:\n\n```bash\nrg --files\nrg -n \"typescript|react|next|supabase|django|spring|flutter|swift\"\ncat package.json\ncat pyproject.toml\ncat Cargo.toml\ncat pubspec.yaml\ncat go.mod\n```\n\n## Parallel Review Passes\n\nIf parallel subagents are available, split the review into these passes:\n\n1. Agents\n   - classify `agents\u002F*`\n2. Skills\n   - classify `skills\u002F*`\n3. Commands\n   - classify `commands\u002F*`\n4. Rules\n   - classify `rules\u002F*`\n5. Hooks and scripts\n   - classify hook surfaces, MCP health checks, helper scripts, and OS compatibility\n6. Extras\n   - classify contexts, examples, MCP configs, templates, and guidance docs\n\nIf subagents are not available, run the same passes sequentially.\n\n## Core Workflow\n\n### 1. Read the repo\n\nEstablish the real stack before classifying anything:\n\n- languages in use\n- frameworks in use\n- primary package manager\n- test stack\n- lint\u002Fformat stack\n- deployment\u002Fruntime surface\n- operator integrations already present\n\n### 2. Build the evidence table\n\nFor every candidate surface, record:\n\n- component path\n- component type\n- proposed bucket\n- repo evidence\n- short justification\n\nUse this format:\n\n```text\nskills\u002Ffrontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | core frontend stack\nskills\u002Fdjango-patterns   | skill | LIBRARY | no .py files, no pyproject.toml       | not active in this repo\nrules\u002Ftypescript\u002F*       | rules | DAILY | package.json + tsconfig.json            | active TS repo\nrules\u002Fpython\u002F*           | rules | LIBRARY | zero Python source files             | keep accessible only\n```\n\n### 3. Decide DAILY vs LIBRARY\n\nPromote to `DAILY` when:\n\n- the repo clearly uses the matching stack\n- the component is general enough to help every session\n- the repo already depends on the corresponding runtime or workflow\n\nDemote to `LIBRARY` when:\n\n- the component is off-stack\n- the repo might need it later, but not every day\n- it adds context overhead without immediate relevance\n\n### 4. Build the install plan\n\nTranslate the classification into action:\n\n- DAILY skills -> install or keep in `.claude\u002Fskills\u002F`\n- DAILY commands -> keep as explicit shims only if still useful\n- DAILY rules -> install only matching language sets\n- DAILY hooks\u002Fscripts -> keep only compatible ones\n- LIBRARY surfaces -> keep accessible through search or `skill-library`\n\nIf the repo already uses selective installs, update that plan instead of creating another system.\n\n### 5. Create the optional library router\n\nIf the project wants a searchable library surface, create:\n\n- `.claude\u002Fskills\u002Fskill-library\u002FSKILL.md`\n\nThat router should contain:\n\n- a short explanation of DAILY vs LIBRARY\n- grouped trigger keywords\n- where the library references live\n\nDo not duplicate every skill body inside the router.\n\n### 6. Verify the result\n\nAfter the plan is applied, verify:\n\n- every DAILY file exists where expected\n- stale language rules were not left active\n- incompatible hooks were not installed\n- the resulting install actually matches the repo stack\n\nReturn a compact report with:\n\n- DAILY count\n- LIBRARY count\n- removed stale surfaces\n- open questions\n\n## Handoffs\n\nIf the next step is interactive installation or repair, hand off to:\n\n- `configure-ecc`\n\nIf the next step is overlap cleanup or catalog review, hand off to:\n\n- `skill-stocktake`\n\nIf the next step is broader context trimming, hand off to:\n\n- `strategic-compact`\n\n## Output Format\n\nReturn the result in this order:\n\n```text\nSTACK\n- language\u002Fframework\u002Fruntime summary\n\nDAILY\n- always-loaded items with evidence\n\nLIBRARY\n- searchable\u002Freference items with evidence\n\nINSTALL PLAN\n- what should be installed, removed, or routed\n\nVERIFICATION\n- checks run and remaining gaps\n```\n",{"name":5,"origin":48,"description":7},"ECC","master","8ec37df6d71fb664ea19d32c079e7d3ff931a8e0","skills\u002Fecc\u002Fagent-sort",3,"https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit","https:\u002F\u002Fweblyfe.ai","https:\u002F\u002Fgithub.com\u002FS3YED","2026-08-27 01:54:02",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add S3YED\u002Fappie-kit --skill agent-sort",{"tool":63,"command":64},"bunx","bunx skills add S3YED\u002Fappie-kit --skill agent-sort",{"tool":66,"command":67},"pnpm","pnpm dlx skills add S3YED\u002Fappie-kit --skill agent-sort","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fecc\u002Fagent-sort\u002FSKILL.md",true,[],[72,104,139,163,194,217],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":85,"publishedAt":43},"01M6JFD4M6N4DSGC7TXEJ5R3J2","ai-music","AI music generation and audio tools: HeartMuLa lyrics-to-music generation, songwriting craft (+ Suno prompts), and audio spectrogram\u002Ffeature visualization.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fwethlete\u002Fai-music\u002FSKILL.md",[78,81,84],{"categoryNo":79,"categoryName":80,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":82,"categoryName":83,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103],"music","ai music","humanizer","visualization","Tools","Audio","hermes","hermes agent","songwriting","suno","lyrics","prompts","heartmula","craft","generation","feature","ai music generation","music generation",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":118,"publishedAt":43},"01M6JFCZE4XNFQFMNZDHKHT5V5","agentic-webdesign-design-system-ingestion","Use v0 Design Systems 2.0, Bolt Design System Agents, or Lovable to generate production UI from a client's real design system components — not generic Tailwind. Use when building a client website where brand consistency matters.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fweb-design\u002Fagentic-webdesign-design-system-ingestion\u002FSKILL.md",[110,113],{"categoryNo":111,"categoryName":112,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138],"design","agentic","design system","system","ingestion","webdesign","agentic webdesign design system ingestion","components","generate","design systems","website","ui","Tailwind","bolt","lovable","v0","design-system","wed","design system components","appie",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":147,"publishedAt":43},"01M6JFCVPX3913CFAS6QQJ33ZB","agentic-webdesign-agent-elements","Use 21st.dev Agent Elements — 25 shadcn\u002Fui components purpose-built for AI agent UIs. Tool cards (Bash, Edit, Search, Plan, Subagent, MCP), chat, input, streaming. Open source, shadcn-registry install, no runtime lock-in.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fweb-design\u002Fagentic-webdesign-agent-elements\u002FSKILL.md",[145,146],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},[120,148,124,149,150,151,126,152,153,154,155,156,157,41,158,159,37,160,161,162],"elements","agentic webdesign agent elements","MCP","ai agent","registry","search","streaming","open source","open","Bash","subagent","edit","input","lock","source",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":173,"publishedAt":43},"01M6JFCQC7H65M9QJ6TRE71BS1","vercel-deployment","Deploy static sites and frontends to Vercel — handles both CLI and REST API paths, including the CLI token sanitization workaround.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Fvercel-deployment\u002FSKILL.md",[169,172],{"categoryNo":170,"categoryName":171,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193],"deployment","vercel deployment","vercel","macos","cli","linux","windows","deploy","vercel deploy","REST","api","site","deploy to vercel","token","rest api","host","sites","paths","sanitization","static site",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":201,"publishedAt":43},"01M6JFCM4SMTXBM5A01BK2YQG1","software-quality-workflows","Umbrella workflow for TDD, debugging, code simplification, spikes, pre-commit review, and debugger-assisted investigation.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Fsoftware-quality-workflows\u002FSKILL.md",[200],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[202,203,204,205,34,206,207,208,209,210,211,212,213,214,215,216,26],"workflows","quality","software","software quality workflows","tdd","workflow","commit","debugging","code","debugger","pre-commit","investigation","code simplification","user","simplification",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":230,"publishedAt":43},"01M6JFCGD0M6CEATY01W7YN6DB","react-component-refactoring","Safely refactor large React components into smaller, maintainable pieces using proven patterns","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Freact-component-refactoring\u002FSKILL.md",[223,226,229],{"categoryNo":224,"categoryName":225,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":227,"categoryName":228,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[231,232,233,234,235,236,237,238,177,239,240,126,241,180,242,210,243,244,245,246],"react","component","refactoring","component refactoring","react component","react component refactoring","frontend","writing","safe","typescript","react components","modular","refactor","simplify","patterns","test-driven-development"]