elixir-no-shortcuts

Enforce root-cause fixes for Elixir errors without suppressing warnings.

10|2|Updated Oct 24, 2025
One-click install
npx skills add https://github.com/mkreyman/bmad-elixir --skill elixir-no-shortcuts
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: elixir-no-shortcuts
Source: https://github.com/mkreyman/bmad-elixir/tree/main/priv/skills/elixir-no-shortcuts
Command: npx skills add https://github.com/mkreyman/bmad-elixir --skill elixir-no-shortcuts

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill blocks edits that suppress warnings or ignore tools, enforcing fixes to real issues rather than masking them.

Core Features & Use Cases

  • No Ignore Footprints: Prohibits editing dialyzer.ignore or credo excludes to hide issues.
  • No Silent Fixes: Prevents code or tests from bypassing problems.
  • Systematic Debugging: Guides you to fix root causes with proper tooling.

Quick Start

When you encounter a warning or failure, use this Skill to address the underlying problem rather than silencing it.

Frequently Asked Questions about elixir-no-shortcuts

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix Dialyzer warnings instead of ignoring them in Elixir?

Dialyzer warnings indicate type mismatches or unreachable code. Fix the root cause by adding proper function specs, correcting implementations, and verifying the fix resolves the issue rather than adding entries to dialyzer.ignore.

Why does Credo report issues and what should I do instead of excluding them?

Credo detects code quality problems like complexity and style violations. Address the underlying problem by refactoring code or improving implementation rather than excluding rules in .credo.exs.

What's the best way to handle 'pattern can never match' compiler warnings in Elixir?

These warnings signal unreachable code paths. Fix them by correcting pattern logic and function implementations instead of suppressing the warnings in your build configuration.

Should I comment out failing tests or fix the code they're testing?

Failing tests expose real bugs. Fix the implementation to make tests pass rather than commenting out tests, which masks problems and breaks verification of your fixes.

How do I document that an Elixir error has been properly resolved?

After fixing the root cause—whether adding specs, refactoring logic, or correcting implementations—document the verification steps showing the warning or test failure no longer occurs.

Can I use this approach for 'no local return' and high-complexity issues?

Yes. Both require fixing the underlying problem: add type specs for 'no local return' issues and refactor to reduce complexity rather than suppressing these warnings.