[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DATQ58BH3CSRTFP5N2BX4F":3,"skill-same:01M6DATQ58BH3CSRTFP5N2BX4F":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":22,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":13,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6DATQ58BH3CSRTFP5N2BX4F","code-readability",null,"Use when judging or improving how readable and maintainable code is — naming, function shape, abstraction altitude, comment discipline, and simplicity-over-cleverness — in a diff, module, or review, especially when code works but is hard to follow.","tzeusy-org\u002Fai-bootstrap","tzeusy-org","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141543652?v=4","01M6DAM1AP09H27BYGFY9QCNPB","01M6DAM1F4R187EK11XDN9JZKH",0,"MIT","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fcode-readability\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35],"code","readability","code readability","review","how","use","discipline","simplicity","diff","shape","but","active","module","2026-11-10 10:12:30",false,"---\nname: code-readability\ndescription: >\n  Use when judging or improving how readable and maintainable code is — naming, function\n  shape, abstraction altitude, comment discipline, and simplicity-over-cleverness — in a\n  diff, module, or review, especially when code works but is hard to follow.\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n  status: active\n  last_reviewed: \"2026-06-12\"\n---\n\n# Code Readability\n\nCode is read far more than written. Judges whether a future reader — human or\nagent, without the author present — can reconstruct intent, predict behavior,\nand change code safely.\n\n## Use This Skill When\n\n- Reviewing a diff or module for clarity, naming, or structure\n- A working implementation \"feels dense\" and needs simplification before merge\n- Deciding whether an abstraction earns its keep\n- Asked \"is this readable\", \"simplify this\", \"review naming and structure\"\n\n## Do Not Use This Skill For\n\n- Correctness or test review — [test-rigor](..\u002Ftest-rigor\u002FSKILL.md)\n- Leftover compatibility shims — [cruft-cleanup](..\u002Fcruft-cleanup\u002FSKILL.md)\n- Module boundaries and import structure —\n  [dependency-hygiene](..\u002Fdependency-hygiene\u002FSKILL.md)\n- Pure formatting that a linter\u002Fformatter already owns\n\n## Core Rule\n\n**Optimize for the reader's first pass.** If understanding a unit requires\njumping files, holding hidden state in your head, or decoding a clever trick,\nthe code is wrong even when it works. Simplicity needs no justification;\ncleverness does.\n\n## The Bar\n\nReviewable expectations — cite the one violated, with file:line evidence:\n\n1. **Names state intent, at the right altitude** — Name says what the thing\n   means in the domain, not how it is computed (`overdue_invoices`, not\n   `filtered_list2`). One concept gets one name across the codebase; renaming\n   half the occurrences is worse than not renaming.\n2. **Functions do one thing at one altitude** — Mix abstraction levels\n   (business policy next to byte-twiddling) only with strong justification.\n   Extract when a block needs a comment to say what it does; inline when an\n   indirection exists only to be called once and hides the flow.\n3. **Control flow is followable top-to-bottom** — Early returns over nested\n   conditionals. No action-at-a-distance: reader should not need to know about\n   a decorator, hook, or global to predict what a call does.\n4. **Abstractions earn their keep** — An interface, base class, generic\n   parameter, or config knob with one real implementation\u002Fvalue is\n   speculation, not design. Duplicate twice before abstracting once; the\n   third occurrence reveals the real shape.\n5. **Comments state constraints, not narration** — Comment says what the code\n   cannot: the invariant, the external quirk, the why-not-the-obvious-way.\n   Comments that restate the next line, or talk to a reviewer about the change\n   (\"updated to fix…\"), get deleted.\n6. **Consistency beats local preference** — Match the surrounding file's\n   idiom, naming style, and comment density even when you'd choose otherwise\n   in a vacuum. A diff that switches styles mid-module adds permanent reading\n   cost for transient taste.\n7. **State is scoped as tightly as possible** — Mutable state lives in the\n   narrowest scope that works; data flows through parameters and return\n   values, not through fields or globals reached around the call graph.\n\n## Workflow\n\n1. Read the change as a stranger: top of the diff to bottom, no author\n   context. Note every place you had to stop, re-read, or jump.\n2. For each stall point, name the violated expectation (1–7 above) and draft\n   the minimal fix — rename, extract, inline, delete the comment, hoist the\n   early return.\n3. Prefer fixes that shrink the diff's concept count over fixes that add\n   structure. Deleting an abstraction usually beats documenting it.\n4. Apply in-scope fixes directly; report only what genuinely needs the\n   author's intent to resolve.\n5. Re-read the result end-to-end once — readability fixes can themselves\n   introduce stall points.\n\n## Trigger Sanity Check\n\nShould trigger:\n\n- \"This works but I had to read it three times — tighten it up.\"\n- \"Is this abstraction worth keeping, or should I inline it?\"\n- \"Simplify this module before we merge.\"\n- \"Review the naming and structure in this diff.\"\n\nShould not trigger:\n\n- \"Run the formatter\" — pure formatting belongs to the linter\u002Fformatter.\n- \"Find the bug in this function\" — correctness review, not readability.\n","# Code Readability\n\nCode is read far more than written. Judges whether a future reader — human or\nagent, without the author present — can reconstruct intent, predict behavior,\nand change code safely.\n\n## Use This Skill When\n\n- Reviewing a diff or module for clarity, naming, or structure\n- A working implementation \"feels dense\" and needs simplification before merge\n- Deciding whether an abstraction earns its keep\n- Asked \"is this readable\", \"simplify this\", \"review naming and structure\"\n\n## Do Not Use This Skill For\n\n- Correctness or test review — [test-rigor](..\u002Ftest-rigor\u002FSKILL.md)\n- Leftover compatibility shims — [cruft-cleanup](..\u002Fcruft-cleanup\u002FSKILL.md)\n- Module boundaries and import structure —\n  [dependency-hygiene](..\u002Fdependency-hygiene\u002FSKILL.md)\n- Pure formatting that a linter\u002Fformatter already owns\n\n## Core Rule\n\n**Optimize for the reader's first pass.** If understanding a unit requires\njumping files, holding hidden state in your head, or decoding a clever trick,\nthe code is wrong even when it works. Simplicity needs no justification;\ncleverness does.\n\n## The Bar\n\nReviewable expectations — cite the one violated, with file:line evidence:\n\n1. **Names state intent, at the right altitude** — Name says what the thing\n   means in the domain, not how it is computed (`overdue_invoices`, not\n   `filtered_list2`). One concept gets one name across the codebase; renaming\n   half the occurrences is worse than not renaming.\n2. **Functions do one thing at one altitude** — Mix abstraction levels\n   (business policy next to byte-twiddling) only with strong justification.\n   Extract when a block needs a comment to say what it does; inline when an\n   indirection exists only to be called once and hides the flow.\n3. **Control flow is followable top-to-bottom** — Early returns over nested\n   conditionals. No action-at-a-distance: reader should not need to know about\n   a decorator, hook, or global to predict what a call does.\n4. **Abstractions earn their keep** — An interface, base class, generic\n   parameter, or config knob with one real implementation\u002Fvalue is\n   speculation, not design. Duplicate twice before abstracting once; the\n   third occurrence reveals the real shape.\n5. **Comments state constraints, not narration** — Comment says what the code\n   cannot: the invariant, the external quirk, the why-not-the-obvious-way.\n   Comments that restate the next line, or talk to a reviewer about the change\n   (\"updated to fix…\"), get deleted.\n6. **Consistency beats local preference** — Match the surrounding file's\n   idiom, naming style, and comment density even when you'd choose otherwise\n   in a vacuum. A diff that switches styles mid-module adds permanent reading\n   cost for transient taste.\n7. **State is scoped as tightly as possible** — Mutable state lives in the\n   narrowest scope that works; data flows through parameters and return\n   values, not through fields or globals reached around the call graph.\n\n## Workflow\n\n1. Read the change as a stranger: top of the diff to bottom, no author\n   context. Note every place you had to stop, re-read, or jump.\n2. For each stall point, name the violated expectation (1–7 above) and draft\n   the minimal fix — rename, extract, inline, delete the comment, hoist the\n   early return.\n3. Prefer fixes that shrink the diff's concept count over fixes that add\n   structure. Deleting an abstraction usually beats documenting it.\n4. Apply in-scope fixes directly; report only what genuinely needs the\n   author's intent to resolve.\n5. Re-read the result end-to-end once — readability fixes can themselves\n   introduce stall points.\n\n## Trigger Sanity Check\n\nShould trigger:\n\n- \"This works but I had to read it three times — tighten it up.\"\n- \"Is this abstraction worth keeping, or should I inline it?\"\n- \"Simplify this module before we merge.\"\n- \"Review the naming and structure in this diff.\"\n\nShould not trigger:\n\n- \"Run the formatter\" — pure formatting belongs to the linter\u002Fformatter.\n- \"Find the bug in this function\" — correctness review, not readability.\n",{"name":5,"metadata":41,"description":46},{"owner":42,"status":34,"authors":43,"last_reviewed":45},"tze",[42,44],"Claude Fable 5","2026-06-12","Use when judging or improving how readable and maintainable code is — naming, function shape, abstraction altitude, comment discipline, and simplicity-over-cleverness — in a diff, module, or review, especially when code works but is hard to follow.\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fcode-readability","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap","https:\u002F\u002Fgithub.com\u002Ftzeusy-org","2026-11-10 23:17:25",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill code-readability",{"tool":59,"command":60},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill code-readability",{"tool":62,"command":63},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill code-readability","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fcode-readability\u002FSKILL.md",true,[],[68,93,114,129,147,158],{"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},"01M6DAZD21TWH2ET70V9FF75CQ","user-run","Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable \u002Fhome\u002Forca\u002F.tmp\u002F\u003Cslug>\u002Frun.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: \"I'll run it for you\", \"permission denied on docker.sock\", \"needs sudo\", \"sudo: a password is required\", \"run as tze\", \"\u002Fuser-run\".","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002FSKILL.md",[],[75,76,77,78,79,28,80,81,82,83,34,84,85,86,87,88,89,90,91,92],"user run","user","run","docker","logs","host","as","triggers","permission","time","log","artifacts","session","password","access","secrets","risk","brief",{"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":105,"publishedAt":36},"01M6DAZAHTCBAD2WF0GAHWPST8","requesting-code-review","Use when completing tasks, implementing major features, or before merging to verify work meets requirements","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Frequesting-code-review\u002FSKILL.md",[99,104],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[106,23,26,107,108,109,34,110,111,28,112,113],"requesting code review","code review","work","requirements","upstream","superpowers","verify","tasks",{"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":122,"publishedAt":36},"01M6DAZ7CJ82D81XZB2YHVVY48","receiving-code-review","Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Freceiving-code-review\u002FSKILL.md",[120,121],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[123,23,26,107,34,110,124,111,28,125,126,127,128],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":36},"01M6DAZ4ER76ADXJ9KRFP7V3Q9","finishing-a-development-branch","Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Ffinishing-a-development-branch\u002FSKILL.md",[],[136,137,138,139,28,140,108,27,141,142,111,143,144,145,34,110,146,124],"branch","development","finishing a development branch","integrate","decide","cleanup","pr","merge","tests","structured","options",{"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},"01M6DAYZFWWW2YPKP89QNQR96H","executing-plans","Use when you have a written implementation plan to execute in a separate session with review checkpoints","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fexecuting-plans\u002FSKILL.md",[],[154,155,156,26,157,34,110,124,111,28,87],"plans","executing plans","plan","execute",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":36},"01M6DAYWM2YQHYCK7C35K1D29J","dispatching-parallel-agents","Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fdispatching-parallel-agents\u002FSKILL.md",[],[165,166,167,28,111,110,168,34,169,113,170],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]