New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Omk Coding

by KaimingWan in KaimingWan/oh-my-kiro

Enforces coding best practices: deep-read before modify, LSP-first navigation, TDD red-green-refactor, minimal changes, self-review, verification.

MITAuto-check passedDevelopment

Install Omk Coding

skills CLI
$ npx skills add KaimingWan/oh-my-kiro --skill omk-coding -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install KaimingWan/oh-my-kiro omk-coding --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/KaimingWan/oh-my-kiro.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/omk-coding .claude/skills/omk-coding && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
omk-coding
GitHub stars
107
Token cost
~2.4k tokens
SKILL.md length
687 words
Files
1
Skills in repo
15
Repo updated
First seen
Licence
MIT

At a glance

Enforces coding best practices: deep-read before modify, LSP-first navigation, TDD red-green-refactor, minimal changes, self-review, verification.

  • Works in 8 steps: Environment Setup → 5: Deep Read — Build Understanding… → Understand Before Changing → …
  • Modifying source files
  • SKILL.md covers Trigger Examples, Overview, Phase 0: Environment Setup and Phase 0.5: Deep Read — Build…, plus 9 more sections
  • Calls git and mvn

What it does

Omk Coding is an agent skill from KaimingWan/oh-my-kiro. Enforces coding best practices: deep-read before modify, LSP-first navigation, TDD red-green-refactor, minimal changes, self-review, verification. Trigger when writing code, modifying source files, fixing bugs, refactoring, optimizing code, entering a worktree or submodule, or when user says 'write code', 'implement', 'fix this', 'fix PR', 'add feature', 'add field', 'refactor', 'optimize', 'modify', 'change this', 'update code', 'apply feedback', 'apply review', '改代码', '修复', '加个', '改一下', '优化'. Also trigger when…

Its SKILL.md is about 2.4k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Test-driven development, React components and Refactoring. It works with Vue.js and Java. The licence is MIT.

When your agent uses it

  • Modifying source files
  • Optimizing code
  • Entering a worktree
  • User says write code

Example prompts

  • “write code”
  • “implement”
  • “fix this”
  • “/omk-coding”

Requirements

  • Python 3

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Environment Setup
  2. 5: Deep Read — Build Understanding (MANDATORY)
  3. Understand Before Changing
  4. Write Code (TDD)
  5. Self-Verify
  6. Self-Review
  7. 5: Self-Explanation
  8. Commit

What it can do on your machine

Read from SKILL.md and the folder at commit ba228be. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • mvn

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Omk Coding loads about 2.4k tokens when it runs. Until then it costs about 169 tokens; SKILL.md has 687 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~169
When it runs · the whole SKILL.md, loaded when a task matches
~2.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from KaimingWan/oh-my-kiro at commit ba228be, republished under its MIT licence (© KaimingWan). 687 words, ~2,440 tokens.

Download SKILL.mdSave it as .claude/skills/omk-coding/SKILL.md (or your agent's skills folder).
name
omk-coding
description
Enforces coding best practices: deep-read before modify, LSP-first navigation, TDD red-green-refactor, minimal changes, self-review, verification. Trigger when writing code, modifying source files, fixing bugs, refactoring, optimizing code, entering a worktree or submodule, or when user says 'write code', 'implement', 'fix this', 'fix PR', 'add feature', 'add field', 'refactor', 'optimize', 'modify', 'change this', 'update code', 'apply feedback', 'apply review', '改代码', '修复', '加个', '改一下', '优化'. Also trigger when creating/editing .java .py .ts .js .go .rs .sh .tsx .jsx .vue .css .scss files, or after debugging identifies root cause and implementation begins.

Coding — Write Code Right

Trigger Examples

  • "帮我实现这个功能"
  • "fix this bug in the auth module"
  • "重构一下这段代码"
  • "修复 PR review 发现的问题"
  • "改一下这个 hook 的逻辑"
  • "apply the review feedback"
  • "优化这段代码的性能"
  • "加个字段到这个 model 里"

Overview

Writing code without discipline creates debt. This skill enforces quality at the point of creation.

Core principle: Every code change must be minimal, tested, verified, and self-reviewed before claiming done.

Phase 0: Environment Setup

Before writing any code in a worktree or submodule:

1. Initialize LSP for semantic analysis:
   /code init

2. Get project overview:
   generate_codebase_overview

3. Detect language & build system:
   - Java → find pom.xml / build.gradle → note test command (mvn test / gradle test)
   - TypeScript/JS → find package.json → note test command (npm test / vitest / jest)
   - Python → find pyproject.toml / pytest.ini → note test command (pytest)
   - Rust → Cargo.toml → cargo test
   - Go → go test ./...

4. Run existing tests to establish baseline:
   <detected test command>
   Record: N tests, M passing, K failing

If LSP init fails: Retry with /code init -f. If still fails, log to plan Errors and continue with grep fallback — but note degraded analysis quality.

Phase 0.5: Deep Read — Build Understanding (MANDATORY)

This phase is NOT optional. Even for "simple" changes, you MUST complete it before writing any code. Research shows: the most expensive failure mode is code that is "correct in isolation but breaks the surrounding system" (Boris Tane). Agents only explore dependencies 42% of the time when left to decide on their own (CodeCompass). This phase forces the other 58%.

1. goto_definition — navigate to the code you'll change, read it deeply (not skim)

2. find_references — map ALL callers and dependents of the symbols you'll modify
   Output: list of files and functions that call/use the target code

3. get_document_symbols — understand the internal structure of files you'll modify
   Output: key types, functions, constants in each file

4. Read adjacent code — other files in the same module/package
   Look for: naming conventions, error handling patterns, test patterns, shared utilities

5. get_diagnostics — record current state (zero new errors allowed after your change)

6. Synthesize a Codebase Understanding summary (output this explicitly):

   Codebase Understanding:
   - Module role: [what this module does in the system]
   - File structure: [key symbols in the files you'll modify]
   - Callers: [who calls the code you'll modify]
   - Dependencies: [what the target code depends on]
   - Conventions: [code style, naming, error handling patterns]
   - Impact scope: [which other files/modules could be affected by your change]

7. Signal completion:
   touch /tmp/omk-coding-deep-read-done

If you cannot answer any field in the Codebase Understanding summary, you haven't read enough code. Go back and read more before proceeding.

Phase 1: Understand Before Changing

Before modifying any file, confirm you completed Phase 0.5 and that your Codebase Understanding covers the target code.

Rules (Iron Rules — no exceptions):

  • No modify without goto_definition
  • No refactor without find_references
  • No new public API without searching for existing similar abstractions
  • Match existing code style — don't introduce new conventions

Phase 2: Write Code (TDD)

Red → Green → Refactor
Step 1: Write failing test FIRST
  - Test names: methodName_condition_expectedResult
  - One behavior per test
  - Run test → must FAIL (red)

Step 2: Write minimal implementation
  - Solve ONLY what the test requires
  - No speculative features (YAGNI)
  - No premature abstraction

Step 3: Run test → must PASS (green)

Step 4: Refactor if needed
  - Extract only when duplication is real (not imagined)
  - Run tests again → still PASS
Minimal Change Rules
RuleCheck
Single responsibilityDoes this change do exactly one thing?
Minimal diffCan any line be removed without breaking the goal?
No drive-by fixesUnrelated improvements go in separate commits
No new dependenciesUnless essential and approved
Backward compatibleExisting callers unaffected unless explicitly intended
Match existing styleFollow the conventions of the surrounding code, not your ideal. If the codebase is 85/100, write 85–90/100 code — don't chase 100
Don't "fix" old codeExisting code works. Don't refactor, restyle, or "improve" code outside your change scope. If you see a real problem, file it separately
Code Quality Gates
  • Methods ≤ 20 lines (split when longer)
  • No boolean flag parameters — split into two methods
  • No swallowed exceptions — catch must log or rethrow
  • Return empty collections, not null
  • Use self-documenting names — comments explain WHY, not WHAT
  • Depend on interfaces, not concrete implementations

Phase 3: Self-Verify

After implementation, before claiming done:

1. Run full test suite (not just new tests):
   <project test command>
   → Must show 0 new failures

2. Run linter/compiler:
   get_diagnostics on all modified files
   → Must show 0 new errors/warnings

3. Check diff scope:
   git diff --stat
   → Every changed file must be intentional

4. Regression check:
   - New test passes? → Revert your fix → test must FAIL → restore fix
   - This proves the test actually tests your change
Show full SKILL.md (284 more words)Show less
Frontend Visual Verification (when UI files changed)

If any modified file is a frontend file (.tsx/.jsx/.vue/.html/.css/.scss), you MUST verify visually:

1. Ensure dev server is running (check with curl or ps)
2. Use agent-browser to screenshot the affected page:
   agent-browser open http://localhost:<port>/<path> && agent-browser wait --load networkidle && agent-browser screenshot --annotate
3. Review the screenshot — does it match the expected behavior?
4. If the visual result is wrong, fix and re-verify. Do NOT claim done without visual confirmation.
5. For style/layout issues, use agent-browser snapshot -i to inspect element structure

CRITICAL: Never claim a frontend issue is "fixed" based only on code changes. The browser is the source of truth.

Phase 4: Self-Review

Before committing, review your own diff:

1. git diff (staged or unstaged)

2. For each changed file, check:
   □ SRP — one reason to change?
   □ No dead code introduced
   □ Error paths handled (what if this fails?)
   □ Boundary conditions (null, empty, zero, max)
   □ No hardcoded values — use constants/config
   □ Thread safety (if concurrent context)

3. Ask yourself:
   - "What breaks if I revert this?"
   - "What breaks if input is unexpected?"
   - "Would a new team member understand this?"

If any check fails: Fix before committing. Don't leave TODOs for "later."

Phase 4.5: Self-Explanation

After self-review, explain your changes in natural language before committing:

1. What did I change and why?
2. How do my changes interact with the callers/dependencies identified in Phase 0.5 (Codebase Understanding)?
3. Are there potential side effects on other modules?

If you discover a logical contradiction while explaining → go back to Phase 2 and revisit the implementation. The act of explaining often reveals errors that code review misses (Self-Debugging research: explanation outperforms chain-of-thought for error detection).

Phase 5: Commit

bash
# Verify one last time
<test command>

# Commit with descriptive message
git add -p  # stage intentionally, not git add .
git commit -m "<type>: <what changed and why>"

Commit message types: feat, fix, refactor, test, docs, chore

Language-Specific Addenda

Java
  • Load knowledge/reference/java-coding-standards.md when touching .java files
  • After interface changes: mvn compile -pl <module> -am
  • After all changes: mvn clean test
  • Prefer constructor injection over @Autowired
TypeScript/JavaScript
  • Strict mode, no any unless justified
  • Prefer const over let, never var
  • Handle async errors — no unhandled promise rejections
Python
  • Type hints on all public functions
  • pytest with -v flag for visibility
  • No bare except: — always specify exception type

When to Apply

Always when:

  • Creating new files in a worktree/submodule
  • Modifying existing code
  • Fixing bugs (TDD: write failing test reproducing bug first)
  • Refactoring

Skip Phase 2 (TDD) only when:

  • Pure documentation changes
  • Config-only changes (but still verify)
  • User explicitly says "skip tests"

Anti-patterns

Don'tDo Instead
Write code then "add tests later"Test first, always
git add .git add -p — stage intentionally
Fix + unrelated cleanup in one commitSeparate commits
Trust "it should work"Run and see output
Copy-paste without understandingRead source, then adapt
Add abstraction "for future use"Solve today's problem

© KaimingWan, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/omk-coding of KaimingWan/oh-my-kiro.

Open the folder on GitHubat commit ba228be

Compare with similar skills

Omk Coding next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Omk Coding compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Omk Coding this skillKaimingWan/oh-my-kiro107—~2.4kAutomated safety check: PassMIT
Ij Debuggerxpinjection/test-driven-spring-boot112—~6.4kAutomated safety check: PassMIT
React Refactor Tournamentragnar-pwninskjold/tech-snacks136—~1.3kAutomated safety check: PassMIT
Tsh Writing HooksTheSoftwareHouse/copilot-collections284—~3kAutomated safety check: PassMIT
Test Coveragescott-fryxell/brayness124—~1.6kAutomated safety check: PassMIT
Tailwindcss Developmentanonaddy/anonaddy4.9k10 repos~865Automated safety check: PassMIT

Similar skills

  • Ij Debugger

    xpinjection/test-driven-spring-boot

    Debugger-first runtime root-cause analysis for JVM code in IntelliJ IDEA.

    112 GitHub stars~6.4k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

  • React Refactor Tournament

    ragnar-pwninskjold/tech-snacks

    Review React/Next.js code against the real vercel-react-best-practices skill, backlog the performance findings keyed to actual rule ids + impact tiers, rank the most over-subscribed tiers, then fix…

    136 GitHub stars~1.3k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

  • Tsh Writing Hooks

    TheSoftwareHouse/copilot-collections

    Custom hook and composable patterns — naming, composition, stable return shapes, lifecycle cleanup, and testing strategies.

    284 GitHub stars~3k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • Test Coverage

    scott-fryxell/brayness

    Write Vitest specs for Vue 3 JavaScript (Vite Plus, happy-dom, @vue/test-utils) and analyze V8 coverage + Fallow health to prioritize test-first refactors.

    124 GitHub stars~1.6k tokensUpdated 9 days ago
    Testing & QAAuto-check passed

  • Tailwindcss Development

    anonaddy/anonaddy

    Always invoke when the user's message includes 'tailwind' in any form.

    4.9k GitHub starsUsed in 10 repos~865 tokens
    Frontend & DesignAuto-check passed

  • Component Refactoring

    langflow-ai/langflow

    Refactor high-complexity React components in Langflow frontend.

    156k GitHub stars~3.5k tokensUpdated today
    DevelopmentAuto-check passed

More from KaimingWan/oh-my-kiro

All 15 skills in this repo

  • Omk Research

    KaimingWan/oh-my-kiro

    Multi-level research: built-in knowledge → web search → Tavily deep research API.

    107 GitHub stars~827 tokensUpdated 6 mo ago
    Auto-check passed

  • Omk Reviewing

    KaimingWan/oh-my-kiro

    Code and plan review with multi-angle dispatch. An agent skill from KaimingWan/oh-my-kiro.

    107 GitHub stars~1.9k tokensUpdated 6 mo ago
    Auto-check passed

  • Omk Skill Creation

    KaimingWan/oh-my-kiro

    Create high-quality, production-ready skills from scratch. An agent skill from KaimingWan/oh-my-kiro.

    107 GitHub stars~2k tokensUpdated 6 mo ago
    Auto-check passed

  • Omk Youtube

    KaimingWan/oh-my-kiro

    Extract and summarize YouTube video content via subtitle extraction.

    107 GitHub stars~381 tokensUpdated 6 mo ago
    Auto-check passed

  • Documentation Lookup

    KaimingWan/oh-my-kiro

    Fetch current library/framework documentation via Context7. An agent skill from KaimingWan/oh-my-kiro.

    107 GitHub stars~616 tokensUpdated 6 mo ago
    Auto-check passed

  • Omk Debugging

    KaimingWan/oh-my-kiro

    Systematic debugging: reproduce → hypothesize → verify → fix.

    107 GitHub stars~4.7k tokensUpdated 6 mo ago
    Auto-check passed

Works with

Categories

Questions about Omk Coding

What does Omk Coding do?

Enforces coding best practices: deep-read before modify, LSP-first navigation, TDD red-green-refactor, minimal changes, self-review, verification. Omk Coding is an agent skill from KaimingWan/oh-my-kiro. Enforces coding best practices: deep-read before modify, LSP-first navigation, TDD red-green-refactor, minimal changes, self-review, verification.

When should I use Omk Coding?

Omk Coding fits situations like: modifying source files; optimizing code; entering a worktree; user says write code.

How do I install Omk Coding in Claude Code?

Run `npx skills add KaimingWan/oh-my-kiro --skill omk-coding -a claude-code`. Or copy the skill folder (skills/omk-coding in KaimingWan/oh-my-kiro) into .claude/skills/omk-coding in your project. Claude Code loads it when a task matches its description.

How do I install Omk Coding in Codex?

Run `npx skills add KaimingWan/oh-my-kiro --skill omk-coding -a codex`. Or copy the skill folder (skills/omk-coding in KaimingWan/oh-my-kiro) into .agents/skills/omk-coding in your project. Codex loads it when a task matches its description.

Can I use Omk Coding in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add KaimingWan/oh-my-kiro --skill omk-coding -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/omk-coding, .gemini/skills/omk-coding, .github/skills/omk-coding and .opencode/skills/omk-coding in your project.

What does Omk Coding need to run?

Going by SKILL.md and its folder, Omk Coding needs the command-line tools its instructions call (git and mvn). Our summary lists: Python 3.

Does Omk Coding access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Omk Coding safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Omk Coding use?

Omk Coding is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Omk Coding use?

About 2.4k tokens (SKILL.md is roughly 9.8k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Omk Coding?

Skills that share tags, products or a category with Omk Coding: Ij Debugger (xpinjection/test-driven-spring-boot, 112 stars), React Refactor Tournament (ragnar-pwninskjold/tech-snacks, 136 stars), Tsh Writing Hooks (TheSoftwareHouse/copilot-collections, 284 stars) and Test Coverage (scott-fryxell/brayness, 124 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Omk Coding?

KaimingWan (a GitHub user) maintains it in KaimingWan/oh-my-kiro, which has 107 GitHub stars. The repository holds 15 skills in this directory. The repository was last updated on April 2, 2026.

Source: KaimingWan/oh-my-kiro on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.