[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WYYRM9MJS795ZGJCBS14SQ":3,"skill-same:01M6WYYRM9MJS795ZGJCBS14SQ":78},{"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":57,"commitSha":58,"skillDirectory":59,"forksCount":14,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M6WYYRM9MJS795ZGJCBS14SQ","python-best-practices",null,"Python conventions and patterns — typing, testing, project layout, tooling. Use when writing or reviewing Python code, setting up a new Python project, or deciding on tooling, typing, or testing conventions.","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\u002Fpython-best-practices\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"python","best practices","python best practices","best-practices","when","python conventions","v1","python code","typing","python project","layout","project","testing conventions","testing","tooling","up","use","work","code","writing","2026-11-10 10:12:30",false,"---\nname: python-best-practices\ndescription: |\n  Python conventions and patterns — typing, testing, project layout, tooling. Use when writing or reviewing Python code, setting up a new Python project, or deciding on tooling, typing, or testing conventions.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-python-best-practices\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# Python Best Practices\n\n## Intro\n\nModern Python is opinionated: `src\u002F` layout, `pyproject.toml`, type\nhints on public APIs, `pytest` for tests, `ruff` for lint and format.\nApply these conventions when writing or reviewing Python code.\n\n## Overview\n\n### Project layout\n\nUse the `src\u002F` layout. The package lives at `src\u002F\u003Cpackage>\u002F` with an\n`__init__.py`; tests live in a sibling `tests\u002F` tree mirroring the\npackage structure. Configuration goes in `pyproject.toml` — never\n`setup.py` or `setup.cfg`. Prefer `uv` for dependency management when\nthe project supports it; fall back to `pip-tools` or `poetry`\notherwise.\n\n```\nmy-project\u002F\n├── pyproject.toml\n├── src\u002F\n│   └── my_package\u002F\n│       ├── __init__.py\n│       └── core.py\n└── tests\u002F\n    └── test_core.py\n```\n\n### Type hints\n\nAdd type hints to all public function signatures and dataclass fields.\nUse `from __future__ import annotations` at the top of every module to\nenable modern syntax (PEP 563-style postponed evaluation) without\nruntime cost. Prefer `TypeAlias`, `Protocol`, and `dataclass` over raw\ndicts and tuples for non-trivial data shapes.\n\n### Testing with pytest\n\nTest files mirror the `src\u002F` tree: `src\u002Fmy_package\u002Ffoo.py` is tested\nby `tests\u002Ftest_foo.py`. Use fixtures for shared setup and `parametrize`\nfor variant testing. Name tests `test_\u003Cfunction>_\u003Cscenario>_\u003Cexpected>`\nso failures self-document.\n\n### Code style\n\nFormat with `ruff format`, lint with `ruff check`. Both replace older\ncombinations of black + isort + flake8 + pyupgrade. Prefer dataclasses\nor Pydantic models over plain dicts. Use `pathlib.Path` over\n`os.path`. Use f-strings over `.format()` or `%` formatting.\n\n### Error handling\n\nRaise specific exception classes, not generic `Exception`. Define\ncustom exception classes per domain (e.g.\n`UserNotFoundError(LookupError)`). Never write a bare `except:` —\nalways catch the specific exception type you expect.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Bare `except:` or catching `Exception` and silencing it.** A broad except that does nothing (or just logs) hides bugs, masks KeyboardInterrupt, and makes debugging impossible. Always catch the specific exception type; re-raise anything you didn't expect.\n- **Mutable default arguments.** `def foo(x=[]):` creates the list once at function-definition time, so all callers share the same list. The canonical fix is `def foo(x=None): if x is None: x = []`. This is a Python-specific trap that surprises engineers coming from other languages.\n- **`from module import *` at the top of a module.** Star imports pollute the namespace, hide the origin of names, and prevent tools from detecting unused imports. Use explicit imports; ruff catches violations.\n- **Mixing `os.path` and `pathlib.Path` in the same codebase.** `pathlib.Path` is the modern, readable API. Once adopted, `os.path` usage stands out as a maintenance signal. Pick one; default to `pathlib` for new code.\n- **Constructing SQL queries by string formatting.** f-strings and `%` formatting in SQL produce SQL injection vulnerabilities. Always use parameterized queries, regardless of whether the input comes from a user.\n- **Missing `from __future__ import annotations` in modules with complex types.** Without this import, forward references and complex annotations are evaluated at import time, causing `NameError` on circular references. Add it to every module that uses type hints.\n- **Making a library async by default without a sync entry point.** Sync callers cannot easily wrap an async library; they must run an event loop manually. Default libraries to sync and provide async variants, or offer a sync wrapper via `asyncio.to_thread`.\n\n## Full reference\n\n### `pyproject.toml` skeleton\n\n```toml\n[project]\nname = \"my-package\"\nversion = \"0.1.0\"\ndescription = \"Short description.\"\nrequires-python = \">=3.10\"\ndependencies = [\n    \"httpx>=0.27\",\n]\n\n[project.optional-dependencies]\ndev = [\n    \"pytest>=8.0\",\n    \"pytest-cov>=4.0\",\n    \"ruff>=0.5\",\n]\n\n[build-system]\nrequires = [\"hatchling\"]\nbuild-backend = \"hatchling.build\"\n\n[tool.ruff]\nline-length = 80\ntarget-version = \"py310\"\n\n[tool.ruff.lint]\nselect = [\"E\", \"F\", \"I\", \"B\", \"UP\", \"SIM\"]\n\n[tool.pytest.ini_options]\ntestpaths = [\"tests\"]\n```\n\n### Type-hint patterns\n\n| Use case | Pattern |\n|---|---|\n| Function returning nothing | `def foo() -> None:` (not `-> ()` or omitted) |\n| Optional value | `x: int \\| None` (PEP 604, modern) over `Optional[int]` |\n| Iterable input | `Iterable[T]` for read-only consumption; `list[T]` only when mutation is needed |\n| Callback \u002F interface | `Protocol` over abstract base class |\n| Frozen value | `dataclass(frozen=True)` or `tuple` |\n| Factory return type | The interface (`Protocol` or ABC), not the concrete class |\n\n### Testing conventions\n\n- **Fixtures over setup methods.** pytest fixtures are composable and\n  scoped; `unittest`-style `setUp\u002FtearDown` is not.\n- **One assertion per test, ideally.** When more is genuinely needed,\n  use `pytest.subtests` or split.\n- **No mocking the unit under test.** Mock the boundary\n  (HTTP client, database driver, clock). Mocking the function you're\n  testing means you're testing the mock.\n- **Coverage is a smoke alarm, not a goal.** Aim for meaningful\n  coverage of branching logic, not 100% line coverage.\n\n### Async vs sync\n\nUse `async`\u002F`await` when the workload is genuinely I\u002FO bound and the\necosystem supports it (HTTP servers, network clients, databases with\nasync drivers). Do **not** make a library async by default — sync\ncallers cannot easily wrap async code, but async callers can wrap\nsync code via `asyncio.to_thread`. Default to sync; opt into async\nwhen concurrency is the point.\n\n### Anti-patterns to avoid\n\n- **Bare `except:`** — catch specific types\n- **`from module import *`** — explicit imports only\n- **Mutable default arguments** (`def foo(x=[]):`) — use `None` and\n  initialize inside\n- **Generic exception handling that swallows errors** — at minimum\n  log + re-raise; never silently `pass`\n- **Mixing tabs and spaces** — ruff catches this; never bypass\n- **`os.path.join` over `Path \u002F Path`** — pathlib is the modern API\n- **Shell-style string concatenation for SQL** — parametrized queries\n  always\n\n### When to break the rules\n\nEvery rule above has exceptions. Pin yourself to the rule until you\nunderstand why it exists; only then are you qualified to break it.\nCommon legitimate exceptions: type-stub files (`.pyi`) intentionally\nomit type hints in body, scientific code uses `numpy` arrays which\nhave their own typing patterns, scripts under ~50 lines may skip the\n`src\u002F` layout.\n","# Python Best Practices\n\n## Intro\n\nModern Python is opinionated: `src\u002F` layout, `pyproject.toml`, type\nhints on public APIs, `pytest` for tests, `ruff` for lint and format.\nApply these conventions when writing or reviewing Python code.\n\n## Overview\n\n### Project layout\n\nUse the `src\u002F` layout. The package lives at `src\u002F\u003Cpackage>\u002F` with an\n`__init__.py`; tests live in a sibling `tests\u002F` tree mirroring the\npackage structure. Configuration goes in `pyproject.toml` — never\n`setup.py` or `setup.cfg`. Prefer `uv` for dependency management when\nthe project supports it; fall back to `pip-tools` or `poetry`\notherwise.\n\n```\nmy-project\u002F\n├── pyproject.toml\n├── src\u002F\n│   └── my_package\u002F\n│       ├── __init__.py\n│       └── core.py\n└── tests\u002F\n    └── test_core.py\n```\n\n### Type hints\n\nAdd type hints to all public function signatures and dataclass fields.\nUse `from __future__ import annotations` at the top of every module to\nenable modern syntax (PEP 563-style postponed evaluation) without\nruntime cost. Prefer `TypeAlias`, `Protocol`, and `dataclass` over raw\ndicts and tuples for non-trivial data shapes.\n\n### Testing with pytest\n\nTest files mirror the `src\u002F` tree: `src\u002Fmy_package\u002Ffoo.py` is tested\nby `tests\u002Ftest_foo.py`. Use fixtures for shared setup and `parametrize`\nfor variant testing. Name tests `test_\u003Cfunction>_\u003Cscenario>_\u003Cexpected>`\nso failures self-document.\n\n### Code style\n\nFormat with `ruff format`, lint with `ruff check`. Both replace older\ncombinations of black + isort + flake8 + pyupgrade. Prefer dataclasses\nor Pydantic models over plain dicts. Use `pathlib.Path` over\n`os.path`. Use f-strings over `.format()` or `%` formatting.\n\n### Error handling\n\nRaise specific exception classes, not generic `Exception`. Define\ncustom exception classes per domain (e.g.\n`UserNotFoundError(LookupError)`). Never write a bare `except:` —\nalways catch the specific exception type you expect.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Bare `except:` or catching `Exception` and silencing it.** A broad except that does nothing (or just logs) hides bugs, masks KeyboardInterrupt, and makes debugging impossible. Always catch the specific exception type; re-raise anything you didn't expect.\n- **Mutable default arguments.** `def foo(x=[]):` creates the list once at function-definition time, so all callers share the same list. The canonical fix is `def foo(x=None): if x is None: x = []`. This is a Python-specific trap that surprises engineers coming from other languages.\n- **`from module import *` at the top of a module.** Star imports pollute the namespace, hide the origin of names, and prevent tools from detecting unused imports. Use explicit imports; ruff catches violations.\n- **Mixing `os.path` and `pathlib.Path` in the same codebase.** `pathlib.Path` is the modern, readable API. Once adopted, `os.path` usage stands out as a maintenance signal. Pick one; default to `pathlib` for new code.\n- **Constructing SQL queries by string formatting.** f-strings and `%` formatting in SQL produce SQL injection vulnerabilities. Always use parameterized queries, regardless of whether the input comes from a user.\n- **Missing `from __future__ import annotations` in modules with complex types.** Without this import, forward references and complex annotations are evaluated at import time, causing `NameError` on circular references. Add it to every module that uses type hints.\n- **Making a library async by default without a sync entry point.** Sync callers cannot easily wrap an async library; they must run an event loop manually. Default libraries to sync and provide async variants, or offer a sync wrapper via `asyncio.to_thread`.\n\n## Full reference\n\n### `pyproject.toml` skeleton\n\n```toml\n[project]\nname = \"my-package\"\nversion = \"0.1.0\"\ndescription = \"Short description.\"\nrequires-python = \">=3.10\"\ndependencies = [\n    \"httpx>=0.27\",\n]\n\n[project.optional-dependencies]\ndev = [\n    \"pytest>=8.0\",\n    \"pytest-cov>=4.0\",\n    \"ruff>=0.5\",\n]\n\n[build-system]\nrequires = [\"hatchling\"]\nbuild-backend = \"hatchling.build\"\n\n[tool.ruff]\nline-length = 80\ntarget-version = \"py310\"\n\n[tool.ruff.lint]\nselect = [\"E\", \"F\", \"I\", \"B\", \"UP\", \"SIM\"]\n\n[tool.pytest.ini_options]\ntestpaths = [\"tests\"]\n```\n\n### Type-hint patterns\n\n| Use case | Pattern |\n|---|---|\n| Function returning nothing | `def foo() -> None:` (not `-> ()` or omitted) |\n| Optional value | `x: int \\| None` (PEP 604, modern) over `Optional[int]` |\n| Iterable input | `Iterable[T]` for read-only consumption; `list[T]` only when mutation is needed |\n| Callback \u002F interface | `Protocol` over abstract base class |\n| Frozen value | `dataclass(frozen=True)` or `tuple` |\n| Factory return type | The interface (`Protocol` or ABC), not the concrete class |\n\n### Testing conventions\n\n- **Fixtures over setup methods.** pytest fixtures are composable and\n  scoped; `unittest`-style `setUp\u002FtearDown` is not.\n- **One assertion per test, ideally.** When more is genuinely needed,\n  use `pytest.subtests` or split.\n- **No mocking the unit under test.** Mock the boundary\n  (HTTP client, database driver, clock). Mocking the function you're\n  testing means you're testing the mock.\n- **Coverage is a smoke alarm, not a goal.** Aim for meaningful\n  coverage of branching logic, not 100% line coverage.\n\n### Async vs sync\n\nUse `async`\u002F`await` when the workload is genuinely I\u002FO bound and the\necosystem supports it (HTTP servers, network clients, databases with\nasync drivers). Do **not** make a library async by default — sync\ncallers cannot easily wrap async code, but async callers can wrap\nsync code via `asyncio.to_thread`. Default to sync; opt into async\nwhen concurrency is the point.\n\n### Anti-patterns to avoid\n\n- **Bare `except:`** — catch specific types\n- **`from module import *`** — explicit imports only\n- **Mutable default arguments** (`def foo(x=[]):`) — use `None` and\n  initialize inside\n- **Generic exception handling that swallows errors** — at minimum\n  log + re-raise; never silently `pass`\n- **Mixing tabs and spaces** — ruff catches this; never bypass\n- **`os.path.join` over `Path \u002F Path`** — pathlib is the modern API\n- **Shell-style string concatenation for SQL** — parametrized queries\n  always\n\n### When to break the rules\n\nEvery rule above has exceptions. Pin yourself to the rule until you\nunderstand why it exists; only then are you qualified to break it.\nCommon legitimate exceptions: type-stub files (`.pyi`) intentionally\nomit type hints in body, scientific code uses `numpy` arrays which\nhave their own typing patterns, scripts under ~50 lines may skip the\n`src\u002F` layout.\n",{"name":5,"metadata":49,"description":56},{"processkit":50},{"id":51,"created":52,"version":53,"category":54,"apiVersion":55},"SKILL-python-best-practices",1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","Python conventions and patterns — typing, testing, project layout, tooling. Use when writing or reviewing Python code, setting up a new Python project, or deciding on tooling, typing, or testing conventions.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fpython-best-practices","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-09 00:53:29",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add projectious-work\u002Fprocesskit --skill python-best-practices",{"tool":70,"command":71},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill python-best-practices",{"tool":73,"command":74},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill python-best-practices","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fpython-best-practices\u002FSKILL.md",true,[],[79,103,123,144,161,179],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":88,"publishedAt":44},"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",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[89,90,91,92,93,94,41,95,96,97,81,98,99,100,30,101,102],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":110,"publishedAt":44},"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",[109],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[89,111,112,113,114,115,94,41,116,117,96,118,119,120,98,121,122],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":44},"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",[],[89,130,131,91,92,132,94,41,133,134,135,136,98,137,138,139,140,141,142,143],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":44},"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",[],[89,97,151,91,94,152,153,116,154,133,96,155,156,98,157,158,138,159,30,160],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":44},"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",[],[168,169,170,171,94,172,173,174,41,175,176,177,178],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":44},"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",[],[89,186,187,91,92,132,94,152,41,95,133,188,96,135,98,158,138,139,189,102],"capability","capability management","queries","changes"]