# Output Style System: A Complete Analysis This chapter analyzes Claude Code's output style switching mechanism—how the same AI can seamlessly transition between terse, instructional, and custom output styles by loading different style configurations. --- > **🌍 Industry Context**: Output style customization is an emerging feature direction in AI coding tools. Different tools have chosen different implementation paradigms: > > - **Cursor**: Evolved from the early `.cursorrules` single file to 2025's `.cursor/rules/` multi-rule directory, supporting layered Project Rules and User Rules, with dynamic `@rules` references in conversations—functionally highly aligned with Claude Code's multi-layer style system. > - **Windsurf (Codeium)**: Implements project-level and user-level layered configuration via `.windsurfrules` files and global Rules, reaching considerable maturity by 2025. > - **GitHub Copilot**: Embeds instruction text via `github.copilot.chat.codeGeneration.instructions` in VS Code's `settings.json`—deeply integrated with the IDE settings system with zero learning curve, but no multi-preset switching support. > - **Aider**: Switches between structured output formats like diff/whole/ask via `--edit-format`, focusing on the **mechanical format** of code editing rather than the AI's **expressive style**—an interesting design divergence: Aider optimizes for engineering efficiency, Claude Code optimizes for user experience. > - **ChatGPT**: The 2024 launch of Custom Instructions and Memory was the first mainstream validation of "persistent user preferences for AI behavior"—Claude Code's style system can be seen as the vertical implementation of this direction within programming tools. > > In this design space, three paradigms exist: (a) IDE settings integration (Copilot: zero cost but inflexible), (b) plain-text rule files (Cursor/Aider/Windsurf: simple but lacking structured metadata), and (c) structured style system (Claude Code: Markdown + Frontmatter metadata + five-layer priority merging). Claude Code's uniqueness is not the concept of "styles as prompts" itself (Cursor's rule files are fundamentally the same), but **making it a structured system with frontmatter metadata** and a **five-layer priority merge mechanism**. In particular, the Learning mode concretizes the "AI tutor" concept into a `TODO(human)` protocol within the CLI environment—novel at the execution level, though the Socratic dialogue educational philosophy has prior art (e.g., Khan Academy's Khanmigo, 2023). --- ## Chapter Guide Output Styles is a lightweight yet far-reaching subsystem in Claude Code 2.1.88. It allows users to change Claude's output style—the same programming task can be rendered in the default concise style, switched to "teaching mode" where Claude explains code as it writes it, or switched to any custom style. **Technical Analogy (OS Perspective)**: The output style system is like a **theme engine** in an operating system—the kernel (AI reasoning) stays the same, but the rendering layer (output manner) can be changed by loading different theme files. Just as a GTK theme changes how buttons look without changing what they do, output styles change Claude's "way of speaking" without changing its reasoning ability. > 💡 **Plain English**: Output styles are like **chat app theme skins**—the same message looks completely different depending on the theme. The default theme is minimalist white; the "Explanatory" theme adds background annotation boxes; the "Learning" theme turns into an interactive teaching interface. And you can upload your own custom themes. ## Architecture Distribution The output style system consists of three core files and several peripheral files: | File | Location | Responsibility | |------|----------|----------------| | `loadOutputStylesDir.ts` | `src/outputStyles/` | Loads custom styles from `.claude/output-styles/` | | `outputStyles.ts` | `src/constants/` | Built-in style definitions + style merging + config retrieval | | `output-style.tsx` | `src/commands/` | `/output-style` command (deprecated) | | `OutputStylePicker.tsx` | `src/components/` | Style picker UI | | `loadPluginOutputStyles.ts` | `src/utils/plugins/` | Loads styles from plugins | The core modules are small—`loadOutputStylesDir.ts` is only 99 lines, `outputStyles.ts` about 217 lines. Meanwhile, the output style prompt is injected into the **system prompt of every API call**, giving it impact far beyond the code's physical size. It's worth noting that small code size doesn't automatically equal good design—it also means an absence of explicit length limits, content validation, and safety boundary checks (see Section 8 Security Analysis). ## 1. Built-in Style Definitions ### 1.1 Style Data Structure Lines 11-23 of `constants/outputStyles.ts` define the style configuration type: ```typescript export type OutputStyleConfig = { name: string description: string prompt: string // Content injected into system prompt source: SettingSource | 'built-in' | 'plugin' keepCodingInstructions?: boolean // Whether to retain default coding instructions forceForPlugin?: boolean // Whether a plugin can force this style } ``` The `prompt` field is the core—its contents are injected directly into Claude's system prompt, thereby changing Claude's output behavior. ### 1.2 Default Style The default style is configured as `null`: ```typescript export const DEFAULT_OUTPUT_STYLE_NAME = 'default' export const OUTPUT_STYLE_CONFIG: OutputStyles = { [DEFAULT_OUTPUT_STYLE_NAME]: null, // null means no extra prompt is injected // ... } ``` When the style is `null`, no additional system prompt is injected, and Claude uses its default output manner. ### 1.3 Explanatory Mode "Explanatory" mode has Claude add educational annotations while performing tasks (lines 43-54): ```typescript Explanatory: { name: 'Explanatory', source: 'built-in', description: 'Claude explains its implementation choices and codebase patterns', keepCodingInstructions: true, prompt: `You are an interactive CLI tool that helps users with software engineering tasks. In addition to software engineering tasks, you should provide educational insights about the codebase along the way. # Explanatory Style Active ## Insights In order to encourage learning, before and after writing code, always provide brief educational explanations about implementation choices using: "\`★ Insight ─────────────────────────────────────\` [2-3 key educational points] \`─────────────────────────────────────────────────\`" ` } ``` Note `keepCodingInstructions: true`—this means the Explanatory style does not replace the default coding instructions, but **appends** educational content on top of them. ### 1.4 Learning Mode "Learning" mode goes further, having Claude pause execution and ask the user to write small code snippets (lines 56-134): ```typescript Learning: { name: 'Learning', source: 'built-in', prompt: `... ## Requesting Human Contributions In order to encourage learning, ask the human to contribute 2-10 line code pieces when generating 20+ lines involving: - Design decisions (error handling, data structures) - Business logic with multiple valid approaches - Key algorithms or interface definitions ### Request Format \`\`\` ● **Learn by Doing** **Context:** [what's built and why this decision matters] **Your Task:** [specific function/section in file] **Guidance:** [trade-offs and constraints to consider] \`\`\` ` } ``` The Learning mode defines a detailed "learn by doing" protocol: 1. Claude first sets up the code framework 2. Pauses at key decision points and requests user input 3. Marks the user's fill-in position with `TODO(human)` 4. After the user completes it, Claude shares a connecting insight This design shifts the AI from "writing code for you" to "teaching you to write code." Socratic teaching dialogues have prior art in AI education (e.g., Khan Academy's Khanmigo, 2023), but Claude Code's innovation is concretizing this philosophy into a **`TODO(human)` protocol in the CLI environment**—an engineering innovation at the execution level, not a conceptual first. ## 2. Loading Custom Styles ### 2.1 Directory Scanning `loadOutputStylesDir.ts` loads custom styles from two locations: ```typescript export const getOutputStyleDirStyles = memoize( async (cwd: string): Promise => { const markdownFiles = await loadMarkdownFilesForSubdir( 'output-styles', cwd, ) // ... } ) ``` Scanning paths: - Project-level: `.claude/output-styles/*.md` - User-level: `~/.claude/output-styles/*.md` It uses the same `loadMarkdownFilesForSubdir` infrastructure as the Skill system. ### 2.2 Frontmatter Parsing Each custom style is a Markdown file supporting the following frontmatter fields: ```yaml --- name: My Custom Style description: A concise and focused output style keep-coding-instructions: true --- You are a concise developer assistant. Never use bullet points. Always explain trade-offs in one sentence. ``` Parsing logic (lines 34-76): ```typescript const styles = markdownFiles.map(({ filePath, frontmatter, content, source }) => { const fileName = basename(filePath) const styleName = fileName.replace(/\.md$/, '') // Name fallback: frontmatter.name → filename const name = (frontmatter['name'] || styleName) as string // Description fallback: frontmatter.description → Markdown first paragraph const description = coerceDescriptionToString(frontmatter['description'], styleName) ?? extractDescriptionFromMarkdown(content, `Custom ${styleName} output style`) // keep-coding-instructions boolean parsing const keepCodingInstructionsRaw = frontmatter['keep-coding-instructions'] const keepCodingInstructions = keepCodingInstructionsRaw === true || keepCodingInstructionsRaw === 'true' ? true : keepCodingInstructionsRaw === false || keepCodingInstructionsRaw === 'false' ? false : undefined // Warning: force-for-plugin only valid for plugin styles if (frontmatter['force-for-plugin'] !== undefined) { logForDebugging( `Output style "${name}" has force-for-plugin set, but this option ` + `only applies to plugin output styles. Ignoring.`, { level: 'warn' }, ) } return { name, description, prompt: content.trim(), source, keepCodingInstructions } }) ``` ### 2.3 Meaning of keepCodingInstructions This flag controls whether Claude Code's default coding instructions are retained (the `getSimpleDoingTasksSection()` part from `prompts.ts`). The actual judgment logic in source code (`prompts.ts` lines 564-567): ```typescript outputStyleConfig === null || outputStyleConfig.keepCodingInstructions === true ? getSimpleDoingTasksSection() : null, ``` This means the three possible values behave as follows: - `true`: Retain default coding instructions; the style prompt acts as **additional content** - `false`: **Replace** default coding instructions; the style prompt becomes the sole guidance on task execution in the system prompt - `undefined` (unset): **Behaviorally equivalent to `false`**—because `undefined === true` is false, the coding instruction section is skipped > **Pitfall Warning**: This is an **unsafe default**. When a user creates a custom style file, if they forget to set `keep-coding-instructions: true` in the frontmatter, the value parses to `undefined`, which silently replaces Claude's default coding instructions. The user might only want Claude to "reply in Chinese" or "add more detailed code comments," but accidentally strips all built-in guidance about how Claude writes code. In security engineering, defaults should choose the safest option (fail-safe default)—that is, retain coding instructions by default. The Claude Code team's reason for the current behavior is likely to give custom styles maximum flexibility (complete takeover of the system prompt), but at the cost of increased risk of user error. > > 💡 **Plain English**: This is like putting the "factory reset" button inside the "change wallpaper" menu—the user only wants a new wallpaper, but might accidentally wipe all their settings. ## 3. Style Merging and Priority ### 3.1 Five-Layer Merge The `getAllOutputStyles` function (lines 137-175) merges styles from all sources by priority: ```typescript export const getAllOutputStyles = memoize(async function getAllOutputStyles( cwd: string, ): Promise<{ [styleName: string]: OutputStyleConfig | null }> { const customStyles = await getOutputStyleDirStyles(cwd) const pluginStyles = await loadPluginOutputStyles() const allStyles = { ...OUTPUT_STYLE_CONFIG } // 1. Built-in styles const managedStyles = customStyles.filter(s => s.source === 'policySettings') const userStyles = customStyles.filter(s => s.source === 'userSettings') const projectStyles = customStyles.filter(s => s.source === 'projectSettings') // Priority from low to high const styleGroups = [pluginStyles, userStyles, projectStyles, managedStyles] for (const styles of styleGroups) { for (const style of styles) { allStyles[style.name] = { ... } // Higher priority overrides lower priority } } return allStyles }) ``` Priority layers: 1. **Built-in styles** (lowest): default, Explanatory, Learning 2. **Plugin styles**: Provided by third-party plugins 3. **User styles**: `~/.claude/output-styles/` 4. **Project styles**: `.claude/output-styles/` 5. **Enterprise policy styles** (highest): Administrator-mandated styles Same-name styles are overridden by higher priority—enterprise administrators can forcibly replace any user-defined style. > **📚 Course Connection**: This layered override mechanism is the classic pattern of **configuration file search paths** from Operating Systems courses—isomorphic to Linux's config lookup order (`/etc/` → `~/.config/` → `./.`), CSS cascade priority (user-agent → user → author → !important), and Git's config layers (system → global → local). In Software Engineering, this is a combination of the **Strategy Pattern** and **Chain of Responsibility Pattern**. ### 3.2 Plugin-Forced Styles ```typescript export async function getOutputStyleConfig(): Promise { // Check for any plugin-forced styles const forcedStyles = Object.values(allStyles).filter( (style): style is OutputStyleConfig => style !== null && style.source === 'plugin' && style.forceForPlugin === true, ) const firstForcedStyle = forcedStyles[0] if (firstForcedStyle) { if (forcedStyles.length > 1) { logForDebugging( `Multiple plugins have forced output styles: ` + `${forcedStyles.map(s => s.name).join(', ')}. Using: ${firstForcedStyle.name}`, { level: 'warn' }, ) } return firstForcedStyle } // Otherwise use the user-configured style const outputStyle = settings?.outputStyle || DEFAULT_OUTPUT_STYLE_NAME return allStyles[outputStyle] ?? null } ``` If multiple plugins set `forceForPlugin: true`, the system uses only the first one and emits a warning—a potential conflict scenario. ## 4. /output-style Command (Deprecated) `commands/output-style/output-style.tsx` contains only 7 lines of actual code: ```typescript export async function call(onDone: LocalJSXCommandOnDone): Promise { onDone( '/output-style has been deprecated. Use /config to change your output style, ' + 'or set it in your settings file. Changes take effect on the next session.', { display: 'system' } ) } ``` This command is deprecated, directing users to the `/config` command. Note "Changes take effect on the next session"—style switching does not take effect immediately; a new session is required. ## 5. Caching and Invalidation ### 5.1 Multi-Layer Caching The system uses three layers of memoize caching: ```typescript // Layer 1: loadMarkdownFilesForSubdir (file I/O) export const getOutputStyleDirStyles = memoize(async (cwd) => { ... }) // Layer 2: getAllOutputStyles (merged result) export const getAllOutputStyles = memoize(async (cwd) => { ... }) // Layer 3: Plugin styles // loadPluginOutputStyles has its own cache ``` ### 5.2 Cache Keys and Multi-Project Behavior The system uses lodash's `memoize` function, whose default behavior is to **use the first argument as the cache key**. Therefore: - `getOutputStyleDirStyles(cwd)` uses the `cwd` string as the key—different working directories produce different cache entries. In a monorepo scenario, if the user switches between subproject A and subproject B, each directory's style files are cached independently. - `getAllOutputStyles(cwd)` also uses `cwd` as its key, ensuring merged results for different projects don't interfere with each other. - `loadPluginOutputStyles()` has no arguments and is cached globally as a single entry. This means the memoize caching strategy is **cwd-isolated** multiple caches, not just caching the result of the last call. But note one edge case: lodash `memoize` uses `Map` by default, and cache entries never expire automatically. If a user frequently switches working directories within a long session, cache entries will accumulate until `clearOutputStyleCaches()` is called. In practice this is usually not a problem (working directory switches within a session are infrequent), but in theory it could cause a memory leak in a very long-running process. ### 5.3 Cache Clearing ```typescript // loadOutputStylesDir.ts export function clearOutputStyleCaches(): void { getOutputStyleDirStyles.cache?.clear?.() loadMarkdownFilesForSubdir.cache?.clear?.() clearPluginOutputStyleCache() } // outputStyles.ts export function clearAllOutputStylesCache(): void { getAllOutputStyles.cache?.clear?.() } ``` Cache clearing happens on: settings changes, plugin load/unload, and session restart. ## 6. Integration with System Prompt The output style's `prompt` field is ultimately injected into Claude's system prompt. This happens in `src/constants/prompts.ts` (although the specific injection code is outside the outputStyles module). The injection behavior depends on `keepCodingInstructions`. The precise logic from source code (`prompts.ts` lines 564-567): ```typescript // Only retains coding instructions when keepCodingInstructions strictly equals true outputStyleConfig === null || outputStyleConfig.keepCodingInstructions === true ? getSimpleDoingTasksSection() // Retain default coding instructions : null, // Skip coding instructions ``` Translated into user-comprehensible rules: ``` If keepCodingInstructions === true: System prompt = [intro section] + [default coding instructions] + ... + [style prompt] If keepCodingInstructions === false or undefined: System prompt = [intro section] + ... + [style prompt] (coding instruction section skipped) ``` Note that the style prompt itself is injected into the dynamic area via `getOutputStyleSection()`, formatted as `# Output Style: {name}\n{prompt}`. The remaining system prompt sections (tool usage instructions, tone and style, output efficiency, etc.) are retained in all modes. The only section skipped is `getSimpleDoingTasksSection()`—it contains Claude's core guidance on how to perform coding tasks. This means a custom style with `keepCodingInstructions: false` (or without `keep-coding-instructions` set) removes Claude's coding task guidance—not just a change in output format, but a change in how Claude approaches coding tasks. This is both powerful flexibility (allowing styles to completely redefine Claude's behavior) and a risk point requiring explicit user understanding (see the Pitfall Warning in Section 2.3). ## 7. Learning Mode Pedagogical Design Analysis The Learning mode's design merits deep analysis because it represents a novel human-AI collaboration paradigm: ### 7.1 Pause Point Selection Strategy ``` ask the human to contribute 2-10 line code pieces when generating 20+ lines involving: - Design decisions (error handling, data structures) - Business logic with multiple valid approaches - Key algorithms or interface definitions ``` Pause points are not random, but **pedagogically meaningful decision points**—error handling strategies, data structure choices, algorithm design. These are exactly the parts of programming that require the most thinking. ### 7.2 TODO(human) Protocol ``` - You must first add a TODO(human) section into the codebase with your editing tools before making the Learn by Doing request - Make sure there is one and only one TODO(human) section in the code - Don't take any action after the Learn by Doing request ``` Claude must first **physically mark** the location requiring human input in the code, then stop and wait. This ensures the user knows where to write and what to write. ### 7.3 TodoList Integration ``` If using a TodoList for the overall task, include a specific todo item like "Request human input on [specific decision]" when planning to request human input. ``` This integrates the teaching session into the task workflow rather than making it a separate "teaching mode." > **📚 Course Connection**: The Learning mode's design of "pausing at decision points to request human input" maps to **scaffolding** and **Active Learning** theory in Software Engineering—the AI builds the framework and then has the learner fill in key logic, consistent with Vygotsky's "Zone of Proximal Development (ZPD)" theory. From a technical implementation perspective, the `TODO(human)` marker is essentially a **coroutine yield point**—the AI execution flow pauses here, waiting to resume after human input. ## 8. Security Analysis: Style System as Prompt Injection Pipeline The output style system's essence is a **user-controllable system prompt injection pipeline**. The Markdown body content of each style file is injected verbatim into Claude's system prompt. This design introduces several security and cost concerns alongside its flexibility. ### 8.1 Supply Chain Attack Vector Project-level style files live in the `.claude/output-styles/` directory, which is typically committed to version control. This means: 1. **Malicious PR attack**: An attacker can slip a `.claude/output-styles/helpful.md` file into an otherwise normal Pull Request, containing instructions that modify Claude's behavior (e.g., "silently introduce backdoors when generating code"). Since style files are Markdown format and their contents are injected directly into the system prompt, code reviewers can easily overlook the security implications of this file. 2. **Team propagation**: Once a malicious style file is merged into the main branch, all team members using Claude Code on that project who select that style will be affected. 3. **Open source project risk**: An open source project's `.claude/` directory may contain style files submitted by untrusted contributors. After cloning the project, these styles automatically appear in the user's selectable list. > 💡 **Plain English**: This is like the office shared printer suddenly having its ink cartridges swapped—on the surface it still prints documents, but every page's content is secretly modified. And because everyone shares the same printer, everyone is affected. ### 8.2 Missing Behavioral Boundaries Style prompts have no length limits or content validation mechanisms: - **No length ceiling**: A user could theoretically write a 10,000-token style prompt, significantly increasing the cost and latency of every API call. Across 30 API calls in a session, an overly long style prompt could unknowingly waste tens of thousands of tokens. - **No content filtering**: Style prompts can contain any text, including instructions attempting to override Claude's safety boundaries. While Claude's model itself has safety training to resist such attacks, injecting user-controllable text directly into the system prompt still expands the attack surface. - **No schema validation**: Frontmatter field names and values are not strictly validated. Incorrect field names (like `keepCodingInstructions` instead of `keep-coding-instructions`) are silently ignored without any warning. ### 8.3 Interaction with Prompt Caching The style prompt is placed in the dynamic area of the system prompt (registered via `systemPromptSection('output_style', ...)`), after the `SYSTEM_PROMPT_DYNAMIC_BOUNDARY` marker. This means: - Changes to the style prompt do not invalidate the prompt cache for the static area—a positive design decision. - But the style prompt itself is sent with every request and is not cache-hit eligible—if the style prompt is long, this token overhead is incurred on every single call. ### 8.4 Mitigation Recommendations For teams using Claude Code, the following practices are recommended: - Treat changes in the `.claude/output-styles/` directory as **security-sensitive changes** during code review, on par with CI configurations or deployment scripts - Always explicitly set `keep-coding-instructions: true` in custom style files, unless there is a clear reason to replace the default coding instructions - Consider whether to exclude the styles directory in `.gitignore`, or establish a team approval workflow - For enterprise deployments, leverage `policySettings` (the enterprise policy layer) to enforce a secure baseline style, preventing lower-priority layers from making dangerous behavior modifications ## Critical Analysis ### Strengths 1. **Minimal core**: The loading module is only 99 lines, style definitions about 217 lines—achieving code-level simplicity by sinking complexity into the prompt layer. But note that this simplicity comes at the cost of missing runtime validation (e.g., prompt length limits, content safety checks), with safety boundaries relying on user diligence. 2. **Skill infrastructure reuse**: Uses `loadMarkdownFilesForSubdir` and the frontmatter parser, sharing infrastructure with the Skill system and reducing duplicated code. 3. **Layered override mechanism**: The 5-layer priority ensures a balance between enterprise compliance (administrators can enforce styles) and personal flexibility (users can customize). 4. **Learning mode design ingenuity**: The concept of shifting AI from "doer" to "coach" has prior art in educational technology (e.g., Khanmigo's Socratic dialogue), but Claude Code's `TODO(human)` protocol concretizes it into a code-level interaction interface, which is relatively novel among AI coding tools. ### Weaknesses **Architecture-level issues**: 1. **Unsafe default for `keepCodingInstructions`**: When a custom style does not set this field, `undefined` behaves equivalently to `false`—silently replacing the coding instructions. This violates the fail-safe default principle. A user might unknowingly create a "Claude that doesn't write code as expected" (see Section 2.3 for details). 2. **Crude plugin style conflict handling**: Taking the first plugin when multiple `forceForPlugin: true` exist is non-deterministic behavior (dependent on `Object.values()` iteration order). A better conflict resolution strategy is needed—such as explicit priority declarations or user choice. 3. **No safety boundaries on style prompts**: No length limits, no content validation, and project-level style files constitute a supply chain attack vector (see Section 8 Security Analysis). **Product experience issues**: 4. **Style switching is not instant**: The `/output-style` command is deprecated, and style switching requires a new session—for users wanting to temporarily switch styles, this is inconvenient. The technical reason is likely that the system prompt is generated at session start, and mid-session modification would invalidate the prompt cache. 5. **Lack of style preview**: Users cannot preview the effect of a style before selecting it; they can only guess from the description. 6. **Learning mode practicality concerns**: Having users manually edit the `TODO(human)` position in the terminal, then return to the Claude Code conversation—this workflow may be awkward in practice, especially for users accustomed to IDE inline editing. **Extensibility issues**: 7. **Limited built-in style count**: Only 3 built-in styles (including default), and no visible mechanism for loading or recommending community styles—compared to Skill's MCP loading, the style system's extensibility is weaker. 8. **Coupling risk from shared Skill infrastructure**: `loadMarkdownFilesForSubdir` is shared between the style system and the Skill system. If the Skill system needs more complex loading logic in the future (e.g., version control, signature verification), this sharing could become a constraint. ### Architectural Observation The output style system exemplifies the "configuration as prompt" design paradigm in AI-native applications—styles do not change output through code logic, but by modifying the system prompt to guide AI behavior. Cursor's `.cursor/rules/`, Windsurf's `.windsurfrules`, Aider's conventions files, and OpenAI's Custom Instructions all follow a similar approach. But the deeper question is: **When prompts become configuration files, do traditional software engineering best practices for configuration management still apply?** - **Schema validation**: Traditional config files (like `tsconfig.json`) have strict JSON Schema validation, and type errors are reported at parse time. The style system's frontmatter has no schema validation; incorrect field names are silently ignored—this is not a problem at Claude Code's current scale of 3 built-in styles, but if a community style ecosystem opens up in the future, the lack of validation will lead to many "why isn't my style working" issues. - **Version control and rollback**: Style files can be version-controlled via Git, which is good. But there are no style version numbers or compatibility markers—if a future Claude Code upgrade renders certain prompt patterns ineffective, users have no way to know whether their styles need updating. - **Canary releases and A/B testing**: Traditional config systems support percentage-based canary releases; the style system currently has no such capability. For enterprise users, validating a new style with a small group before rolling it out to the whole team is a reasonable requirement. These "old problems mapped to a new paradigm"—i.e., whether prompt configurations need the engineering governance of traditional configuration management—are architectural decisions that AI tool platforms must face as they scale. Claude Code currently chooses "simplicity first," which is reasonable at this stage, but as the style ecosystem expands, these engineering capabilities may become necessary.