メニュー
Audit where mutable state lives in Python modules—module globals and ContextVars vs class classmethods, pure functions vs hubs, ABC vs coordinator split. Use when reviewing singletons, request scope, caches, or "should this be a class". Read-only.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | state-shape-audit |
| description | Audit where mutable state lives in Python modules—module globals and ContextVars vs class classmethods, pure functions vs hubs, ABC vs coordinator split. Use when reviewing singletons, request scope, caches, or "should this be a class". Read-only. |
| disable-model-invocation | true |
I own: module-level mutable state, function vs classmethod choice for stateful subsystems.
I don't own: file splits, domain naming, thin wrappers.
Read: CONVENTIONS.md.
| Situation | Shape | pyjinhx example |
|---|---|---|
| ContextVar + locks + process/request state | Class with @classmethod | LoadCache, MutationTracker, InvalidationHub, ClientBackend |
| Request-scoped opaque DI bag | Static methods on frozen dataclass base | PjxContext |
| Pure input → output | Module functions | coerce_reactive_key, pjx_load_field_names, PjxKey validation |
| Decorator ergonomics | Module decorator → class method | @mutates → MutationTracker.record |
| Plugin extension point | ABC, no hub state | InvalidationBackend |
| Runtime coordinator | Hub class | InvalidationHub |
| Dev toggles | Module fn + private dataclass | enable_reactive_dev, _DevConfig |
rg '^_\w+: (ContextVar|threading\.Lock)' pyjinhx/ --glob '*.py'
rg '^_[a-z_]+ = ' pyjinhx/reactive --glob '*.py'
For each module-global cluster, ask: should this be methods on one class?
LoadCache style)@staticmethod and no state (prefer function unless grouping API)_dev_config module global with functions as canonical dev APIPjxContext.current / Registry.request_scope pattern)CacheScope enum at module level next to LoadCache classInvalidationHub vs InvalidationBackend)keys.py.clear(), .reset(), .reset_request() on owning classUse CONVENTIONS template.
Audit pyjinhx for dead code—removed API ghosts in code/docs/tests, symbols with no callers, obsolete backward-compat paths, unused parameters, and tests for deleted behavior. Use after refactors, API removals, or when the user asks to "sweep for dead code", "find unused code", or "remove leftovers". Read-only report.
Orchestrate a full structural code audit of pyjinhx using eight focused lenses (file responsibility, module placement, domain entities, state shape, duplication, indirection, public API, dead code). Use when the user asks to "audit the codebase", "sweep for quality", "review architecture", "audit reactive/", or before a large PR merge. Produces a merged read-only report; remediation is a separate pass unless requested.
Audit whether classes and module names match domain concepts—entities vs algorithms, ABC vs hub vs value object, procedural filenames vs type names. Use when naming new types, reviewing package structure, or asking "what should this be called". Read-only report.
Audit pyjinhx public API surface—pyjinhx.__all__, top-level exports vs canonical implementations, docs/reference/public-api.md alignment, tests/36_public_api_test.py. Use before releases, after refactors, or when removing deprecated symbols. Read-only.
Audit for duplicated workflows and parallel call sequences that will drift—same orchestration in two modules, duplicate parsing/validation, identical decorator and context-manager bodies. Use when reviewing refactors, merge conflicts, or "keep these in sync" code. Read-only report; documents intentional asymmetry.
Audit Python files for single responsibility—oversized modules, mixed concerns (parsing + algorithm + runtime in one file), misleading filenames, empty package __init__ without module maps. Use when a file feels crowded or before splitting a module. Read-only report.