1.5 KiB
1.5 KiB
Cross-Project Learning & Reusable Intelligence
What Transfers Well
| Type | Transferability | Example |
|---|---|---|
| Problem-solving patterns (abstract) | ✅ High | "When implementing OAuth, these are the common pitfalls and the architecture that avoids them" |
| Code templates & scaffolding | ✅ With adaptation | Proven auth module structure, tested payment integration pattern |
| Learned pitfalls | ✅ High | "When integrating Stripe, these edge cases around webhooks most implementations miss" |
| Project-specific conventions | ❌ Does not transfer | Architectural decisions are contextual |
| Domain logic | ❌ Does not transfer | Business rules are project-specific |
The Optimal Architecture: A Pattern Library
Each pattern includes:
- Description of the problem it solves
- The approach and tradeoffs
- Common pitfalls
- Verification tests
- Reference implementation
Growth Through Extraction, Not Manual Curation
When a task completes with high quality (first-attempt success, no subsequent modifications, clean review), flag it as a candidate for pattern extraction. A dedicated pass determines whether the solution embodies a generalizable pattern.
The Critical Constraint
Patterns should be descriptive, not prescriptive — "here's an approach that has worked well, with these tradeoffs" not "always do it this way." Grok adds an overfitting guard: require 3+ project examples before promoting to reusable.