Skip to content

sliekens/engineering-workflow

v2.3.0MIT

Engineering skills for complexity and consistency analysis, test design, scenario analysis, and technical debt reviews.

analyze-complexity

Analyze a code path, system, workflow, or architecture to separate inherent complexity imposed by requirements and external constraints from accidental complexity introduced by the current implementation, then define the invariants a simplification must preserve. Use when the user asks what complexity is necessary or unavoidable, asks for inherent vs. accidental complexity, says a pipeline or subsystem feels too complex, wants to understand why something cannot be simpler, or wants a complexity map before refactoring. Also use before a technical-debt audit when unavoidable constraints and removable implementation complexity are mixed together. Do not use for exploring competing greenfield designs (design-space-exploration) or for a pure structural-debt inventory that does not need an invariant boundary (technical-debt-audit).

Read SKILL.md at the source

Pinned to revision 6d023e9e7532, so it is the text this page describes rather than whatever the author pushed since.

Files

Every link opens the file at its source, pinned to the revision this page describes.