sonder-change-control

Classifies repository changes by blast radius and enforces CI gates before commits.

6|3|Updated Jul 3, 2026
One-click install
npx skills add https://github.com/Krilliac/Sonder-runtime --skill sonder-change-control-krilliac
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sonder-change-control
Source: https://github.com/Krilliac/Sonder-runtime/tree/main/.claude/skills/sonder-change-control
Command: npx skills add https://github.com/Krilliac/Sonder-runtime --skill sonder-change-control-krilliac

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Contributors to the Sonder Runtime repo risk pushing changes that violate shrink-only ratchets, touch protected control-plane files, or leak private data into Git history. This Skill encodes the repo's change-classification tiers, CI gate order, and hard never-commit rules so every commit clears the right gates. ## Core Features & Use Cases - Blast-radius classification: Sorts every change into tiers 0-4 (docs-only through protected control-plane) with the exact gate each tier must clear. - CI gate reproduction: Lists all seven CI steps in order with local commands, plus release-only gates like check_history_privacy.py --require-clean. - Ratchet and evidence discipline: Explains why regenerating the error-signal baseline is forbidden and what evidence SHAs a checkbox change requires. - Use Case: Before opening a PR that touches selfmod.py, run the pre-push checklist, confirm the path is in selfmod.protected_paths(), and write a commit body stating what was verified versus assumed. ## Quick Start Ask the assistant to check whether your staged Sonder Runtime changes are safe to commit and which CI gates they must pass before pushing.

Frequently Asked Questions about sonder-change-control

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if my change is safe to commit in the Sonder Runtime repo?

Classify the change into a blast-radius tier first, then run the pre-push checklist: compileall, git diff --check, the architecture and evidence checks, the error-signal ratchet, and the full pytest suite. State in the commit body what you verified, not what you believe.

What should I do when the error-signal ratchet fails in CI?

Fix the new stringly ERROR: site by migrating it to a structured error, and prove your pinning test fails without the fix. Never regenerate scripts/error_signal_baseline.json to make CI green, since that permanently widens the baseline.

Which files are protected control-plane paths in selfmod?

Run python -c "import selfmod, json; print(json.dumps(selfmod.protected_paths(), indent=2))" to get the live list. It covers permission, approval, backup, rollback, credential, and audit machinery plus the tests that pin them, and automatic edits to these paths are forbidden.

Why does CI pass on my PR but the release build still fails?

Ordinary CI runs check_history_privacy.py with --json, which only prevents new debt, while releases run --require-clean demanding zero debt. A change adding history-privacy debt can pass PR CI yet block the next release.

What files must never be committed to the Sonder Runtime repository?

Never commit personal training data or adapters (personal_dataset.jsonl, sonder-personal-lora/), memory.db or unscrubbed derivatives, or credentials of any kind including in test fixtures. Use the opt-in contribute.py export to share lessons after privacy classification.

When should I not use this change-control skill?

Use sonder-architecture-contract for layering and import boundaries, sonder-validation-and-qa for test writing and evidence quality, and sonder-selfmod-lifecycle for running the selfmod pipeline. This skill covers only classification, gates, and commit mechanics.