software-engineering-library

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, code-quality loads on every turn and 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

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 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.