MichaelYcJo

evidence-ci

Wire the ledger drift check into this repo's CI — vendor the checker and write the workflow, so drift fails a build instead of waiting to be run by hand.

parity-setup

Declare that this repo ports behavior from another codebase — find the original, record the baseline, write .specseal/parity.md.

preset-setup

Merge the specseal CLAUDE.md block into the user's CLAUDE.md with semantic dedup — propose, get approval, then apply.

Data & Documents Listed

Walk a web-service security checklist — OWASP Top 10, auth, data exposure, configuration, dependencies. For a service taking untrusted input over a network; on a mobile, embedded, library, or pipeline target it reports cleanly about the wrong threats.

Testing & QA Listed

testing

Walk a test-strategy pass — which level each test belongs at, what to cover first, the edge cases that get missed. Verifying a completion claim is `verify`; chasing one failing test is `debug`.

update

Update the plugin to the newest release and say what changed — runs both commands in the right order, then names the entries you are getting.

code-review

Two-stage review methodology (spec compliance, then quality) with comparison axes, cross-session review records, and re-review inheritance. Use when: reviewing a PR or diff, re-reviewing after fixes, orchestrating reviewer agents. NOT for: implementing fixes (use `implement`), style-only linting a formatter can do, or a plain bug-and-cleanup sweep of a diff — Claude Code's built-in `/code-review` covers that. This one judges spec compliance before quality and carries earlier rounds' coordinates across sessions.

confidence-check

Readiness check before implementing: does something equivalent already exist, is the API verified against the installed version, is the cause of the bug actually understood rather than guessed. Reports which checks are unsatisfied — no score, since any single miss is the whole answer. Use when: about to build something non-trivial against an unfamiliar library, a suspected duplicate, or a bug whose cause is still a hypothesis. NOT for: firing on your own while the smith is driving — its design gate invokes this when readiness is the open question. Not for typo, config, or one-line changes.

evidence-check

Verify that the evidence ledger's spec-to-code coordinates still resolve — broken links fail, ranges touched since the baseline demand re-verification. Use when: checking ledger health, before merging spec-driven work, wiring the check into CI, or after large refactors. NOT for: judging whether the code is CORRECT — this checks that the evidence still points somewhere, not that the claim is still true.

gap-analysis

Compare a design or spec document against what was actually built — API surface, data model, business logic — and list what is missing, extra, or divergent. Use when: a written design exists and someone needs to know how far the implementation has drifted from it. NOT for: checking that ledger coordinates still resolve (`evidence-check`), judging ported behavior against an original (`legacy-parity`), or reviewing a diff (`code-review`).

implement

Spec-driven implementation methodology: document layout (specs/ + .specseal/), policy-first judgment, evidence feedback, and review incorporation. Use when: implementing a feature, starting a ticket — including deciding how to start one, incorporating review feedback, or when a repo needs its document layout bootstrapped. NOT for: reviewing someone else's code (use `code-review`), or explaining how something already works. The line is whether the question names a work item to be built: "how should I approach TICKET-4" is this skill, "how does the review chain work" is not.

legacy-parity

Behavior-equivalence methodology for legacy migrations: three-way judgment (policy ↔ original code ↔ new code) with original-preservation as the default. Use when: a project declares a migration config (.specseal/parity.md), porting or reviewing ported behavior, judging divergence from a legacy original. NOT for: greenfield work — implement/code-review alone cover that.

verify

Evidence protocol for completion claims (the Seal Test): name the proving command before running it, show the check can fail, bind the result to a tree state, and label every claim executed / read / unverified. Use when: about to say done, fixed, passes, or complete; before a commit; before handing work to the review chain. NOT for: deciding whether the work is worth doing, or reviewing someone else's diff (`code-review`).

writing-style

Prose and structure rules for review comments, PR bodies, and reports. Structure rules are language-agnostic; sentence rules are per-language (Korean and English sections — they are independent norms, not mirrors). Use when: writing a review comment, PR body, investigation report, or a reply to another team. NOT for: code comments/docstrings, branch/commit format.

audit

Validate project-specific rules a linter cannot express, declared as `.claude/audit-rules/*.md`. Use when: checking conventions this repo wrote down for itself before a commit or release. NOT for: formatting or style a linter already enforces, security review (`security-audit`), or comparing a spec against the code (`gap-analysis`).

build-fix

Resolve build, compile, and type-check errors at their cause instead of suppressing them. Use when: the build does not produce output — type errors, missing modules, syntax or config failures. NOT for: code that compiles but behaves wrong (that is `debug`).

checkpoint

Establish a rollback point before an operation that is hard to undo, and get explicit approval with the blast radius stated. Use when: deleting files, migrating schemas, renaming across the codebase, or changing a core abstraction — where reverting later is not just a git command. NOT for: ordinary refactors that a commit already makes reversible.

debug

Find the cause of wrong behavior: reproduce, locate, one hypothesis at a time, then a failing test before the fix. Use when: the code runs but produces the wrong result, or a test fails. NOT for: build, compile, or type-check errors — nothing runs there, so there is nothing to reproduce (that is `build-fix`).

feature-planner

Decompose work into ordered tasks with dependencies mapped, then lock scope in writing before starting. Use when: the work spans more than about three files or needs phasing, and no plan exists yet. NOT for: firing on your own while the smith is driving — its design gate invokes this when decomposition is what the work needs. Not for single-file changes.

learn

Record an insight that cost real debugging effort and cannot be recovered from a search — project-specific causes, dependency quirks, the reason behind an architectural choice. Use when: something was just figured out the hard way and the next session would otherwise pay for it again. NOT for: narrating ordinary work, anything a search answers in five minutes, or facts the code and git history already carry.