agentleFS
Sign inStart free
MetalLegBobMetalLegBob/solana-vibes-kit/dont-break-shit/SKILL.md

DBS

Skill19 starsChanged 9 months agoMITView on GitHub

Don't Break Shit: Controlled change management for large-scope modifications. Use when: sweeping codebase changes needed, refactoring across many files, architectural migration, any change where breaking things is the risk. Pipeline: brief → interview → analyze → map → (discuss → plan → execute) per phase. Run /DBS:brief to start, or /DBS:status to check progress.

4 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions4 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 4

    1. dontbesilent2025/dbskill★ 11ksame name
    2. Pluviobyte/rnskill★ 1.6ksame name
    3. stericishere/skills★ 1same name
    4. ftcalvinwang-ai/claude_skills★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository7 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 5 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Look for .claude/svk-meta.json in the current project.

    line 27
  2. Very specific:

    Read the svk_repo path and installed_version from the metadata file.

    line 28
  3. Very specific:

    Run: git -C <svk_repo> tag --sort=-v:refname | head -1 to get the latest tag.

    line 30
  4. Distinctive:

    If they match, skip — the user is up to date.

    line 32
  5. Distinctive:

    If the latest tag is newer, show this message ONCE (never repeat in this session):

    line 33
  6. Distinctive:

    If the git commands fail (offline, repo moved, etc.), skip silently.

    line 39
  7. Distinctive:

    Important: Do NOT block or delay the user's actual command.

    line 41
  8. Very specific:

    Run /DBS:status at any time to check progress.

    line 60
  9. Distinctive:

    If no SVK artifacts exist, this integration is silently skipped.

    line 119
  10. Very specific:

    Every phase output is a standalone .md file — if a session dies, resume from the last artifact

    line 129

≈ “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
<!-- SVK Version Check — runs once per session on first skill invocation --><svk-version-check> **On first invocation this session**, silently perform a version check:
  1. Look for .claude/svk-meta.json in the current project. If it doesn't exist, skip this check entirely.
  2. Read the svk_repo path and installed_version from the metadata file.
  3. Run: git -C <svk_repo> fetch --tags --quiet 2>/dev/null
  4. Run: git -C <svk_repo> tag --sort=-v:refname | head -1 to get the latest tag.
  5. Compare the installed version against the latest tag (strip the leading v).
  6. If they match, skip — the user is up to date.
  7. If the latest tag is newer, show this message ONCE (never repeat in this session):

SVK Update Available: v{latest} is available (you're on v{installed}).

  • Update now: I can pull and reinstall the changed skills in this session
  • Update later: Start a new chat and run /SVK:update
  1. If the git commands fail (offline, repo moved, etc.), skip silently. Never show errors from version checking.

Important: Do NOT block or delay the user's actual command. Perform this check, show the notification if needed, then proceed with the command they invoked. </svk-version-check>

Don't Break Shit

GSD gets shit done. DBS makes sure you don't break shit while doing it.

Controlled change management for large-scope codebase modifications. When a project has significant existing code, documentation, and architecture in place and needs sweeping changes, DBS ensures nothing gets missed and the LLM makes as few unsupervised micro-decisions as possible.

Getting Started

/DBS:brief

This begins a change management session by capturing your change brief and scanning the project baseline. Follow the prompts — each phase tells you what was produced and what command to run next.

Run /DBS:status at any time to check progress.

Full Pipeline

/DBS:brief → /DBS:interview → /DBS:analyze → /DBS:map
    → /DBS:discuss N → /DBS:plan N → /DBS:execute N (repeats per phase)

Phases 1-4 are sequential strategic analysis. Phase 5 repeats per execution phase, wrapping GSD's discuss/plan/execute cycle. Each command runs in its own context window.

Commands

CommandPhaseDescription
/DBS:brief1Capture change brief + scan project baseline
/DBS:interview2Deep interview mapping all changes and 1st/2nd/3rd order effects
/DBS:analyze3Sonnet blanket sweep + Opus synthesis for full impact map
/DBS:map4Generate multi-phase execution plan with testing gates
/DBS:discuss N5aWraps GSD discuss for a specific execution phase
/DBS:plan N5bWraps GSD plan for a specific execution phase
/DBS:execute N5cWraps GSD execute for a specific execution phase
/DBS:status—Progress tracking and next-step guidance

Foundation Patterns

PatternHow DBS Uses It
Thin OrchestratorPhase 3 — main context spawns Sonnet/Opus agents for analysis, doesn't do analysis itself
Signal-Based IndexingPhase 1 — scan structure first, read selectively. Phase 3 — batch files for agents
Progressive DisclosureResource loading via resources/INDEX.md — command files loaded on demand
Structured Handoff NotesAll phase outputs are .dbs/*.md files with frontmatter, consumed by subsequent phases

GSD Dependency

GSD is a soft dependency:

  • Phases 1-4 (brief, interview, analyze, map) work fully standalone — no GSD required
  • Phase 5 (discuss, plan, execute) wraps GSD's commands — GSD must be installed
  • DBS checks for GSD when you first invoke a phase 5 command and tells you if it's missing

DBS never writes to GSD's .planning/ directory. Both can run simultaneously without collision.

SVK Awareness

DBS automatically checks for SVK artifacts during /DBS:brief and uses them in subsequent phases:

  • GL documentation — reference during interview for architecture context
  • SOS audit findings — flags if changes touch areas with known vulnerabilities
  • BOK verification — warns if changes affect mathematically verified invariants
  • DB audit findings — flags if changes touch areas with known off-chain security issues

If no SVK artifacts exist, this integration is silently skipped. Non-SVK projects get full value from the core workflow.

Context Budget Strategy

  • Phase handoffs use condensed structured summaries, not raw outputs
  • Sonnet agents get bounded file batches (15-20 files) with condensed manifests
  • Opus synthesis receives condensed Sonnet reports
  • Large analysis outputs are chunked and summarized before passing to the next phase
  • Every phase output is a standalone .md file — if a session dies, resume from the last artifact

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