All authors
Claude Skills by jhlee0409
github.com/jhlee040950 skills0 installs99 views
- AnalyzeCode and component analysis — analyze code, trace flows, audit consistency, inspect componentsVotes: 0GitHub stars: 7
- ArchitectArchitecture analysis and design reviewVotes: 0GitHub stars: 7
- AutoFull auto pipeline — run spec-to-clean cycle automatically for new featuresVotes: 0GitHub stars: 7
- CheckpointSave session state for later resumptionVotes: 0GitHub stars: 7
- ClarifyResolve spec ambiguities with clarifying questionsVotes: 0GitHub stars: 7
- CleanPipeline artifact cleanup and codebase hygieneVotes: 0GitHub stars: 7
- ConsultExpert consultation — backend, infra, PM, design, marketing, legal, or tech guidanceVotes: 0GitHub stars: 7
- DebugBug diagnosis and fix — root-cause analysis for errors, crashes, broken behaviorVotes: 0GitHub stars: 7
- DoctorDiagnose afc plugin setup and healthVotes: 0GitHub stars: 7
- IdeateExplore and structure a product idea — brainstorm, ideate, create product briefVotes: 0GitHub stars: 7
- ImplementExecute code implementation — implement features, refactors, or planned changesVotes: 0GitHub stars: 7
- InitProject initial setup and tech stack detectionVotes: 0GitHub stars: 7
- IssueAnalyze GitHub issue — investigate bug reports, understand requirements, inspect issuesVotes: 0GitHub stars: 7
- LaunchGenerate release artifacts — version bump, changelog, release tagsVotes: 0GitHub stars: 7
- LearnerReview and promote learned patterns to project rulesVotes: 0GitHub stars: 7
- PlanImplementation design — plan approach, create file change map, design architectureVotes: 0GitHub stars: 7
- Pr CommentPost structured review comments to GitHub PRVotes: 0GitHub stars: 7
- PrinciplesManage project coding principles and conventionsVotes: 0GitHub stars: 7
- QaProject quality audit — test confidence, error handling gaps, code healthVotes: 0GitHub stars: 7
- Release NotesGenerate release notes from git historyVotes: 0GitHub stars: 7
- ResearchTechnical research — investigate technologies, compare libraries, explore optionsVotes: 0GitHub stars: 7
- ResolveAddress LLM bot review comments on PR — fix valid issues, dismiss false positivesVotes: 0GitHub stars: 7
- ResumeRestore previous session stateVotes: 0GitHub stars: 7
- ReviewCode review — review code, analyze PR diff, evaluate quality and correctnessVotes: 0GitHub stars: 7
- SecuritySecurity scan — vulnerability check and threat assessmentVotes: 0GitHub stars: 7
- SetupConfigure afc routing block in global CLAUDE.mdVotes: 0GitHub stars: 7
- SpecGenerate feature specification — write requirements, acceptance criteria, scopeVotes: 0GitHub stars: 7
- TasksTask decomposition from plan with dependency trackingVotes: 0GitHub stars: 7
- TestTest strategy and writing — unit, integration, e2e tests, coverage improvementVotes: 0GitHub stars: 7
- TriageParallel triage of open PRs and issuesVotes: 0GitHub stars: 7
- ValidateValidate spec/plan/task artifact consistencyVotes: 0GitHub stars: 7
- QaProject quality audit — test confidence, error handling gaps, code healthVotes: 0GitHub stars: 7
- Accessibility ChecksUse 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...Votes: 0GitHub stars: 2
- Chrome Verify ChecksUse 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...Votes: 0GitHub stars: 2
- Db Verify ChecksUse 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 ...Votes: 0GitHub stars: 2
- Llm Eng ChecksUse 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...Votes: 0GitHub stars: 2
- Perf ChecksUse 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...Votes: 0GitHub stars: 2
- Ui Verify ChecksUse 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...Votes: 0GitHub stars: 2
- AdrRecord 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".Votes: 0GitHub stars: 2
- AssessRead-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.Votes: 0GitHub stars: 2
- Blast RadiusEnumerate 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...Votes: 0GitHub stars: 2
- Coding GuidelinesBehavioral 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".Votes: 0GitHub stars: 2
- DiagnoseDisciplined 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", "버그 진단", "왜 안 되지", "디버깅".Votes: 0GitHub stars: 2
- HandoffWrite 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).Votes: 0GitHub stars: 2
- IntrospectScan 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".Votes: 0GitHub stars: 2
- LocalizeResolve 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.Votes: 0GitHub stars: 2
- New SpecScaffold 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", "기획부터".Votes: 0GitHub stars: 2
- PickupRe-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".Votes: 0GitHub stars: 2
- TddDrive 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.Votes: 0GitHub stars: 2
- WorktreeCreate 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".Votes: 0GitHub stars: 2