Quality

DLC: Code Quality Check

Run code quality analysis against the current project and create a GitHub issue with findings.

Before running, read ../dlc/references/ISSUE-TEMPLATE.md now for the issue format, and read ../dlc/references/REPORT-FORMAT.md now for the findings data structure.

Step 1: Detect Linting Config

Scan for linting configuration and project type:

Also check for formatter configs: .prettierrc*, .editorconfig, rustfmt.toml.

Step 2: Run Quality Tools

Linting

Run the detected linter with JSON/machine-readable output:

Select the tool based on availability (command -v), not exit codes — linters exit non-zero when issues are found, which is a valid result to capture.

# JS/TS — select by availability
if command -v eslint >/dev/null 2>&1; then
  eslint . --format=json 2>/dev/null
elif command -v biome >/dev/null 2>&1; then
  biome check . --reporter=json 2>/dev/null
fi

# Python — prefer Ruff, fall back to flake8
if command -v ruff >/dev/null 2>&1; then
  ruff check . --output-format=json 2>/dev/null
elif command -v flake8 >/dev/null 2>&1; then
  flake8 . --format=json 2>/dev/null
fi

# Go
command -v golangci-lint >/dev/null 2>&1 && golangci-lint run --out-format=json 2>/dev/null

# Rust
command -v cargo-clippy >/dev/null 2>&1 && cargo clippy --message-format=json 2>/dev/null

Complexity Analysis

# JS/TS — eslint complexity rule or cr tool
eslint . --rule '{"complexity": ["warn", 10]}' --format=json 2>/dev/null

# Python
radon cc . --json --min=C 2>/dev/null

# General — if no tool available, use Claude analysis
# Look for functions > 50 lines, cyclomatic complexity > 10, deep nesting > 4 levels

Duplication Detection

# JS/TS
jscpd . --reporters=json 2>/dev/null

# General
# If no tool available, Claude analysis: search for repeated code blocks > 10 lines

Dead Code Detection

# JS/TS — select by availability
if command -v knip >/dev/null 2>&1; then
  knip --reporter=json 2>/dev/null
elif command -v ts-prune >/dev/null 2>&1; then
  ts-prune 2>/dev/null
fi

# Python
command -v vulture >/dev/null 2>&1 && vulture . 2>/dev/null

If no dedicated quality tools are available, use the Explore agent to discover code quality hotspots across the codebase. Use repomix-explorer (if available) for large codebases to get a structural overview. Then use targeted Grep and Read for detailed analysis:

• Review for unused imports, exports, and functions
• Check for unreachable code paths
• Identify overly complex functions (nesting depth, parameter count)

Step 3: Classify Findings

Map tool output to the findings format from REPORT-FORMAT.md.

Severity mapping (reinforced here for defense-in-depth):

Step 4: Create GitHub Issue

Read ../dlc/references/ISSUE-TEMPLATE.md now and format the issue body exactly as specified.

Critical format rules (reinforced here):

• Title: [DLC] Quality: {summary of top finding}
• Label: dlc-quality
• Body must contain: Scan Metadata table, Findings Summary table (severity x count), Findings Detail grouped by severity, Recommended Actions, Raw Output in collapsed details

Acquire BRANCH for the Scan Metadata table above — ISSUE-TEMPLATE.md's lifecycle acquires REPO itself. Then follow ISSUE-TEMPLATE.md's Issue Creation Command lifecycle exactly — substitute {skill-name} = quality, {Type} = Quality, {type} = quality, {additional-required-sections} = '## Raw Output':

BRANCH=$(git branch --show-current)
echo "BRANCH=$BRANCH"   # ISSUE-TEMPLATE.md's Write step is a separate tool call and can't see this shell's variables

Step 5: Report

Quality check complete.
  - Linter: {detected linter}
  - Tools used: {list}
  - Findings: {high} high, {medium} medium, {low} low
  - Issue: #{number} ({url})

If no findings, skip issue creation and report: "No quality issues found."