[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WYYWBZ8KAQ7YZ9Y9Q8VNE5":3,"skill-same:01M6WYYWBZ8KAQ7YZ9Y9Q8VNE5":80},{"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":18,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6WYYWBZ8KAQ7YZ9Y9Q8VNE5","refactoring",null,"Systematic refactoring with Fowler's catalog, GoF patterns, and code smell detection. Use when restructuring code without changing behavior — cleaning up smells, applying patterns, reducing duplication, or preparing a module for an upcoming feature.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Frefactoring\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"patterns","when","for","v1","with","systematic","module","feature","duplication","code","up","use","catalog","behavior","work","detection","engineering","2026-11-10 10:12:30",false,"---\nname: refactoring\ndescription: |\n  Systematic refactoring with Fowler's catalog, GoF patterns, and code smell detection. Use when restructuring code without changing behavior — cleaning up smells, applying patterns, reducing duplication, or preparing a module for an upcoming feature.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-refactoring\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n    layer: 3\n---\n\n# Refactoring\n\n## Intro\n\nRefactoring is changing the structure of code without changing its\nobservable behavior. Do it in small, test-protected steps, one\ntransformation at a time, and never mix it with feature changes in\nthe same commit.\n\n## Overview\n\n### Verify the safety net first\n\nBefore any refactoring, run the existing tests and confirm they\npass. If no tests cover the code you are about to change, write\ncharacterization tests first — tests that capture current behavior,\nnot desired behavior. Plan the refactoring as a sequence of atomic\ntransformations where each step keeps the suite green, and commit\nafter each step. The golden rule: never mix refactoring with feature\nchanges in the same commit.\n\n### Identify code smells\n\nScan systematically for the well-known smells. The full catalog\nlives in `references\u002Fcode-smells.md`; the most common offenders:\n\n| Smell | What to look for |\n|---|---|\n| Long Method | Function > 20 lines or doing more than one thing |\n| Large Class | Class with > 5 responsibilities or > 300 lines |\n| Long Parameter List | Function with > 3 parameters |\n| Feature Envy | Method uses another object's data more than its own |\n| Data Clumps | Same group of variables appears together repeatedly |\n| Primitive Obsession | Strings\u002Fints where a domain type belongs |\n| Shotgun Surgery | One change requires edits in many unrelated files |\n| Divergent Change | One class changed for multiple unrelated reasons |\n| Duplicate Code | Same logic in two or more places |\n| Dead Code | Unreachable or unused code |\n\n### Apply Fowler's refactoring catalog\n\nMatch smells to specific refactorings:\n\n- **Composing methods** — Extract Function, Inline Function, Extract\n  Variable, Replace Temp with Query.\n- **Moving features** — Move Function\u002FField, Extract Class, Inline\n  Class.\n- **Simplifying conditionals** — Replace Nested Conditional with\n  Guard Clauses, Decompose Conditional, Replace Conditional with\n  Polymorphism, Introduce Null Object.\n- **Organizing data** — Introduce Parameter Object, Replace Magic\n  Number with Constant, Encapsulate Collection.\n- **Generalization** — Pull Up \u002F Push Down Method, Extract\n  Interface\u002FTrait, Replace Inheritance with Composition.\n\n### Apply GoF patterns when they simplify\n\nOnly introduce a design pattern when it solves a concrete problem,\nnever speculatively. The full catalog is in\n`references\u002Fgof-patterns.md`. Most commonly useful: Strategy,\nObserver, Factory Method, Builder, Adapter, Decorator, Command,\nState, Template Method, Iterator. Warning signs of overuse: adding\na pattern \"just in case\", pattern adds more code than it removes,\nonly one implementation exists, the team cannot explain why.\n\n### Example\n\nUser says \"this function is too long\". The agent identifies three\ndistinct responsibilities, extracts each into a named helper\nkeeping the original as a high-level orchestrator, runs tests after\neach extraction, and commits each extraction separately.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Mixing refactoring with feature changes in the same commit.** When a commit changes both structure and behavior, reviewers cannot verify that behavior was preserved, and rollback becomes surgical. Keep refactoring commits separate; the commit message should start with `refactor:`.\n- **Starting without a test safety net.** If the code has no tests, changing its structure with no verification is guessing. Write characterization tests first — tests that capture current behavior, not desired behavior — then refactor.\n- **Big-bang rewrite instead of incremental transformation.** Full rewrites take longer, introduce more bugs, and stall new features during the rewrite. Refactor incrementally: one smell, one transformation, one commit, tests green throughout.\n- **Removing code assumed to be dead without verifying.** Dynamic dispatch, reflection, plugin systems, and config-driven loads can call code that static analysis says is unreachable. Search for all invocation paths before deleting anything.\n- **Speculative generality.** Adding extension points, plugin hooks, or configuration flags \"just in case\" is not refactoring — it is adding untested code for hypothetical future requirements. Refactor to the current need, not the imagined future.\n- **Pattern cargo-culting.** Introducing a design pattern because it sounds clever adds indirection and complexity without value. Apply a pattern only when it solves a concrete, present problem — and only after the \"rule of three\" (three similar occurrences) is met.\n- **Skipping the refactor step after green.** The refactor step is where the design payoff from TDD-style cycles lives. Skipping it means the test suite is green but the technical debt is accumulating.\n\n## Full reference\n\n### Modern considerations\n\nFor async\u002Fconcurrent code, extract async boundaries clearly (sync\ncore, async shell), replace callback chains with async\u002Fawait where\npossible, and isolate side effects at the edges. For\nfunctional-style code, replace mutable loops with map\u002Ffilter\u002Freduce\npipelines, extract pure functions from impure ones, and use\nalgebraic types (enums\u002Funions) over class hierarchies for closed\nsets.\n\n### Smell-to-pattern map\n\n| Smell \u002F situation | Candidate pattern |\n|---|---|\n| Complex conditional logic on types | Strategy, State, polymorphism |\n| Growing switch\u002Fmatch statements | Factory Method + polymorphism |\n| Duplicated algorithm with variations | Template Method |\n| Complex object construction | Builder |\n| Third-party integration coupling | Adapter |\n| Need to add behavior to existing code | Decorator |\n| Multiple objects reacting to events | Observer |\n| Complex state-dependent behavior | State |\n| Request needs undo\u002Fqueue\u002Flog | Command |\n| Many interacting objects | Mediator |\n\n### Selecting a pattern (rule of three)\n\nWait until you see a need in three places before abstracting. One\noccurrence is a fact, two is a coincidence, three is a pattern.\nPremature abstraction is harder to undo than late abstraction\nbecause the wrong shape constrains future changes.\n\n### Anti-patterns\n\n- Mixing refactoring with feature work in the same commit\n- Refactoring without a test safety net\n- Speculative generality — adding hooks \"just in case\"\n- Pattern cargo-culting — applying GoF because it sounds clever\n- Big-bang rewrites instead of incremental transformation\n- Removing dead code without checking it is truly unreachable\n  (search for dynamic dispatch, reflection, config-driven loads)\n\n### Example: extracting test seams\n\nTo make code more testable, identify concrete dependencies (file\nI\u002FO, HTTP, database), extract interfaces\u002Ftraits at those\nboundaries (Adapter pattern), move domain logic into pure\nfunctions, and introduce dependency injection so tests can supply\nfakes. This is refactoring in service of testability, not feature\nwork, and should ship in its own commit series.\n","# Refactoring\n\n## Intro\n\nRefactoring is changing the structure of code without changing its\nobservable behavior. Do it in small, test-protected steps, one\ntransformation at a time, and never mix it with feature changes in\nthe same commit.\n\n## Overview\n\n### Verify the safety net first\n\nBefore any refactoring, run the existing tests and confirm they\npass. If no tests cover the code you are about to change, write\ncharacterization tests first — tests that capture current behavior,\nnot desired behavior. Plan the refactoring as a sequence of atomic\ntransformations where each step keeps the suite green, and commit\nafter each step. The golden rule: never mix refactoring with feature\nchanges in the same commit.\n\n### Identify code smells\n\nScan systematically for the well-known smells. The full catalog\nlives in `references\u002Fcode-smells.md`; the most common offenders:\n\n| Smell | What to look for |\n|---|---|\n| Long Method | Function > 20 lines or doing more than one thing |\n| Large Class | Class with > 5 responsibilities or > 300 lines |\n| Long Parameter List | Function with > 3 parameters |\n| Feature Envy | Method uses another object's data more than its own |\n| Data Clumps | Same group of variables appears together repeatedly |\n| Primitive Obsession | Strings\u002Fints where a domain type belongs |\n| Shotgun Surgery | One change requires edits in many unrelated files |\n| Divergent Change | One class changed for multiple unrelated reasons |\n| Duplicate Code | Same logic in two or more places |\n| Dead Code | Unreachable or unused code |\n\n### Apply Fowler's refactoring catalog\n\nMatch smells to specific refactorings:\n\n- **Composing methods** — Extract Function, Inline Function, Extract\n  Variable, Replace Temp with Query.\n- **Moving features** — Move Function\u002FField, Extract Class, Inline\n  Class.\n- **Simplifying conditionals** — Replace Nested Conditional with\n  Guard Clauses, Decompose Conditional, Replace Conditional with\n  Polymorphism, Introduce Null Object.\n- **Organizing data** — Introduce Parameter Object, Replace Magic\n  Number with Constant, Encapsulate Collection.\n- **Generalization** — Pull Up \u002F Push Down Method, Extract\n  Interface\u002FTrait, Replace Inheritance with Composition.\n\n### Apply GoF patterns when they simplify\n\nOnly introduce a design pattern when it solves a concrete problem,\nnever speculatively. The full catalog is in\n`references\u002Fgof-patterns.md`. Most commonly useful: Strategy,\nObserver, Factory Method, Builder, Adapter, Decorator, Command,\nState, Template Method, Iterator. Warning signs of overuse: adding\na pattern \"just in case\", pattern adds more code than it removes,\nonly one implementation exists, the team cannot explain why.\n\n### Example\n\nUser says \"this function is too long\". The agent identifies three\ndistinct responsibilities, extracts each into a named helper\nkeeping the original as a high-level orchestrator, runs tests after\neach extraction, and commits each extraction separately.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Mixing refactoring with feature changes in the same commit.** When a commit changes both structure and behavior, reviewers cannot verify that behavior was preserved, and rollback becomes surgical. Keep refactoring commits separate; the commit message should start with `refactor:`.\n- **Starting without a test safety net.** If the code has no tests, changing its structure with no verification is guessing. Write characterization tests first — tests that capture current behavior, not desired behavior — then refactor.\n- **Big-bang rewrite instead of incremental transformation.** Full rewrites take longer, introduce more bugs, and stall new features during the rewrite. Refactor incrementally: one smell, one transformation, one commit, tests green throughout.\n- **Removing code assumed to be dead without verifying.** Dynamic dispatch, reflection, plugin systems, and config-driven loads can call code that static analysis says is unreachable. Search for all invocation paths before deleting anything.\n- **Speculative generality.** Adding extension points, plugin hooks, or configuration flags \"just in case\" is not refactoring — it is adding untested code for hypothetical future requirements. Refactor to the current need, not the imagined future.\n- **Pattern cargo-culting.** Introducing a design pattern because it sounds clever adds indirection and complexity without value. Apply a pattern only when it solves a concrete, present problem — and only after the \"rule of three\" (three similar occurrences) is met.\n- **Skipping the refactor step after green.** The refactor step is where the design payoff from TDD-style cycles lives. Skipping it means the test suite is green but the technical debt is accumulating.\n\n## Full reference\n\n### Modern considerations\n\nFor async\u002Fconcurrent code, extract async boundaries clearly (sync\ncore, async shell), replace callback chains with async\u002Fawait where\npossible, and isolate side effects at the edges. For\nfunctional-style code, replace mutable loops with map\u002Ffilter\u002Freduce\npipelines, extract pure functions from impure ones, and use\nalgebraic types (enums\u002Funions) over class hierarchies for closed\nsets.\n\n### Smell-to-pattern map\n\n| Smell \u002F situation | Candidate pattern |\n|---|---|\n| Complex conditional logic on types | Strategy, State, polymorphism |\n| Growing switch\u002Fmatch statements | Factory Method + polymorphism |\n| Duplicated algorithm with variations | Template Method |\n| Complex object construction | Builder |\n| Third-party integration coupling | Adapter |\n| Need to add behavior to existing code | Decorator |\n| Multiple objects reacting to events | Observer |\n| Complex state-dependent behavior | State |\n| Request needs undo\u002Fqueue\u002Flog | Command |\n| Many interacting objects | Mediator |\n\n### Selecting a pattern (rule of three)\n\nWait until you see a need in three places before abstracting. One\noccurrence is a fact, two is a coincidence, three is a pattern.\nPremature abstraction is harder to undo than late abstraction\nbecause the wrong shape constrains future changes.\n\n### Anti-patterns\n\n- Mixing refactoring with feature work in the same commit\n- Refactoring without a test safety net\n- Speculative generality — adding hooks \"just in case\"\n- Pattern cargo-culting — applying GoF because it sounds clever\n- Big-bang rewrites instead of incremental transformation\n- Removing dead code without checking it is truly unreachable\n  (search for dynamic dispatch, reflection, config-driven loads)\n\n### Example: extracting test seams\n\nTo make code more testable, identify concrete dependencies (file\nI\u002FO, HTTP, database), extract interfaces\u002Ftraits at those\nboundaries (Adapter pattern), move domain logic into pure\nfunctions, and introduce dependency injection so tests can supply\nfakes. This is refactoring in service of testability, not feature\nwork, and should ship in its own commit series.\n",{"name":5,"metadata":41,"description":48},{"processkit":42},{"id":43,"layer":44,"created":45,"version":46,"category":35,"apiVersion":47},"SKILL-refactoring",3,1775433600000,"1.1.0","processkit.projectious.work\u002Fv1","Systematic refactoring with Fowler's catalog, GoF patterns, and code smell detection. Use when restructuring code without changing behavior — cleaning up smells, applying patterns, reducing duplication, or preparing a module for an upcoming feature.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Frefactoring","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add projectious-work\u002Fprocesskit --skill refactoring",{"tool":62,"command":63},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill refactoring",{"tool":65,"command":66},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill refactoring","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Frefactoring\u002FSKILL.md",true,[70,76],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fcode-smells.md","REFERENCE","参考文档",6116,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Frefactoring\u002Freferences\u002Fcode-smells.md",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fgof-patterns.md",9413,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Frefactoring\u002Freferences\u002Fgof-patterns.md",[81,107,127,148,165,183],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":92,"publishedAt":36},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[87],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[93,94,95,96,97,98,33,99,100,101,83,102,103,104,22,105,106],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":114,"publishedAt":36},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[113],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},[93,115,116,117,118,119,98,33,120,121,100,122,123,124,102,125,126],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":36},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[93,134,135,95,96,136,98,33,137,138,139,140,102,141,142,143,144,145,146,147],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":36},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[93,101,155,95,98,156,157,120,158,137,100,159,160,102,161,162,142,163,22,164],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":36},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[172,173,174,175,98,176,177,178,33,179,180,181,182],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":36},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[93,190,191,95,96,136,98,156,33,99,137,192,100,139,102,162,142,143,193,106],"capability","capability management","queries","changes"]