harness-kit

Plugin harness-kit from marketplace harness-kit-marketplace in jhlee0409/omni-harness-kit. Commands read from the repo's manifest — 1 month ago.

Skills (18)

• accessibility-checks

  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` / `g

• chrome-verify-checks

  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

• db-verify-checks

  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 ow

• llm-eng-checks

  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 —

• perf-checks

  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 → memo

• ui-verify-checks

  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

• adr

  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".

• assess

  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 "유지보수성 점검",

• blast-radius

  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 sy

• coding-guidelines

  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".

• diagnose

  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", "버그 진단", "왜 안 되지", "디버깅".

• handoff

  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).

• introspect

  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 t

• localize

  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

• new-spec

  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", "기획부터".

• pickup

  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".

• tdd

  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",

• worktree

  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".

Subagents (9)

• architecture-reviewer

  Fresh-context architecture-fit critic — reviews a diff against the project's stated architecture (its ARCHITECTURE.md / the CLAUDE.md spine / ADRs) and an architecture-smell taxonomy: layer compliance, smell delta, domain invariants, reuse-before-build, throwaway-vs-durable intent, blast radius of t

• change-verifier

  Independently verifies that a code change is actually complete before it is reported done. Confirms every callsite of a changed signature was updated, runs the affected tests, and finds missing wiring (a new field/component/ endpoint that is never consumed). Use before claiming a migration, interfac

• claim-checker

  Independently falsifies a TERMINAL / analytical claim before it is stated as a conclusion — "X is the limit / ceiling", "this is impossible", "the context is sufficient", "this fully solves it", "no effect". Checks whether the claim was MEASURED or merely asserted, names the measurement that would f

• instruction-critic

  Independent critic for an INCOMING multi-step instruction, before any work starts. Audits the request against three cores — ① ambiguity ② scope ③ is this the real problem — plus repo grounding (a mentioned PR# / file / field actually exists and isn't already done). Use on a non-trivial instruction,

• pr-shepherd

  Tracks a pull / merge request toward a mergeable state — but it does NOT assume any particular PR workflow. It DISCOVERS the repo's actual setup (host, CI, reviewers, bots) at runtime, honors a per-repo `pr_workflow` config for intent it can't infer, and degrades gracefully when something isn't ther

• readability-critic

  Critic for a HUMAN-FACING output (a report / summary / dashboard / scorecard): can a person actually make a DECISION from it? Readable labels, actionable rows, no jargon-only descriptions. Use before shipping a human-facing surface, or when the user says "가독성 검토", "사람이 판단할 수 있어?", "내가 판단할 게 없잖아", "c

• requirement-fidelity-critic

  Independent critic for a SPEC / DESIGN / plan ARTIFACT — does it actually solve the user's ORIGINAL stated requirement, or has it drifted to an easier/adjacent problem? Catches drift at the artifact stage, before code is built on a drifted premise. Use after a spec/design is drafted, or when the use

• spec-reviewer

  Independently checks a PR's diff against what its active spec REQUIRED — did the change deliver the spec's scope, silently exceed it, or skip a plan task it claims to close? If the PR has NO spec (hotfix / doc-only), it NO-OPS and never blocks. Use at PR time, or when the user asks "스펙대로 됐어?", "범위 넘

• tdd-runner

  Runs Kent Beck's red → green → refactor loop end-to-end for a single behavior change and returns one green-with-evidence verdict. Writes the failing test FIRST, runs it to confirm red, implements the minimum to go green, then refactors. Use when the user wants a behavior built/fixed test-first hands

Hooks (2)

• PreToolUse

  "${CLAUDE_PLUGIN_ROOT}"/hooks/scripts/protected-branch-guard.sh

• Stop

  "${CLAUDE_PLUGIN_ROOT}"/hooks/scripts/verify-loop.sh

Similar plugins