code-review
Skill245 starsChanged todayApache-2.0View on GitHub
Conduct authoritative code review on python-roborock changes against repository architectural hierarchy, typing standards, and maintainer conventions.
We split this skill into the rules it gives an agent
6 rules. 0 are common, 2 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 183 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Use this skill when reviewing pull requests, inspecting code changes, or verifying new device traits in python-roborock.
- Distinctive: line 10
All reviews are evaluated against the engineering conventions defined in AGENTS.md.
- Very specific: line 34
Value-Returning Helpers: Do helper functions return values instead of modifying self via hidden side effects?
- Very specific: line 43
Do status and error code enums subclass RoborockEnum (with lowercase unknown = -1 member) or RoborockModeEnum (with from_code_optional())?
- Very specific: line 51
Do assertions verify public behavior rather than private _state variables?
- Distinctive: line 59
Keep feedback high-signal: focus on architectural violations, state/concurrency bugs, protocol safety, and test gaps.
“Common” is measured: kept by at least 6 in 10 of the 183 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Code Review Skill
Use this skill when reviewing pull requests, inspecting code changes, or verifying new device traits in python-roborock.
All reviews are evaluated against the engineering conventions defined in AGENTS.md.
Review Workflow
- Classify Changed Files & Scope:
Group changed files according to the 3-tier architectural hierarchy and evaluate PR scoping:
- Priority 1: Public Trait APIs & Consumer Contracts (
roborock/devices/traits/,roborock/data/containers.py) - Priority 2: Data Lifecycle & State Management (trait state, callbacks,
RoborockDevice.close(), map/render pipelines) - Priority 3: Wire Protocols, Codecs & Cryptography (
roborock/protocols/,roborock/devices/transport/,roborock/devices/rpc/) - PR Scoping: Flag PRs that mix unrelated subsystems or combine large protocol/parser additions with trait consumption when they should be split into focused PRs.
- Automated Conformance: Structural invariants (
RoborockBaseinheritance,RoborockEnumfallback members,RoborockExceptionrooting, and trait boundary types) are enforced intests/conformance/. Flag any unjustified allowlist exemptions added totests/conformance/and focus deeper review energy on semantic, lifecycle, and design issues.
- Priority 1: Public Trait APIs & Consumer Contracts (
- Evaluate Layer 1: Public Trait APIs & Consumer Contracts:
- Are trait models subclassing
RoborockBasewith@dataclass? - Is
TypedDictcompletely avoided for domain data models? - Is
Anystrictly prohibited on public trait boundaries? - Are forward references (
"ClassName") andtyping.TYPE_CHECKINGguards avoided? (Needing them usually indicates circular dependencies or coupling that should be refactored). - Are non-universal traits gated by device feature flags (
device.features) and supported categories? - Are trait abstractions consumer-agnostic (not hardcoded exclusively to Home Assistant entities)?
- Are transport details (keys, tokens, sockets) cleanly isolated from traits?
- Are trait models subclassing
- Evaluate Layer 2: Lifecycle, State & Concurrency:
- Value-Returning Helpers: Do helper functions return values instead of modifying
selfvia hidden side effects? - Direct Flow: Is the execution path straightforward and direct, avoiding unnecessary indirection or ping-ponging between methods?
- Render & Cache Immutability: Are cached telemetry state and raw packets kept immutable during presentation/rendering? When caching derived state (e.g., parsed maps or calibration), is cache invalidation handled accurately across out-of-order or concurrent updates?
- Event Loop Safety: Are CPU-intensive operations (e.g., heavy map decompression or PIL image rendering) kept off the
asyncioevent loop (such as viaasyncio.to_thread) with proper concurrency/staleness guards? - Concurrency: Does 1:1 async command-response matching use
asyncio.Futurecorrelated by protocol request/sequence ID (request_idormsg_id)? - Teardown: Are all tasks, event listeners, and channels cleanly unhooked in
RoborockDevice.close()? - Capability Gating: Is capability gating checking protocol version, category (appropriate for device family), and device feature flags?
- Value-Returning Helpers: Do helper functions return values instead of modifying
- Evaluate Layer 3: Wire Protocols, Codecs & Resilient Enums:
- Do status and error code enums subclass
RoborockEnum(with lowercaseunknown = -1member) orRoborockModeEnum(withfrom_code_optional())? - Are unexpected wire codes prevented from crashing via unhandled
ValueError? - Is wire-contained
Anyproperly scoped to genuine protocol polymorphism (e.g. Tuya DPS maps)?
- Do status and error code enums subclass
- Evaluate Tests & Fixtures:
- Test Mirroring & Colocation: Are tests colocated in the matching mirror path under
tests/for the module being tested (e.g., tests forroborock/devices/traits/v1/status.pyintests/devices/traits/v1/test_status.py; new modules have corresponding new test suites under the mirror directory)? - No One-Off Bugfix Test Files: Flag any fragmented single-bug or single-PR test files (e.g.,
tests/test_battery_low_voltage_fix.py). Tests must be integrated into the module's corresponding test suite. - Are tests using
fake_channeland@pytest.mark.parametrizerather than hand-rolled mocks or duplicate methods? - Do assertions verify public behavior rather than private
_statevariables?
- Test Mirroring & Colocation: Are tests colocated in the matching mirror path under
- Format Review Output:
Structure review comments with clear rationale and actionable code recommendations:
- Priority Level & File Reference
- Issue / Anti-Pattern Identified
- Grounded Rationale (citing protocol resilience, consumer stability, or maintainability)
- Concrete Before / After Diff or Suggested Fix Keep feedback high-signal: focus on architectural violations, state/concurrency bugs, protocol safety, and test gaps; avoid nitpicking formatting or style already enforced by Ruff and Mypy.
- Interactive / Summary Reviews: Group findings by Priority Layer (1 → 3) with file references, the anti-pattern identified, grounded rationale (citing protocol resilience, consumer stability, or maintainability), and a concrete before/after diff or suggested fix.
- Inline PR Review Comments: State the issue, grounded rationale (citing
AGENTS.mdconventions), and suggested fix concisely right on the affected lines.
Other versions193 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 193
- mattpocock/skills★ 309ksame name
- TheAlgorithms/Python★ 226ksame name
- microsoft/vscode★ 194ksame name
- github/spec-kit★ 145ksame name
- ggml-org/llama.cpp★ 133ksame name
- shareAI-lab/analysis_claude_code★ 80ksame name
- shareAI-lab/learn-claude-code★ 80ksame name
- vectorize-io/hindsight★ 57ksame name
- dbeaver/dbeaver★ 52ksame name
- roboflow/supervision★ 51ksame name
183 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use add-new-model, azsdk-common-sdk-breaking-change and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
PydanticSkilladd-new-model
Add support for a newly-released language or image generation model in pydantic-ai (e.g. openai:gpt-5.6, anthropic:claude-sonnet-5, openai:gpt-image-2). Use when a provider ships a new model id and you need to wire literals, profile flags, adapters, and tests to recognize it. Handles SDK-lag, gateway list conventions, capability probing, and direct image-model geometry.
Also in 9 projects that use this
Microsoft AzureSkillazsdk-common-sdk-breaking-change
Detect and mitigate SDK Breaking changes for an SDK package which is generated from TypeSpec. WHEN: "Detect SDK breaking changes for a service", "Detect SDK breaking changes for an SDK package", "Detect and mitigate SDK breaking changes for a service", "Detect and mitigate SDK breaking changes for an SDK package". INVOKES: skill: azsdk-common-generate-sdk-locally; MCP tools: azure-sdk-mcp:azsdk_customized_code_update, azure-sdk-mcp:azsdk_package_detect_breaking_change.
Also in 4 projects that use this
ww-w-aiSkillbkend-auth
bkend.ai authentication guide. Signup, login, JWT tokens, sessions, role-based access control, and password management with bkend.ai BaaS. Triggers: bkend auth, bkend login, bkend signup, JWT, session, RBAC, password, bkend 인증, 로그인, 회원가입, bkend認証, ログイン, 新規登録, bkend认证, 登录, 注册, autenticacion bkend, authentification bkend, bkend-Auth Do NOT use for: data operations (use $bkend-data), file storage (use $bkend-storage).
Also in 4 projects that use this
ww-w-aiSkillbkend-cookbook
bkend.ai cookbook with step-by-step tutorials and example projects. Build a todo app, blog, e-commerce store, and more with bkend.ai BaaS. Triggers: bkend cookbook, bkend tutorial, bkend example, todo app, blog app, bkend 쿡북, bkend 튜토리얼, 예제 프로젝트, bkendクックブック, チュートリアル, bkend教程, 示例项目, tutorial bkend, tutoriel bkend, bkend-Tutorial, ricettario Do NOT use for: initial setup (use $bkend-quickstart), specific features (use $bkend-data/auth/storage).
Also in 4 projects that use this
dzhngSkillclose-spec
When a spec under specs/<feature>/ is done shipping (a write-spec build, or any planned task that produced a spec), archive it to specs/done/ and rewrite it from a build-plan into a durable rationale — the why, the principles, the invariants — pointing back to the real code for the how. Use when implementation has landed and the plan no longer matches what shipped, or the user says a feature/spec is finished. Pairs with [write-spec](../write-spec/SKILL.md) (the plan this closes) and [review](../review/SKILL.md) (run before closing).
Also in 4 projects that use this
dzhngSkilldesign-with-images
Explore UI and visual design with image generation, then iterate the real implementation against the user-selected concept. Use when brainstorming visual directions, offering mockup variants, or implementing an approved generated design; do not stop at the mockups or the first code approximation.
Also in 4 projects that use this
- +5 more from ww-w-ai
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

