omk-coding

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