with one click
refactoring-audit-workflow
A systematic workflow for identifying code pain points, planning refactoring, and creating GitHub issues.
Menu
A systematic workflow for identifying code pain points, planning refactoring, and creating GitHub issues.
| name | Refactoring Audit Workflow |
| description | A systematic workflow for identifying code pain points, planning refactoring, and creating GitHub issues. |
This skill guides the agent through the process of auditing the codebase for refactoring opportunities, validating findings, drafting implementation plans, and creating GitHub issues.
Goal: Identify high-value refactoring targets by looking for specific code smells.
App.axaml.cs handling UI, Startup, and Logic).switch statements or massive configuration classes that require modification for every new feature type (e.g., UploadersConfig).Actions:
list_dir to explore src and subdirectories.view_file to inspect largest files.grep_search to find "Helper" or "Manager" classes.Goal: Ensure the identified "pain point" isn't already solved or constrained by design.
Goal: Create a structured plan for each refactoring before creating issues.
Format: For each identified issue, draft a markdown section with:
[Refactor] <Title>Action:
refactoring_plans.md) or the task.md artifact for user review.Goal: proper tracking of the work.
Action:
gh issue create to submit the vetted plans.--title and --body-file arguments.Example Command:
gh issue create --title "[Refactor] Split GeneralHelpers.cs" --body-file "c:/path/to/body.md"
Use the local ShareX checkout as the source of truth for ShareX.ImageEditor, find the latest upstream commit that touches it, and port or sync the matching changes into the XerahS ShareX.ImageEditor submodule with path-aware diffing and build gates.
Orchestrate XerahS release flow in strict order: run maintenance prep first, update-changelog second (optional only if docs/CHANGELOG.md is intentionally absent), verify build, bump/commit/push/tag while syncing Chocolatey version metadata, monitor GitHub Actions every 2 minutes, ensure standard release notes content, then set pre-release by default (use explicit opt-out for stable). On failures, inspect logs, fix root cause, and retry with the next patch release.
Rules and workflows for updating docs/CHANGELOG.md, including version grouping, aggressive consolidation, and GitHub tag-linked release headings.
Repository maintenance preparation for XerahS. Use before release or changelog work to sync repositories, inspect submodule state, identify version/changelog needs, and hand off commit/push/version rules to git-workflow.
Bring src/mobile-experimental Avalonia/MAUI mobile apps to feature and behavior parity with src/mobile/ios while preserving native platform feel. Use when comparing the Swift iOS app against XerahS.Mobile.Ava, XerahS.Mobile.Maui, or the experimental iOS share extension, implementing parity gaps, or validating Android/iOS experimental mobile flows.
Bring src/mobile/android to feature and behavior parity with src/mobile/ios while keeping each app native. Use when comparing iOS Swift/SwiftUI/UIKit mobile behavior against Android Kotlin/Jetpack Compose behavior, implementing missing Android features, or validating parity with the Test Android Apps emulator QA workflow.