---
name: software-engineering-library
version: 1.0.0
description: Route software engineering design and discovered code-risk tasks to on-demand book references. Use for `architecture review`, `layer boundary change`, `dependency boundary`, `module interface shape`, `domain modeling`, `bounded context`, `refactoring`, `code smell`, `legacy code`, `low test coverage`, `old file`, `characterization test`, `external API calls`, `queues`, `retries`, `transactions`, `event ordering`, `data layer`, `storage design`, `consistency`, `schema evolution`, `timeout`, `circuit breaker`, `bulkhead`, and production resilience in .py, .cs, .ts, .tsx, .js, .ps1, .sql, and service design docs. Do NOT use for reinventing-the-wheel or build-vs-buy, use programming-advisor. Do NOT use for single-file maintainability scoring, use code-qualities-assessment. Do NOT use for CVA design, use cva-analysis.
license: MIT
---

# 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, the always-on rules code-quality, pragmatic-programmer, and unified-software-engineering already apply; 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

| Task | Reference |
|------|-----------|
| Architecture / layer boundaries | `references/clean-architecture.md`, `references/philosophy-of-software-design.md` |
| Domain modeling / bounded contexts | `references/domain-driven-design.md` |
| Persistence / repository / unit-of-work | `references/enterprise-patterns.md` |
| Refactoring / code smells | `references/refactoring.md` |
| Legacy code / seams / characterization tests | `references/working-with-legacy-code.md` |
| Data systems / consistency / schema evolution | `references/data-intensive-applications.md` |
| Production resilience / timeouts / bulkheads | `references/release-it.md` |

## 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 always-on 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.