safe-refactoring
Execute behavior-preserving or intentionally scoped refactors safely. Use this for multi-file renames, component/service extraction, state-management changes, API migrations, concurrency refactors, or any request where unrelated user work and subtle contracts must be preserved.
git clone --depth 1 https://github.com/ageerle/ruoyi-ai /tmp/safe-refactoring && cp -r /tmp/safe-refactoring/ruoyi-modules/ruoyi-chat/src/main/resources/coding-harness/skills/safe-refactoring ~/.claude/skills/safe-refactoringSKILL.md
# Safe refactoring Change structure without losing behavior, protocol validity, or concurrent user edits. ## Before mutation 1. Establish the exact behavior to preserve and the intentional behavior change, if any. 2. Locate callers, implementations, serialized forms, tests, configuration, and external protocol names. 3. Check the working tree and treat unrelated modifications as user-owned. 4. Define mechanical acceptance checks: compile, focused tests, type checks, contract tests, and diff inspection. 5. Split the work into dependency-ordered increments when a single atomic patch would be hard to verify. ## Mutation rules - Use expected content hashes for existing files; a mismatch means reload and reconcile instead of overwriting. - Prefer narrow edits and stable compatibility adapters while consumers migrate. - Keep persisted schema and event changes versioned; tolerate additive fields where forward compatibility is intended. - Preserve tool-call/result adjacency, event IDs, resource ownership, cancellation, and error semantics during agent-runtime refactors. - Do not mix broad formatting or unrelated cleanup into the functional diff. - If a generated artifact should change, update its source and regenerate it with the documented command. ## Verification loop 1. Inspect the resulting diff for accidental deletion, path drift, stale names, and expanded authority. 2. Run the smallest fast check that catches syntax/type errors, then the focused behavior tests. 3. Run broader integration checks when the changed boundary has multiple consumers. 4. Treat warnings or skipped tests relevant to the change as evidence to explain, not automatic success. 5. If verification fails, retain the diagnostic evidence, correct the implementation, and repeat. ## Completion report Report the behavioral outcome, compatibility decisions, important changed paths, and checks actually executed. Call out anything not verified. Do not describe a refactor as behavior-preserving without evidence.
Use this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files). Triggers include: any mention of 'Word doc', 'word document', '.docx', or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a 'report', 'memo', 'letter', 'template', or similar deliverable as a Word or .docx file, use this skill. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.
Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms. When Claude needs to fill in a PDF form or programmatically process, generate, or analyze PDF documents at scale.
Comprehensive spreadsheet creation, editing, and analysis with support for formulas, formatting, data analysis, and visualization. When Claude needs to work with spreadsheets (.xlsx, .xlsm, .csv, .tsv, etc) for: (1) Creating new spreadsheets with formulas and formatting, (2) Reading or analyzing data, (3) Modify existing spreadsheets while preserving formulas, (4) Data analysis and visualization in spreadsheets, or (5) Recalculating formulas
Investigate an unfamiliar repository before changing it. Use this whenever a coding task spans multiple modules, asks for architecture or root-cause analysis, names behavior whose implementation location is unknown, or risks editing before enough evidence is gathered.
Prove that a coding task is actually complete. Use this after meaningful code changes, when tests/builds fail or are skipped, before marking a plan or goal complete, and whenever acceptance depends on runtime, security, recovery, performance, or cross-module evidence.