Claude Skills by jhlee0409

Code and component analysis — analyze code, trace flows, audit consistency, inspect components

Architecture analysis and design review

Full auto pipeline — run spec-to-clean cycle automatically for new features

Save session state for later resumption

Resolve spec ambiguities with clarifying questions

Pipeline artifact cleanup and codebase hygiene

Expert consultation — backend, infra, PM, design, marketing, legal, or tech guidance

Bug diagnosis and fix — root-cause analysis for errors, crashes, broken behavior

Diagnose afc plugin setup and health

Explore and structure a product idea — brainstorm, ideate, create product brief

Execute code implementation — implement features, refactors, or planned changes

Project initial setup and tech stack detection

Analyze GitHub issue — investigate bug reports, understand requirements, inspect issues

Generate release artifacts — version bump, changelog, release tags

Review and promote learned patterns to project rules

Implementation design — plan approach, create file change map, design architecture

Post structured review comments to GitHub PR

Manage project coding principles and conventions

Project quality audit — test confidence, error handling gaps, code health

Generate release notes from git history

Technical research — investigate technologies, compare libraries, explore options

Address LLM bot review comments on PR — fix valid issues, dismiss false positives

Restore previous session state

Code review — review code, analyze PR diff, evaluate quality and correctness

Security scan — vulnerability check and threat assessment

Configure afc routing block in global CLAUDE.md

Generate feature specification — write requirements, acceptance criteria, scope

Task decomposition from plan with dependency tracking

Test strategy and writing — unit, integration, e2e tests, coverage improvement

Parallel triage of open PRs and issues

Validate spec/plan/task artifact consistency

Project quality audit — test confidence, error handling gaps, code health

Use when verifying accessibility (WCAG 2.2 AA) of a rendered UI in a real browser before reporting done — the omp-native replacement for the chrome-devtools a11y plugin. Runs a concrete ordered checklist with omp's builtin `browser` tool (open tab → `tab.evaluate` DOM query / `elementFromPoint` / `getComputedStyle` / `getBoundingClientRect` / `tab.screenshot`), NOT chrome-devtools MCP or axe-in-CI self-report. Every criterion gets PASS/FAIL WITH the measured value (contrast ratio, px size, ta...

Use when verifying a chrome-extension/ change before reporting done. The canonical 7-check list (build → Service Worker vm.createContext compat → manifest sanity → per-site content-script DOM contract → message-passing trace → test suite → manual-load checklist) + verdict rules. chrome-extension/ is a strong-guard sub-context the maintainer cannot easily verify (MV3 SW quirks, per-site content-script breakage). Load when invoking chrome-verify or after any change in chrome-extension/. Trigger...

Use when verifying data-shape claims against a real store — MongoDB or a SQL store (SQLAlchemy / SQLite / Postgres) — before reporting any data-touching change done. Detects the store from repo config, then runs the canonical checks (existence count, type distribution, 10-row/doc sample, index or owner crosscheck) and emits a CONFIRMED / REFUTED / CANT-VERIFY verdict. Default target = local store; prod only on schema-change + explicit approval. Load when invoking db-verify, backend-architect ...

Use when building or hardening an LLM feature — prompt design, RAG, eval harness, model/provider selection, guardrails, and token/cost budgeting — with omp-native tools (bash for real API round-trips, read/grep for the repo's own client, no vendor-plugin dependency, provider-agnostic). PRIME RULE — no LLM feature is "working" until ONE real API round-trip is shown (real prompt in, real output quoted, provider+model named); a stubbed/synthetic response is "static OK, dynamic unverified", never...

Use when investigating or optimizing performance in a real browser/build/DB before reporting a fix — the omp-native replacement for the chrome-devtools LCP/memory-leak plugins. Ordered MEASURE-before-and-after methodology (Core Web Vitals → LCP breakdown → bundle → render → DB query → caching → memory leaks) driven by the omp `browser` (`tab.evaluate` + CDP), `bash`, and `lsp` builtins. Every claim carries a before/after NUMBER — "should be faster" is banned. Load before claiming any perf imp...

Use when verifying a frontend UI change in a real browser before reporting done. The canonical 7-check list (real auth → render≠behavior → scroll containment → primary-button reachability → selection-state sync → responsive → console) + environment fail-fast rule (transport-unreachable vs HTTP error distinction) + verdict rules. Load when invoking ui-verify, after any UI change in the frontend app, before claiming any user-visible feature works. Triggers on UI check, design broken, scroll che...

Record an architecture / cross-cutting decision as the next numbered ADR under docs/adr/. Use when a non-obvious or hard-to-reverse decision is made (a module boundary, a trade-off, a tech choice), or when the user says "record an ADR", "ADR 남겨", "이 결정 기록", "document this decision".

Read-only maintainability audit of a whole codebase — ranks the files most likely to cause maintenance pain (size × churn hotspots, test gaps, lint debt) and proposes discrete fixes, each as its own PR. Use before a cleanup/refactor pass, when inheriting a codebase, or when the user says "유지보수성 점검", "어디부터 리팩토링", "코드베이스 상태 봐줘", "where is the tech debt?", "what should we clean up first?". Produces a findings table + top-3 fix proposals; it edits nothing and stores no grade.

Enumerate the full impact set of a symbol before or during a change — every reference, caller, implementation/subtype, and reverse import — plus an explicit list of what could NOT be resolved (dynamic dispatch, reflection, generated code). Use before touching a shared / exported / widely-imported symbol, before an interface or signature change, or when the user asks "what breaks if I change this?", "어디까지 영향 가?", "누락 없이 찾아줘", "전부 찾았어?". Produces an evidence table + an "enumeration complete?" c...

Behavioral guidelines that reduce common LLM coding mistakes — surgical changes, no overcomplication, surface assumptions, define verifiable success, no silent scope creep. Use while writing, reviewing, or refactoring code, or when the user says "코딩 가이드", "수술적으로", "과설계 하지마", "keep it simple".

Disciplined diagnosis loop for a hard bug or performance regression — reproduce → minimize → hypothesize → instrument → fix the cause → regression-test. Use when something is broken / throwing / failing or regressed, or when the user says "diagnose this", "debug this", "버그 진단", "왜 안 되지", "디버깅".

Write the live working-set state into a resume block so a FRESH session can continue this work without re-narration. Use when stopping mid-task, or when the user says "handoff", "핸드오프", "체크포인트", "이어서 할 수 있게", "checkpoint". Pairs with `/harness-kit:pickup` (handoff writes, pickup reads).

Scan a repository's tech stack and generate a tailored Claude Code harness for it — a thin .claude/CLAUDE.md spine, stack-specific architect agent(s), and specs/ADR scaffolding — fitting the generic harness-kit engine to this repo. Use when setting up the harness in a new or existing repo, or when the user says "set up the harness here", "introspect this repo", "tailor claude config", "scaffold .claude for this project".

Resolve a change request into an EXACT edit target before touching code, then gate the edit on tests — the localize → edit → validate loop. Use for a bug fix, an issue, or a feature change where the right files/symbols are not already obvious, or when the user says "이거 고쳐줘", "어디를 고쳐야 해?", "fix this issue", "where does this live?". Produces a localization artifact (targets + evidence + uncertainty) first; edits only after it, validates with a focused test then a regression run.

Scaffold a spec triplet (spec.md / plan.md / context.md) under specs/YYYYMMDD-<name>/ before starting a non-trivial piece of work. Use when a task spans multiple modules / several commits / a new ADR, or when the user says "new spec", "스펙 만들어", "plan this out", "spec this", "기획부터".

Re-enter in-flight work in a fresh session by reading a resume block a previous session left (the read half of the handoff/pickup loop). Use at the start of a fresh session, or when the user says "pickup", "resume", "이어서", "재개", "어디까지 했지", "continue where we left off".

Drive a single behavior change with Kent Beck's red → green → refactor loop — write the failing test FIRST, confirm it fails for the right reason, implement the minimum to pass, then refactor. Use when building a feature or fixing a bug test-first, or when the user says "TDD", "red-green-refactor", "테스트 먼저", "실패 테스트부터". For a hands-off loop that owns the whole cycle, delegate to the `tdd-runner` agent instead.

Create an isolated git worktree for a code-change task (../<repo>-<slug> on its own branch), keeping the main checkout clean. Use in a repo that opted into the worktree-per-task workflow, or when the user says "new worktree", "워크트리 만들어", "isolate this task", "task별 worktree".