[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JD2CJ3P694B4RT2FBTWX78":3,"skill-same:01M6JD2CJ3P694B4RT2FBTWX78":65},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6JD2CJ3P694B4RT2FBTWX78","homelab-network-readiness",null,"Readiness checklist for homelab VLAN segmentation, local DNS filtering, and WireGuard-style remote access before changing router, firewall, DHCP, or VPN configuration.","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\u002Fhomelab-network-readiness\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"homelab network readiness","network","readiness","homelab","community","for","dhcp","remote","style","vpn","local","readiness checklist","router","filtering","access","segmentation","wireguard","firewall","vlan","dns","2026-11-10 10:12:30",false,"---\nname: homelab-network-readiness\ndescription: Readiness checklist for homelab VLAN segmentation, local DNS filtering, and WireGuard-style remote access before changing router, firewall, DHCP, or VPN configuration.\norigin: community\n---\n\n# Homelab Network Readiness\n\nUse this skill before changing a home or small-lab network that mixes VLANs,\nPi-hole or another local DNS resolver, firewall rules, and remote VPN access.\n\nThis is a planning and review skill. Do not turn it into copy-paste router,\nfirewall, or VPN configuration unless the target platform, current topology,\nrollback path, console access, and maintenance window are all known.\n\n## When to Use\n\n- Preparing to split a flat network into trusted, IoT, guest, server, or\n  management VLANs.\n- Moving DHCP clients to Pi-hole, AdGuard Home, Unbound, or another local DNS\n  resolver.\n- Adding WireGuard, Tailscale, ZeroTier, OpenVPN, or router-native VPN access.\n- Reviewing whether a homelab change can lock the operator out of the gateway,\n  switch, access point, DNS server, or VPN server.\n- Turning an informal home-network idea into a staged migration plan with\n  validation evidence.\n\n## Safety Rules\n\n- Keep the first answer read-only: inventory, risks, staged plan, validation,\n  and rollback.\n- Do not expose gateway admin panels, DNS resolvers, SSH, NAS consoles, or VPN\n  management UIs directly to the public internet.\n- Do not provide firewall, NAT, VLAN, DHCP, or VPN commands without a confirmed\n  platform and a rollback procedure.\n- Require out-of-band or same-room console access before changing management\n  VLANs, trunk ports, firewall default policies, or DHCP\u002FDNS settings.\n- Keep a working path back to the internet before pointing the whole network at\n  a new DNS resolver or VPN route.\n- Treat IoT, guest, camera, and lab-server networks as different trust zones\n  until the operator explicitly chooses otherwise.\n\n## Required Inventory\n\nCollect this before giving implementation steps:\n\n| Area | Questions |\n| --- | --- |\n| Internet edge | What is the modem or ONT? Is the ISP router bridged or still routing? |\n| Gateway | What routes, firewalls, handles DHCP, and terminates VPNs? |\n| Switching | Which switch ports are uplinks, access ports, trunks, or unmanaged? |\n| Wi-Fi | Which SSIDs map to which networks, and are APs wired or mesh? |\n| Addressing | What subnets exist today, and which ranges conflict with VPN sites? |\n| DNS\u002FDHCP | Which service currently hands out leases and resolver addresses? |\n| Management | How will the operator reach the gateway, switch, and AP after changes? |\n| Recovery | What can be reverted locally if DNS, DHCP, VLANs, or VPN routes break? |\n\n## VLAN And Trust-Zone Plan\n\nStart with intent rather than vendor syntax.\n\n| Zone | Typical contents | Default policy |\n| --- | --- | --- |\n| Trusted | Laptops, phones, admin workstations | Can reach shared services and management only when needed |\n| Servers | NAS, Home Assistant, lab hosts, DNS resolver | Accepts narrow inbound flows from trusted clients |\n| IoT | TVs, smart plugs, cameras, speakers | Internet access plus explicit exceptions only |\n| Guest | Visitor devices | Internet-only, no LAN reachability |\n| Management | Gateway, switches, APs, controllers | Reachable only from trusted admin devices |\n| VPN | Remote clients | Same or narrower access than trusted clients |\n\nBefore recommending VLAN IDs or subnets, confirm:\n\n1. The gateway supports inter-VLAN routing and firewall rules.\n2. The switch supports the required tagged and untagged port behavior.\n3. The APs can map SSIDs to VLANs.\n4. The operator knows which port they are connected through during the change.\n5. The management network remains reachable after trunk and SSID changes.\n\n## DNS Filtering Readiness\n\nPi-hole or another local resolver should be introduced as a dependency, not as a\nsingle point of failure.\n\n1. Give the resolver a reserved address before using it in DHCP options.\n2. Confirm it can resolve public DNS and local `home.arpa` names.\n3. Keep the gateway or a second resolver available as a temporary fallback.\n4. Test one client or one VLAN before changing every DHCP scope.\n5. Document which networks may bypass filtering and why.\n6. Check that blocking rules do not break captive portals, work VPNs, firmware\n   updates, or medical\u002Fsecurity devices.\n\nUseful validation evidence:\n\n```text\nClient gets expected DHCP lease\nClient receives expected DNS resolver\nPublic DNS lookup succeeds\nLocal home.arpa lookup succeeds\nBlocked test domain is blocked only where intended\nGateway and DNS admin interfaces are not reachable from guest or IoT networks\n```\n\n## Remote Access Readiness\n\nFor WireGuard-style access, decide what the VPN is allowed to reach before\ngenerating keys or opening ports.\n\n| Mode | Use when | Risk notes |\n| --- | --- | --- |\n| Split tunnel to one subnet | Remote admin for NAS or lab hosts | Keep route list narrow |\n| Split tunnel to trusted services | Access selected apps by IP or DNS | Requires precise firewall rules |\n| Full tunnel | Untrusted networks or travel | More bandwidth and DNS responsibility |\n| Overlay VPN | Simpler remote access with identity controls | Still needs ACL review |\n\nDo not recommend port forwarding until the operator confirms:\n\n- The VPN endpoint is patched and actively maintained.\n- The forwarded port goes only to the VPN service, not an admin UI.\n- Dynamic DNS, public IP behavior, and ISP CGNAT status are understood.\n- Peer keys can be revoked without rebuilding the whole network.\n- Logs or connection status can verify who connected and when.\n\n## Change Sequence\n\nPrefer small, reversible changes:\n\n1. Snapshot the current topology, IP plan, DHCP settings, DNS settings, and\n   firewall rules.\n2. Reserve infrastructure addresses for gateway, DNS, controller, APs, NAS, and\n   VPN endpoint.\n3. Create the new zone or VLAN without moving critical devices.\n4. Move one test client and validate DHCP, DNS, routing, internet, and block\n   behavior.\n5. Add narrow firewall exceptions for required flows.\n6. Move one low-risk device group.\n7. Add VPN access with the narrowest route and firewall policy that satisfies\n   the use case.\n8. Document final state, known exceptions, and rollback commands or UI steps.\n\n## Review Checklist\n\n- Each network has a reason to exist and a clear trust boundary.\n- No management interface is reachable from guest, IoT, or the public internet.\n- DNS failure does not take down the operator's ability to recover locally.\n- DHCP scope changes were tested on one client before broad rollout.\n- VPN clients receive only the routes and DNS settings they need.\n- Firewall rules are default-deny between zones, with named exceptions.\n- The operator can still reach gateway, switch, AP, DNS, and VPN admin surfaces.\n- Rollback is documented in the same vocabulary as the chosen platform UI or\n  CLI.\n\n## Anti-Patterns\n\n- Segmenting networks before knowing which switch ports and SSIDs carry which\n  VLANs.\n- Moving the admin workstation off the only reachable management network.\n- Pointing all DHCP scopes at a Pi-hole before testing fallback DNS.\n- Publishing NAS, DNS, router, or hypervisor management directly to the\n  internet.\n- Treating VPN access as equivalent to full trusted-LAN access.\n- Adding allow-all firewall rules temporarily and forgetting to remove them.\n- Copying commands from another vendor or firmware version without checking the\n  exact platform syntax.\n\n## See Also\n\n- Skill: `homelab-network-setup`\n- Skill: `network-config-validation`\n- Skill: `network-interface-health`\n","# Homelab Network Readiness\n\nUse this skill before changing a home or small-lab network that mixes VLANs,\nPi-hole or another local DNS resolver, firewall rules, and remote VPN access.\n\nThis is a planning and review skill. Do not turn it into copy-paste router,\nfirewall, or VPN configuration unless the target platform, current topology,\nrollback path, console access, and maintenance window are all known.\n\n## When to Use\n\n- Preparing to split a flat network into trusted, IoT, guest, server, or\n  management VLANs.\n- Moving DHCP clients to Pi-hole, AdGuard Home, Unbound, or another local DNS\n  resolver.\n- Adding WireGuard, Tailscale, ZeroTier, OpenVPN, or router-native VPN access.\n- Reviewing whether a homelab change can lock the operator out of the gateway,\n  switch, access point, DNS server, or VPN server.\n- Turning an informal home-network idea into a staged migration plan with\n  validation evidence.\n\n## Safety Rules\n\n- Keep the first answer read-only: inventory, risks, staged plan, validation,\n  and rollback.\n- Do not expose gateway admin panels, DNS resolvers, SSH, NAS consoles, or VPN\n  management UIs directly to the public internet.\n- Do not provide firewall, NAT, VLAN, DHCP, or VPN commands without a confirmed\n  platform and a rollback procedure.\n- Require out-of-band or same-room console access before changing management\n  VLANs, trunk ports, firewall default policies, or DHCP\u002FDNS settings.\n- Keep a working path back to the internet before pointing the whole network at\n  a new DNS resolver or VPN route.\n- Treat IoT, guest, camera, and lab-server networks as different trust zones\n  until the operator explicitly chooses otherwise.\n\n## Required Inventory\n\nCollect this before giving implementation steps:\n\n| Area | Questions |\n| --- | --- |\n| Internet edge | What is the modem or ONT? Is the ISP router bridged or still routing? |\n| Gateway | What routes, firewalls, handles DHCP, and terminates VPNs? |\n| Switching | Which switch ports are uplinks, access ports, trunks, or unmanaged? |\n| Wi-Fi | Which SSIDs map to which networks, and are APs wired or mesh? |\n| Addressing | What subnets exist today, and which ranges conflict with VPN sites? |\n| DNS\u002FDHCP | Which service currently hands out leases and resolver addresses? |\n| Management | How will the operator reach the gateway, switch, and AP after changes? |\n| Recovery | What can be reverted locally if DNS, DHCP, VLANs, or VPN routes break? |\n\n## VLAN And Trust-Zone Plan\n\nStart with intent rather than vendor syntax.\n\n| Zone | Typical contents | Default policy |\n| --- | --- | --- |\n| Trusted | Laptops, phones, admin workstations | Can reach shared services and management only when needed |\n| Servers | NAS, Home Assistant, lab hosts, DNS resolver | Accepts narrow inbound flows from trusted clients |\n| IoT | TVs, smart plugs, cameras, speakers | Internet access plus explicit exceptions only |\n| Guest | Visitor devices | Internet-only, no LAN reachability |\n| Management | Gateway, switches, APs, controllers | Reachable only from trusted admin devices |\n| VPN | Remote clients | Same or narrower access than trusted clients |\n\nBefore recommending VLAN IDs or subnets, confirm:\n\n1. The gateway supports inter-VLAN routing and firewall rules.\n2. The switch supports the required tagged and untagged port behavior.\n3. The APs can map SSIDs to VLANs.\n4. The operator knows which port they are connected through during the change.\n5. The management network remains reachable after trunk and SSID changes.\n\n## DNS Filtering Readiness\n\nPi-hole or another local resolver should be introduced as a dependency, not as a\nsingle point of failure.\n\n1. Give the resolver a reserved address before using it in DHCP options.\n2. Confirm it can resolve public DNS and local `home.arpa` names.\n3. Keep the gateway or a second resolver available as a temporary fallback.\n4. Test one client or one VLAN before changing every DHCP scope.\n5. Document which networks may bypass filtering and why.\n6. Check that blocking rules do not break captive portals, work VPNs, firmware\n   updates, or medical\u002Fsecurity devices.\n\nUseful validation evidence:\n\n```text\nClient gets expected DHCP lease\nClient receives expected DNS resolver\nPublic DNS lookup succeeds\nLocal home.arpa lookup succeeds\nBlocked test domain is blocked only where intended\nGateway and DNS admin interfaces are not reachable from guest or IoT networks\n```\n\n## Remote Access Readiness\n\nFor WireGuard-style access, decide what the VPN is allowed to reach before\ngenerating keys or opening ports.\n\n| Mode | Use when | Risk notes |\n| --- | --- | --- |\n| Split tunnel to one subnet | Remote admin for NAS or lab hosts | Keep route list narrow |\n| Split tunnel to trusted services | Access selected apps by IP or DNS | Requires precise firewall rules |\n| Full tunnel | Untrusted networks or travel | More bandwidth and DNS responsibility |\n| Overlay VPN | Simpler remote access with identity controls | Still needs ACL review |\n\nDo not recommend port forwarding until the operator confirms:\n\n- The VPN endpoint is patched and actively maintained.\n- The forwarded port goes only to the VPN service, not an admin UI.\n- Dynamic DNS, public IP behavior, and ISP CGNAT status are understood.\n- Peer keys can be revoked without rebuilding the whole network.\n- Logs or connection status can verify who connected and when.\n\n## Change Sequence\n\nPrefer small, reversible changes:\n\n1. Snapshot the current topology, IP plan, DHCP settings, DNS settings, and\n   firewall rules.\n2. Reserve infrastructure addresses for gateway, DNS, controller, APs, NAS, and\n   VPN endpoint.\n3. Create the new zone or VLAN without moving critical devices.\n4. Move one test client and validate DHCP, DNS, routing, internet, and block\n   behavior.\n5. Add narrow firewall exceptions for required flows.\n6. Move one low-risk device group.\n7. Add VPN access with the narrowest route and firewall policy that satisfies\n   the use case.\n8. Document final state, known exceptions, and rollback commands or UI steps.\n\n## Review Checklist\n\n- Each network has a reason to exist and a clear trust boundary.\n- No management interface is reachable from guest, IoT, or the public internet.\n- DNS failure does not take down the operator's ability to recover locally.\n- DHCP scope changes were tested on one client before broad rollout.\n- VPN clients receive only the routes and DNS settings they need.\n- Firewall rules are default-deny between zones, with named exceptions.\n- The operator can still reach gateway, switch, AP, DNS, and VPN admin surfaces.\n- Rollback is documented in the same vocabulary as the chosen platform UI or\n  CLI.\n\n## Anti-Patterns\n\n- Segmenting networks before knowing which switch ports and SSIDs carry which\n  VLANs.\n- Moving the admin workstation off the only reachable management network.\n- Pointing all DHCP scopes at a Pi-hole before testing fallback DNS.\n- Publishing NAS, DNS, router, or hypervisor management directly to the\n  internet.\n- Treating VPN access as equivalent to full trusted-LAN access.\n- Adding allow-all firewall rules temporarily and forgetting to remove them.\n- Copying commands from another vendor or firmware version without checking the\n  exact platform syntax.\n\n## See Also\n\n- Skill: `homelab-network-setup`\n- Skill: `network-config-validation`\n- Skill: `network-interface-health`\n",{"name":5,"origin":22,"description":7},"master","8ec37df6d71fb664ea19d32c079e7d3ff931a8e0","skills\u002Fecc\u002Fhomelab-network-readiness",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":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add S3YED\u002Fappie-kit --skill homelab-network-readiness",{"tool":57,"command":58},"bunx","bunx skills add S3YED\u002Fappie-kit --skill homelab-network-readiness",{"tool":60,"command":61},"pnpm","pnpm dlx skills add S3YED\u002Fappie-kit --skill homelab-network-readiness","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fecc\u002Fhomelab-network-readiness\u002FSKILL.md",true,[],[66,102,137,163,194,218],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":83,"publishedAt":38},"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",[72,77,80],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000013","分析与可视化","SCENARIO","使用场景",{"categoryNo":78,"categoryName":79,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":81,"categoryName":82,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000023","Skill与智能体开发",[84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101],"music","ai music","humanizer","visualization","Tools","Audio","hermes","hermes agent","songwriting","suno","lyrics","prompts","heartmula","craft","generation","feature","ai music generation","music generation",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":116,"publishedAt":38},"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",[108,111],{"categoryNo":109,"categoryName":110,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136],"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":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":145,"publishedAt":38},"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",[143,144],{"categoryNo":81,"categoryName":82,"taxonomyType":75,"taxonomyTypeDesc":76},{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},[118,146,122,147,148,149,124,150,151,152,153,154,155,156,157,158,159,160,161,162],"elements","agentic webdesign agent elements","MCP","ai agent","registry","search","streaming","open source","open","Bash","plan","subagent","edit","install","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":38},"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":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":81,"categoryName":82,"taxonomyType":75,"taxonomyTypeDesc":76},[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":38},"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":81,"categoryName":82,"taxonomyType":75,"taxonomyTypeDesc":76},[202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,23],"workflows","quality","software","software quality workflows","review","tdd","workflow","commit","debugging","code","debugger","pre-commit","investigation","code simplification","user","simplification",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":222,"categories":223,"keywords":231,"publishedAt":38},"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",[224,227,230],{"categoryNo":225,"categoryName":226,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":228,"categoryName":229,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":81,"categoryName":82,"taxonomyType":75,"taxonomyTypeDesc":76},[232,233,234,235,236,237,238,239,177,240,241,124,242,180,243,211,244,245,246,247],"react","component","refactoring","component refactoring","react component","react component refactoring","frontend","writing","safe","typescript","react components","modular","refactor","simplify","patterns","test-driven-development"]