Addressing Detekt Violations
SkillDev toolsUse when Detekt reports a violation and you need to fix the underlying problem without papering over it with suppressions or configuration changes.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Addressing Detekt Violations skill
What this skill tells your AI
The instructions your AI receives, as published by rock3r/spectre in .agents/skills/addressing-detekt-violations/SKILL.md and read by ahel’s review.
Golden Rule
Fix the design problem. Do not use @Suppress, baselines, or config loosening as the default way
out of a finding.
What To Do First
When Detekt reports a violation:
- Identify whether it reflects a real design/code-structure problem.
- Prefer extracting collaborators or simplifying control flow over shuffling code around.
- Re-run the smallest relevant Detekt task after the fix.
Red Flags
Treat these as bad fixes:
- adding
@Suppresswith no clear boundary reason - moving methods around purely to dodge rule counts
- converting complex functions into lambdas stored in properties just to hide them from Detekt
- relaxing the config or generating a baseline without explicit user approval
Spectre Notes
ktfmtowns formatting; do not try to resolve formatting findings by adding Detekt formatting plugins or config churn.- Compose-bearing modules also run
io.nlopez.compose.rules:detekt; treat those findings like any other structural warning and prefer API/design fixes over suppressions. - If a Detekt rule seems wrong for this repo, surface it and ask before changing
config/detekt. - For current repo policy and commands, read
docs/STATIC-ANALYSIS.md.
Signals
- GitHub stars
- 35
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
addressing-detekt-violations- Source
- github.com/rock3r/spectre