What problem does it solve? Feature modules like SEO, Mail, and SMS each need {{...}} placeholder interpolation, but building separate engines per module creates duplicated logic, inconsistent placeholder behavior, and tight coupling between features. This Skill defines how to build one small, reusable templating engine in a neutral kernel package that all modules share. ## Core Features & Use Cases - Compile-then-render pipeline: Templates are compiled against an allowlisted variable set so malformed delimiters and unknown variables fail before rendering, while declared-but-missing values render empty with structured warnings. - Context-aware rendering: Separate output contexts for plain text, HTML (with automatic escaping of dynamic values), and message headers (with CR/LF rejection to prevent header injection). - Namespaced variable catalogs: Enforces explicit namespaces like site., resource., data., and user., with shared domain catalogs (e.g., site.field.<key>) owned by core packages rather than duplicated per feature. - Use Case: Migrate the existing SEO module's local interpolation engine into kernel/templating, then have Mail reuse the same engine and the same site variable catalog without changing any existing SEO placeholder behavior. ## Quick Start Ask the agent to extract the SEO module's interpolation logic into a shared kernel/templating package following this skill's ownership, namespacing, and testing rules.
