technical debt tracker recipe (#5451)
Signed-off-by: Better-Boy <panaroma365@gmail.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This commit is contained in:
@@ -0,0 +1,52 @@
|
||||
version: 1.0.0
|
||||
title: "Code Complexity Analyzer"
|
||||
description: "Analyzes cyclomatic complexity and identifies overly complex functions and classes"
|
||||
instructions: |
|
||||
You are analyzing code complexity to identify technical debt.
|
||||
|
||||
Your tasks:
|
||||
1. Scan all source code files in {{ repository_path }}
|
||||
2. Calculate cyclomatic complexity for functions, methods, and classes
|
||||
3. Identify code that exceeds the complexity threshold of {{ complexity_threshold }}
|
||||
4. Look for:
|
||||
- Long functions (>50 lines)
|
||||
- Deep nesting levels (>4 levels)
|
||||
- High parameter counts (>5 parameters)
|
||||
- Large classes (>500 lines)
|
||||
|
||||
5. For each complex item found, provide:
|
||||
- File path and line number
|
||||
- Current complexity score
|
||||
- Brief explanation of why it's complex
|
||||
- Suggested refactoring approach
|
||||
|
||||
Return results in a structured format with severity levels:
|
||||
- Critical: Complexity > 2x threshold
|
||||
- High: Complexity > 1.5x threshold
|
||||
- Medium: Complexity > threshold
|
||||
|
||||
parameters:
|
||||
- key: repository_path
|
||||
input_type: string
|
||||
requirement: required
|
||||
description: "Path to the code repository"
|
||||
|
||||
- key: complexity_threshold
|
||||
input_type: number
|
||||
requirement: optional
|
||||
default: 15
|
||||
description: "Cyclomatic complexity threshold"
|
||||
|
||||
extensions:
|
||||
- type: builtin
|
||||
name: developer
|
||||
timeout: 300
|
||||
bundled: true
|
||||
|
||||
settings:
|
||||
temperature: 0.2
|
||||
|
||||
prompt: |
|
||||
Analyze code complexity in {{ repository_path }}.
|
||||
Flag any function/method with cyclomatic complexity > {{ complexity_threshold }}.
|
||||
Provide specific file paths, line numbers, and refactoring recommendations.
|
||||
@@ -0,0 +1,69 @@
|
||||
version: 1.0.0
|
||||
title: "Dependency Health Analyzer"
|
||||
description: "Analyzes dependencies for outdated versions, vulnerabilities, and maintenance issues"
|
||||
instructions: |
|
||||
You are analyzing project dependencies to identify security and maintenance risks.
|
||||
|
||||
Your tasks:
|
||||
1. Locate dependency files:
|
||||
- package.json / package-lock.json (Node.js)
|
||||
- requirements.txt / Pipfile (Python)
|
||||
- pom.xml / build.gradle (Java)
|
||||
- Gemfile / Gemfile.lock (Ruby)
|
||||
- go.mod (Go)
|
||||
- Cargo.toml (Rust)
|
||||
|
||||
2. For each dependency, check:
|
||||
- Current version vs latest stable version
|
||||
- Last update date
|
||||
- Known security vulnerabilities (CVEs)
|
||||
- Maintenance status (archived, deprecated)
|
||||
- License compatibility
|
||||
|
||||
3. Flag dependencies that are:
|
||||
- Critical: Known security vulnerabilities
|
||||
- High: Outdated by >{{ max_age_days }} days or deprecated
|
||||
- Medium: Minor updates available
|
||||
- Low: Patch updates available
|
||||
|
||||
4. Identify:
|
||||
- Unused dependencies that can be removed
|
||||
- Duplicate dependencies
|
||||
- Heavy dependencies that could be replaced
|
||||
- Missing security patches
|
||||
|
||||
5. Provide upgrade recommendations with potential breaking changes noted.
|
||||
|
||||
parameters:
|
||||
- key: repository_path
|
||||
input_type: string
|
||||
requirement: required
|
||||
description: "Path to the code repository"
|
||||
|
||||
- key: max_age_days
|
||||
input_type: number
|
||||
requirement: optional
|
||||
default: 365
|
||||
description: "Flag dependencies older than this many days"
|
||||
|
||||
- key: check_vulnerabilities
|
||||
input_type: string
|
||||
requirement: optional
|
||||
default: "true"
|
||||
description: "Whether to check for known vulnerabilities"
|
||||
|
||||
extensions:
|
||||
- type: builtin
|
||||
name: developer
|
||||
timeout: 300
|
||||
bundled: true
|
||||
|
||||
settings:
|
||||
temperature: 0.2
|
||||
|
||||
prompt: |
|
||||
Analyze dependencies in {{ repository_path }}.
|
||||
Check for vulnerabilities: {{ check_vulnerabilities }}
|
||||
Flag dependencies older than {{ max_age_days }} days.
|
||||
|
||||
Provide specific upgrade recommendations prioritized by security impact.
|
||||
@@ -0,0 +1,69 @@
|
||||
version: 1.0.0
|
||||
title: "Documentation Quality Analyzer"
|
||||
description: "Identifies missing, outdated, or inadequate documentation"
|
||||
instructions: |
|
||||
You are analyzing documentation quality to identify gaps and issues.
|
||||
|
||||
Your tasks:
|
||||
1. Check for essential documentation:
|
||||
- README.md with setup/usage instructions
|
||||
- CONTRIBUTING.md for contributor guidelines
|
||||
- API documentation for public interfaces
|
||||
- Architecture/design documents
|
||||
- Inline code comments for complex logic
|
||||
|
||||
2. Analyze existing documentation for:
|
||||
- Completeness - are all public APIs documented?
|
||||
- Accuracy - does code match documentation?
|
||||
- Clarity - is it easy to understand?
|
||||
- Examples - are there usage examples?
|
||||
- Maintenance - is it up to date?
|
||||
|
||||
3. Identify specific gaps:
|
||||
- Undocumented public functions/classes
|
||||
- Complex code without explanatory comments
|
||||
- Missing setup/installation instructions
|
||||
- Absence of examples or tutorials
|
||||
- Outdated documentation (check git history)
|
||||
|
||||
4. Prioritize documentation tasks:
|
||||
- Critical: Public APIs with no documentation
|
||||
- High: Complex code without comments
|
||||
- Medium: Missing examples/tutorials
|
||||
- Low: Incomplete inline comments
|
||||
|
||||
Provide specific file paths and function signatures that need documentation.
|
||||
|
||||
parameters:
|
||||
- key: repository_path
|
||||
input_type: string
|
||||
requirement: required
|
||||
description: "Path to the code repository"
|
||||
|
||||
- key: check_readme
|
||||
input_type: string
|
||||
requirement: optional
|
||||
default: "true"
|
||||
description: "Whether to check README quality"
|
||||
|
||||
- key: check_api_docs
|
||||
input_type: string
|
||||
requirement: optional
|
||||
default: "true"
|
||||
description: "Whether to check API documentation"
|
||||
|
||||
extensions:
|
||||
- type: builtin
|
||||
name: developer
|
||||
timeout: 300
|
||||
bundled: true
|
||||
|
||||
settings:
|
||||
temperature: 0.3
|
||||
|
||||
prompt: |
|
||||
Analyze documentation in {{ repository_path }}.
|
||||
Check README quality: {{ check_readme }}
|
||||
Check API docs: {{ check_api_docs }}
|
||||
|
||||
Identify missing or inadequate documentation and provide specific recommendations.
|
||||
@@ -0,0 +1,66 @@
|
||||
version: 1.0.0
|
||||
title: "Code Duplication Detector"
|
||||
description: "Identifies duplicated code blocks that should be refactored into reusable components"
|
||||
instructions: |
|
||||
You are analyzing code for duplication to identify refactoring opportunities.
|
||||
|
||||
Your tasks:
|
||||
1. Scan all source code files in {{ repository_path }}
|
||||
2. Identify duplicated code blocks:
|
||||
- Similar functions/methods (>{{ similarity_threshold }} similarity)
|
||||
- Copy-pasted code sections (>{{ min_lines }} lines)
|
||||
- Repeated patterns and logic
|
||||
- Similar class structures
|
||||
|
||||
3. For each duplication found:
|
||||
- Show both/all locations (file paths and line numbers)
|
||||
- Calculate similarity percentage
|
||||
- Estimate lines of duplicated code
|
||||
- Assess refactoring complexity
|
||||
|
||||
4. Suggest refactoring strategies:
|
||||
- Extract common functions/utilities
|
||||
- Create base classes or mixins
|
||||
- Use composition or inheritance
|
||||
- Apply design patterns (Strategy, Template Method, etc.)
|
||||
|
||||
5. Prioritize by impact:
|
||||
- Critical: >100 lines duplicated, appears 3+ times
|
||||
- High: >50 lines duplicated, appears 2+ times
|
||||
- Medium: >20 lines duplicated
|
||||
- Low: Minor code similarities
|
||||
|
||||
Focus on duplications that will provide the most maintenance benefit when refactored.
|
||||
|
||||
parameters:
|
||||
- key: repository_path
|
||||
input_type: string
|
||||
requirement: required
|
||||
description: "Path to the code repository"
|
||||
|
||||
- key: min_lines
|
||||
input_type: number
|
||||
requirement: optional
|
||||
default: 10
|
||||
description: "Minimum lines for a code block to be considered duplicate"
|
||||
|
||||
- key: similarity_threshold
|
||||
input_type: number
|
||||
requirement: optional
|
||||
default: 0.85
|
||||
description: "Similarity threshold (0.0-1.0) for detecting duplicates"
|
||||
|
||||
extensions:
|
||||
- type: builtin
|
||||
name: developer
|
||||
timeout: 300
|
||||
bundled: true
|
||||
|
||||
settings:
|
||||
temperature: 0.2
|
||||
|
||||
prompt: |
|
||||
Detect code duplication in {{ repository_path }}.
|
||||
Find blocks >{{ min_lines }} lines with >{{ similarity_threshold }} similarity.
|
||||
|
||||
Provide specific locations and refactoring recommendations for each duplication.
|
||||
@@ -0,0 +1,54 @@
|
||||
version: 1.0.0
|
||||
title: "Test Coverage Analyzer"
|
||||
description: "Identifies code with insufficient test coverage and missing test cases"
|
||||
instructions: |
|
||||
You are analyzing test coverage to identify untested code.
|
||||
|
||||
Your tasks:
|
||||
1. Locate test files and test frameworks used (Jest, pytest, JUnit, etc.)
|
||||
2. Identify the test coverage reporting mechanism if available
|
||||
3. Analyze which parts of the codebase lack tests:
|
||||
- Public APIs and exported functions
|
||||
- Critical business logic
|
||||
- Error handling paths
|
||||
- Edge cases
|
||||
|
||||
4. For each file/module below {{ min_coverage }}% coverage:
|
||||
- Calculate estimated current coverage
|
||||
- Identify specific untested functions/methods
|
||||
- Prioritize based on code criticality
|
||||
- Suggest test cases that should be added
|
||||
|
||||
5. Check for:
|
||||
- Missing unit tests
|
||||
- Missing integration tests
|
||||
- Missing error case tests
|
||||
- Flaky or skipped tests
|
||||
|
||||
Focus on high-value areas where tests would most improve reliability.
|
||||
|
||||
parameters:
|
||||
- key: repository_path
|
||||
input_type: string
|
||||
requirement: required
|
||||
description: "Path to the code repository"
|
||||
|
||||
- key: min_coverage
|
||||
input_type: number
|
||||
requirement: optional
|
||||
default: 80
|
||||
description: "Minimum acceptable test coverage percentage"
|
||||
|
||||
extensions:
|
||||
- type: builtin
|
||||
name: developer
|
||||
timeout: 300
|
||||
bundled: true
|
||||
|
||||
settings:
|
||||
temperature: 0.2
|
||||
|
||||
prompt: |
|
||||
Analyze test coverage in {{ repository_path }}.
|
||||
Identify code with coverage below {{ min_coverage }}%.
|
||||
Prioritize critical paths that lack tests and recommend specific test cases to add.
|
||||
@@ -0,0 +1,115 @@
|
||||
version: 1.0.0
|
||||
title: "Technical Debt Tracker"
|
||||
description: "Comprehensive analysis of technical debt in a code repository including complexity, test coverage, documentation, dependencies, and code duplication"
|
||||
author:
|
||||
contact: Better-Boy
|
||||
|
||||
instructions: |
|
||||
You are a senior software engineer conducting a comprehensive technical debt analysis.
|
||||
|
||||
Your workflow:
|
||||
1. First, examine the repository structure at {{ repository_path }} to understand the project
|
||||
2. Identify the primary programming language(s) and frameworks used
|
||||
3. Run each sub-recipe to gather specific technical debt metrics:
|
||||
- complexity_analyzer: Identify complex code that needs refactoring
|
||||
- test_coverage_analyzer: Find untested or poorly tested code
|
||||
- documentation_analyzer: Identify missing or outdated documentation
|
||||
- dependency_analyzer: Check for outdated or vulnerable dependencies
|
||||
- duplication_detector: Find duplicated code that should be refactored
|
||||
|
||||
4. After all analyses complete, create a consolidated report that:
|
||||
- Prioritizes issues by severity (Critical, High, Medium, Low)
|
||||
- Groups related issues together
|
||||
- Provides actionable recommendations with estimated effort
|
||||
- Creates a technical debt reduction roadmap
|
||||
|
||||
5. Save the report as {{ output_file }} in markdown format
|
||||
|
||||
Be thorough but focused on issues that will have the most impact on code quality and maintainability.
|
||||
|
||||
parameters:
|
||||
- key: repository_path
|
||||
input_type: string
|
||||
requirement: required
|
||||
description: "Path to the code repository to analyze"
|
||||
|
||||
- key: output_file
|
||||
input_type: string
|
||||
requirement: optional
|
||||
default: "technical-debt-report.md"
|
||||
description: "Output file name for the technical debt report"
|
||||
|
||||
- key: complexity_threshold
|
||||
input_type: number
|
||||
requirement: optional
|
||||
default: 15
|
||||
description: "Cyclomatic complexity threshold (functions above this are flagged)"
|
||||
|
||||
- key: min_test_coverage
|
||||
input_type: number
|
||||
requirement: optional
|
||||
default: 80
|
||||
description: "Minimum acceptable test coverage percentage"
|
||||
|
||||
- key: max_dependency_age_days
|
||||
input_type: number
|
||||
requirement: optional
|
||||
default: 365
|
||||
description: "Flag dependencies older than this many days"
|
||||
|
||||
sub_recipes:
|
||||
- name: "complexity_analyzer"
|
||||
path: "./subrecipes/complexity-analysis.yaml"
|
||||
values:
|
||||
complexity_threshold: "{{ complexity_threshold }}"
|
||||
|
||||
- name: "test_coverage_analyzer"
|
||||
path: "./subrecipes/test-coverage-analysis.yaml"
|
||||
values:
|
||||
min_coverage: "{{ min_test_coverage }}"
|
||||
|
||||
- name: "documentation_analyzer"
|
||||
path: "./subrecipes/documentation-analysis.yaml"
|
||||
values:
|
||||
check_readme: "true"
|
||||
check_api_docs: "true"
|
||||
|
||||
- name: "dependency_analyzer"
|
||||
path: "./subrecipes/dependency-analysis.yaml"
|
||||
values:
|
||||
max_age_days: "{{ max_dependency_age_days }}"
|
||||
check_vulnerabilities: "true"
|
||||
|
||||
- name: "duplication_detector"
|
||||
path: "./subrecipes/duplication-detection.yaml"
|
||||
values:
|
||||
min_lines: "10"
|
||||
similarity_threshold: "0.85"
|
||||
|
||||
extensions:
|
||||
- type: builtin
|
||||
name: developer
|
||||
timeout: 300
|
||||
bundled: true
|
||||
description: "File system and code analysis tools"
|
||||
|
||||
prompt: |
|
||||
Analyze the code repository at {{ repository_path }} for technical debt.
|
||||
|
||||
Run a comprehensive analysis covering:
|
||||
- Code complexity and maintainability
|
||||
- Test coverage gaps
|
||||
- Documentation quality
|
||||
- Dependency health and security
|
||||
- Code duplication
|
||||
|
||||
Create a prioritized technical debt report and save it to {{ output_file }}.
|
||||
|
||||
activities:
|
||||
- "Scan repository structure"
|
||||
- "Analyze code complexity"
|
||||
- "Check test coverage"
|
||||
- "Review documentation"
|
||||
- "Audit dependencies"
|
||||
- "Detect code duplication"
|
||||
- "Generate prioritized report"
|
||||
Reference in New Issue
Block a user