Use when editing, creating, refactoring, formatting, especially Unreal C++ .h .cpp, ModuleRules .Build.cs, TargetRules .Target.cs, comments, includes, lambdas, naming, copyright headers, custom copyright header config, author/date header fields, CRLF, and Tab indentation.
Installation
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Use when editing, creating, refactoring, formatting, especially Unreal C++ .h .cpp, ModuleRules .Build.cs, TargetRules .Target.cs, comments, includes, lambdas, naming, copyright headers, custom copyright header config, author/date header fields, CRLF, and Tab indentation.
Orion Code Style
Use this skill for all code creation, refactoring, and formatting in this project. Before touching .h, .cpp, .Build.cs, .Target.cs, or other code files, read the detailed Simplified Chinese reference:
references/orion-code-style.zh-CN.md
Core rules:
Use CRLF for Windows text code files.
Use Tab indentation for all code files. Do not use spaces for indentation, including C++, .Build.cs, and .Target.cs.
In .h files, keep trivial inline functions on one line when the body is a single simple expression or return; .cpp files do not need this one-line rule. Namespace definitions still use Allman braces on separate lines.
For project modules, PublicDependencyModuleNames must only contain "Core", "CoreUObject", and "Engine" unless the user explicitly authorizes otherwise. Put all other dependencies in PrivateDependencyModuleNames, and do not delete or rewrite existing business logic just to satisfy dependency placement.
Do not add #include "CoreMinimal.h" to generated code. Include the actual minimal engine/project headers needed by the types used.
Separate top-level code sections with a blank line, including copyright header, pragma, include block, forward declarations, and class/struct declarations.
Copyright block comments must be followed by one blank line before #pragma once, #include, or any other code.
In Unreal headers, place the .generated.h include after all other includes, separated from the regular include block by a blank line; do not put any include after .generated.h.
Use GENERATED_BODY() for USTRUCT; do not generate GENERATED_USTRUCT_BODY().
Use GENERATED_BODY() for UCLASS; do not generate GENERATED_UCLASS_BODY().
Class comments use Doxygen block comments (/** ... */), not // line comments.
Doxygen block comments must align the leading * with one space after the current Tab indentation: top-level lines use *, nested lines use \t *; never write \t*.
Treat installed Unreal Engine code as read-only. Do not edit, patch, instrument, format, chmod/attrib, or otherwise modify files under an installed engine root; only read them for API/reference lookup. If engine-level diagnostics seem necessary, stop and ask for an explicit source-engine workspace or another project-local approach.
Only generate the configured copyright header for code files newly created by this task. Existing code files are not header-fill targets unless the user explicitly asks; if an existing code file already has any copyright header, keep it unchanged even when it differs from the current template.
Only add Author, Date, Website, or other custom header lines when the header config template explicitly requests them; do not add ad hoc author lines.
Match Source/GameCore style for naming, spacing, comments, includes, lambdas, long-call wrapping, and alignment.
For existing historical files, format only newly added or touched code unless the user explicitly asks for full-file formatting.