메뉴
MUST load when the user asks to check code health, run codehealth, refactor for codehealth, run a pre-commit codehealth check, or assess code quality of pending/branch changes. Enforces a per-file 10.0 verification — passing CodeScene quality gates alone is NOT sufficient.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | easi-codehealth |
| description | MUST load when the user asks to check code health, run codehealth, refactor for codehealth, run a pre-commit codehealth check, or assess code quality of pending/branch changes. Enforces a per-file 10.0 verification — passing CodeScene quality gates alone is NOT sufficient. |
| compatibility | opencode |
Every modified and untracked file in the pending change set must:
mcp__codescene__code_health_score, or be explicitly justified as inherent.quality_gates: passed is necessary but not sufficient. A 10.0 score is necessary but not sufficient. Both are required.
Run in order. Do not skip steps. Do not check for previous code health before asserting and fixing. It does not matter WHEN the bad code was introduced.
From git status: modified (M) and untracked (??). Test files (*_test.go, *.test.ts, *.test.tsx) count.
Call mcp__codescene__code_health_score per file, in parallel. Build a file → score table.
Each file under 10.0 is one of:
backend/docs/docs.go, frontend/openapi.json.Apply the refactor. Re-run tests touching that file (go test ./... or npm test -- --run <pattern>) before re-scoring.
If a refactor worsens readability, cohesion, or domain fit (one-caller helpers created only to dodge a metric; splitting intentionally-parallel switches; renaming for the metric not for intent) — revert it. Find a better refactor or mark inherent with reasoning.
Re-read the full diff and the surrounding code. For every changed file, walk this checklist and act on every issue found:
data, info, process, handle, manager, helper, util, bare boolean flag. Function names match what they do.a.b.c.d). Data fetched at the right layer.string that is an OrderId; map[string]any that is a typed payload). No anaemic structs that should hold behavior. No domain rules in handlers, no presentation in domain.%w in Go). Errors handled at the right layer. Typed errors over panic/throw. Query/error states surfaced in the UI.// what this does comment is a refactor signal.easi-architecture-canvas, easi-go-backend-patterns, easi-frontend-data, easi-frontend-styling, easi-api-standards.After fixing, re-run tests and re-score. Issues you choose not to fix go in the report with reasoning.
Re-score every refactored file.
| Excuse | Rule |
|---|---|
| "Quality gates passed, we're done" | Score every file. |
| "It's only test code" | Test files are scored the same way. |
| "It was already that score" | "Pre-existing" is not "inherent". Fix it or justify deferral by name. |
| "Refactoring it would be a larger change" | Call it out explicitly with that reasoning. |
| "The score only dropped from 9.4 to 9.3" | Below 10.0 is below 10.0. |
| "The drift is microscopic" | If the branch made it worse, fix it. |
| "All files are at 10.0, so the review is done" | Run the Step 6 pass. |
| "CodeScene didn't flag it" | Step 6 covers what CodeScene cannot see. |
| "Extracting this helper got the score to 10.0" | One-caller helpers created only to dodge a metric: revert. |
| "Tests still pass after the refactor" | Verify the public contract; tests may be locking in implementation. |
No further justification needed:
backend/docs/docs.go — Swaggo-generated; regenerated via make swagger.frontend/openapi.json — generated from backend OpenAPI spec.All other files require written justification.
Per-file score table, gate verdict, inherent list, and Step 6 review summary. No success claim without all four.
MUST load when building a feature contract-first or frontend-before-backend in EASI — designing an API contract before code, mocking that contract, building a runnable frontend against the mock, then implementing the backend to the same contract. Load whenever you hear "frontend first", "stub/mock the API", "contract first".
MUST load when UI/frontend changes are completed, to verify functionality by running the app in a browser.
MUST load when writing or reviewing any UI component, dialog, form, button, layout, or styling in the EASI frontend. Load when picking a UI primitive, deciding how to lay out a component, when you would otherwise reach for `style={{}}` or a bare HTML element, or when adding any visual chrome. The single UI vocabulary in EASI is Mantine v8 — this skill enforces it.
MUST load when creating, updating, or reviewing any documentation in EASI — docs/, architecture canvases, READMEs, INDEX files, or pattern guides. Load when adding a new bounded context canvas, writing a pattern guide, restructuring docs, or reviewing existing documentation for bloat.
MUST load after completing a feature, bug fix, or any behavior-changing implementation, before declaring the work done. A deliberate cleanup pass over the affected area — files you modified AND files you read while doing the work — so the code is measurably better than you found it. Distinct from `easi-codehealth`: codehealth scores the change set; boyscouting decides what additional structural cleanups belong in this branch.
Load when implementing new features. Model software around the business domain. Use when designing bounded contexts, defining aggregates and value objects, mapping context relationships, or working with complex business logic. Apply before implementation to prevent model drift.