rules
The Codex Rules skill automatically injects static project instructions and file-specific rules into Claude sessions to enforce custom coding standards and behaviors. Use this skill when users ask about configuring rule file locations, understanding how rules are matched and applied, managing environment variables that control rule injection, or troubleshooting rule behavior across different project sources including CONTEXT.md, .omo/rules, .claude/rules, .cursor/rules, and GitHub instruction directories.
git clone --depth 1 https://github.com/code-yeongyu/lazycodex /tmp/rules && cp -r /tmp/rules/plugins/omo/skills/rules ~/.claude/skills/rulesSKILL.md
# Codex Rules Codex Rules is automatic once the plugin is enabled. It injects: - static project instructions on `SessionStart` and `UserPromptSubmit` - matching file-specific rules after Codex `apply_patch` by default Dynamic `PostToolUse` output is injected as additional context and is deduplicated per plugin data session. Codex Rules does not rewrite tool output. Supported project sources: - `CONTEXT.md` - `.omo/rules/**/*.md` - `.claude/rules/**/*.md` - `.cursor/rules/**/*.md` - `.github/instructions/**/*.md` - `.github/copilot-instructions.md` Supported environment knobs: - `CODEX_RULES_DISABLED=1` - `CODEX_RULES_MODE=both|static|dynamic|off` - `CODEX_RULES_MAX_RULE_CHARS=<number>` - `CODEX_RULES_MAX_RESULT_CHARS=<number>` - `CODEX_RULES_ENABLED_SOURCES=CONTEXT.md,.omo/rules` The legacy `PI_RULES_*` variables are accepted as fallbacks for users migrating from `pi-rules`.
Use when Codex needs to understand or respond to automatic comment-checker feedback emitted after an edit-like PostToolUse hook.
Use when Codex needs language-server diagnostics, definitions, references, symbols, or rename safety checks in the current workspace.
Codex-native strategic planning consultant. Explores the codebase exhaustively, surfaces only the ambiguities exploration cannot resolve, asks the user, and waits for explicit approval before producing one decision-complete work plan. MUST USE when the work has 5+ steps, scope is ambiguous, multiple modules are involved, or the user asks for a plan. Triggers: ulw-plan, plan this, create a work plan, interview me, start planning, plan mode, break this down.
Goal-like loop that uses ultrawork mode to decompose work into systematic, evidence-bound steps.
MUST USE for any real runtime debugging across ANY language or binary — crashes, silent failures, wrong responses, stuck processes, memory leaks, async misbehavior, unexplained timing, reverse engineering. Runs a hypothesis-driven loop: form ≥3 hypotheses, investigate in parallel, after 2 failed rounds spawn Oracles from orthogonal angles, confirm root cause, lock with a failing test, fix minimally, QA by actually USING the system, scrub artifacts. The actual HOW lives in `references/` — READ THEM. Triggers: 'debug this', 'why is X not working', 'hanging', 'attach a debugger', 'reverse engineer', 'pwndbg', 'gdb', 'lldb', 'node inspect', 'tsx debug', 'pdb', 'dlv', 'delve', 'rust-gdb', 'set a breakpoint', 'context window exploded', 'why is the response empty', 'attach the debugger', 'debug it', 'why is this happening', 'trace this bug', 'reproduce and fix', 'silent failure', 'HTTP 200 but empty', 'why did it stop', 'inspect the binary', 'reverse engineering', 'playwright'.
Designer-turned-developer who crafts stunning UI/UX even without design mockups
MUST USE whenever a task needs a commit or git-history investigation. Covers atomic commits, staging, commit-message style, rebase, squash, fixup/autosquash, blame, bisect, reflog, git log -S/-G, and questions like who wrote this or when was this added. Do not use for ordinary code edits unless the user asks for git work.
(builtin) Initialize hierarchical AGENTS.md knowledge base