red-flags

Red Flags Diagnostic

When invoked with $ARGUMENTS, scope the scan to the specified file or directory. Read the target code first, then run every flag below against it. Each flag points to a deeper lens from Clairvoyance (https://clairvoyance.fyi). This skill works best when the full collection is installed.

A red flag is a signal, not a diagnosis. It tells you something is wrong but not why. Each flag below points to a deeper lens that identifies the root cause.

When to Apply

• Before merging a PR or completing a design review
• When code "feels wrong" but the specific problem is unclear
• When evaluating unfamiliar code for design quality
• When asked for a "red flags check" or "design diagnostic"

The Red Flags

Structural (4)

1. Shallow Module

Interface isn't much simpler than implementation.

• Check: → deep-modules, error-design
  • Could a caller skip this module and do the work directly?
• Signals:
  • More public methods than meaningful internal state
  • Abstract class with only one implementation and no prospect of more
  • Layer that exists "for testability" but adds no abstraction value
  • A split that created more total interface surface than the original
  • Error handling code longer than the happy path
  • Excessive exceptions in a method signature

2. Pass-Through Method

Method forwards arguments to another with a similar signature, adding zero logic.

• Check: → deep-modules, abstraction-quality
  • Does removing the method lose any behavior?
• Signals:
  • Method takes N parameters, passes N-1 unchanged
  • Constructor injects collaborators just to delegate
  • Class API mirrors its dependency's API
  • Wrapper adds one behavior, delegates everything else
  • "Wrapper" or "Adapter" classes that add no functionality
  • Many thin layers providing the same abstraction
  • Decorator with nineteen pass-throughs for one behavior

3. Conjoined Methods

Two separate pieces of code that can only be understood together.