[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XC5PNEYW5317QGJ7WNMDAR":3,"skill-same:01M6XC5PNEYW5317QGJ7WNMDAR":67},{"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":17,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":13,"repositoryHtmlUrl":44,"repositoryHomepageUrl":6,"ownerHtmlUrl":45,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":46,"install":47,"resources":60},"01M6XC5PNEYW5317QGJ7WNMDAR","codebase-pattern-analyzer",null,"Analyze a reference codebase to discover and extract reusable architectural patterns. Produces structured pattern descriptions that can be turned into standalone skills. This is a meta-skill that bootstraps the skill evolution chain.","UF-gzj\u002Fopenspace-claude-evolution","UF-gzj","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272393507?v=4","01M6XBCZB755P01VVYGQWPYZY3","01M6XBCZFJA5AREA17WGETA3FW",0,"MIT","https:\u002F\u002Fgithub.com\u002FUF-gzj\u002Fopenspace-claude-evolution\u002Fblob\u002Fmain\u002Fshowcase\u002Fskills\u002Fcodebase-pattern-analyzer\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"codebase pattern analyzer","codebase","analyzer","pattern","structured","skill evolution","standalone","can","chain","discover","Meta","meta-skill","patterns","reusable","reference","extract","evolution","analyze","2026-11-10 10:12:30",false,"---\nname: codebase-pattern-analyzer\ndescription: Analyze a reference codebase to discover and extract reusable architectural patterns. Produces structured pattern descriptions that can be turned into standalone skills. This is a meta-skill that bootstraps the skill evolution chain.\n---\n\n# Codebase Pattern Analyzer\n\nSystematically analyze a reference codebase and extract reusable architectural patterns into structured descriptions. These descriptions become the raw material for new skills (via the `skill-template-generator` skill).\n\n## When to Use\n\n- You need to understand how a large codebase is structured before replicating it\n- You want to extract a specific pattern (component architecture, service layer, API proxy, etc.) from a reference project\n- You are bootstrapping a new project that should follow the conventions of an existing one\n\n## Step 1: Map the Directory Structure\n\nRead the top-level directory and identify the major code zones:\n\n```\nlist_dir \u003Cproject_root>\nlist_dir \u003Cproject_root>\u002Fsrc\n```\n\nClassify each directory into one of these roles:\n\n| Role | Typical Dirs | What to Look For |\n|------|-------------|------------------|\n| **Components** | `src\u002Fcomponents\u002F` | UI classes, base class inheritance, DOM manipulation |\n| **Services** | `src\u002Fservices\u002F` | Data fetching, API calls, circuit breakers, caching |\n| **Config** | `src\u002Fconfig\u002F` | Constants, panel definitions, API endpoints, feature flags |\n| **Styles** | `src\u002Fstyles\u002F` | CSS custom properties, theme variables, grid layout |\n| **Utils** | `src\u002Futils\u002F` | Helper functions, formatting, DOM utilities |\n| **API Layer** | `api\u002F`, `server\u002F` | Serverless functions, route handlers, CORS, proxy logic |\n| **Entry Point** | `src\u002Fmain.ts` | Bootstrap, panel instantiation, scheduler setup |\n\n## Step 2: Identify the Component Pattern\n\nFind the base component class (usually the most imported file in `components\u002F`):\n\n```\nread_file \u003Cproject_root>\u002Fsrc\u002Fcomponents\u002FPanel.ts\n```\n\nExtract these structural elements:\n\n1. **Constructor options interface** — what config each component accepts (id, title, className, etc.)\n2. **DOM structure** — how the element tree is built (header, content area, resize handles)\n3. **Lifecycle methods** — constructor, destroy, show\u002Fhide, refresh\n4. **State management** — loading\u002Ferror\u002Fcontent states, fetching guards\n5. **Data binding** — how data flows from service → render → DOM\n\nRecord the pattern as:\n```\nCOMPONENT PATTERN:\n  Base class: [name]\n  Options: [list of constructor params]\n  DOM tree: [element hierarchy]\n  States: [loading, error, content]\n  Lifecycle: [init → fetch → render → destroy]\n  Key methods: [getElement, showLoading, showError, setContent, refresh, destroy]\n```\n\n## Step 3: Identify the Service Layer Pattern\n\nExamine 2-3 service files to find the common structure:\n\n```\nread_file \u003Cproject_root>\u002Fsrc\u002Fservices\u002Fnews.ts\nread_file \u003Cproject_root>\u002Fsrc\u002Fservices\u002Fstock-market.ts\n```\n\nLook for:\n\n1. **Circuit breaker \u002F resilience** — retry logic, cooldown, cached fallback\n2. **Interface definitions** — typed data shapes returned by each service\n3. **Fetch pattern** — how HTTP calls are made (direct fetch, proxy, batching)\n4. **Caching strategy** — TTLs, stale-while-revalidate, in-memory cache\n5. **Error handling** — what happens on failure, default return values\n\nRecord as:\n```\nSERVICE PATTERN:\n  Resilience: [circuit breaker with N failures → cooldown]\n  Cache: [in-memory, TTL=Xms]\n  Fetch: [browser fetch → \u002Fapi\u002F... proxy → external API]\n  Error: [catch → recordFailure → return default]\n  Exports: [async functions, not class instances]\n```\n\n## Step 4: Identify the API Proxy Pattern\n\nRead the server-side proxy layer:\n\n```\nlist_dir \u003Cproject_root>\u002Fapi\u002F\nread_file \u003Cproject_root>\u002Fapi\u002F_cors.js\nread_file \u003Cproject_root>\u002Fapi\u002Fstocks.ts    # or similar endpoint\n```\n\nExtract:\n\n1. **File-per-endpoint structure** — one file per API domain\n2. **CORS handling** — origin allowlist, preflight response\n3. **API key isolation** — `process.env.*` usage, never exposed to frontend\n4. **Cache headers** — `Cache-Control`, `s-maxage`, `stale-while-revalidate`\n5. **Error wrapping** — structured JSON errors, never raw upstream responses\n6. **Input validation** — query parameter checks before upstream call\n\n## Step 5: Identify the Styling System\n\n```\nread_file \u003Cproject_root>\u002Fsrc\u002Fstyles\u002Fmain.css   # first 100 lines for CSS variables\n```\n\nExtract:\n\n1. **CSS custom properties** — color tokens, font stacks, spacing\n2. **Theme structure** — dark\u002Flight mode switch mechanism\n3. **Grid layout** — `grid-template-columns`, `auto-fill`, `minmax()` values\n4. **Component styles** — panel base styles, header, content, scrollbar\n5. **Semantic colors** — positive\u002Fnegative, severity levels, status indicators\n6. **Typography** — font family, sizes, letter-spacing, text-transform\n\n## Step 6: Identify the Scheduling \u002F Refresh Pattern\n\n```\nread_file \u003Cproject_root>\u002Fsrc\u002Fapp\u002Frefresh-scheduler.ts\n```\n\nExtract:\n\n1. **Registration API** — how panels register their refresh functions\n2. **Interval management** — per-panel configurable intervals\n3. **Visibility awareness** — pause when tab hidden, flush stale on return\n4. **In-flight guards** — prevent duplicate concurrent refreshes\n5. **Stagger logic** — avoid API burst when resuming\n\n## Step 7: Synthesize Into Pattern Descriptions\n\nFor each pattern discovered, produce a structured description:\n\n```markdown\n## Pattern: [Name]\n\n**Source file(s)**: [paths in reference codebase]\n**Category**: component | service | api | style | scheduler | utility\n\n### Structure\n[Key structural elements — interfaces, classes, functions]\n\n### Key Code\n[Minimal representative code snippet, 20-40 lines]\n\n### Conventions\n[Naming, file organization, import paths]\n\n### Dependencies\n[Other patterns this depends on]\n\n### Adaptation Notes\n[What must change when applying to a different project]\n```\n\n## Output\n\nThe final output should be a list of pattern descriptions, one per architectural concern. These become the input to the `skill-template-generator` skill, which turns each pattern into a standalone SKILL.md.\n\n## Tips\n\n- **Read broadly first, deeply second** — scan directory listings before reading individual files\n- **Follow imports** — if a component imports from `..\u002Fservices\u002F`, read that service next\n- **Count instances** — if 10+ components extend the same base class, that's a core pattern\n- **Note what's NOT used** — no framework (React, Vue) means vanilla DOM; no ORM means raw fetch\n- **Compare 2-3 examples** of the same pattern to distinguish the template from the instance-specific parts\n\n","# Codebase Pattern Analyzer\n\nSystematically analyze a reference codebase and extract reusable architectural patterns into structured descriptions. These descriptions become the raw material for new skills (via the `skill-template-generator` skill).\n\n## When to Use\n\n- You need to understand how a large codebase is structured before replicating it\n- You want to extract a specific pattern (component architecture, service layer, API proxy, etc.) from a reference project\n- You are bootstrapping a new project that should follow the conventions of an existing one\n\n## Step 1: Map the Directory Structure\n\nRead the top-level directory and identify the major code zones:\n\n```\nlist_dir \u003Cproject_root>\nlist_dir \u003Cproject_root>\u002Fsrc\n```\n\nClassify each directory into one of these roles:\n\n| Role | Typical Dirs | What to Look For |\n|------|-------------|------------------|\n| **Components** | `src\u002Fcomponents\u002F` | UI classes, base class inheritance, DOM manipulation |\n| **Services** | `src\u002Fservices\u002F` | Data fetching, API calls, circuit breakers, caching |\n| **Config** | `src\u002Fconfig\u002F` | Constants, panel definitions, API endpoints, feature flags |\n| **Styles** | `src\u002Fstyles\u002F` | CSS custom properties, theme variables, grid layout |\n| **Utils** | `src\u002Futils\u002F` | Helper functions, formatting, DOM utilities |\n| **API Layer** | `api\u002F`, `server\u002F` | Serverless functions, route handlers, CORS, proxy logic |\n| **Entry Point** | `src\u002Fmain.ts` | Bootstrap, panel instantiation, scheduler setup |\n\n## Step 2: Identify the Component Pattern\n\nFind the base component class (usually the most imported file in `components\u002F`):\n\n```\nread_file \u003Cproject_root>\u002Fsrc\u002Fcomponents\u002FPanel.ts\n```\n\nExtract these structural elements:\n\n1. **Constructor options interface** — what config each component accepts (id, title, className, etc.)\n2. **DOM structure** — how the element tree is built (header, content area, resize handles)\n3. **Lifecycle methods** — constructor, destroy, show\u002Fhide, refresh\n4. **State management** — loading\u002Ferror\u002Fcontent states, fetching guards\n5. **Data binding** — how data flows from service → render → DOM\n\nRecord the pattern as:\n```\nCOMPONENT PATTERN:\n  Base class: [name]\n  Options: [list of constructor params]\n  DOM tree: [element hierarchy]\n  States: [loading, error, content]\n  Lifecycle: [init → fetch → render → destroy]\n  Key methods: [getElement, showLoading, showError, setContent, refresh, destroy]\n```\n\n## Step 3: Identify the Service Layer Pattern\n\nExamine 2-3 service files to find the common structure:\n\n```\nread_file \u003Cproject_root>\u002Fsrc\u002Fservices\u002Fnews.ts\nread_file \u003Cproject_root>\u002Fsrc\u002Fservices\u002Fstock-market.ts\n```\n\nLook for:\n\n1. **Circuit breaker \u002F resilience** — retry logic, cooldown, cached fallback\n2. **Interface definitions** — typed data shapes returned by each service\n3. **Fetch pattern** — how HTTP calls are made (direct fetch, proxy, batching)\n4. **Caching strategy** — TTLs, stale-while-revalidate, in-memory cache\n5. **Error handling** — what happens on failure, default return values\n\nRecord as:\n```\nSERVICE PATTERN:\n  Resilience: [circuit breaker with N failures → cooldown]\n  Cache: [in-memory, TTL=Xms]\n  Fetch: [browser fetch → \u002Fapi\u002F... proxy → external API]\n  Error: [catch → recordFailure → return default]\n  Exports: [async functions, not class instances]\n```\n\n## Step 4: Identify the API Proxy Pattern\n\nRead the server-side proxy layer:\n\n```\nlist_dir \u003Cproject_root>\u002Fapi\u002F\nread_file \u003Cproject_root>\u002Fapi\u002F_cors.js\nread_file \u003Cproject_root>\u002Fapi\u002Fstocks.ts    # or similar endpoint\n```\n\nExtract:\n\n1. **File-per-endpoint structure** — one file per API domain\n2. **CORS handling** — origin allowlist, preflight response\n3. **API key isolation** — `process.env.*` usage, never exposed to frontend\n4. **Cache headers** — `Cache-Control`, `s-maxage`, `stale-while-revalidate`\n5. **Error wrapping** — structured JSON errors, never raw upstream responses\n6. **Input validation** — query parameter checks before upstream call\n\n## Step 5: Identify the Styling System\n\n```\nread_file \u003Cproject_root>\u002Fsrc\u002Fstyles\u002Fmain.css   # first 100 lines for CSS variables\n```\n\nExtract:\n\n1. **CSS custom properties** — color tokens, font stacks, spacing\n2. **Theme structure** — dark\u002Flight mode switch mechanism\n3. **Grid layout** — `grid-template-columns`, `auto-fill`, `minmax()` values\n4. **Component styles** — panel base styles, header, content, scrollbar\n5. **Semantic colors** — positive\u002Fnegative, severity levels, status indicators\n6. **Typography** — font family, sizes, letter-spacing, text-transform\n\n## Step 6: Identify the Scheduling \u002F Refresh Pattern\n\n```\nread_file \u003Cproject_root>\u002Fsrc\u002Fapp\u002Frefresh-scheduler.ts\n```\n\nExtract:\n\n1. **Registration API** — how panels register their refresh functions\n2. **Interval management** — per-panel configurable intervals\n3. **Visibility awareness** — pause when tab hidden, flush stale on return\n4. **In-flight guards** — prevent duplicate concurrent refreshes\n5. **Stagger logic** — avoid API burst when resuming\n\n## Step 7: Synthesize Into Pattern Descriptions\n\nFor each pattern discovered, produce a structured description:\n\n```markdown\n## Pattern: [Name]\n\n**Source file(s)**: [paths in reference codebase]\n**Category**: component | service | api | style | scheduler | utility\n\n### Structure\n[Key structural elements — interfaces, classes, functions]\n\n### Key Code\n[Minimal representative code snippet, 20-40 lines]\n\n### Conventions\n[Naming, file organization, import paths]\n\n### Dependencies\n[Other patterns this depends on]\n\n### Adaptation Notes\n[What must change when applying to a different project]\n```\n\n## Output\n\nThe final output should be a list of pattern descriptions, one per architectural concern. These become the input to the `skill-template-generator` skill, which turns each pattern into a standalone SKILL.md.\n\n## Tips\n\n- **Read broadly first, deeply second** — scan directory listings before reading individual files\n- **Follow imports** — if a component imports from `..\u002Fservices\u002F`, read that service next\n- **Count instances** — if 10+ components extend the same base class, that's a core pattern\n- **Note what's NOT used** — no framework (React, Vue) means vanilla DOM; no ORM means raw fetch\n- **Compare 2-3 examples** of the same pattern to distinguish the template from the instance-specific parts\n\n",{"name":5,"description":7},"main","0650921d63895de3997bc81f1ff1d0ac67032072","showcase\u002Fskills\u002Fcodebase-pattern-analyzer","https:\u002F\u002Fgithub.com\u002FUF-gzj\u002Fopenspace-claude-evolution","https:\u002F\u002Fgithub.com\u002FUF-gzj","2026-04-16 09:31:03",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add UF-gzj\u002Fopenspace-claude-evolution --skill codebase-pattern-analyzer",{"tool":53,"command":54},"bunx","bunx skills add UF-gzj\u002Fopenspace-claude-evolution --skill codebase-pattern-analyzer",{"tool":56,"command":57},"pnpm","pnpm dlx skills add UF-gzj\u002Fopenspace-claude-evolution --skill codebase-pattern-analyzer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FUF-gzj\u002Fopenspace-claude-evolution\u002Fblob\u002Fmain\u002Fshowcase\u002Fskills\u002Fcodebase-pattern-analyzer\u002FSKILL.md",true,[61],{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},".skill_id","OTHER","其他",39,"https:\u002F\u002Fgithub.com\u002FUF-gzj\u002Fopenspace-claude-evolution\u002Fblob\u002Fmain\u002Fshowcase\u002Fskills\u002Fcodebase-pattern-analyzer\u002F.skill_id",[68,93,110,119,147,163],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":36},"01M6XCCXD3NCM2YKR3WNGBASPC","write-special-chars-ts-check","Workaround for write_file failures caused by special characters (apostrophes, backticks, template literals) using a Python heredoc script, plus a reliable TypeScript type-checking step that filters output to only the newly-written files to avoid being misled by pre-existing errors.","https:\u002F\u002Fgithub.com\u002FUF-gzj\u002Fopenspace-claude-evolution\u002Fblob\u002Fmain\u002Fshowcase\u002Fskills\u002Fwrite-special-chars-ts-check\u002FSKILL.md",[],[75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92],"check","write","write special chars ts check","typescript","filters","characters","Existing","type-checking","for","errors","script","output","type","files","only","template","file","python",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":36},"01M6XCCT7E3J922Q345PBGSHPN","write-special-chars-readback","Workaround for write_file failures caused by special characters (apostrophes, backticks, template literals) using a Python heredoc script, with mandatory post-write verification via read_file and cleanup of \u002Ftmp helper scripts.","https:\u002F\u002Fgithub.com\u002FUF-gzj\u002Fopenspace-claude-evolution\u002Fblob\u002Fmain\u002Fshowcase\u002Fskills\u002Fwrite-special-chars-readback\u002FSKILL.md",[],[100,101,76,91,102,92,103,104,105,106,107,90,108,109,80,83,85],"readback","write special chars readback","helper","post","via","scripts","cleanup","read","verification","with",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":36},"01M6XCCMQX1R8B6FECWB3P63T7","write-special-chars-heredoc","Workaround for write_file failures caused by special characters (apostrophes, backticks, template literals) by using a Python heredoc script executed via shell.","https:\u002F\u002Fgithub.com\u002FUF-gzj\u002Fopenspace-claude-evolution\u002Fblob\u002Fmain\u002Fshowcase\u002Fskills\u002Fwrite-special-chars-heredoc\u002FSKILL.md",[],[117,76,80,118,85,104,90,91,92,83],"write special chars heredoc","shell",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":130,"publishedAt":36},"01M6XCCG41M994JJEX6VN52PEP","worldmonitor-reference","Curated architecture index of the WorldMonitor open-source dashboard. Reference for extracting patterns — vanilla TypeScript, Panel class hierarchy, service layer, CSS grid, API edge functions, refresh scheduler, and 60+ data source integrations.","https:\u002F\u002Fgithub.com\u002FUF-gzj\u002Fopenspace-claude-evolution\u002Fblob\u002Fmain\u002Fshowcase\u002Fskills\u002Fworldmonitor-reference\u002FSKILL.md",[125],{"categoryNo":126,"categoryName":127,"taxonomyType":128,"taxonomyTypeDesc":129},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[32,131,132,133,134,78,135,136,137,138,139,83,140,141,30,142,143,144,145,146],"worldmonitor","worldmonitor reference","architecture","dashboard","css","scheduler","layer","hierarchy","source","extracting","panel","edge functions","integrations","open","api","data",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":36},"01M6XCCCHWNKG2W4VH9E6A10HF","virtual-list","Implement efficient virtual scrolling for rendering large lists with DOM recycling, chunk-based rendering, and performance optimizations","https:\u002F\u002Fgithub.com\u002FUF-gzj\u002Fopenspace-claude-evolution\u002Fblob\u002Fmain\u002Fshowcase\u002Fskills\u002Fvirtual-list\u002FSKILL.md",[],[154,155,156,157,83,158,109,159,160,161,162],"virtual list","list","virtual","chunk","dom","rendering","recycling","implement","performance",{"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":169,"publishedAt":36},"01M6XCC7X8PKMR2DEW91XGHYSV","verify-directory-structure","Diagnose and resolve file access issues by first verifying the directory structure.","https:\u002F\u002Fgithub.com\u002FUF-gzj\u002Fopenspace-claude-evolution\u002Fblob\u002Fmain\u002Fshowcase\u002Fskills\u002Fverify-directory-structure\u002FSKILL.md",[],[170,171,172,173,174,175,91,176,177,178],"directory","verify directory structure","structure","verify","access","first","issues","diagnose","file access"]