[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JEVGVVECRH9QST759VBKQ1":3,"skill-same:01M6JEVGVVECRH9QST759VBKQ1":83},{"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":27,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":66,"ownerHtmlUrl":67,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":68,"install":69,"resources":82},"01M6JEVGVVECRH9QST759VBKQ1","simplify-code",null,"Parallel 3-agent cleanup of recent code changes.","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\u002Fmisc\u002Fsimplify-code\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"simplify code","code","simplify","refactor","changes","test-driven-development","hermes agent","hermes","parallel","subagent","plan","macos","code-review","delegation","cleanup","development","windows","test","linux","review","2026-11-10 10:12:30",false,"---\nname: simplify-code\ndescription: \"Parallel 3-agent cleanup of recent code changes.\"\nversion: 1.0.0\nauthor: Hermes Agent (inspired by Claude Code \u002Fsimplify)\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [code-review, cleanup, refactor, delegation, subagent, parallel, simplify]\n    related_skills: [requesting-code-review, test-driven-development, plan]\n---\n\n# Simplify Code — Parallel Review & Cleanup\n\nReview your recent code changes with three focused reviewers running in\nparallel, aggregate their findings, and apply the fixes worth applying.\n\n**Core principle:** Three narrow reviewers beat one broad reviewer. Each one\ndeeply searches the codebase for a single class of problem — reuse, quality,\nefficiency — without diluting its attention across all three. They run\nconcurrently, so you pay the latency of one review, not three.\n\n## When to Use\n\nTrigger this skill when the user says any of:\n\n- \"simplify\" \u002F \"simplify my changes\" \u002F \"simplify these changes\"\n- \"review my code\" \u002F \"review my recent changes\" \u002F \"clean up my changes\"\n- \"\u002Fsimplify\" (if they're carrying the Claude Code habit over)\n\nOptional modifiers the user may add — honor them:\n\n- **Focus:** \"simplify focus on efficiency\" → run only the efficiency reviewer\n  (or weight the aggregation toward it). Recognized focuses: `reuse`,\n  `quality`, `efficiency`.\n- **Dry run:** \"simplify but don't change anything\" \u002F \"just report\" → run the\n  three reviewers, present findings, apply NOTHING. Ask before applying.\n- **Scope:** \"simplify the last commit\" \u002F \"simplify staged\" \u002F \"simplify\n  src\u002Ffoo.py\" → narrow the diff source accordingly (see Phase 1).\n\nDo NOT auto-run this after every edit. It costs three subagents' worth of\ntokens — invoke it only when the user explicitly asks.\n\n## The Process\n\n### Phase 1 — Identify the changes\n\nCapture the diff to review. Pick the source by what the user asked for, in\nthis default order:\n\n```bash\n# 1. Default: uncommitted working-tree changes (tracked files)\ngit diff\n\n# 2. If that's empty, include staged changes\ngit diff HEAD\n\n# 3. Scoped variants the user may request:\ngit diff --staged                 # \"staged changes\"\ngit diff HEAD~1                    # \"the last commit\"\ngit diff main...HEAD              # \"this branch\" \u002F \"my PR\"\ngit diff -- src\u002Ffoo.py            # specific file(s)\n```\n\nIf `git diff` and `git diff HEAD` are both empty and there's no git repo or no\nchanges, fall back to the files the user explicitly named or that were\nrecently created\u002Fedited in this session. If you genuinely can't find any\nchanged code, say so and stop — there's nothing to simplify.\n\nCapture the full diff text. Note its size: if it's very large (say >2000\nchanged lines), warn the user that three subagents each carrying the full diff\nwill be token-heavy, and offer to scope it down (per-directory, per-commit)\nbefore proceeding.\n\n### Phase 2 — Launch three reviewers in parallel\n\nUse `delegate_task` **batch mode** — pass all three tasks in one `tasks`\narray so they run concurrently. Three is the right fan-out for this pattern;\nit's well within the `delegation.max_concurrent_children` budget on any\ndefault install.\n\nGive **every** reviewer the **complete diff** (not fragments — cross-file\nissues hide in the gaps) plus the absolute repo path so they can search the\nwider codebase. Each reviewer gets `terminal`, `file`, and `search`\ntoolsets (so they can `git`, `read_file`, and `search_files`\u002Fgrep).\n\nTell each reviewer to:\n- Search the existing codebase for evidence (don't reason from the diff alone).\n- Report findings as a concrete list: `file:line → problem → suggested fix`.\n- Rank each finding `high` \u002F `medium` \u002F `low` confidence.\n- Skip nits and style-only churn. Only flag things that materially improve\n  the code.\n\nPass these three goals (drop any the user's focus excludes):\n\n**Reviewer 1 — Code Reuse**\n> Review this diff for code that duplicates functionality already in the\n> codebase. Search utility modules, shared helpers, and adjacent files\n> (use search_files \u002F grep) for existing functions, constants, or patterns\n> the new code could call instead of reimplementing. Flag: new functions\n> that duplicate existing ones; hand-rolled logic that an existing utility\n> already does (manual string\u002Fpath manipulation, custom env checks, ad-hoc\n> type guards, re-implemented parsing). For each, name the existing thing to\n> use and where it lives.\n\n**Reviewer 2 — Code Quality**\n> Review this diff for quality problems. Look for: redundant state (values\n> that duplicate or could be derived from existing state; caches that don't\n> need to exist); parameter sprawl (new params bolted on where the function\n> should have been restructured); copy-paste-with-variation (near-duplicate\n> blocks that should share an abstraction); leaky abstractions (exposing\n> internals, breaking an existing encapsulation boundary); stringly-typed\n> code (raw strings where a constant\u002Fenum\u002Fregistry already exists — check the\n> canonical registries before flagging). For each, give the concrete refactor.\n\n**Reviewer 3 — Efficiency**\n> Review this diff for efficiency problems. Look for: unnecessary work\n> (redundant computation, repeated file reads, duplicate API calls, N+1\n> access patterns); missed concurrency (independent ops run sequentially);\n> hot-path bloat (heavy\u002Fblocking work on startup or per-request paths);\n> TOCTOU anti-patterns (existence pre-checks before an op instead of doing\n> the op and handling the error); memory issues (unbounded growth, missing\n> cleanup, listener\u002Fhandle leaks); overly broad reads (loading whole files\n> when a slice would do). For each, give the concrete fix and why it's faster\n> or lighter.\n\n### Phase 3 — Aggregate and apply\n\nWait for all three to return (batch mode returns them together).\n\n1. **Merge** the findings into one list, deduping where reviewers overlap.\n2. **Discard false positives** — you have the most context; you don't have to\n   argue with a reviewer, just drop weak or wrong suggestions silently.\n3. **Resolve conflicts.** Reviewers can disagree (Reviewer 1: \"use existing\n   util X\"; Reviewer 3: \"X is slow, inline it\"). Default resolution order:\n   **correctness > the user's stated focus > readability\u002Freuse > micro-perf.**\n   Don't apply a perf \"fix\" that hurts clarity unless the path is genuinely\n   hot. When two suggestions are mutually exclusive and both defensible, pick\n   the one that touches less code and note the alternative.\n4. **Apply** the surviving fixes directly with `patch` \u002F `write_file` — unless\n   the user asked for a dry run, in which case present the list and ask first.\n5. **Verify** you didn't break anything: run the project's targeted tests for\n   the touched files (not the full suite), and re-run any linter\u002Ftype check the\n   repo uses. If a fix breaks a test, revert that one fix and report it.\n6. **Summarize** what you changed: a short list of applied fixes grouped by\n   reviewer category, plus any findings you deliberately skipped and why.\n\n## Pitfalls\n\n- **Don't fan out wider than ~3.** More reviewers means more cost and more\n  conflicting suggestions to reconcile, not better coverage. Three categories\n  cover the space.\n- **Give the WHOLE diff to each reviewer.** Splitting the diff across reviewers\n  defeats the design — cross-file duplication and N+1s only show up with the\n  full picture.\n- **Reviewers search, they don't guess.** A reuse finding with no pointer to\n  the existing utility (\"there's probably a helper for this\") is noise. Require\n  `file:line` evidence; drop findings that lack it.\n- **Apply ≠ rewrite.** This is cleanup of the user's recent changes, not a\n  license to refactor the whole module. Keep edits scoped to what the diff\n  touched plus the minimal surrounding change a fix requires.\n- **Respect project conventions.** If the repo has AGENTS.md \u002F CLAUDE.md \u002F\n  HERMES.md or a linter config, fold those rules into the reviewer prompts so\n  suggestions match house style instead of fighting it.\n- **Large diffs blow context.** If the diff is huge, scope it down before\n  delegating — three subagents each carrying a 5000-line diff is expensive and\n  may truncate.\n\n## Related\n\nIf your install has the `subagent-driven-development` skill (optional), it\ncovers the complementary case: parallel review *during* implementation, per\ntask. This skill is the standalone *after-the-fact* cleanup pass. Use\n`requesting-code-review` for the pre-commit security\u002Fquality gate.","# Simplify Code — Parallel Review & Cleanup\n\nReview your recent code changes with three focused reviewers running in\nparallel, aggregate their findings, and apply the fixes worth applying.\n\n**Core principle:** Three narrow reviewers beat one broad reviewer. Each one\ndeeply searches the codebase for a single class of problem — reuse, quality,\nefficiency — without diluting its attention across all three. They run\nconcurrently, so you pay the latency of one review, not three.\n\n## When to Use\n\nTrigger this skill when the user says any of:\n\n- \"simplify\" \u002F \"simplify my changes\" \u002F \"simplify these changes\"\n- \"review my code\" \u002F \"review my recent changes\" \u002F \"clean up my changes\"\n- \"\u002Fsimplify\" (if they're carrying the Claude Code habit over)\n\nOptional modifiers the user may add — honor them:\n\n- **Focus:** \"simplify focus on efficiency\" → run only the efficiency reviewer\n  (or weight the aggregation toward it). Recognized focuses: `reuse`,\n  `quality`, `efficiency`.\n- **Dry run:** \"simplify but don't change anything\" \u002F \"just report\" → run the\n  three reviewers, present findings, apply NOTHING. Ask before applying.\n- **Scope:** \"simplify the last commit\" \u002F \"simplify staged\" \u002F \"simplify\n  src\u002Ffoo.py\" → narrow the diff source accordingly (see Phase 1).\n\nDo NOT auto-run this after every edit. It costs three subagents' worth of\ntokens — invoke it only when the user explicitly asks.\n\n## The Process\n\n### Phase 1 — Identify the changes\n\nCapture the diff to review. Pick the source by what the user asked for, in\nthis default order:\n\n```bash\n# 1. Default: uncommitted working-tree changes (tracked files)\ngit diff\n\n# 2. If that's empty, include staged changes\ngit diff HEAD\n\n# 3. Scoped variants the user may request:\ngit diff --staged                 # \"staged changes\"\ngit diff HEAD~1                    # \"the last commit\"\ngit diff main...HEAD              # \"this branch\" \u002F \"my PR\"\ngit diff -- src\u002Ffoo.py            # specific file(s)\n```\n\nIf `git diff` and `git diff HEAD` are both empty and there's no git repo or no\nchanges, fall back to the files the user explicitly named or that were\nrecently created\u002Fedited in this session. If you genuinely can't find any\nchanged code, say so and stop — there's nothing to simplify.\n\nCapture the full diff text. Note its size: if it's very large (say >2000\nchanged lines), warn the user that three subagents each carrying the full diff\nwill be token-heavy, and offer to scope it down (per-directory, per-commit)\nbefore proceeding.\n\n### Phase 2 — Launch three reviewers in parallel\n\nUse `delegate_task` **batch mode** — pass all three tasks in one `tasks`\narray so they run concurrently. Three is the right fan-out for this pattern;\nit's well within the `delegation.max_concurrent_children` budget on any\ndefault install.\n\nGive **every** reviewer the **complete diff** (not fragments — cross-file\nissues hide in the gaps) plus the absolute repo path so they can search the\nwider codebase. Each reviewer gets `terminal`, `file`, and `search`\ntoolsets (so they can `git`, `read_file`, and `search_files`\u002Fgrep).\n\nTell each reviewer to:\n- Search the existing codebase for evidence (don't reason from the diff alone).\n- Report findings as a concrete list: `file:line → problem → suggested fix`.\n- Rank each finding `high` \u002F `medium` \u002F `low` confidence.\n- Skip nits and style-only churn. Only flag things that materially improve\n  the code.\n\nPass these three goals (drop any the user's focus excludes):\n\n**Reviewer 1 — Code Reuse**\n> Review this diff for code that duplicates functionality already in the\n> codebase. Search utility modules, shared helpers, and adjacent files\n> (use search_files \u002F grep) for existing functions, constants, or patterns\n> the new code could call instead of reimplementing. Flag: new functions\n> that duplicate existing ones; hand-rolled logic that an existing utility\n> already does (manual string\u002Fpath manipulation, custom env checks, ad-hoc\n> type guards, re-implemented parsing). For each, name the existing thing to\n> use and where it lives.\n\n**Reviewer 2 — Code Quality**\n> Review this diff for quality problems. Look for: redundant state (values\n> that duplicate or could be derived from existing state; caches that don't\n> need to exist); parameter sprawl (new params bolted on where the function\n> should have been restructured); copy-paste-with-variation (near-duplicate\n> blocks that should share an abstraction); leaky abstractions (exposing\n> internals, breaking an existing encapsulation boundary); stringly-typed\n> code (raw strings where a constant\u002Fenum\u002Fregistry already exists — check the\n> canonical registries before flagging). For each, give the concrete refactor.\n\n**Reviewer 3 — Efficiency**\n> Review this diff for efficiency problems. Look for: unnecessary work\n> (redundant computation, repeated file reads, duplicate API calls, N+1\n> access patterns); missed concurrency (independent ops run sequentially);\n> hot-path bloat (heavy\u002Fblocking work on startup or per-request paths);\n> TOCTOU anti-patterns (existence pre-checks before an op instead of doing\n> the op and handling the error); memory issues (unbounded growth, missing\n> cleanup, listener\u002Fhandle leaks); overly broad reads (loading whole files\n> when a slice would do). For each, give the concrete fix and why it's faster\n> or lighter.\n\n### Phase 3 — Aggregate and apply\n\nWait for all three to return (batch mode returns them together).\n\n1. **Merge** the findings into one list, deduping where reviewers overlap.\n2. **Discard false positives** — you have the most context; you don't have to\n   argue with a reviewer, just drop weak or wrong suggestions silently.\n3. **Resolve conflicts.** Reviewers can disagree (Reviewer 1: \"use existing\n   util X\"; Reviewer 3: \"X is slow, inline it\"). Default resolution order:\n   **correctness > the user's stated focus > readability\u002Freuse > micro-perf.**\n   Don't apply a perf \"fix\" that hurts clarity unless the path is genuinely\n   hot. When two suggestions are mutually exclusive and both defensible, pick\n   the one that touches less code and note the alternative.\n4. **Apply** the surviving fixes directly with `patch` \u002F `write_file` — unless\n   the user asked for a dry run, in which case present the list and ask first.\n5. **Verify** you didn't break anything: run the project's targeted tests for\n   the touched files (not the full suite), and re-run any linter\u002Ftype check the\n   repo uses. If a fix breaks a test, revert that one fix and report it.\n6. **Summarize** what you changed: a short list of applied fixes grouped by\n   reviewer category, plus any findings you deliberately skipped and why.\n\n## Pitfalls\n\n- **Don't fan out wider than ~3.** More reviewers means more cost and more\n  conflicting suggestions to reconcile, not better coverage. Three categories\n  cover the space.\n- **Give the WHOLE diff to each reviewer.** Splitting the diff across reviewers\n  defeats the design — cross-file duplication and N+1s only show up with the\n  full picture.\n- **Reviewers search, they don't guess.** A reuse finding with no pointer to\n  the existing utility (\"there's probably a helper for this\") is noise. Require\n  `file:line` evidence; drop findings that lack it.\n- **Apply ≠ rewrite.** This is cleanup of the user's recent changes, not a\n  license to refactor the whole module. Keep edits scoped to what the diff\n  touched plus the minimal surrounding change a fix requires.\n- **Respect project conventions.** If the repo has AGENTS.md \u002F CLAUDE.md \u002F\n  HERMES.md or a linter config, fold those rules into the reviewer prompts so\n  suggestions match house style instead of fighting it.\n- **Large diffs blow context.** If the diff is huge, scope it down before\n  delegating — three subagents each carrying a 5000-line diff is expensive and\n  may truncate.\n\n## Related\n\nIf your install has the `subagent-driven-development` skill (optional), it\ncovers the complementary case: parallel review *during* implementation, per\ntask. This skill is the standalone *after-the-fact* cleanup pass. Use\n`requesting-code-review` for the pre-commit security\u002Fquality gate.",{"name":5,"author":53,"license":14,"version":54,"metadata":55,"platforms":60,"description":7},"Hermes Agent (inspired by Claude Code \u002Fsimplify)","1.0.0",{"hermes":56},{"tags":57,"related_skills":58},[40,42,31,41,37,36,30],[59,33,38],"requesting-code-review",[46,39,44],"master","8ec37df6d71fb664ea19d32c079e7d3ff931a8e0","skills\u002Fmisc\u002Fsimplify-code",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":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add S3YED\u002Fappie-kit --skill simplify-code",{"tool":75,"command":76},"bunx","bunx skills add S3YED\u002Fappie-kit --skill simplify-code",{"tool":78,"command":79},"pnpm","pnpm dlx skills add S3YED\u002Fappie-kit --skill simplify-code","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fmisc\u002Fsimplify-code\u002FSKILL.md",true,[],[84,114,147,171,199,222],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":97,"publishedAt":48},"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",[90,93,96],{"categoryNo":91,"categoryName":92,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":94,"categoryName":95,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[98,99,100,101,102,103,35,34,104,105,106,107,108,109,110,111,112,113],"music","ai music","humanizer","visualization","Tools","Audio","songwriting","suno","lyrics","prompts","heartmula","craft","generation","feature","ai music generation","music generation",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":126,"publishedAt":48},"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",[120,123],{"categoryNo":121,"categoryName":122,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":124,"categoryName":125,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师",[127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146],"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":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":155,"publishedAt":48},"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",[153,154],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":124,"categoryName":125,"taxonomyType":25,"taxonomyTypeDesc":26},[128,156,132,157,158,159,134,160,161,162,163,164,165,38,37,166,167,168,169,170],"elements","agentic webdesign agent elements","MCP","ai agent","registry","search","streaming","open source","open","Bash","edit","install","input","lock","source",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":181,"publishedAt":48},"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",[177,180],{"categoryNo":178,"categoryName":179,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[182,183,184,39,185,46,44,186,187,188,189,190,191,192,193,194,195,196,197,198],"deployment","vercel deployment","vercel","cli","deploy","vercel deploy","REST","api","site","deploy to vercel","token","rest api","host","sites","paths","sanitization","static site",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":206,"publishedAt":48},"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",[205],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[207,208,209,210,47,211,212,213,214,29,215,216,217,218,219,220,221],"workflows","quality","software","software quality workflows","tdd","workflow","commit","debugging","debugger","pre-commit","investigation","code simplification","user","simplification","for",{"skillNo":223,"name":224,"nameZh":6,"description":225,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":226,"categories":227,"keywords":235,"publishedAt":48},"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",[228,231,234],{"categoryNo":229,"categoryName":230,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":232,"categoryName":233,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[236,237,238,239,240,241,242,243,39,244,245,134,246,44,247,29,31,30,248,33],"react","component","refactoring","component refactoring","react component","react component refactoring","frontend","writing","safe","typescript","react components","modular","patterns"]