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.
MUST USE for planning before coding: 5+ steps, ambiguous scope, multiple modules, architecture decisions, a vague 'just make it good / figure out what to build' brief, or any request to plan, interview, or break work down. Explore-first planning consultant (Prometheus) that grounds in the codebase, asks only the forks exploration cannot resolve - or researches them to best practice when the intent is fuzzy - waits for explicit approval, then writes ONE decision-complete work plan a worker executes with zero further interview. Triggers: ulw-plan, plan this, make a plan, plan before coding, interview me, break this down, start planning, plan mode, just make it good, figure out what to build.
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