OpenChamber Change Discipline
Enforces "smallest complete change, narrowest sufficient validation" discipline when modifying the OpenChamber codebase, preventing local fixes from ballooning into speculative rewrites.
This is a pure process/discipline document: no scripts, no permissions, no external effects or data flows, so no red-line risk exists; it explicitly demands rollback, cleanup, and explicit outcomes for destructive work. Deducted for: attribution limited to the repository MIT license — the skill file itself has no authorship or version, and publisher identity is unverified.
Internally self-consistent: the risk classification table, validation matrix, and completion standard align; it requires stopping on conflicting instructions rather than silently choosing, and reporting exactly what ran. Deducted for: nothing was executed; commands like 'bun run dead-code' depend on repository script availability, unverifiable statically — capped by the static calibration ceiling.
The description gives clear trigger conditions (implementing, fixing, refactoring OpenChamber source, dependencies, exports, build config), with well-scoped boundaries and explicit warnings against escalating local changes into workspace-wide ritual. Deducted for: hard binding to this specific monorepo (bun, knip, multi-workspace), no reuse across projects, no Chinese-language support declared.
Well-layered progressive disclosure (principle → risk classification → structural discipline → review prompts → validation matrix → test design → completion standard) with readable tables; the repo provides MIT license and SECURITY.md. Deducted for: the skill file itself lacks versioning, changelog, examples, FAQ, and an explicit maintenance/update path at the skill level.
As a change-discipline guide, its smallest-complete-change, risk-classification, and validation-matrix methodology offers real marginal value for agents modifying this repository, with concrete actionable instructions. Deducted for: static review cannot verify outcomes; value depends on model adherence; no representative output evidence — capped by static calibration.
The repository contains real CI workflows, test scripts, and a manual checklist (shortcut-registry), providing partial corroboration for the validation processes the skill invokes. Deducted for: no evidence directly covers this skill file's key paths, no executed reproduction, and thin multi-source corroboration.
- The skill is tightly bound to the OpenChamber toolchain (bun, knip, multi-workspace scripts) and does not transfer to other projects.
- All referenced validation commands (bun run dead-code, per-package test/lint) are statically cited only; none were executed or reproduced.
- The skill file has no version number or changelog, making future revisions hard to track.
- Publisher is unverified and treated as unknown; no points were added or deducted on that basis.
- Core workflows depend on overseas services (GitHub, opencode.ai); reachability from mainland-China networks is unverified.
What does this skill do, and when should you use it?
openchamber-change-discipline is one of 18 skills bundled in the OpenChamber repository (a desktop/web interface for the OpenCode AI agent), located at .agents/skills/openchamber-change-discipline/SKILL.md. It is a pure instruction-based methodology document with no scripts or tool dependencies. The skill mandates: inspecting nearby implementations, callers, and tests before editing; classifying each change by risk tier (local implementation, module contract, cross-workspace contract, persisted/external behavior, platform/runtime behavior); and validating at the narrowest level that covers the real risk. It also provides structural discipline rules (behavior preservation, dependency injection, no any types), review prompts, a validation matrix, and test design principles, ending with a completion standard.
When a change is intended, the skill guides the model to: 1) classify the change into five risk categories and assign an owner and required validation to each; 2) select minimal validation from a matrix (package-scoped type-check and lint, workspace-wide checks, bun run dead-code for export changes, compatibility and round-trip tests for persisted contracts); 3) apply structural discipline — preserve caller-established behavior, keep entrypoints thin, prefer explicit dependency injection, avoid any and blind casts, demand evidence for retries/caches/compatibility paths; 4) answer explicitly what rolls back, what gets cleaned up, what can be retried, and what the user observes for destructive or multi-step work; 5) run a final simplification pass removing speculative branches and shallow wrappers.
- A developer maintaining an OpenChamber-style multi-package monorepo who modifies exported APIs or types and needs to know which consumers are affected and which checks to run.
- A team wanting to constrain an AI agent (or new contributor) from expanding a local fix into a workspace-wide rewrite, or from disguising an architectural migration as a local patch.
- Changing persisted data, routes, or CLI output where compatibility, failure handling, and downgrade behavior must be explicitly considered.
- Making Electron or VS Code platform-behavior changes where real runtime validation must replace static checks alone.
- Designing regression tests that assert observable contracts rather than internal implementation details, keeping refactor tests resilient.
What are this skill's strengths and limitations?
- Offers a concrete validation matrix mapping change types to minimum checks, not abstract advice.
- The risk classification table ties directly to planning consequences, making test scoping mechanical.
- Definitions for destructive operations, data migration, and rollback semantics are explicit and deliberately restrained, resisting over-engineering.
- Pure documentation with no runtime dependencies — portable to any Agent Skills-compatible client.
- Tightly coupled to the OpenChamber project context (bun run dead-code, workspace structure, Electron/VS Code platforms); adapting to other projects requires rewriting specifics.
- Contains no automation scripts or check tooling — all validation depends on the executor actually running commands.
- No independent test suite or evidence that the discipline reduces defects; the source provides no adoption metrics.
- Dense and lengthy instructions may feel heavy for trivial changes.
How do you install this skill?
The skill ships with the OpenChamber repository. Obtain it by cloning https://github.com/openchamber/openchamber and using the skill at .agents/skills/openchamber-change-discipline/SKILL.md; the README does not document a separate install command for this skill. Agent Skills-standard clients typically only need the skill folder placed in their skills directory.
How do you use this skill?
Trigger it whenever implementing, fixing, refactoring, or otherwise modifying OpenChamber source, dependencies, exports, build configuration, generated assets, or module ownership. Example prompt: "I'm about to refactor this package's exported API — first classify the risks per change discipline and list every affected consumer and required validation." It also works as a pre-implementation checklist by having the agent answer the review prompts (is the new abstraction actually reused, can failure strand state, etc.).