kaimingwan/oh-my-kiro/omk-coding

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

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

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

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

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

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

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?

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