marketing-vs-product-system skillA
marketing-vs-product-system is agent-read markdown (skill) from dembrandt/dembrandt-skills: A marketing site and the product it sells share a brand but not a design system. The surfaces differ in density, type scale, radius and weight for good reasons, and those differences are legitimate, but the token layer underneath them must stay single. The same rule covers the other surfaces a brand runs, including documentation, transactional email and a status page. Use when a product app and its public site drift apart, when deciding which values may differ between surfaces, when a signed-in .
Indexed from public GitHub and served as immutable, content-addressed versions. Install it pinned to an exact SHA-256 with the mdr CLI, and every file is verified against the hash recorded here before it reaches your agent. The deterministic audit below grades the latest version, and the same file always earns the same grade.
What the file says
# Marketing and Product Are Two Surfaces of One Brand The public site sells; the product is used. A visitor reads one marketing page for ninety seconds and leaves. An operator opens the same brand every morning and stays for hours. Designing both to one specification produces either a brochure that is exhausting to work in or a product screen that cannot sell anything. So the two surfaces *should* diverge. The question is never whether, it is **which layer is allowed to diverge**. Marketing and product are the pair that forces the question, because they are the two nobody can pretend are the same job. But the rule underneath is not about two. Most brands run four or five surfaces: the site, the product, the documentation, the transactional email, the status page, sometimes a sales deck. Each one is a different job for a different reader at a different moment. **The brand owns the layer; every surface chooses from it.** Adding a sixth surface then changes nothing about the rule, which is the test of whether the rule was right. Where a new surface belongs is settled by the same question the layer rule asks, not by which team built it. Docs …
Read the whole file at its exact version.
How to install
mdr add dembrandt/dembrandt-skills/marketing-vs-product-system@git:20260919.1f99785mdr add dembrandt/dembrandt-skills/marketing-vs-product-system@sha256:e2640e84760c2bb9Pin to a label to follow the author's releases, or to a sha256 to freeze the exact bytes forever. Either way the resolved hash is written to mdr.lock, and mdr install reproduces it on any machine.
[](https://markdownregistry.com/a/art_4oezvlhpgxmn4za3)
1 badge views in 30 days
Versions
Audit of the latest version
- pass: Frontmatter block present
- pass: Frontmatter declares a name
- pass: Frontmatter declares a description
- pass: Size between 200 bytes and 200 KB (14302 bytes)
- pass: No zero-width or bidi control characters
- pass: No instruction hidden inside an HTML comment
- pass: No link to an exfiltration or paste host
- pass: No credential-shaped string
- pass: No instruction to send local credentials anywhere
- pass: No text hidden with inline styles
- pass: No prompt-injection phrasing
- pass: No curl or wget piped into a shell
- pass: No recursive delete of root, home or parent
- pass: No instruction to read or print local credentials
- pass: No base64 blob over 200 characters
- pass: No link to a raw IP address
- pass: No script tag
Source
dembrandt/dembrandt-skills · 56 stars · license MIT · pushed 2026-09-23 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_4oezvlhpgxmn4za3 GET https://markdownregistry.com/api/v1/resolve?ref=dembrandt/dembrandt-skills/marketing-vs-product-system GET https://markdownregistry.com/api/v1/blob/e2640e84760c2bb9713735c7746acaabc0dceb4a70b2318091c4e17f1b161da3
Your agent does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.