Output Style Authoring

Author Claude Code output styles that change response role, tone, structure, and format without smuggling project conventions or unsafe coding behavior into the style. Treat an output style as persistent system-prompt instruction text, not as a skill, artifact, policy file, or project memory. [DOC]

Use current Claude Code docs as required evidence when giving operational advice because output-style selection, plugin behavior, and frontmatter fields are version-sensitive. If the docs or target runtime cannot be checked, mark coverage_gap. [DOC]

Version note (official). The standalone /output-style command was deprecated and later removed. Select an output style via /config → Output style, or edit the outputStyle setting directly. Do not instruct users to run /output-style. Exact deprecation/removal versions are not verifiable offline; treat any specific version numbers as coverage_gap until checked against current docs. [DOC] (https://code.claude.com/docs/en/output-styles) [SUPUESTO]

Inputs Expected

• Target scope: user-level, project-level, managed policy, or plugin-packaged output style. [DOC]
• Target path or package shape, such as ~/.claude/output-styles/, .claude/output-styles/, <plugin>/output-styles/, or a manifest outputStyles path. [DOC]
• Intended behavior: communication style, response format, role, artifact presentation, review voice, teaching mode, or non-coding persona. [DOC]
• Coding posture: still coding with Claude Code defaults preserved, or non-coding work where the built-in software engineering instructions should be omitted. [DOC]
• Distribution posture: local experiment, repo-shared style, managed configuration, plugin default style, or forced plugin style. [DOC]

Outputs Expected

• A safe output-style Markdown file or review report. [DOC]
• Correct frontmatter for name, description, keep-coding-instructions, and plugin-only force-for-plugin. [DOC]
• Body instructions written as concise system-prompt directives. [DOC]
• A decision on when to use an output style versus a skill, CLAUDE.md, an appended system prompt, an agent, or an artifact. [DOC]
• Validation evidence and residual coverage_gap for runtime version, plugin load order, path placement, style selection, or coding-instruction preservation. [CONFIG]

Procedure

1. Classify The Style

Decide whether the user needs a persistent response style, a reusable workflow, a project convention, a one-off system-prompt addition, a subagent, or an artifact. Use references/safety-and-boundaries.md when the request crosses skills, artifacts, or coding policy. [DOC]

Use an output style only when the same role, tone, or default response format should apply across turns. Use a skill when the user needs a reusable procedure. Use an artifact when the output should become a live or shareable page. [DOC]

2. Choose Scope And Placement

Use references/claude-code-output-styles.md for path and frontmatter rules. Place standalone styles under output-styles/*.md in the correct Claude Code scope. For plugins, use references/plugin-output-styles.md and confirm whether the plugin uses the default output-styles/ directory or a manifest outputStyles override. [DOC]

3. Preserve Coding Instructions Deliberately

Set keep-coding-instructions: true when Claude should still behave like Claude Code while changing communication style or output format. Omit it or set false only when the style is not for software engineering. Apply assets/output-style-dod-checklist.md before finalizing. [DOC][CONFIG]

When keep-coding-instructions is false for a style that still mentions tools, edits, code, or verification, stop and revise. Either preserve coding instructions or write a non-coding style that does not imply normal Claude Code engineering behavior. [INFERENCIA]

4. Write The Style Body

Write the Markdown body as system-prompt instructions. Prefer direct imperatives, compact sections, and explicit output constraints. Avoid project facts, secrets, repo-specific policy, hidden chain-of-thought requests, permission bypasses, or instructions that weaken user approval. [DOC][INFERENCIA]

Use assets/style-template.md as the starting point and assets/frontmatter-schema.json as the field checklist. Keep the style body short enough to avoid unnecessary recurring system-prompt token cost. [DOC]

5. Handle Plugin Defaults Safely

Use force-for-plugin: true only when a plugin cannot operate safely or coherently without that style. State that forced plugin styles override the user outputStyle setting and that multiple forced styles depend on plugin load order. Prefer opt-in styles when user autonomy matters. [DOC][INFERENCIA]

6. Validate

For this skill packet, run from the plugin root (CLAUDE_PLUGIN_ROOT, default ~/.claude/plugins/claude-native-toolkit):

cd "${CLAUDE_PLUGIN_ROOT:-$HOME/.claude/plugins/claude-native-toolkit}"
bash scripts/check.sh                 # frontmatter + evals + lineage gate (CI entry point)
python3 -B scripts/validate_packet.py # per-skill packet audit (needs CWD = plugin root)
git diff --check -- skills/output-style-authoring

For a generated output style, validate frontmatter, target path, style selection or plugin reload requirement, and whether /clear or a new session is needed before behavior changes take effect. [DOC]

Quality Criteria

• Style scope and path are explicit. [DOC]
• Frontmatter includes name and description; keep-coding-instructions and force-for-plugin are justified when present. [DOC]
• Body instructions are system-prompt-style directives, not project memory, task procedure, or artifact content. [DOC]
• Coding-instruction preservation is explicit for any coding style. [DOC]
• Plugin output styles document reload behavior, forced-style risk, and load-order ambiguity when relevant. [DOC]
• Skills and artifacts are routed to their own surfaces rather than overloaded into output styles. [DOC]
• Safety review blocks permission bypass, hidden reasoning exposure, secret capture, and weakening of verification habits. [INFERENCIA]

Resources

• references/claude-code-output-styles.md - Core output-style semantics, placement, frontmatter, use cases, and activation behavior. [DOC]
• references/plugin-output-styles.md - Plugin packaging, manifest paths, reload behavior, and forced-style guardrails. [DOC]
• references/safety-and-boundaries.md - Relation to skills, artifacts, project docs, agents, and safety boundaries. [DOC][INFERENCIA]
• assets/output-style-dod-checklist.md - Authoring and review checklist. [CONFIG]
• assets/frontmatter-schema.json - Machine-readable field catalog for output-style files. [CONFIG]
• assets/style-template.md - Reusable output-style Markdown starter. [CONFIG]
• assets/source-map.md - Source URLs and refresh notes for maintainers. [DOC]
• examples/example-input.md and examples/example-output.md - Concrete authoring request and expected response. [CONFIG]
• evals/evals.json - Activation, routing, boundary, safety, and false-positive eval cases. [CONFIG]

Contract

• Acceptance: reusable output style with keep-coding-instructions when it affects code. [EXPLICIT]
• Limits: repeated formatting only; a one-off is better served by an artifact. [EXPLICIT]
• Edge cases: /output-style removed → use /config. [EXPLICIT]
• Assumptions: config feature with no in-session tool [DOC]. [SUPUESTO]
• Trade-off: persistent style vs one-off terse-output — consistency vs adaptability. [EXPLICIT]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · templates/ plantilla de output · assets/ recursos estáticos.