The context stack: skills, templates, design systems, and craft rules
For OpenDesign, the decisive question before an agent writes a file is not only which model will run; it is which instructions and design decisions will surround that model. This chapter examines the context stack—portable skills, rendering templates, design systems, craft references, and their plugin envelope—so the reader can predict how a brief is shaped before execution and what happens when several layers overlap.
That distinction matters because “prompt” suggests one block of text with one author. OpenDesign's current implementation is closer to a composition of contracts. Each contract has a different owner and a different job. If those jobs are kept separate, a brand can change without rewriting a workflow, and a workflow can move between agents without losing its intent. If they are confused, a color preference can be mistaken for a layout rule, or a marketplace label can be mistaken for an instruction the agent must follow.
A skill is a workflow; a template is a starting shape
The lowest common denominator in OpenDesign is a directory containing SKILL.md. Its body is ordinary Markdown that an agent can read: a workflow, principles, required checks, and expected outputs. This is what makes the format portable. A skill author does not need to implement a new runtime or teach every supported CLI a different programming interface. They describe the work in a file that compatible coding agents already know how to consume.
OpenDesign can add an optional od: metadata block to that file. The block can classify the skill's mode and surface, describe a preview, identify a scenario, declare whether an active design system is required, request universal craft references, and expose typed inputs. Those fields allow the host application to offer a picker, form, or filter without changing the underlying Markdown workflow. A skill remains usable outside OpenDesign, while OpenDesign can understand more about how to present and run it.
The difference between the portable contract and the host metadata is consequential. The Markdown body tells the agent what to do. The optional metadata tells OpenDesign how to classify and frame that behavior. The metadata may say that a bundle belongs to a prototype surface or needs a design system, but it does not replace the workflow body. Nor does it magically give an unrelated agent the UI behavior that OpenDesign builds around it.
A rendering template is a specialized kind of starting point. It is listed separately from a functional skill because it answers a different question. A functional skill might teach an agent how to audit a page, extract a design system, or refine an existing artifact. A rendering template says, in effect, “begin with this shape and personalize it.” That distinction avoids a common mistake: assuming that every generation task should start from a blank page.
The bundled SaaS landing template shows the boundary. It expects an active design system, accepts values such as a product name and tagline, defines the sections of the page, and requires one self-contained HTML output. It also specifies how to use colors, typography, layout, buttons, and accents, along with responsive and content checks. The template is not just a catalog card. It is an executable set of expectations for the agent. Yet it is also not the brand itself. It gives the page a workflow and output shape; the design system supplies the visual language that shape should express.
OpenDesign makes the distinction visible in its registries. Functional skills are discovered through one surface, rendering templates through another, even though both may use SKILL.md. The creation UI has its own categories—Prototype, Live Artifact, Deck, Template, Media, and Other—while the daemon's registry uses a separate set of skill modes. This is not needless taxonomy. A user-facing tab describes the work they are starting; a registry mode describes how an instruction bundle is classified and routed. A live artifact, for example, may still be prototype-shaped at the project level while requiring data or connector behavior that a simple prototype does not.
The selection rule also matters. When a person chooses a rendering template as the primary starting point, the daemon does not automatically inject the default functional skill for that surface as a second, co-equal workflow. The selected template replaces the default primary skill. That prevents two potentially conflicting sets of instructions from both claiming authority over the same output. Additional skills can still be selected as context where the product supports them, but composition is deliberate rather than an accidental merge of every matching file.
The stack is ordered as well as separated. OpenDesign's prompt composer can place execution-profile rules and core design guidance around the active design context, craft references, skill or template, plugin context, stage guidance, and metadata. The active design system is treated as authoritative for brand tokens. Craft rules sit on top of the brand where the brand has not specified a decision. The skill or template remains the workflow carrier. This gives an agent an answer when instructions overlap: use the brand's declared token values, follow the workflow's output rules, and apply universal craft guidance to the parts the brand leaves open.
Selected skill directories are staged into real project-private copies for a run. That arrangement gives the agent access to references and assets relative to its working directory without requiring OpenDesign to symlink the bundle into a global agent configuration. It also creates a useful write barrier around the source: an agent that edits the staged copy has not changed the source skill that will be used later. The staging copy is a delivery mechanism, not a security guarantee. A tool-capable agent still acts with the authority assigned by its runtime.
The discovery rules support local variation. User-managed entries can take precedence over bundled entries with the same identifier, and the daemon rescans its roots when listing the catalog. A team can therefore test a changed workflow without replacing the bundled copy for everyone. That flexibility has a cost: the meaning of an identifier can depend on which root won the precedence decision. For repeatable work, provenance and versioning matter more than a label in a picker.
A design system is a contract, not a mood board
OpenDesign's design-system package addresses the problem that a skill alone cannot solve. A skill can say “use the active brand,” but the brand needs a durable representation. The current package shape centers on manifest.json, DESIGN.md, and tokens.css. The manifest provides discovery metadata, provenance, and declared package files. DESIGN.md carries the canonical design prose. tokens.css carries the compiled semantic values that generated code can bind to directly.
The three files divide labor without dividing authority. The prose can explain why a system uses a particular type scale, how a surface should feel, which components carry emphasis, and where an accent should be restrained. The token stylesheet gives those decisions names and values that a page can reuse. A design system is therefore not merely a palette attached to a prompt; it is a shared language for visual decisions.
The Linear-inspired package in the repository makes that language concrete. Its DESIGN.md describes a near-black, dark-mode-native canvas, subtle luminance steps, Inter Variable typography, a distinctive intermediate text weight, tightly tracked display headings, a restrained indigo-violet accent, and translucent borders. It also describes button shapes, cards, inputs, badges, spacing, focus, and elevation. These details are not an inventory for its own sake. They explain how the visual identity appears in actual interface decisions.
The corresponding tokens.css translates the same intent into semantic variables: background and surface, primary and secondary foregrounds, borders, accent states, font families, type scale, leading, tracking, spacing, radii, elevation, focus rings, motion, and layout limits. A generated artifact can paste the token contract into its first style block and refer to var(--accent) or var(--space-4) rather than recreating values from memory. The code is more likely to stay internally consistent because the model is given a binding vocabulary instead of a loose collection of adjectives and hex codes.
This is where the prose channel and token channel reinforce each other. Tokens alone can tell a page what value to use but not when it should be used. Prose alone can express design judgment but leaves the agent to re-derive exact values repeatedly. Together they make a design decision legible to both people and machines. A designer can review the rationale, while the generated page can consume the compiled contract.
The package can be richer when the brand needs more evidence. OpenDesign supports usage guidance, component fixtures or manifests, derived token representations, Tailwind mappings, assets, fonts, previews, and importer evidence. The daemon can inject a compact component manifest or fall back to a fixture, and it can expose an index of additional files for on-demand inspection. This is a push-and-pull design: the essential contract is placed in the prompt, while deeper material remains available when the agent needs to inspect it.
That distinction reduces prompt weight without abandoning detail. A component manifest can tell the agent which button and card shapes exist, while the full fixture remains available for a closer look. A preview can help a human judge the system, while provenance files explain where it came from. The package is not required to carry every possible artifact to be valid; legacy folders containing only DESIGN.md remain readable. Compatibility is a deliberate part of the design-system strategy.
Craft references sit beside, not inside, the brand contract. Some rules are meant to hold across brands: accessibility baselines, typography discipline, sensible animation, state coverage, color practice, and defenses against generic AI-generated styling. If every brand package copied those rules, the repository would accumulate duplication and drift. OpenDesign instead lets a skill request the universal references it needs. The brand decides its tokens; craft decides how to use them where the brand has not made a contrary choice.
The distinction can be seen in the SaaS landing example. Its workflow says to use the active palette, avoid invented colors, respect declared type and layout rules, and limit accent use. A craft reference can reinforce why excessive accent color weakens hierarchy or why a form needs clear states. The Linear package, meanwhile, determines that its dark surfaces use luminance stepping and that its indigo accent is sparse. Universal guidance and brand-specific decisions meet, but neither needs to pretend to be the other.
Prompt composition makes this relationship explicit. OpenDesign can include usage guidance, the DESIGN.md body, import-mode information, tokens.css, component information, a pull-layer index, craft references, and finally the active skill or template. The exact prompt may vary by execution profile and product path, and the repository documents multiple prompt variants rather than claiming one immutable string. The stable idea is the ownership order: brand context should not be silently replaced by a generic color suggestion, and a rendering template should not have to carry every universal quality rule inside itself.
There are two limits worth keeping in view. First, the design-system package is a constraint and a source of reference, not a guarantee that the agent will obey every token. The generated artifact still depends on the model's reading, the skill's workflow, and the host's preview and quality checks. Second, packages that reference recognizable brands are described by the repository as aesthetic inspirations, not official brand assets. A package can encode a visual study without conferring endorsement or legal ownership.
The catalog count also needs careful reading. The design-system guide advertises 151 bundled packages, while a direct count of top-level directories containing DESIGN.md in this checkout finds 152. That difference is best treated as a snapshot or counting-rule discrepancy, not as a substantive product contradiction. The important mechanism is the package contract and its compatibility behavior, not an apparently precise catalog number that may change with generated or auxiliary entries.
When layers overlap, ownership determines the result
The value of this stack appears when a single task activates several layers at once. Suppose a person asks for a product landing page using a Linear-inspired system. The rendering template determines the broad page shape and file handoff. The skill tells the agent to plan the sections, use meaningful content, and perform its checks. DESIGN.md explains the visual character and component rules. tokens.css supplies the exact values. Craft references add universal constraints around typography, accessibility, and anti-slop patterns. The daemon composes those materials before the chosen coding agent begins.
If the brief asks for a dark page but the active design system is light, the system's token contract should govern the brand decision; the brief may still determine the product content and structure. If the user asks for a deck, a deck-oriented template or skill changes the output surface rather than merely adding another paragraph to a prototype workflow. If a user-installed skill shares an identifier with a bundled one, precedence determines which body is resolved, so the run should be interpreted through the selected source and its version rather than through the name alone.
Plugins add another layer of context, but they should not erase these boundaries. A plugin can add typed context, pipeline and capability declarations around the underlying workflow, while the portable skill and design-system files remain the substantive contracts. It does not need to duplicate the full body of every skill or design system it references. That separation keeps distribution metadata distinct from the files that govern the agent.
This separation is also what makes portability plausible. A skill can be read by a compatible agent outside OpenDesign. A design system can be inspected as a file and reused by multiple workflows. A plugin can enrich the experience inside OpenDesign without becoming a proprietary UI process. Yet portability is not sameness. Outside the host, an agent may ignore OpenDesign-specific metadata, lack the same preview surface, or have no way to materialize the same artifact contract. The portable file is the foundation, not a promise that every surrounding behavior travels with it.
The same principle applies to quality. A checklist in SKILL.md can ask the agent to test a page at several widths, avoid placeholder copy, and keep accent use within bounds. Craft references can add general safeguards, and the host can stream critique or preview events. These mechanisms make failure easier to see and correct. They do not convert a generated page into a certified design. A token can be present and still be misapplied; a page can render and still have weak hierarchy or inaccessible interaction.
The context stack therefore solves a specific problem: it makes design intent composable without making every part of the system responsible for every other part. Skills own workflows. Templates own starting shapes. Design systems own brand decisions. Craft references own universal practices. Plugins own distribution and typed workflow context. The daemon resolves those contracts and sends them to the selected agent. That division is the foundation for the next question: once context is packaged, how does OpenDesign turn it into a repeatable, permission-aware workflow rather than another one-off prompt?