pattern-finder

Pattern Finder

Use this skill to turn a problem statement into a short, practical pattern shortlist.

References

• For force-discovery usage modes and output expectations, read references/usages.md.
• For smell-to-pattern examples, read references/examples.md.
• For force mapping and false-positive guidance, read references/implementation.md.
• For catalog lookup commands and shortlist rules, read references/catalog.md.

Start by identifying the forces in the user's request:

• Variation point: object creation, algorithm choice, object structure, lifecycle state, collaboration, message routing, transformation, delivery, or operations.
• Coupling pressure: which components know too much about each other.
• Runtime pressure: latency, durability, ordering, throughput, retries, observability, or deployment independence.
• Change pressure: what is likely to vary next.
• Language and framework: whether the local stack already has an idiom that should be preferred.

Lookup workflow:

1. Run patterns search "$ARGUMENTS" when the user names a pattern, force, or term.
2. Run patterns list object-design --language <language> for object design problems or patterns list integration-design --language <language> for messaging and integration problems when the language is known.
3. Read the relevant Markdown entries under data/patterns before making a recommendation.

Response shape:

1. State the likely primary pattern.
2. Give two close alternatives and why they are weaker or stronger.
3. Explain what code or architecture would change.
4. Include language-specific advice if the language is known.
5. Name the signals that would make you change the recommendation.

Keep the shortlist tight. A good recommendation is usually one pattern, one backup, and one "do not use a pattern yet" option.