Software Engineering Library

Software Engineering Library

This skill routes software engineering design work to deeper book-derived references without loading them on every turn.

For the everyday default, none loads on every turn and code-quality, pragmatic-programmer and unified-software-engineering load on code files; open a reference here only when the task needs that specific book's depth (start with one, add a second only when it changes a decision).

Triggers

• architecture review
• domain modeling bounded context
• refactoring code smells legacy code low test coverage old file characterization tests
• external API calls queues retries timeouts circuit breaker bulkhead
• transactions event ordering data consistency schema evolution module interface shape

When Each Reference Applies

• Use references/clean-architecture.md when dependency direction, layer ownership, or boundary placement drives the decision.
• Use references/philosophy-of-software-design.md when module depth, interface shape, or complexity hiding drives the decision.
• Use references/domain-driven-design.md when the work models a domain, splits bounded contexts, or translates across contexts.
• Use references/enterprise-patterns.md when persistence, repositories, unit-of-work, transactions, or application service orchestration are central.
• Use references/refactoring.md when changing internal structure, addressing code smells, or preserving behavior while improving shape.
• Use references/working-with-legacy-code.md when the code is hard to test, poorly covered, or needs seams and characterization tests before change.
• Use references/data-intensive-applications.md when state, storage, schema evolution, consistency, ordering, or delivery semantics are central.
• Use references/release-it.md when production resilience, timeouts, circuit breakers, bulkheads, retries, and operational failure modes are central.

Task To Reference Router

Process

1. Classify the task using the routing table.
2. If another skill discovers a risk condition, route from that evidence to the matching reference.
3. Open the smallest matching reference set.
4. Apply the reference to the current decision.
5. Add a second reference only when it changes the decision.
6. Keep the final answer tied to files, user impact, and validation evidence.

Verification

• The selected reference matches the task type in the routing table.
• No more than two references were opened unless the task spans more than two book domains.
• The final recommendation names the reference that changed the decision.
• The baseline rules remain the default for routine code quality decisions.

Anti-Patterns

• Opening every reference before classifying the task.
• Using this skill for build-vs-buy or wheel detection instead of programming-advisor.
• Using this skill for single-file maintainability scoring instead of code-qualities-assessment.
• Using this skill for Commonality Variability Analysis instead of cva-analysis.

Extension Points

• Add a new reference only when it represents a distinct book-depth decision surface.
• Keep the skill body as the router. Put long material in references/.
• Update the description when a new reference changes the trigger surface.