oh-my-kimicli

Perform focused code review after meaningful code, config, prompt, workflow, or documentation changes; before commit or PR; or whenever the user asks for review. Uses parallel subagents for 4-perspective review (security, correctness, tests, architecture). Report real issues only and write the report under the current workspace .omk directory.

Keep working autonomously under the oh-my-kimicli Stop-hook Ralph system until the task is complete, verified, or honestly blocked. Use when the user says keep going, don't stop until done, just finish it, complete this end-to-end, plow through it, or similar no-hand-holding language. Also used by ultrawork as its persistence layer. Do not use for one-shot Q&A, simple lookups, or tasks that should stop after a normal single response.

Generate an oh-my-kimicli usage insights report from KimiCLI sessions. Use when the user asks for usage insights, session analysis, work patterns, friction analysis, suggestions, skill opportunities, repeated-instruction analysis, or an insights report.

Autonomous high-throughput execution for complex tasks. Trigger when the user says ulw, ultrawork, keep going, finish it, complete this end-to-end, or asks for no-hand-holding work across multiple files, tests, investigation, or review. Uses omk-ralph hook state for persistence and omk-review as the final quality gate. Do not use for simple one-shot answers or tiny edits.

Resolve execution-time uncertainty before making a consequential choice. Use during an active task when a concrete implementation detail is unclear, multiple valid approaches have different outcomes, or an action may affect important files/data/configuration. Do not use for unclear goals, scope, or requirements; use requirements-elicitation for that. Do not use for trivial choices or anything that can be safely inferred from context.

Clarify the user's goal, scope, constraints, audience, and acceptance criteria before execution when a request is under-specified and guessing would risk building the wrong thing. Trigger for broad requests like build, design, plan, write, or develop X without enough detail, or problem statements missing purpose, users, constraints, scale, must-have behavior, or done criteria. Do not trigger when the user gave enough detail, explicitly says just do it or you decide, or asks for a simple one-off. Use clarify-first later for execution-time decisions.