Author a pattern

Create a bundle with a stable machine ID:

patterns init backend-feature-slices

The scaffold starts with scope: internal. That is intentional: extracted house architecture may contain product names, accidental conventions, or rules that only make sense in one repository.

1. Name the outcome for humans

Keep name short, technical, and immutable. Give title the job of explaining the pattern:

name: backend-feature-slices
title: Organize Backend Features by Use Case

The directory and CLI display the title. The installed directory, update selector, relationship lookup, and claimed namespace use the stable ID. The Git/discovery ref is a separate address: owner/repo[/subdir].

2. Teach one primary decision

A strong bundle answers:

• What repeated change or coupling problem does this solve?
• When is the added structure worth its cost?
• When should a team avoid it?
• Who owns each responsibility?
• Which dependency directions are forbidden?
• How do common changes preserve those decisions?

Avoid packaging an entire preferred tech stack as one pattern. Separate independent decisions so users can compose only what they need.

3. Build the progressive guide

Use patterns.yaml as a compact router. Every entry in structure, rules, recipes, and adrs carries a one-line summary and points at one focused document.

4. Generalize and validate

Remove company, product, team, and business-entity language before changing to scope: shareable.

patterns validate ./backend-feature-slices

Validation checks the manifest and confirms that every indexed guide file exists. It cannot judge whether the prose is honest, generic, or useful; review those qualities explicitly.

See the manifest reference for every metadata field.