사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/riekelt/principal-engineer --skill grounding-before-coding시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Grounding before coding
REQUIRED BACKGROUND: the principal-engineering skill.
Overview
Before writing a spec, a fix, or a first line: map the real code and data. Quote file:line and run the query behind every number you rely on.
The discipline
- Read the implementations, not the names. A method called
validatethat does not validate is the default assumption. Verify what a thing does before building on what it is called. - Quote your evidence. Every load-bearing claim in your plan gets a
file:line, an exact query result, or a command output. When you cannot back a claim, say so out loud instead of assuming it. - Never guess conventions. How this repo names things, wires dependencies, handles errors, or runs tests is discoverable in minutes.
- Trust code, not status. A document's or ticket's self-reported state is not evidence of execution state; adjudicate with the code and the history (
git log -S <symbol>, grep the tree) before building on it. - Reproduce before fixing. For bugs: see the failure happen before changing anything.
- Fix where the callers converge. A bug report names one symptom on one path; before editing, find every route into the code you are about to touch. When the defect lives in something shared, the guard belongs in the shared place: it is the smaller diff AND the fix that covers the sibling paths the ticket never mentioned. Patching only the reported path repairs the report, not the bug.
- Map the invariants a change must not break. The output of grounding is a map: the touchpoints, the current behavior (quoted), and those invariants. Tests named after old bugs, guards with explanatory comments, and constants encoding hard-won thresholds mark earlier incidents.
Limits of grounding
- Not reading everything: map what the change touches plus one ring around it, at the depth the risk demands.
- Not a substitute for asking: when the code cannot answer an intent question (why is this threshold 7?), the history or the owner can. An unanswerable question becomes a named assumption, never a silent one.
- Not re-grounding what this session already established: ground once, cite it after.
Common mistakes
- Theorizing from the framework's documentation about what the project's code does. The project forked, wrapped, or misused the framework; the tree tells you which.
- Grounding the happy path only. The invariants live in the error paths and the edge-case guards.
- Trusting a prior session's summary of the code over the code. Open the files the summary names before building on it.
- Skipping grounding because the task "looks like" a previous one. The signal that pattern-matches a known case may have a different cause; check that the evidence supports this case.
