Patterns are not templates
A pattern preserves architectural intent; a template copies a starting implementation.
A template answers “what files should I copy to start?”. A pattern answers “what decisions must remain true while this codebase changes?”. They can complement each other, but they have different lifecycles.
| Pattern | Template or boilerplate | |
|---|---|---|
| Primary artifact | Decisions, structure, rules, recipes, ADRs | Source files and configuration |
| Installation | Knowledge under .patterns/ | New application code |
Effect on src/ | None | Creates or replaces files |
| Useful after launch | Yes; it guides ongoing changes | Usually declines as the code diverges |
| Verification | Declared import boundaries and review rules | Build, tests, and template-specific checks |
Descriptive, not generative
The CLI is deliberately deterministic and LLM-free. It fetches, validates, installs, routes, updates, and checks a bundle. Your coding agent supplies contextual judgment when it applies that bundle to a real change.
This separation keeps the installed artifact auditable: a person can read the same instructions the agent follows, and patterns check enforces only rules the manifest explicitly declares.
Framework compatibility is explicit
A pattern is not “for Next.js” merely because a source document mentions Next.js. The manifest separates languages, frameworks, and runtimes so the index never has to guess what a mixed technology token means. An empty or absent frameworks array simply means the pattern is unclassified on that axis; declare a framework only when the guidance genuinely depends on it.