agentleFS
Sign inStart free
AhmiDarrowAhmiDarrow/RemedyAI/skills/change-safety/SKILL.md

change-safety

Skill5 starsChanged 24 days agoApache-2.0View on GitHub

Blast-radius protocol before code changes — name the surface, list coupled neighbors, run paired checks, and smoke UI/chrome/messengers that unit tests miss. Use when implementing, fixing, refactoring, reviewing risk, or when the user says don't break anything / check neighbors / change safety.

  • Commits and pushes

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run this before multi-file work (and again before commit/ship).

    line 17
  2. Very specific:

    Known failure class?: Prefer architecture that removes the class (e.g.

    line 43
  3. Distinctive:

    If remote CI fails: run that failed step locally, fix until green, then push.

    line 80

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Change-safety (blast radius)

Ship gates catch red tests. This skill catches “fixed A, broke B.”

Run this before multi-file work (and again before commit/ship).

When to use

  • Implement / fix / refactor / “don't break X”
  • Desktop shell, messengers, browser embed, settings, concurrent chat
  • Any monorepo or multi-surface app (desktop + web, agent + gateway)

Steps (always)

1. Name the change

One sentence: what user- or API-visible behavior changes?

2. Classify the surface

Pick primary (+ secondary): chat/ReAct · messengers/gateway · desktop chrome · workspace rails (browser/terminal) · settings/secrets · docs-only · release/packaging.

3. Blast-radius questions

  1. Same SPA / shared frontend? UI change may need rebuild + server restart for WebUI.
  2. Two processes? Sidecar + UI, dual pollers, dual port owners — avoid fights.
  3. Cross-path? Desktop stream vs messenger vs legacy chat — session provider/model.
  4. OS / Windows-only? Paths, secrets, WebView2, installers — reason about those.
  5. Hard to unit-test? Title bar, tray, embedded browser, live bots → manual smoke.
  6. Known failure class? Prefer architecture that removes the class (e.g. OS window decorations for min/max/close; exclusive poll lock for Telegram) over another patch.

4. Paired checks

If you touch…Also verify…
Gateway / TelegramSingle poller; inbound + outbound; no 409 thrash
Session stream / LLMProvider switch isolation; messenger uses session LLM
SSE / messages UINo force-reload mid-stream
Window chromeOS min/max/close; tray; close-to-tray; quit
Browser railLoad works; popout chrome clickable; external open
Settings / secretsSave + reconnect; no secrets in plain config
DocsSync/check scripts the project uses
Version / releaseAll version surfaces aligned

5. Manual smoke (when chrome / messengers / browser touched)

One clean instance: launch → short chat → window controls → browser rail → messenger round-trip (if enabled) → full quit → relaunch (no dual serve).

6. Neighbor rule before commit

List files you did not edit that couple to this change and confirm tested or safe. If unsure: targeted test or commit note Risk: … / Smoke: ….

7. What CI does not prove

CI does not click title bars, drive Telegram, or exercise multiwebview on a real GPU. Green CI is necessary, not sufficient for those zones.

8. Local CI before every push

Remote CI is not a surprise. Run the same commands .github/workflows/ci.yml runs (ruff, mypy, docs, pytest, desktop npm test+build — see root AGENTS.md Local CI). Pytest-only is not enough.

If remote CI fails: run that failed step locally, fix until green, then push. Do not push a guess.

After implementation

  • Targeted tests for behavior you changed
  • Full suite when shipping or when user asked “test everything”
  • Local CI commands green before git push
  • For ship/release, also activate project-etiquette (gate chain)

Anti-patterns

  • “Tests pass” without smoke for the surface you changed
  • Pushing after pytest-only when CI also runs ruff / mypy / docs
  • Pushing a CI-fix without re-running the failed step locally
  • Patching a recurring class of bug without changing architecture
  • Shipping desktop UI without WebUI rebuild/restart when SPA is shared
  • Dual processes fighting a single bot token or port

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.

Check your setup, free