code-quality-fix-all: Скилл исправления качества кода

--- name: code-quality-fix-all description: Fix code quality issues identified in a code quality review stored in agent_artefacts/code_quality/<topic>/. Systematically addresses issues found by the code-quality-review-all skill for ANY code quality topic, with validation and testing at each step. Use when user asks to fix issues from a code quality review, or asks to fix issues from agent_artefacts/code_quality/<topic>. --- # Code Quality Fix All Fix code quality issues identified in a code quality review. This skill systematically addresses issues found by the `code-quality-review-all` skill for ANY code quality topic, with validation and testing at each step. ## Expected Arguments When invoked, this skill expects the path to a code quality topic as an argument (e.g., `agent_artefacts/code_quality/private_api_imports`). If not provided, the skill will ask the user for the topic path. Within the topic path, there are several files: - README.md - contains description of the issue and examples of how to fix it - results.json - contains list of all identified issues - SUMMARY.md - contains summary of the identified issues **Filters and options** are specified interactively after the skill starts by using the `AskUserQuestion` tool to present options unless specified otherwise in arguments. - Which issue types to target: - all - specific types - Fix complexity level (easy only, medium and below, or all) - Which evaluations to fix (all, specific ones, evaluations with small number of issues) - Maximum number of issues to fix in this run ## Workflow ### Phase 1: Understanding the Topic and Planning 1. **Read topic documentation** - Read the README.md to understand: - What code quality issue this topic addresses - Why it matters (stability, maintainability, etc.) - How to detect the issue - How to fix the issue (fix patterns, examples) - Read results.json to get all identified issues - Identify which issues are in scope based on arguments 2. **Analyze and categorize issues** - Analyze fix complexity based on: - issue_description - suggested_fix from results.json - Fix examples in README.md - Classify as: - **Easy**: Single-line changes, clear fix pattern in README - **Medium**: Multi-line changes, well-documented fix approach - **Hard**: No clear fix pattern, requires research or copying code - Group issues by evaluation and issue type - Generate statistics for presenting to user 3. **Ask user for filtering preferences** - Use `AskUserQuestion` tool to ask: - Which evaluations to fix? (all / specific ones / most affected) - Which issue types to target? (all / specific types) - Fix complexity level? (easy only / easy+medium / all) - Max issues per run? (all / limit to specific number) - Apply filters based on user responses - Present filtered plan with: - Number of issues to fix - Breakdown by evaluation and issue type - Complexity distribution - Ask for final confirmation to proceed 4. **Validate understanding of fixes** - For each unique issue type in scope: - Check if README.md documents how to fix it - Look for "Good Examples" and "Bad Examples" sections - Check "suggested_fix" field in results.json - If fix approach is unclear for any issue type: - Research the correct approach - Update `<topic>/README.md` with findings - Ask user for guidance if still uncertain ### Phase 2: Pre-Fix Validation For each issue to be fixed: 1. **Read and understand context** - Read the entire file containing the issue (not just the line) - Understand how the problematic code is used - Look for related issues in the same file - Check for patterns that might affect the fix (e.g., multiple occurrences) - Identify any cascading changes needed (related imports, type hints, etc.) 2. **Validate the suggested fix** - Review the "suggested_fix" from results.json - Check against fix patterns in README.md - Verify the fix won't break functionality - For complex fixes: - Check if dependencies/alternatives actually exist - Validate that replacement code follows same patterns - Consider edge cases 3. **Estimate change scope** - Count how many lines will change for this fix - Identify if cascading changes are needed - Determine if multiple files need updating - **If changes exceed 100 lines for a single issue:** - Alert user with: - Issue details - Why the change is large - What will change - Get explicit approval before proceeding ### Phase 3: Applying Fixes 1. **Apply fixes systematically** - Create a new branch to apply fixes to, with a name like agent/<short_description_of_issue> - Process one evaluation at a time - Within each evaluation, group by issue type - For each fix: - Use Edit tool to apply the change - Follow the suggested_fix guidance - Apply fix patterns from README.md - Handle related issues in same file together - Add comments if the fix requires it (e.g., copied code attribution) - Track what was fixed 1. **Verify changes compile/parse** - After fixing each file, validate: - File is syntactically valid (Python can parse it) - No obvious import errors introduced - Code follows repository patterns - If validation fails: - Investigate the issue - Attempt to fix validation error - Rollback change if cannot be resolved 2. **Track progress** - Maintain list of: - Issues successfully fixed (file, line, issue type) - Issues that couldn't be fixed (with reasons) - Evaluations that have been modified - Files that were changed ### Phase 4: Testing and Validation 1. **Run linting** - Run repository's linter on modified files (ruff, flake8, mypy, etc.) - Check for: - Import errors - Type checking errors - Style violations introduced - Fix any linting issues that result from changes - If linting issues can't be fixed, document them 2. **Run unit tests** - Identify test files for each modified evaluation - Run unit tests for affected evaluations using pytest: **Basic test commands:** ```bash # Install relevant packages in the event of import failure uv sync --extra test # Run tests for a specific evaluation uv run pytest tests/<evaluation_name>/ # Run a specific test file uv run pytest tests/test_file.py # Run a specific test uv run pytest tests/test_file.py::TestClass::test_method # Run slow tests (excluded by default) uv run pytest --runslow tests/ # Skip dataset download tests uv run pytest -m 'not dataset_download' tests/ # Run only slow tests uv run pytest -m slow tests/ ``` **Test markers to be aware of:** - `@pytest.mark.slow` - Tests taking >10 seconds - `@pytest.mark.dataset_download` - Tests that download datasets - `@pytest.mark.docker` - Tests using Docker - `@pytest.mark.huggingface` - HuggingFace-related tests - Focus on tests for the specific evaluation - Look for test failures or errors - **IMPORTANT**: Do NOT run full evaluations (they take too long) unless user explicitly requests it 3. **Handle test failures** - For each test failure: - Read test output carefully - Determine if failure is caused by the fix - Check if it's a pre-existing failure - If caused by fix: - Try to adjust the fix to make tests pass - If cannot be resolved, rollback the change - Document the issue for user review - If pre-existing: - Note it but don't block on it - Inform user ### Phase 5: Re-Review and Handle Remaining Issues 1. **Update results.json with fix status** - For each issue that was fixed, add `"fix_status"` field after `"suggested_fix"`: ```json { ... "suggested_fix": "...", "fix_status": "fixed - please review" } ``` - For issues that couldn't be fixed, add explanation: ```json "fix_status": "not fixed - reason: ..." ``` - **IMPORTANT**: Do NOT remove any entries from results.json - only add/update "fix_status" - The code-quality-review-all skill owns results.json and is responsible for removing entries 2. **Re-run code quality review** - **IMPORTANT**: Use Task tool to spawn subagent running code-quality-review-all skill - Pass the same topic path - This will update results.json with current state - Compare results before and after to identify: - Issues that are now resolved (no longer appear) - New issues that may have been introduced - Issues that still remain despite fix attempts 3. **Fix remaining issues if in scope** - For each new or remaining in-scope issue: - Investigate why previous fix didn't work - Attempt alternative fix approach - Update "fix_status" with attempt results - Repeat this process until no more in-scope issues can be fixed 4. **Update topic's README.md** - Add any knowledge that you have discovered that will be useful in detecting or fixing topic-related issues in the future - Do not remove examples of bad code or patterns that were fixed - they will be useful in future reviews and fixes of future evaluations. 5. **Update SUMMARY.md** - Add a "Recent Fixes" section with: - Date of fix run - Number of issues fixed - Which evaluations were updated - Keep historical data (don't remove past information) - Update recommendations to reflect remaining work 6. **Run markdown linters** - Use `uv run pre-commit run markdownlint-fix` to fix markdown linting issues ### Phase 6: Create PR Description and Present Results 1. **Create/Update PR description (cumulative)** - Read existing `PR_DESCRIPTION.md` if it exists (from previous runs) - **Cumulative tracking**: PR description represents ALL changes from branch base, not just this run - If PR_DESCRIPTION.md exists: - Parse existing content to extract previous runs' data - Append information from this run - Update cumulative statistics - If PR_DESCRIPTION.md doesn't exist (first run): - Create new file - Format for GitHub/GitLab pull request with: - **Summary**: Brief overview of the code quality topic and total fixes (2-3 sentences) - **Overall Changes** (cumulative from all runs): - Total issues fixed across all runs by type - Total evaluations affected - Total files modified - **Fix Sessions**: List each run session with: - Date/time of run - Issues fixed in that session - Complexity level targeted (easy/medium/all) - **Fixed Issues** (cumulative): Table or list with all file paths and issue types from all runs - **Testing** (from latest run): - Which tests were run - Pass/fail status - Any test issues encountered - **Remaining Issues** (current state): - Count of issues still open - Brief note on what remains - **Review Notes** (cumulative): - Any complications or special considerations from any run - Areas that need extra attention during review - Use proper markdown formatting for PR readability - **IMPORTANT**: Do NOT commit PR_DESCRIPTION.md - it's only for creating the PR - Example structure: ```markdown ## Summary Fix private API imports code quality issues across evaluations. ## Overall Changes - Total issues fixed: 25 - Evaluations affected: 8 ## Fix Sessions ### Session 1: 2026-01-18 10:30 (Easy issues) - Fixed 10 easy issues - Targeted: Easy complexity, All evaluations ### Session 2: 2026-01-18 14:15 (Medium issues) - Fixed 15 medium issues - Targeted: Medium complexity, Specific evaluations ## Fixed Issues [Table of all fixed issues from all sessions] ## Testing [Latest test results] ## Remaining Issues 6 issues remain (4 hard, 2 require investigation) ## Review Notes - Session 1: All tests passed - Session 2: One test required adjustment in fortress/scorer.py ``` 2. **Present results to user** - Show high-level summary for **this run**: - X issues fixed in this session - Y issues remain - Z tests passed - Show **cumulative progress** from PR_DESCRIPTION.md: - Total issues fixed across all runs - Number of fix sessions completed - Show before/after statistics from SUMMARY.md - List modified files from this run - Display content of PR_DESCRIPTION.md for user review - **Do NOT automatically commit** - let user review changes 3. **Offer next steps** - **Create commit and PR**: Offer to: - Commit all changes (source files, results.json, SUMMARY.md) - Create pull request with description from PR_DESCRIPTION.md - Note: PR_DESCRIPTION.md itself is NOT committed (it's just for PR description) - The PR description includes **cumulative changes from all fix sessions** on this branch - **Run more fixes**: If issues remain, suggest running skill again with different filters - Running again will **append** to PR_DESCRIPTION.md, creating cumulative tracking - This allows iterative fixing: easy issues first, then medium, then hard - **Manual review needed**: List any issues that require manual attention ## Important Guidelines ### Safety First - **Never batch all fixes blindly** - Validate each fix type before applying en masse - **Always read before editing** - Understand context before changing code - **Verify fixes don't break functionality** - Run tests incrementally - **Be conservative** - Skip fixes you're uncertain about rather than risk breaking code - **Get approval for large changes** - Alert user when fixes exceed 100 lines - **Have rollback strategy** - Be able to revert if fixes cause problems ### Context is Critical - **Understand the quality issue** - Read README.md thoroughly - **Understand why code was written that way** - There might be good reasons - **Look for patterns** - Similar issues often need similar fixes - **Check related code** - Fixes might require updating nearby code - **Read existing comments** - Developers might have documented why they used certain patterns ### Validation at Every Step - **Verify fix patterns from README** - Don't guess how to fix - **Check suggested_fix in results.json** - Use provided guidance - **Validate changes compile** - Ensure code parses after changes - **Run linters** - Catch style and import issues - **Run tests** - Detect regressions immediately - **Re-run review** - Verify fixes actually resolve issues ### Communication - **Show plan before executing** - Let user see what will be fixed - **Alert for large changes** - Get approval for fixes >10 lines - **Report uncertainties** - Flag issues where fix approach is unclear - **Show progress** - Keep user informed during fixes - **Explain failures** - Document why certain issues couldn't be fixed - **Provide detailed reports** - Create comprehensive fix reports ### What NOT to Do - **Don't assume you know how to fix** - Always consult README.md and results.json - **Don't remove entries from results.json** - Only add/update "fix_status" field - **Don't replace PR_DESCRIPTION.md** - Append to it to maintain cumulative history across runs - **Don't run full evaluations** - Only run unit tests (evaluations are slow) - **Don't commit automatically** - Let user review changes first - **Don't commit PR_DESCRIPTION.md** - It's only for creating the PR - **Don't fix issues you can't validate** - Skip rather than risk breaking - **Don't ignore test failures** - Investigate or rollback - **Don't make unrelated changes** - Only fix the specific quality issues - **Don't assume all issues of same type are identical** - Context matters