[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SG18JMNV8ED6XQ97Z48X0":3,"skill-same:01M71SG18JMNV8ED6XQ97Z48X0":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71SG18JMNV8ED6XQ97Z48X0","simplifying-code",null,"Use when code in a specific module or area is hard to understand or change, when the user asks to simplify, refactor, clean up, or improve the design or architecture of some code, or when a maintenance program hands over a refactor slice. Finds unmanaged complexity from evidence and removes it with small, behavior-preserving changes.","Praneeth-Suresh\u002FBeryl","Praneeth-Suresh","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F86470588?v=4","01M71SF2BCZ4JMKKYZR66WNHAF","Praneeth Suresh","01M71SF2C5JMS7B9676HSA2SG6",11,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fsimplifying-code\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"simplifying code","code","maintenance","changes","change","with","architecture","program","simplify","when","use","module","design","improve","clean","up","slice","evidence","complexity","behavior-preserving","2026-11-10 13:02:02",false,"---\nname: simplifying-code\ndescription: Use when code in a specific module or area is hard to understand or change, when the user asks to simplify, refactor, clean up, or improve the design or architecture of some code, or when a maintenance program hands over a refactor slice. Finds unmanaged complexity from evidence and removes it with small, behavior-preserving changes.\n---\n\n# Simplifying Code\n\n## Purpose\n\nReduce the complexity that makes code hard to understand and change, using\nestablished software design principles that fit the code's language and\nparadigm. The goal is code that a new reader can change safely, not code that\nfollows a pattern for its own sake.\n\nComplexity shows up in three ways:\n\n- **Change amplification:** one small change needs edits in many places.\n- **Cognitive load:** a reader must hold too much in their head to make a change.\n- **Unknown unknowns:** it is not clear what code or which assumptions a change will affect.\n\nEvery finding must point at one of these.\n\n## Scope\n\nUse this for one module, package, class hierarchy, feature area, or file set.\nFor a whole-repository assessment, use `maintaining-codebase` first; it hands\nindividual slices to this skill.\n\nDo not change behavior. Do not add features. Do not reformat or rename code\nthat is outside the agreed scope.\n\n## 1. Understand Before Judging\n\n1. Read `.beryl\u002Fagent\u002Farchitecture.md` and `.beryl\u002Fagent\u002Fubiquitous-language.md`\n   for boundaries and domain terms.\n2. Identify the language, its dominant paradigm in this codebase\n   (object-oriented, functional, procedural, or mixed), and the local\n   conventions: naming, error handling, module layout, dependency injection,\n   and test style. Existing conventions win over textbook preferences unless\n   they cause one of the three complexity symptoms.\n3. Read the callers, the tests, and recent history (`git log -p` on the area)\n   to learn why the code looks the way it does. Treat odd code as possibly\n   deliberate until you find out otherwise.\n4. Find what protects the current behavior: tests, type checks, contracts.\n   Note any gaps.\n\n## 2. Find Problems From Evidence\n\nLook for these, and record the file and line, the symptom, and why it hurts:\n\n| Problem | What it looks like |\n| --- | --- |\n| Shallow module | The interface is about as complex as the implementation; callers must know internal details to use it. |\n| Pass-through layer | A method or class only forwards calls and adds no abstraction. |\n| Information leak | The same knowledge, such as a format, an ordering rule, or a magic value, is spread across several modules. |\n| Temporal coupling | Callers must call things in a particular order that nothing enforces. |\n| Low cohesion | One unit mixes unrelated responsibilities; edits for unrelated reasons keep landing in it. |\n| High coupling | A unit depends on another's internals, or a change in one forces a change in the other. |\n| Duplicated logic | The same rule is implemented twice and can drift. Duplicated text that encodes different rules is not duplication. |\n| Inheritance misuse | Deep or wide hierarchies, subclasses that override to disable behavior, or base classes used only to share helpers. |\n| Leaky dependencies | Domain logic depends on HTTP objects, ORM records, UI state, or vendor types instead of an adapter. |\n| Hidden side effects | A function that looks like a query also writes state, does I\u002FO, or mutates its inputs. |\n| Overly general code | Configuration, hooks, or abstraction layers with a single user and no planned second one. |\n| Unclear names | Names that do not match the ubiquitous language, or one concept with several names. |\n| Error-handling sprawl | The same error is caught and rethrown at many layers, or errors are silently swallowed. |\n\nUse tools when they exist: the linter, type checker, complexity or duplication\nreports, `.\u002F.beryl\u002Fagent\u002Fscripts\u002Fentropy-hotspots.sh` for churn, and the test\nsuite. Say which evidence was unavailable. Do not invent metrics.\n\n## 3. Choose The Principle That Fits\n\nPick the fix from the principle that matches the problem and the paradigm.\nPrefer the smallest change that removes the symptom.\n\nGeneral:\n\n- Make modules deep: a small, simple interface hiding a large implementation.\n- Hide information: put each design decision in exactly one module.\n- Define errors out of existence where possible, for example by making an\n  operation safe to repeat instead of making every caller check first.\n- Keep one level of abstraction per function.\n- Prefer explicit data flow over shared mutable state.\n- Delete code that has no caller.\n\nObject-oriented code:\n\n- Give each class one reason to change.\n- Prefer composition over inheritance. Use inheritance only for a real\n  \"is-a\" relation that honors the base class's contract.\n- Depend on small interfaces the caller owns, not on concrete classes from\n  another context.\n- Keep objects valid after construction; avoid \"call init() before use\".\n- Tell objects what to do instead of pulling their data out to decide for them.\n\nFunctional code:\n\n- Keep a functional core of pure functions and push I\u002FO to a thin outer shell.\n- Model states with types so invalid states cannot be represented.\n- Compose small functions instead of adding flags to large ones.\n- Keep data immutable at module boundaries.\n\nProcedural and scripting code:\n\n- Group related data and the functions that act on it into one module.\n- Replace long parameter lists with a named structure.\n- Validate input once at the boundary, then trust it inside.\n\nDo not apply a pattern because it is named. Each change must remove a\nsymptom you recorded in step 2.\n\n## 4. Propose\n\nPresent a short, ordered list of changes. For each one, give:\n\n- the problem, with its location and evidence;\n- the principle and the concrete change;\n- the expected effect on change amplification, cognitive load, or unknown unknowns;\n- the test or check that proves behavior is unchanged, and any test that must\n  be added first;\n- the risk, and how to roll it back.\n\nOrder the list so that each change is safe on its own, adding protecting\ntests before the refactor that needs them. Stop and wait for the user to\napprove before editing.\n\n## 5. Apply One Change At A Time\n\nAfter approval:\n\n1. If the protecting test is missing, add it first and confirm it passes\n   against the current code.\n2. Make one change. Keep public behavior, outputs, and error cases the same.\n3. Run the formatter, the narrow check, then the broader check.\n4. Use `verification-before-completion` before reporting the change as done.\n5. Repeat for the next approved change.\n\nIf a change turns out to need a behavior change, stop and say so. If a durable\nboundary moved, add a line to the Decision Record in\n`.beryl\u002Fagent\u002Farchitecture.md`.\n\n## Rules\n\n- Never weaken a test to make a refactor pass.\n- Never mix a refactor with a behavior change in the same commit.\n- Do not introduce a new dependency or framework to simplify code; use\n  `composing-modules` if one seems necessary.\n- Do not claim the code is \"clean\" or that complexity is gone. Report what\n  changed and what remains.\n\n## Output\n\nFollow `communicating-with-users`. Report the findings with evidence, the\napproved changes made, the checks run and their results, and the problems\nleft for later.\n","# Simplifying Code\n\n## Purpose\n\nReduce the complexity that makes code hard to understand and change, using\nestablished software design principles that fit the code's language and\nparadigm. The goal is code that a new reader can change safely, not code that\nfollows a pattern for its own sake.\n\nComplexity shows up in three ways:\n\n- **Change amplification:** one small change needs edits in many places.\n- **Cognitive load:** a reader must hold too much in their head to make a change.\n- **Unknown unknowns:** it is not clear what code or which assumptions a change will affect.\n\nEvery finding must point at one of these.\n\n## Scope\n\nUse this for one module, package, class hierarchy, feature area, or file set.\nFor a whole-repository assessment, use `maintaining-codebase` first; it hands\nindividual slices to this skill.\n\nDo not change behavior. Do not add features. Do not reformat or rename code\nthat is outside the agreed scope.\n\n## 1. Understand Before Judging\n\n1. Read `.beryl\u002Fagent\u002Farchitecture.md` and `.beryl\u002Fagent\u002Fubiquitous-language.md`\n   for boundaries and domain terms.\n2. Identify the language, its dominant paradigm in this codebase\n   (object-oriented, functional, procedural, or mixed), and the local\n   conventions: naming, error handling, module layout, dependency injection,\n   and test style. Existing conventions win over textbook preferences unless\n   they cause one of the three complexity symptoms.\n3. Read the callers, the tests, and recent history (`git log -p` on the area)\n   to learn why the code looks the way it does. Treat odd code as possibly\n   deliberate until you find out otherwise.\n4. Find what protects the current behavior: tests, type checks, contracts.\n   Note any gaps.\n\n## 2. Find Problems From Evidence\n\nLook for these, and record the file and line, the symptom, and why it hurts:\n\n| Problem | What it looks like |\n| --- | --- |\n| Shallow module | The interface is about as complex as the implementation; callers must know internal details to use it. |\n| Pass-through layer | A method or class only forwards calls and adds no abstraction. |\n| Information leak | The same knowledge, such as a format, an ordering rule, or a magic value, is spread across several modules. |\n| Temporal coupling | Callers must call things in a particular order that nothing enforces. |\n| Low cohesion | One unit mixes unrelated responsibilities; edits for unrelated reasons keep landing in it. |\n| High coupling | A unit depends on another's internals, or a change in one forces a change in the other. |\n| Duplicated logic | The same rule is implemented twice and can drift. Duplicated text that encodes different rules is not duplication. |\n| Inheritance misuse | Deep or wide hierarchies, subclasses that override to disable behavior, or base classes used only to share helpers. |\n| Leaky dependencies | Domain logic depends on HTTP objects, ORM records, UI state, or vendor types instead of an adapter. |\n| Hidden side effects | A function that looks like a query also writes state, does I\u002FO, or mutates its inputs. |\n| Overly general code | Configuration, hooks, or abstraction layers with a single user and no planned second one. |\n| Unclear names | Names that do not match the ubiquitous language, or one concept with several names. |\n| Error-handling sprawl | The same error is caught and rethrown at many layers, or errors are silently swallowed. |\n\nUse tools when they exist: the linter, type checker, complexity or duplication\nreports, `.\u002F.beryl\u002Fagent\u002Fscripts\u002Fentropy-hotspots.sh` for churn, and the test\nsuite. Say which evidence was unavailable. Do not invent metrics.\n\n## 3. Choose The Principle That Fits\n\nPick the fix from the principle that matches the problem and the paradigm.\nPrefer the smallest change that removes the symptom.\n\nGeneral:\n\n- Make modules deep: a small, simple interface hiding a large implementation.\n- Hide information: put each design decision in exactly one module.\n- Define errors out of existence where possible, for example by making an\n  operation safe to repeat instead of making every caller check first.\n- Keep one level of abstraction per function.\n- Prefer explicit data flow over shared mutable state.\n- Delete code that has no caller.\n\nObject-oriented code:\n\n- Give each class one reason to change.\n- Prefer composition over inheritance. Use inheritance only for a real\n  \"is-a\" relation that honors the base class's contract.\n- Depend on small interfaces the caller owns, not on concrete classes from\n  another context.\n- Keep objects valid after construction; avoid \"call init() before use\".\n- Tell objects what to do instead of pulling their data out to decide for them.\n\nFunctional code:\n\n- Keep a functional core of pure functions and push I\u002FO to a thin outer shell.\n- Model states with types so invalid states cannot be represented.\n- Compose small functions instead of adding flags to large ones.\n- Keep data immutable at module boundaries.\n\nProcedural and scripting code:\n\n- Group related data and the functions that act on it into one module.\n- Replace long parameter lists with a named structure.\n- Validate input once at the boundary, then trust it inside.\n\nDo not apply a pattern because it is named. Each change must remove a\nsymptom you recorded in step 2.\n\n## 4. Propose\n\nPresent a short, ordered list of changes. For each one, give:\n\n- the problem, with its location and evidence;\n- the principle and the concrete change;\n- the expected effect on change amplification, cognitive load, or unknown unknowns;\n- the test or check that proves behavior is unchanged, and any test that must\n  be added first;\n- the risk, and how to roll it back.\n\nOrder the list so that each change is safe on its own, adding protecting\ntests before the refactor that needs them. Stop and wait for the user to\napprove before editing.\n\n## 5. Apply One Change At A Time\n\nAfter approval:\n\n1. If the protecting test is missing, add it first and confirm it passes\n   against the current code.\n2. Make one change. Keep public behavior, outputs, and error cases the same.\n3. Run the formatter, the narrow check, then the broader check.\n4. Use `verification-before-completion` before reporting the change as done.\n5. Repeat for the next approved change.\n\nIf a change turns out to need a behavior change, stop and say so. If a durable\nboundary moved, add a line to the Decision Record in\n`.beryl\u002Fagent\u002Farchitecture.md`.\n\n## Rules\n\n- Never weaken a test to make a refactor pass.\n- Never mix a refactor with a behavior change in the same commit.\n- Do not introduce a new dependency or framework to simplify code; use\n  `composing-modules` if one seems necessary.\n- Do not claim the code is \"clean\" or that complexity is gone. Report what\n  changed and what remains.\n\n## Output\n\nFollow `communicating-with-users`. Report the findings with evidence, the\napproved changes made, the checks run and their results, and the problems\nleft for later.\n",{"name":5,"description":7},"main","3a5bd7e327cbdad81a70b624ec3fc6e43ec91f12",".beryl\u002Fagent\u002Fskills\u002Fsimplifying-code",0,"https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh","Just built it.","2026-11-09 18:59:34",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add Praneeth-Suresh\u002FBeryl --skill simplifying-code",{"tool":63,"command":64},"bunx","bunx skills add Praneeth-Suresh\u002FBeryl --skill simplifying-code",{"tool":66,"command":67},"pnpm","pnpm dlx skills add Praneeth-Suresh\u002FBeryl --skill simplifying-code","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fsimplifying-code\u002FSKILL.md",true,[],[72,94,101,129,154,169],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":76,"licenseFileUrl":77,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":44},"01M71SGEFHAT82F5TQH73XY6H8","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","MIT","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fverification-before-completion\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[81,82,83,84,85,86,87,88,41,33,89,34,90,91,92,93],"verification","verification before completion","committing","commands","about","work","claims","output","assertions","claim","prs","complete","running",{"skillNo":95,"name":96,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":44},"01M71SGD1DV15B9Z2S5V3M8YPH","using-beryl","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fusing-beryl\u002FSKILL.md",[],[100],"using beryl",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":111,"publishedAt":44},"01M71SGAJ7D211GQR4703TTZCW","understand-codebase","Teach a developer how a repository, subsystem, execution path, migration, diff, commit, branch, or pull request works. Use when the user asks to understand, explain, map, walk through, explore, or quiz themselves on code, or asks for an interactive HTML understanding artifact.","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Funderstand-codebase\u002FSKILL.md",[107,108],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000039","教师与教育",[112,113,114,115,116,117,118,119,120,121,34,33,25,122,123,124,125,126,127,128],"understand","codebase","understand codebase","branch","diff","for","explore","execution","quiz","map","commit","interactive","explain","artifact","how","pull request","pull",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":76,"licenseFileUrl":133,"sourceHtmlUrl":134,"categories":135,"keywords":144,"publishedAt":44},"01M71SG8H7CZGRND4C2BS49RV2","test-driven-development","Use when implementing any feature or bugfix, before writing implementation code","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Ftest-driven-development\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[136,141],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":142,"categoryName":143,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000018","写作与文案",[145,146,147,148,149,150,151,34,33,25,152,153],"driven","test","test driven development","development","feature","implementing","writing","bugfix","implementation",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":76,"licenseFileUrl":158,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":44},"01M71SG4N855A3ASYXWFX45DH5","systematic-debugging","Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fsystematic-debugging\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Fsystematic-debugging\u002FSKILL.md",[161],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},[163,164,165,166,34,33,146,167,168],"systematic","debugging","systematic debugging","fixes","behavior","bug",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":176,"publishedAt":44},"01M71SFYCTTCDRHPPVXBPPB7DR","refreshing-context","Use when the user asks to refresh, review, audit, or clean up the agent context files, periodically (for example monthly), or after a large change to the repository such as a restructure, migration, or major feature. Checks the context layer against the code, quizzes the developer to confirm what is still true, and removes or fixes redundant and misleading context with approval.","https:\u002F\u002Fgithub.com\u002FPraneeth-Suresh\u002FBeryl\u002Fblob\u002Fmain\u002F.beryl\u002Fagent\u002Fskills\u002Frefreshing-context\u002FSKILL.md",[175],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[177,178,179,28,180,29,181,25,33,34,182,183,38,39,184,117,166,149,185,186],"context","refreshing context","true","refresh","review","files","audit","example","as","repository"]