New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Openchamber Change Discipline

by openchamber in openchamber/openchamber

A skill your agent uses when implementing, fixing, refactoring, or otherwise modifying OpenChamber source code, dependencies, exports, build configuration, generated assets, package contracts, or…

MITAuto-check passedDevelopment

Install Openchamber Change Discipline

skills CLI
$ npx skills add openchamber/openchamber --skill openchamber-change-discipline -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install openchamber/openchamber openchamber-change-discipline --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/openchamber/openchamber.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/openchamber-change-discipline .claude/skills/openchamber-change-discipline && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
openchamber-change-discipline
GitHub stars
11k
Token cost
~2.1k tokens
SKILL.md length
1,079 words
Files
2 (incl. references)
Skills in repo
21
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when implementing, fixing, refactoring, or otherwise modifying OpenChamber source code, dependencies, exports, build configuration, generated assets, package contracts, or…

  • Works in 3 steps: Inspect nearby implementation, callers,… → Classify every applicable change risk… → Identify every affected consumer,…
  • Otherwise modifying OpenChamber source code
  • SKILL.md covers Core Principle, Before Editing, Risk Classification and Structural Discipline, plus 4 more sections
  • Calls node, docker and bun

What it does

Openchamber Change Discipline is an agent skill from openchamber/openchamber. Use when implementing, fixing, refactoring, or otherwise modifying OpenChamber source code, dependencies, exports, build configuration, generated assets, package contracts, or module ownership.

Its SKILL.md is about 2.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/updater-testing.md`).

It sits in Development, covering Refactoring. The repository describes itself as: Agentic Development Environment based on OpenCode AI agent. The licence is MIT.

When your agent uses it

  • Otherwise modifying OpenChamber source code
  • Build configuration
  • Generated assets
  • Package contracts

Example prompts

  • “/openchamber-change-discipline”

Requirements

  • Docker

Workflow steps

3 steps, taken from the first numbered list in SKILL.md.

  1. Inspect nearby implementation, callers, and tests before introducing a pattern.
  2. Classify every applicable change risk below.
  3. Identify every affected consumer, runtime, persisted format, and public export. This step is complete only when each risk has an owner and…

What it can do on your machine

Read from SKILL.md and the folder at commit 09494f3. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • node
    • docker
    • bun
    • tsc

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use docker, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Openchamber Change Discipline loads about 2.1k tokens when it runs, and up to ~4.4k if it reads all its reference files. Until then it costs about 56 tokens; SKILL.md has 1,079 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~56
When it runs · the whole SKILL.md, loaded when a task matches
~2.1k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~4.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from openchamber/openchamber at commit 09494f3, republished under its MIT licence (© openchamber). 1,079 words, ~2,058 tokens.

Download SKILL.mdSave it as .claude/skills/openchamber-change-discipline/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
openchamber-change-discipline
description
Use when implementing, fixing, refactoring, or otherwise modifying OpenChamber source code, dependencies, exports, build configuration, generated assets, package contracts, or module ownership.

OpenChamber Change Discipline

Core Principle

Make the smallest complete change and validate at the narrowest level that covers the real risk.

Before Editing

  1. Inspect nearby implementation, callers, and tests before introducing a pattern.
  2. Classify every applicable change risk below.
  3. Identify every affected consumer, runtime, persisted format, and public export. This step is complete only when each risk has an owner and required validation.

Risk Classification

RiskExamplesPlanning consequence
Local implementationPrivate helper or component behavior in one packagePreserve observable behavior; validate the owning package
Module contractExported API/type or documented module invariantInspect consumers; update contract tests and owning docs
Cross-workspace contractShared UI/runtime/package shape consumed by multiple workspacesTrace every actual consumer and runtime; validate across workspaces
Persisted or external behaviorStored settings/data, routes, IDs, files, CLI outputDefine compatibility, round-trip, failure, and conversion behavior for existing consumers
Platform/runtime behaviorElectron, VS Code, mobile, relay, native or packaged behaviorRun the relevant runtime/build/integration validation

Apply every matching category. Do not escalate local work into workspace-wide ritual, and do not treat a type-only export as local merely because it emits no JavaScript.

Structural Discipline

  • Preserve behavior established by callers and tests unless the request replaces it. Keep the diff scoped to the complete requested behavior.
  • Make the normal use-case path read top to bottom in domain terms. Keep orchestration entrypoints thin and move mechanics or domain logic behind focused, intention-revealing boundaries.
  • Pull complexity downward only when a boundary hides meaningful mechanics, owns an invariant, isolates a proven integration, or captures stable repetition. Do not spread obvious code across pass-through layers.
  • Prefer explicit dependencies and dependency injection over hidden module coupling.
  • Follow local TypeScript types; avoid any, blind casts, and guessed payload shapes.
  • Reject invalid inputs and broken preconditions early so the valid path stays flat. Do not force a numeric happy-path/error-path ratio when correctness requires substantial failure handling.
  • Require evidence before adding retries, caches, compatibility paths, lifecycle machinery, or generalized race handling. Security, data-loss, destructive-operation, and concurrency invariants still require proactive design when the risk is inherent to the operation.
  • Make partial failure, rollback, cleanup, and user-visible outcomes explicit for destructive or multi-step work.

Review Prompts

Before broadening a change, ask:

  • Is the new abstraction reused or merely possible to reuse?
  • What concrete complexity, invariant, stable repetition, or boundary does each new helper, interface, layer, and file pay for?
  • Is the code in the package that owns the behavior?
  • Does the change alter shared UI contracts across web, desktop, VS Code, or mobile?
  • Does it change persisted data, IDs, routes, exports, generated files, or package entrypoints?
  • Can failure leave optimistic state, caches, files, or remote state stranded?

For partial or destructive flows, answer explicitly:

  • What remains valid after the first failure?
  • What is rolled back or cleaned up?
  • What can be retried or resumed safely?
  • What does the user observe?

For persisted data, require a migration only when existing stored data needs conversion. Test downgrade compatibility only when older application versions are a concrete supported consumer. "Rollback" means preserving/restoring valid state after a failed write or migration unless a broader contract explicitly says otherwise.

Do not hide a required architectural migration behind a local heuristic. Do not turn a local fix into a speculative rewrite.

Show full SKILL.md (539 more words)Show less

Validation Matrix

ChangeMinimum validation
Executable sourceFocused tests for the changed behavior; type-check and lint come from the pre-commit gate. TypeScript and lint do not cover server JS, CLI JS, Electron helpers, or native code: run node --check, focused tests, or the build for those
Cross-workspace/shared contractWorkspace-wide type-check and lint plus affected builds/tests
Added/deleted/renamed source file, export/type/entrypoint/import shapeRelevant checks; dead code comes from the pre-commit gate
Persisted or external contractCompatibility and round-trip tests plus the applicable failure/ordering cases: missing-versus-empty, malformed data, stale reads versus newer mutations, out-of-order writes, lifecycle handling for debounced writes, conversion, and failed-write/migration rollback
Dependency or lockfileWorkspace-wide checks and affected builds
Added, renamed, or removed packages/* workspaceMirror it in the Dockerfile deps stage, which copies those manifests by name, then run docker build .: a COPY of a missing workspace fails the build, and a workspace another one depends on fails the frozen install when absent. CI does not build the image.
Generated assetRegeneration check plus consumer build/test
Docs-only or isolated configNarrow syntax/schema/link validation; do not run unrelated full suites
Platform/runtime behaviorRelevant runtime build or manual/integration check; static checks are insufficient
Desktop update or quit/install sequenceA real update run; read references/updater-testing.md first, because a run done the obvious way completes the update and reports success while testing nothing

bun run check:changed is the pre-commit gate: run it once, right before a commit, on the finished diff. While iterating, run only the focused tests for the behavior you just changed; an edit to docs, comments, or strings needs no check at all.

When several agents edit one checkout in parallel, they edit and run single test files only. The coordinator runs type-check, lint, builds and full suites once, serially, on the combined diff: each tsc -b over packages/ui takes gigabytes, parallel copies have frozen the machine, and a check run mid-edit reports the other agents' half-finished work.

Use a sufficiently long timeout for broad checks. Report exactly what ran and what did not.

Choose affected builds/tests by tracing real consumers and runtime boundaries, not by running everything reflexively.

For type-only shared contracts, validate compile-time consumers. Add runtime serialization tests when the contract crosses a process, persistence, network, or untyped JavaScript boundary.

Test Design

  • Prefer observable contracts, state transitions, failure handling, rollback, and operation counts.
  • Test private helpers through public/module behavior when that captures the risk clearly.
  • Assert internal map shape, helper calls, or call order only when that structure/order is itself a contract.
  • Keep refactor tests resilient to equivalent internal implementations.
  • For behavior-preserving refactors, establish the current behavior before changing structure.

Completion Standard

  • Implement the behavior end to end, including rollback and cleanup.
  • Run focused regression tests for the changed contract; when no test can cover it, say so in the report.
  • Preserve unrelated changes encountered in shared files.
  • Re-read the owning docs and update them when the implementation changed their truth.
  • Perform a final simplification pass over your own diff, hardest after a rework or a removal: every branch, condition, prop, parameter, export, key, and helper the change made unreachable, always-true, or single-valued is gone, along with speculative branches, shallow wrappers, stale compatibility, and names that do not clarify intent.
  • Before a commit, the pre-commit gate passes.

© openchamber, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in .agents/skills/openchamber-change-discipline of openchamber/openchamber.

  • SKILL.md
  • references/updater-testing.md

Open the folder on GitHubat commit 09494f3

Compare with similar skills

Openchamber Change Discipline next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Openchamber Change Discipline compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Openchamber Change Discipline this skillopenchamber/openchamber11k—~2.1kAutomated safety check: PassMIT
Guidelinesakash-network/node1.1k20 repos~577Automated safety check: PassMIT
Migrate Core Code to Submodulestinyhumansai/openhuman42k—~2.6kAutomated safety check: PassGPL-3.0
Component Refactoringlangflow-ai/langflow155k—~3.5kAutomated safety check: PassMIT
Ponytail Lazy Developer ModeDietrichGebert/ponytail160k1 repos~873Automated safety check: PassMIT
ast-grep Structural Searchcode-yeongyu/oh-my-openagent70k—~3.3kAutomated safety check: PassMIT

Similar skills

  • Guidelines

    akash-network/node

    Behavioral guidelines to reduce common LLM coding mistakes. An agent skill from akash-network/node.

    1.1k GitHub starsUsed in 20 repos~577 tokens
    DevelopmentAuto-check passed

  • Migrate Core Code to Submodules

    tinyhumansai/openhuman

    Plans and carries out moving non-host-specific code and its tests from the OpenHuman core into vendored tiny submodule libraries, then releases the submodule and re-pins the host.

    42k GitHub stars~2.6k tokensUpdated today
    DevelopmentAuto-check passed

  • Component Refactoring

    langflow-ai/langflow

    Refactor high-complexity React components in Langflow frontend.

    155k GitHub stars~3.5k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Ponytail Lazy Developer Mode

    DietrichGebert/ponytail

    Makes the agent pick the laziest solution that works: skip unneeded work, reuse what exists, prefer the standard library and platform features, and keep diffs small.

    160k GitHub starsUsed in 1 repo~873 tokens
    DevelopmentAuto-check passed

  • ast-grep Structural Search

    code-yeongyu/oh-my-openagent

    Searches and rewrites code by syntax-tree shape across 25 languages with ast-grep, for codemods, structural queries and YAML lint rules, using a Python wrapper script.

    70k GitHub stars~3.3k tokensUpdated today
    DevelopmentAuto-check passed

  • Systematic Code Refactoring

    luongnv89/claude-howto

    Guides refactoring in phases based on Martin Fowler's method: research, test coverage check, planning and small tested steps, with your approval at each phase.

    42k GitHub stars~3k tokensUpdated today
    DevelopmentAuto-check passed

More from openchamber/openchamber

All 21 skills in this repo

  • Theme System

    openchamber/openchamber

    A skill your agent uses when creating or modifying OpenChamber UI components, styling, colors, buttons, visual states, themes, or icons.

    11k GitHub stars~1.6k tokensUpdated today
    Auto-check passed

  • UI API Decoupling

    openchamber/openchamber

    A skill your agent uses when creating or modifying OpenChamber shared UI data access, OpenCode SDK calls, RuntimeAPIs, runtime fetch/auth/URLs, authenticated browser assets, bridges/proxies, runtime…

    11k GitHub stars~2k tokensUpdated today
    Auto-check passed

  • Drag To Reorder

    openchamber/openchamber

    A skill your agent uses when implementing or modifying OpenChamber sortable or drag-to-reorder behavior, especially @dnd-kit, touch/mobile interactions, variable-width items, or wrapping layouts.

    11k GitHub stars~1.8k tokensUpdated today
    Auto-check passed

  • Locale UI Patterns

    openchamber/openchamber

    A skill your agent uses when creating or modifying OpenChamber UI text, labels, buttons, placeholders, aria labels, empty states, toasts, dialogs, settings copy, navigation labels, or any…

    11k GitHub stars~1.5k tokensUpdated today
    Auto-check passed

  • Serve Sim

    openchamber/openchamber

    A skill your agent uses when working with the OpenChamber iOS Simulator app without opening Xcode - boot/install/launch the Capacitor iOS app, start a browser stream, tap/type/gesture/rotate…

    11k GitHub stars~619 tokensUpdated today
    Auto-check passed

  • Clack CLI Patterns

    openchamber/openchamber

    A skill your agent uses when creating or modifying OpenChamber CLI commands, prompts, terminal output, non-TTY behavior, --quiet, or --json behavior.

    11k GitHub stars~1.5k tokensUpdated today
    Auto-check passed

Categories

Questions about Openchamber Change Discipline

What does Openchamber Change Discipline do?

A skill your agent uses when implementing, fixing, refactoring, or otherwise modifying OpenChamber source code, dependencies, exports, build configuration, generated assets, package contracts, or…. Openchamber Change Discipline is an agent skill from openchamber/openchamber. Use when implementing, fixing, refactoring, or otherwise modifying OpenChamber source code, dependencies, exports, build configuration, generated assets, package contracts, or module ownership.

When should I use Openchamber Change Discipline?

Openchamber Change Discipline fits situations like: otherwise modifying OpenChamber source code; build configuration; generated assets; package contracts.

How do I install Openchamber Change Discipline in Claude Code?

Run `npx skills add openchamber/openchamber --skill openchamber-change-discipline -a claude-code`. Or copy the skill folder (.agents/skills/openchamber-change-discipline in openchamber/openchamber) into .claude/skills/openchamber-change-discipline in your project. Claude Code loads it when a task matches its description.

How do I install Openchamber Change Discipline in Codex?

Run `npx skills add openchamber/openchamber --skill openchamber-change-discipline -a codex`. Or copy the skill folder (.agents/skills/openchamber-change-discipline in openchamber/openchamber) into .agents/skills/openchamber-change-discipline in your project. Codex loads it when a task matches its description.

Can I use Openchamber Change Discipline in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add openchamber/openchamber --skill openchamber-change-discipline -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/openchamber-change-discipline, .gemini/skills/openchamber-change-discipline, .github/skills/openchamber-change-discipline and .opencode/skills/openchamber-change-discipline in your project.

What does Openchamber Change Discipline need to run?

Going by SKILL.md and its folder, Openchamber Change Discipline needs the command-line tools its instructions call (node, docker, bun and tsc). Our summary lists: Docker.

Does Openchamber Change Discipline access the network?

SKILL.md contains no URLs. Its commands use docker, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Openchamber Change Discipline safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Openchamber Change Discipline use?

Openchamber Change Discipline is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Openchamber Change Discipline use?

About 2.1k tokens (SKILL.md is roughly 8.2k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2.4k tokens, read only when the agent opens those files.

What are the alternatives to Openchamber Change Discipline?

Skills that share tags, products or a category with Openchamber Change Discipline: Guidelines (akash-network/node, 1.1k stars), Migrate Core Code to Submodules (tinyhumansai/openhuman, 42k stars), Component Refactoring (langflow-ai/langflow, 155k stars) and Ponytail Lazy Developer Mode (DietrichGebert/ponytail, 160k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Openchamber Change Discipline?

openchamber (a GitHub organization) maintains it in openchamber/openchamber, which has 11,418 GitHub stars. The repository holds 21 skills in this directory. The repository was last updated on October 11, 2026.

Source: openchamber/openchamber on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.