oh-my-claude

Use when the user's request is ambiguous — vague asks, polysemous instructions, unclear scope — BEFORE committing to a feature. Two-track loop (one question at a time + parallel codebase exploration) producing a Context Brief that becomes the SSOT for the follow-up work.

Use when code behaves differently from expectations — 'why does this happen', 'find the bug', 'follow the callstack', symptom reports even without the word debugging. Blackbox methodology: AS-IS/TO-BE confirmation, callstack tracing recorded in a CWD-relative trace file, red-green fix.

Use when a trace.md with unfinished scenarios exists and the user wants autonomous implementation — 'continue the work', 'implement the traced feature', or after a bundle was selected. Accepts an explicit bundle contract (trace_path + scenario_ids); scans for ready scenarios only when no contract is given.

Use when the problem is vague, the domain unfamiliar, multiple approaches are possible, or the user says 'investigate first' / 'before we spec this'. Read-only stance (not a workflow): no code changes, no mandatory artifacts; exits to spec/debug/clarify/direct implementation when insight crystallizes.

Use when the user gives a vague or high-level feature request that needs decomposition into implementable work — new ideas, '~만들어줘' with implicit requirements, features with multiple possible approaches. NOT for specific 1-2 file changes, obvious bug fixes, quick questions, or when spec/trace already exist (use stv:do-work).

Use when the trace backlog has ZERO unfinished scenarios (or the user explicitly asks for new feature ideas) and the project needs its next feature proposed. Hands the chosen idea to new-task for spec + trace.

Use when requirements and architecture need explicit definition before tracing — a new feature interview, or updating an existing spec.md (Update vs New). STV Phase 1: Proposal (WHY) -> Explore First (mandatory unknowns map) -> interview -> docs/{feature}/spec.md.

Use when the user wants real-world experience turned into a methodology, skill, or process — 'turn this into a methodology', 'systematize my approach', 'make this into a skill', or after stv:explore / completed work when raw practice should become reusable structure. Bottom-up inductive distillation, not top-down theory.

Use when a spec.md exists and per-scenario vertical traces + RED contract tests must be derived — or an existing trace.md needs Delta Protocol updates. STV Phase 2: spec.md -> docs/{feature}/trace.md, 7+1-section format with parameter transformation arrows.

Use when a PR must be checked against its issue/spec before merge — 'check the PR', 'is it implemented per the issue', 'compare spec vs implementation', 'verify', 'validate'. Final 3D conformance gate (Completeness/Correctness/Coherence). Inputs: issue (URL or contents) + PR URL.

Use when you do not know what to work on next, the user asks 'what should I work on' / '뭐하지', or a session starts over an existing STV backlog. Routes to what-we-have-to-work when ANY unfinished scenario exists, or plan-new-task when the backlog is empty.

Use when unfinished trace scenarios exist and the next execution scope must be chosen. Bundles leftovers of ANY size into 1-3 options and hands the selected bundle contract (trace_path + scenario_ids) to do-work.

Use when trace scenarios need implementation to GREEN plus trace-conformance verification — invoked with a trace path and OPTIONAL scenario_ids for targeted execution. STV Phase 3.

This skill should be used when the user asks to "visualize data", "render a chart", "plot numbers", "show a graph in terminal", "create a bar chart", "make a sparkline", "draw a heatmap", or needs to display numeric data as terminal charts using chartli. Also triggers on "chartli", "terminal chart", "ASCII chart", "braille chart".