[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71J6CH051SZX156VGGCSVBQ":3,"skill-same:01M71J6CH051SZX156VGGCSVBQ":73},{"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":31,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M71J6CH051SZX156VGGCSVBQ","review",null,"Review checklist for reviewer agents on chipping-orchestrator PRs. Use when evaluating a developer-produced branch before approval or change-requests.","chippingway\u002Fchipping-orchestrator","chippingway","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F323052646?v=4","01M71J5ZFF9SY17XFHJ5C41BVZ","Chipping Way","01M71J5ZG5294QYTVYZJ2RHADZ",18,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freview\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[5,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"change","review checklist","developer","reviewer","branch","orchestrator","approval","use","checklist","change-requests","requests","for","prs","when","2026-11-10 10:12:30",false,"---\nname: review\ndescription: >-\n  Review checklist for reviewer agents on chipping-orchestrator PRs. Use when\n  evaluating a developer-produced branch before approval or change-requests.\n---\n\n# Reviewer skill — chipping-orchestrator\n\n## CI \u002F lint\n\nRun `env -u VIRTUAL_ENV -u CONDA_PREFIX poetry sync` in a fresh review worktree before checks; `poetry run` does not\ninstall or refresh dependencies. Include `--with docs` or `--with dashboard` when the change needs those optional\ndependencies. Clear both markers for every Poetry command so an activated environment cannot override this `.venv\u002F`.\n\nFollow the [logging and exit-status bullets](..\u002Fdevelop\u002FSKILL.md#test-execution) when running tests to retain complete\nlogs and preserve each test command's exit status. Run configured `VERIFY_COMMANDS` commands exactly as the prompt\nlists them, without adding flags or arguments. Treat added log redirection and exit-status capture as shell plumbing\naround each command; keep any redirection or status handling already present in a configured command.\n\nReject (or request fixes) if any of these are red:\n\n- `.venv\u002Fbin\u002Fpython -m ruff check orchestrator tests fuzz .github\u002Fscripts`. Common offenders to look for\n  explicitly:\n  - **F401** — unused import on a package initializer. If the import is intended as a re-export, it must\n    be aliased `from X import Y as Y` or listed in that initializer's `__all__`. A bare import will not\n    survive ruff.\n  - **F541** — f-strings without placeholders, typically in newly-added test files.\n  - **F841** — unused local in tests.\n  - **E402** — import after non-import code.\n- `.venv\u002Fbin\u002Fpython -m flake8 orchestrator tests fuzz .github\u002Fscripts --select=WPS`. All WPS naming,\n  complexity, consistency, bug-prevention, refactoring, and OOP findings are rejection criteria.\n- `git diff --check origin\u002Fmain...HEAD` — trailing whitespace and blank lines at EOF. Check it even\n  if everything else looks clean.\n- The full `.venv\u002Fbin\u002Fpython -m pytest tests` passes on the reviewed commit — run it, or use current verification\n  evidence the orchestrator handed you for exactly this subject (see [Verification evidence](#verification-evidence)).\n  Reject \"known failure\" hand-waves; if the PR claims a baseline failure, the report must include a reproduction on\n  `origin\u002Fmain` at the branch point. Otherwise the developer must fix it.\n- Every source file the PR adds (`*.py`, `*.sh`, `pyproject.toml`) places the `# Copyright 2026 Geser Dugarov` \u002F\n  `# SPDX-License-Identifier: Apache-2.0` header pair immediately after any shebang, or at the beginning of the file\n  when there is no shebang.\n\n## Verification evidence\n\nThe orchestrator hands you the workflow verification evidence current for exactly the head, requirements, and report\nyou are reviewing, when there is any, and publishes the evidence you declare on the pull request itself.\n\n- End your final message with the verification declaration the prompt teaches, above the `VERDICT:` line: the\n  `VERIFICATION: RUN \u003Chead>` block listing every command you ran with its own exit status, or\n  `VERIFICATION: REUSED sha256:\u003Crevision>` naming the evidence you were handed. List only commands you actually ran,\n  declaring each command itself without the logging and status-capture plumbing you wrapped around it. Quote output\n  as plain lines, and never infer a count or a result. An approval is acted on only when that evidence passed and\n  includes every configured `VERIFY_COMMANDS` command, written exactly as the prompt lists it.\n- Do not request changes merely so a developer or a human copies a commit SHA, a test count, or a command into the PR\n  description or the report, while valid evidence covers the current tree and verification context. The orchestrator\n  publishes that evidence with its provenance; a report describing an earlier run truthfully is not inaccurate.\n- These remain actionable: a check that failed, verification the change needs and nobody ran, a report claiming\n  something that did not happen or a result it did not observe, and evidence about another commit, report, or\n  requirements revision than the one under review.\n\n## Failure diagnostics\n\nGive every failure a change request rests on an entry of its own under the numbered finding it supports, in the\nlayout the prompt teaches, opening on the failure's name with each label on a line of its own:\n\n```\nFailure: \u003Cthe exact test ID, a descriptive scenario name, or the check that failed>\nError: \u003Cthe relevant error or assertion, as the output showed it>\nExpected: \u003Cwhat should have happened>\nObserved: \u003Cwhat happened instead>\nReproduce: \u003Cthe command, or a self-contained snippet and the command that runs it>\nUnavailable: \u003Ceach diagnostic you could not obtain, and why>\n```\n\n- A failing test is named by its exact test ID as the runner reported it, parameters included\n  (`tests\u002Fpkg\u002Ftest_mod.py::TestCase::test_name[case]`), and reproduced by a command that runs that test alone.\n- An ad hoc probe is named by a descriptive scenario name and reproduced by a self-contained snippet in a code block —\n  every import and setup step it needs — with the command that runs it. A command reading unnamed code from stdin,\n  such as `.venv\u002Fbin\u002Fpython -`, reproduces nothing by itself. Distinct scenarios are distinct entries, each with its\n  own name, error, and reproduction, even when one command ran them all.\n- A failure no test ID names — a collection or import error before any test ran, a linter finding, a crashed\n  command — is named by the check that failed and reported with its actual error. Never invent a test ID.\n- Write `Expected` and `Observed` where the error alone does not explain the failure.\n- Write `Unavailable` only where a diagnostic is missing, saying which and why, and still report the failure rather\n  than leaving it out or guessing what you could not obtain.\n- Entries and snippets belong to the findings, never inside the verification declaration, and none of their lines\n  opens on `VERIFICATION:`, `COMMAND:`, or `EXIT:`. The declaration still lists each command exactly as you ran it,\n  with its own exit status: a stdin probe stays `.venv\u002Fbin\u002Fpython -`, once per run.\n\n## Behavior preservation\n\nFor any refactor:\n\n- Workflow labels, pinned-state JSON keys, comment marker text, watermark fields, and event-emission\n  shape must match `main` exactly. Issues already in flight depend on these — a rename is a deliberate format\n  change under [C-03](..\u002F..\u002F..\u002Fdocs\u002Fcontracts.md#c-03-persisted-and-externally-consumed-formats), not a refactor.\n- Spot-check that moved code still routes through the same auth \u002F fetch \u002F push \u002F retry helpers. A\n  refactor is not allowed to silently change side effects.\n- Squash-on-approval, the in_review HITL ready-ping gates (mergeable + approved + no standing\n  CHANGES_REQUESTED), retry budgets, and stale-session detection are easy to break by accident during\n  a move; verify their call paths survive intact.\n\n## One writer per issue\n\nEach issue has one active orchestrator writer: dispatch and the per-tick base refresh take its writer claim before\nreading it and hold it through their last write\n([design constraints](..\u002F..\u002F..\u002Fdocs\u002Farchitecture.md#design-constraints)).\n\n- Do not request support for a second orchestrator writer changing the issue's pinned comment or labels during a\n  claimed operation -- adopting a successor it settled there, reconciling records it moved and put back, or wrapping\n  every reading of the comment to catch it -- and flag a PR that adds such machinery.\n- Do request handling for what still happens under the claim: a process lost between two writes, a write refused or\n  whose answer was lost, a comment with no room left, and changes from outside the orchestrator -- humans, labels,\n  issue text, pull requests, remote branches, configuration, and checkouts.\n- A successor or replacement another orchestrator operation wrote between two separately claimed operations is real;\n  the reading taken once the claim is held is what sees it, so do not dismiss that scenario as an excluded writer.\n\n## Workflow owners and stage modules\n\nMost package initializers are markers. The deliberate public APIs retain their explicit `__all__` surfaces and\nexact-path WPS410\u002FWPS412 exclusions. `orchestrator.workflow` publishes the two label vocabularies, the transition\nguard, its predicate and exception, and the lazy per-repo `tick` entry point. Labels live on `workflow\u002Fstate.py`,\nlabel parsing on `workflow\u002Flabel_reading.py`, the graph on `workflow\u002Ftransitions.py`, and write guards on\n`workflow\u002Ftransition_guard.py`.\n\n- The workflow initializer imports no engine or stage. Its `tick` shim resolves `workflow\u002Fengine\u002Ftick.py` inside\n  the call, so the GitHub and git layers can import labels and guards without an initialization cycle.\n  `tests\u002Fworkflow\u002Ftest_imports.py` checks that direction, and `tests\u002Frepository\u002Ftest_package_exports.py` holds the\n  declared public surfaces and marker initializers.\n- Settings reloads and patches target `orchestrator.config`, the same module object all callers retain.\n  `config.RepoSpec` is the public alias of `config.models.RepoSpec`; callers that need only the type may import its\n  defining owner. Token resolution is defined on `config.credentials`.\n- Stage modules import the owner they borrow from at module scope and call through that alias; flag any\n  reintroduced call-time hop through the package initializer.\n- Test patches target the module the call site names. Flag a test that patches anything else — including\n  the workflow package — since a mock left there intercepts nothing.\n- Stage-private helpers stay in the stage package that owns them. Shared helpers are read from their defining\n  owner; copying or re-exporting one creates a second patch target that can drift from the running call.\n- Workflow owners declare `log = logging.getLogger(\"orchestrator.workflow\")` with the channel spelled literally;\n  `workflow\u002Ftransition_guard.py` owns `orchestrator.state_machine`. Operator filters select on those names,\n  and `tests\u002Fworkflow\u002Ftest_imports.py` checks them.\n\n## Test economy and assertion quality\n\n- Identify newly added tests that duplicate existing tests or each other; request merging into\n  `pytest.mark.parametrize` cases or a small named loop when the only difference is fixture values or\n  branch selection.\n- Flag a class whose methods share one `setUp` scenario and differ only in which outcome they inspect.\n  Ask for one test that runs the scenario once and asserts those outcomes together, keeping every\n  assertion and its diagnostic message. Distinct scenarios stay apart: different failure inputs, crash\n  windows, security boundaries, and side effects each earn their own run.\n- Flag a test that patches a helper in the package under test and asserts `call_args`, object identity,\n  or the order two same-package helpers ran in. Ask for the outcome instead — the workflow label,\n  `pinned_data`, comments, and PR read back off the in-memory GitHub client for a stage handler, and\n  the panel order, the selected filters and timezone, and the displayed data read back off the recording\n  page doubles for a dashboard section. A seam patch is fine where the collaborator is deliberately\n  stubbed and its effect cannot otherwise be observed — a network or database read, an agent run, a\n  renderer reaching for an optional dependency — as long as it is patched on the defining owner.\n- Do not extend that to counts and ordering that are themselves contracts — forbidden pushes, duplicate\n  children or PRs, repeated charging, extra API reads or pinned-state writes, timeout cleanup,\n  write-before-publish ordering — or to literal label, pinned-state key, comment marker, watermark, and\n  event payload checks. Reject a PR that trades one of those for a looser outcome check.\n- Reject a test-economy pass that drops a package's `test_imports.py` guards, or that probes fewer owners\n  or environments than before. One fresh process per owner and per environment is the floor.\n- Verify each added regression test fails before the fix and passes afterward.\n- Require tests for changed contracts to assert those contracts directly.\n- Allow tests that document and protect existing behavior, including coverage added before refactoring.\n- For resource-usage fixes (over-fetching, redundant API calls, retained state), reject tests that\n  only assert the final result; require at least one assertion at the helper\u002Fproducer level.\n- Prefer fewer tests with clear distinct coverage over many narrowly overlapping regression tests.\n- Check placement: tests mirror the runtime layout, so a module under `orchestrator\u002F\u003Cpackage>\u002F` is covered by\n  `tests\u002F\u003Cpackage>\u002F` and stage handlers by `tests\u002Fworkflow\u002Fstages\u002F\u003Cstage>\u002F`. Flag a new omnibus module added beside\n  an existing per-behavior split, a test parked away from the owner it exercises, and a stage reaching into a\n  sibling stage's `*_test_support.py` for fixtures.\n\n## Documentation drift\n\nAfter a PR moves, renames, or deletes a symbol or module — a handler, helper, constant, or whole owner — grep the\nPR for stale pointers to that name, inventory entries and docstrings included, and request fixes in:\n\n- `docs\u002Farchitecture.md` and the focused pages under `docs\u002Farchitecture\u002F` — the module-by-module inventory\n  lives here and nowhere else, except `docs\u002Farchitecture\u002Fobservability-modules.md`, which maps\n  `observability\u002F` and `apps\u002F` at the package boundary: flag a per-module entry grown back into that page\n  rather than asking for one\n- `docs\u002Fstate-machine.md` and the focused pages under `docs\u002Fstate-machine\u002F`\n- `docs\u002Fworkflow.md` and the focused pages under `docs\u002Fworkflow\u002F`\n- module docstrings at the top of the owners the symbol moved between, was renamed in, or was deleted from, and of\n  the package initializers above them that describe where a name answers\n\n`AGENTS.md` (and its `CLAUDE.md` symlink) is deliberately off that list, and the inverse is what to flag: it is\nloaded into every agent session and carries no module, owner, or test inventory. Reject a PR that answers a routine\nmove, rename, or deletion of a symbol or module by editing it, or that grows an inventory back into it. It changes\nonly when repository-wide agent instructions, safety rules, or documentation routing change.\n\nTreat blanket statements about what a package publishes — \"every helper is re-exported\", \"the hub answers for\nthese names\" — with suspicion; verify literally against the code, since an attribute that no longer exists raises\n`AttributeError` rather than reading as stale prose.\n\n## Comment hygiene\n\n- Flag diff-relative comments — \"previously\", \"the old retry cap\", \"instead of a dict\", \"now uses\" —\n  in code and test docstrings alike. A comment must read correctly to someone who never saw the\n  change; the before\u002Fafter story belongs in the commit message or PR description.\n- Flag comments that paraphrase an already-readable line or the assert below them instead of stating\n  a why (invariant, non-local consumer, prevented failure). Ask for the reason or for deletion. Do\n  not flag plain-language summaries above genuinely dense code (tricky offset math, multi-step\n  comprehension chains) — a comment that is faster to understand than the code it heads earns its\n  place.\n\n## `plans\u002F` references\n\n- `plans\u002F` holds human working notes, not spec. Flag any code, comment, docstring, or test that cites\n  a `plans\u002F` document — or a numbered \"Proposal N\" from one — as authoritative; the change must stand\n  on its own once that note is revised or deleted. Ask for the reference to be reworded to describe the\n  behavior directly.\n- A developer should not edit or remove files under `plans\u002F` unless the issue explicitly asked. Flag\n  unrequested `plans\u002F` changes.\n\n## Commit hygiene\n\n- Conventional Commits: `\u003Ctype>: \u003Csubject>` only. Reject any commit with a body, a `Co-Authored-By`\n  trailer, or a non-imperative subject. Type must be one of `feat`, `fix`, `chore`, `docs`,\n  `refactor`, `test`.\n- Reject a developer commit whose subject ends in a numeric reference — ` (#N)` — the tracked issue's own number\n  most of all. Publication references belong to the orchestrator, which appends the pull request's own reference when\n  it publishes; a developer-written suffix lands a subject naming the issue and the pull request both. Read the\n  subjects on the branch, not only the PR title, since approval planning can reuse a developer subject verbatim.\n\n## Out of scope — push back\n\n- Dependencies outside the issue's stated scope.\n- Reformatting of files outside the change's blast radius.\n- Abstractions or generality added for hypothetical future features. The issue's stated scope is the source of truth.\n","# Reviewer skill — chipping-orchestrator\n\n## CI \u002F lint\n\nRun `env -u VIRTUAL_ENV -u CONDA_PREFIX poetry sync` in a fresh review worktree before checks; `poetry run` does not\ninstall or refresh dependencies. Include `--with docs` or `--with dashboard` when the change needs those optional\ndependencies. Clear both markers for every Poetry command so an activated environment cannot override this `.venv\u002F`.\n\nFollow the [logging and exit-status bullets](..\u002Fdevelop\u002FSKILL.md#test-execution) when running tests to retain complete\nlogs and preserve each test command's exit status. Run configured `VERIFY_COMMANDS` commands exactly as the prompt\nlists them, without adding flags or arguments. Treat added log redirection and exit-status capture as shell plumbing\naround each command; keep any redirection or status handling already present in a configured command.\n\nReject (or request fixes) if any of these are red:\n\n- `.venv\u002Fbin\u002Fpython -m ruff check orchestrator tests fuzz .github\u002Fscripts`. Common offenders to look for\n  explicitly:\n  - **F401** — unused import on a package initializer. If the import is intended as a re-export, it must\n    be aliased `from X import Y as Y` or listed in that initializer's `__all__`. A bare import will not\n    survive ruff.\n  - **F541** — f-strings without placeholders, typically in newly-added test files.\n  - **F841** — unused local in tests.\n  - **E402** — import after non-import code.\n- `.venv\u002Fbin\u002Fpython -m flake8 orchestrator tests fuzz .github\u002Fscripts --select=WPS`. All WPS naming,\n  complexity, consistency, bug-prevention, refactoring, and OOP findings are rejection criteria.\n- `git diff --check origin\u002Fmain...HEAD` — trailing whitespace and blank lines at EOF. Check it even\n  if everything else looks clean.\n- The full `.venv\u002Fbin\u002Fpython -m pytest tests` passes on the reviewed commit — run it, or use current verification\n  evidence the orchestrator handed you for exactly this subject (see [Verification evidence](#verification-evidence)).\n  Reject \"known failure\" hand-waves; if the PR claims a baseline failure, the report must include a reproduction on\n  `origin\u002Fmain` at the branch point. Otherwise the developer must fix it.\n- Every source file the PR adds (`*.py`, `*.sh`, `pyproject.toml`) places the `# Copyright 2026 Geser Dugarov` \u002F\n  `# SPDX-License-Identifier: Apache-2.0` header pair immediately after any shebang, or at the beginning of the file\n  when there is no shebang.\n\n## Verification evidence\n\nThe orchestrator hands you the workflow verification evidence current for exactly the head, requirements, and report\nyou are reviewing, when there is any, and publishes the evidence you declare on the pull request itself.\n\n- End your final message with the verification declaration the prompt teaches, above the `VERDICT:` line: the\n  `VERIFICATION: RUN \u003Chead>` block listing every command you ran with its own exit status, or\n  `VERIFICATION: REUSED sha256:\u003Crevision>` naming the evidence you were handed. List only commands you actually ran,\n  declaring each command itself without the logging and status-capture plumbing you wrapped around it. Quote output\n  as plain lines, and never infer a count or a result. An approval is acted on only when that evidence passed and\n  includes every configured `VERIFY_COMMANDS` command, written exactly as the prompt lists it.\n- Do not request changes merely so a developer or a human copies a commit SHA, a test count, or a command into the PR\n  description or the report, while valid evidence covers the current tree and verification context. The orchestrator\n  publishes that evidence with its provenance; a report describing an earlier run truthfully is not inaccurate.\n- These remain actionable: a check that failed, verification the change needs and nobody ran, a report claiming\n  something that did not happen or a result it did not observe, and evidence about another commit, report, or\n  requirements revision than the one under review.\n\n## Failure diagnostics\n\nGive every failure a change request rests on an entry of its own under the numbered finding it supports, in the\nlayout the prompt teaches, opening on the failure's name with each label on a line of its own:\n\n```\nFailure: \u003Cthe exact test ID, a descriptive scenario name, or the check that failed>\nError: \u003Cthe relevant error or assertion, as the output showed it>\nExpected: \u003Cwhat should have happened>\nObserved: \u003Cwhat happened instead>\nReproduce: \u003Cthe command, or a self-contained snippet and the command that runs it>\nUnavailable: \u003Ceach diagnostic you could not obtain, and why>\n```\n\n- A failing test is named by its exact test ID as the runner reported it, parameters included\n  (`tests\u002Fpkg\u002Ftest_mod.py::TestCase::test_name[case]`), and reproduced by a command that runs that test alone.\n- An ad hoc probe is named by a descriptive scenario name and reproduced by a self-contained snippet in a code block —\n  every import and setup step it needs — with the command that runs it. A command reading unnamed code from stdin,\n  such as `.venv\u002Fbin\u002Fpython -`, reproduces nothing by itself. Distinct scenarios are distinct entries, each with its\n  own name, error, and reproduction, even when one command ran them all.\n- A failure no test ID names — a collection or import error before any test ran, a linter finding, a crashed\n  command — is named by the check that failed and reported with its actual error. Never invent a test ID.\n- Write `Expected` and `Observed` where the error alone does not explain the failure.\n- Write `Unavailable` only where a diagnostic is missing, saying which and why, and still report the failure rather\n  than leaving it out or guessing what you could not obtain.\n- Entries and snippets belong to the findings, never inside the verification declaration, and none of their lines\n  opens on `VERIFICATION:`, `COMMAND:`, or `EXIT:`. The declaration still lists each command exactly as you ran it,\n  with its own exit status: a stdin probe stays `.venv\u002Fbin\u002Fpython -`, once per run.\n\n## Behavior preservation\n\nFor any refactor:\n\n- Workflow labels, pinned-state JSON keys, comment marker text, watermark fields, and event-emission\n  shape must match `main` exactly. Issues already in flight depend on these — a rename is a deliberate format\n  change under [C-03](..\u002F..\u002F..\u002Fdocs\u002Fcontracts.md#c-03-persisted-and-externally-consumed-formats), not a refactor.\n- Spot-check that moved code still routes through the same auth \u002F fetch \u002F push \u002F retry helpers. A\n  refactor is not allowed to silently change side effects.\n- Squash-on-approval, the in_review HITL ready-ping gates (mergeable + approved + no standing\n  CHANGES_REQUESTED), retry budgets, and stale-session detection are easy to break by accident during\n  a move; verify their call paths survive intact.\n\n## One writer per issue\n\nEach issue has one active orchestrator writer: dispatch and the per-tick base refresh take its writer claim before\nreading it and hold it through their last write\n([design constraints](..\u002F..\u002F..\u002Fdocs\u002Farchitecture.md#design-constraints)).\n\n- Do not request support for a second orchestrator writer changing the issue's pinned comment or labels during a\n  claimed operation -- adopting a successor it settled there, reconciling records it moved and put back, or wrapping\n  every reading of the comment to catch it -- and flag a PR that adds such machinery.\n- Do request handling for what still happens under the claim: a process lost between two writes, a write refused or\n  whose answer was lost, a comment with no room left, and changes from outside the orchestrator -- humans, labels,\n  issue text, pull requests, remote branches, configuration, and checkouts.\n- A successor or replacement another orchestrator operation wrote between two separately claimed operations is real;\n  the reading taken once the claim is held is what sees it, so do not dismiss that scenario as an excluded writer.\n\n## Workflow owners and stage modules\n\nMost package initializers are markers. The deliberate public APIs retain their explicit `__all__` surfaces and\nexact-path WPS410\u002FWPS412 exclusions. `orchestrator.workflow` publishes the two label vocabularies, the transition\nguard, its predicate and exception, and the lazy per-repo `tick` entry point. Labels live on `workflow\u002Fstate.py`,\nlabel parsing on `workflow\u002Flabel_reading.py`, the graph on `workflow\u002Ftransitions.py`, and write guards on\n`workflow\u002Ftransition_guard.py`.\n\n- The workflow initializer imports no engine or stage. Its `tick` shim resolves `workflow\u002Fengine\u002Ftick.py` inside\n  the call, so the GitHub and git layers can import labels and guards without an initialization cycle.\n  `tests\u002Fworkflow\u002Ftest_imports.py` checks that direction, and `tests\u002Frepository\u002Ftest_package_exports.py` holds the\n  declared public surfaces and marker initializers.\n- Settings reloads and patches target `orchestrator.config`, the same module object all callers retain.\n  `config.RepoSpec` is the public alias of `config.models.RepoSpec`; callers that need only the type may import its\n  defining owner. Token resolution is defined on `config.credentials`.\n- Stage modules import the owner they borrow from at module scope and call through that alias; flag any\n  reintroduced call-time hop through the package initializer.\n- Test patches target the module the call site names. Flag a test that patches anything else — including\n  the workflow package — since a mock left there intercepts nothing.\n- Stage-private helpers stay in the stage package that owns them. Shared helpers are read from their defining\n  owner; copying or re-exporting one creates a second patch target that can drift from the running call.\n- Workflow owners declare `log = logging.getLogger(\"orchestrator.workflow\")` with the channel spelled literally;\n  `workflow\u002Ftransition_guard.py` owns `orchestrator.state_machine`. Operator filters select on those names,\n  and `tests\u002Fworkflow\u002Ftest_imports.py` checks them.\n\n## Test economy and assertion quality\n\n- Identify newly added tests that duplicate existing tests or each other; request merging into\n  `pytest.mark.parametrize` cases or a small named loop when the only difference is fixture values or\n  branch selection.\n- Flag a class whose methods share one `setUp` scenario and differ only in which outcome they inspect.\n  Ask for one test that runs the scenario once and asserts those outcomes together, keeping every\n  assertion and its diagnostic message. Distinct scenarios stay apart: different failure inputs, crash\n  windows, security boundaries, and side effects each earn their own run.\n- Flag a test that patches a helper in the package under test and asserts `call_args`, object identity,\n  or the order two same-package helpers ran in. Ask for the outcome instead — the workflow label,\n  `pinned_data`, comments, and PR read back off the in-memory GitHub client for a stage handler, and\n  the panel order, the selected filters and timezone, and the displayed data read back off the recording\n  page doubles for a dashboard section. A seam patch is fine where the collaborator is deliberately\n  stubbed and its effect cannot otherwise be observed — a network or database read, an agent run, a\n  renderer reaching for an optional dependency — as long as it is patched on the defining owner.\n- Do not extend that to counts and ordering that are themselves contracts — forbidden pushes, duplicate\n  children or PRs, repeated charging, extra API reads or pinned-state writes, timeout cleanup,\n  write-before-publish ordering — or to literal label, pinned-state key, comment marker, watermark, and\n  event payload checks. Reject a PR that trades one of those for a looser outcome check.\n- Reject a test-economy pass that drops a package's `test_imports.py` guards, or that probes fewer owners\n  or environments than before. One fresh process per owner and per environment is the floor.\n- Verify each added regression test fails before the fix and passes afterward.\n- Require tests for changed contracts to assert those contracts directly.\n- Allow tests that document and protect existing behavior, including coverage added before refactoring.\n- For resource-usage fixes (over-fetching, redundant API calls, retained state), reject tests that\n  only assert the final result; require at least one assertion at the helper\u002Fproducer level.\n- Prefer fewer tests with clear distinct coverage over many narrowly overlapping regression tests.\n- Check placement: tests mirror the runtime layout, so a module under `orchestrator\u002F\u003Cpackage>\u002F` is covered by\n  `tests\u002F\u003Cpackage>\u002F` and stage handlers by `tests\u002Fworkflow\u002Fstages\u002F\u003Cstage>\u002F`. Flag a new omnibus module added beside\n  an existing per-behavior split, a test parked away from the owner it exercises, and a stage reaching into a\n  sibling stage's `*_test_support.py` for fixtures.\n\n## Documentation drift\n\nAfter a PR moves, renames, or deletes a symbol or module — a handler, helper, constant, or whole owner — grep the\nPR for stale pointers to that name, inventory entries and docstrings included, and request fixes in:\n\n- `docs\u002Farchitecture.md` and the focused pages under `docs\u002Farchitecture\u002F` — the module-by-module inventory\n  lives here and nowhere else, except `docs\u002Farchitecture\u002Fobservability-modules.md`, which maps\n  `observability\u002F` and `apps\u002F` at the package boundary: flag a per-module entry grown back into that page\n  rather than asking for one\n- `docs\u002Fstate-machine.md` and the focused pages under `docs\u002Fstate-machine\u002F`\n- `docs\u002Fworkflow.md` and the focused pages under `docs\u002Fworkflow\u002F`\n- module docstrings at the top of the owners the symbol moved between, was renamed in, or was deleted from, and of\n  the package initializers above them that describe where a name answers\n\n`AGENTS.md` (and its `CLAUDE.md` symlink) is deliberately off that list, and the inverse is what to flag: it is\nloaded into every agent session and carries no module, owner, or test inventory. Reject a PR that answers a routine\nmove, rename, or deletion of a symbol or module by editing it, or that grows an inventory back into it. It changes\nonly when repository-wide agent instructions, safety rules, or documentation routing change.\n\nTreat blanket statements about what a package publishes — \"every helper is re-exported\", \"the hub answers for\nthese names\" — with suspicion; verify literally against the code, since an attribute that no longer exists raises\n`AttributeError` rather than reading as stale prose.\n\n## Comment hygiene\n\n- Flag diff-relative comments — \"previously\", \"the old retry cap\", \"instead of a dict\", \"now uses\" —\n  in code and test docstrings alike. A comment must read correctly to someone who never saw the\n  change; the before\u002Fafter story belongs in the commit message or PR description.\n- Flag comments that paraphrase an already-readable line or the assert below them instead of stating\n  a why (invariant, non-local consumer, prevented failure). Ask for the reason or for deletion. Do\n  not flag plain-language summaries above genuinely dense code (tricky offset math, multi-step\n  comprehension chains) — a comment that is faster to understand than the code it heads earns its\n  place.\n\n## `plans\u002F` references\n\n- `plans\u002F` holds human working notes, not spec. Flag any code, comment, docstring, or test that cites\n  a `plans\u002F` document — or a numbered \"Proposal N\" from one — as authoritative; the change must stand\n  on its own once that note is revised or deleted. Ask for the reference to be reworded to describe the\n  behavior directly.\n- A developer should not edit or remove files under `plans\u002F` unless the issue explicitly asked. Flag\n  unrequested `plans\u002F` changes.\n\n## Commit hygiene\n\n- Conventional Commits: `\u003Ctype>: \u003Csubject>` only. Reject any commit with a body, a `Co-Authored-By`\n  trailer, or a non-imperative subject. Type must be one of `feat`, `fix`, `chore`, `docs`,\n  `refactor`, `test`.\n- Reject a developer commit whose subject ends in a numeric reference — ` (#N)` — the tracked issue's own number\n  most of all. Publication references belong to the orchestrator, which appends the pull request's own reference when\n  it publishes; a developer-written suffix lands a subject naming the issue and the pull request both. Read the\n  subjects on the branch, not only the PR title, since approval planning can reuse a developer subject verbatim.\n\n## Out of scope — push back\n\n- Dependencies outside the issue's stated scope.\n- Reformatting of files outside the change's blast radius.\n- Abstractions or generality added for hypothetical future features. The issue's stated scope is the source of truth.\n",{"name":5,"description":7},"main","987be97a68d2e55b8d0fd5b36c9a0775588fa552",".agents\u002Fskills\u002Freview",4,"https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator","https:\u002F\u002Fchippingway.github.io\u002Fchipping-orchestrator\u002F","https:\u002F\u002Fgithub.com\u002Fchippingway","2026-11-11 22:59:40",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add chippingway\u002Fchipping-orchestrator --skill review",{"tool":65,"command":66},"bunx","bunx skills add chippingway\u002Fchipping-orchestrator --skill review",{"tool":68,"command":69},"pnpm","pnpm dlx skills add chippingway\u002Fchipping-orchestrator --skill review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freview\u002FSKILL.md",true,[],[74,79,85,91,106],{"skillNo":75,"name":5,"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":76,"categories":77,"keywords":78,"publishedAt":46},"01M71J6GGHE6K199YSB0ZKM3HQ","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freview\u002FSKILL.md",[],[5],{"skillNo":80,"name":81,"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":82,"categories":83,"keywords":84,"publishedAt":46},"01M71J6FBNDZBQF3AF05RGGNTT","develop","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdevelop\u002FSKILL.md",[],[81],{"skillNo":86,"name":87,"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":88,"categories":89,"keywords":90,"publishedAt":46},"01M71J6EEGDDQY8QMDPW335XBQ","decompose","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdecompose\u002FSKILL.md",[],[87],{"skillNo":92,"name":81,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":98,"publishedAt":46},"01M71J6AC1EDHXYVA3TGBBFY13","Project conventions and recurring gotchas for implementer agents working on chipping-orchestrator. Use before committing any change in orchestrator\u002F, tests\u002F, or docs\u002F.","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdevelop\u002FSKILL.md",[96,97],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[81,99,100,39,101,43,102,37,103,32,104,105],"docs","conventions","tests","recurring","project conventions","project","implementer",{"skillNo":107,"name":87,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":112,"publishedAt":46},"01M71J671EDMQNZS2K3DGV80V2","Sizing and decomposition policy for chipping-orchestrator issues. Use when you decompose an issue or adjudicate an oversized, already-implemented change: size it, decide single versus split, plan child issues and their dependencies, and emit the manifest the active prompt requires.","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdecompose\u002FSKILL.md",[111],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[87,113,114,37,115,116,45,117,118,32,119,120,121,122,123,43,124,125,126,39],"manifest","prompt","decide","issues","you","plan","child","decomposition","split","active","issue","policy","oversized","single"]